Samme iESI innenfor ett site, unik på tvers av sites: Junos-sying

To gateway-par betjener to datasentre, og noen må avgjøre hvor mange interconnect-ESI-verdier designet trenger. Svaret er én per gateway-gruppe, ikke én per fabric og ikke én per gateway. Gjør man det feil, får man et fabric som ser konfigurert ut og velger feil forwarder, eller slår sammen to sites som skulle holdes atskilt. Regelen og unntakene er verdt å skrive ned ved siden av gateway-listen.

To omfang, to regler

Innenfor et site opptrer de redundante interconnect-gatewayene som ett multihomed-endepunkt, så de deler én interconnect-ESI. Peersene deres må se ett logisk medlem i stedet for to uavhengige. Det er hele poenget med den delte verdien.

Mellom sites får hver gateway-gruppe sin egen verdi. To datasentre som deler en identifikator blir én multihomed-gruppe i kontrollplanet, noe som vanligvis ikke er det et syingsdesign over et WAN tar sikte på. To sites i én gruppe arver også hverandres feilmodi.

Innenfor et site: én identitet for gruppen

Gi paret samme verdi på begge peers, i samme tjenestekontekst, og registrer den i nettets identifikatorinventar i stedet for i en chat-tråd. Avvik mellom de to medlemmene er feilmodusen som gir en gruppe på én og ingen tydelig alarm. Sammenlign begge medlemmene før du tror på en fungerende sesjon.

Den støttede modellen er all-active. Samme referanse utelukker single-active drift, automatisk utledede LACP-identifikatorer og source-bmac-alternativer for denne syingsidentiteten, så et design som antok ett av disse, må revideres før identifikatoren i det hele tatt velges. Den begrensningen er et designinput, ikke en fotnote.

På tvers av sites: forskjellige verdier eller en bevisst sammenslåing

En unik verdi per site holder de to gateway-gruppene atskilt. Hvis hensikten virkelig er å utvide én multihomed-gruppe på tvers av sites, er det en annen arkitektur med egne konsekvenser for latens, feil og videresending, og den bør besluttes som en arkitektur og ikke som et identifikatorvalg. Be om den beslutningen skriftlig før vedlikeholdsvinduet.

Skriv den tiltenkte forskjellen inn i planen, slik at en senere ingeniør som kopierer en fungerende site-mal, ikke importerer identifikatoren med.

Peer-uttalelsen er en del av identiteten

Hver gateway i gruppen lister sine lokale peers etter loopback-adresse, og det forholdet lever på globalt EVPN-nivå i stedet for inne i en individuell MAC-VRF. Å plassere det i feil hierarki er en vanlig måte å lage en konfigurasjon som committer, men aldri danner gruppen. Les referansehierarkiet én gang, og hold deg til det.

Navnet på uttalelsen flyttet også. Juniper endret navnet på interconnect peer-gateways-uttalelsen i 24.2R1 og gjenopprettet den interconnect-spesifikke formen for datasenter-interconnect i 24.4R1. En utdrag tatt fra mellomutgivelsen kan derfor bruke et navn den utrullede versjonen ikke godtar, eller omvendt. Noter utgivelsen utdraget kommer fra, ved siden av selve utdraget.

Hva deling av en iESI ikke gjør

Den definerer ikke route targets, VNI-er eller den lokale EVPN-forekomsten for deg. De forblir separat konfigurasjon som må stemme på begge sider, og en identifikator som stemmer mens en route target ikke gjør det, gir en gruppe som dannes og ikke bærer noe. Sammenlign begge sider av disse innstillingene i samme gjennomgang.

Den beviser heller ikke peer-nåbarhet eller valg av designated forwarder. Test unicast og den påkrevde broadcast- og multicast-oppførselen i normaltilfellet, og gjenta deretter med én gateway fjernet, slik at det overlevende medlemmet bærer gruppen alene.

Det er den andre kjøringen som beviser at gruppen er reell.

Ta vare på det observerte medlemskapet og tjenestekonteksten sammen med testresultatene. En senere identifikatorendring kan da gjennomgås som en multihoming-endring, som den er, i stedet for som en kosmetisk retting av en streng. Resultatene er det eneste beviset for at identifikatoren gjør det tegningen sier.