Same iESI innanfor eit site, unik på tvers av sites: Junos-sying

To gateway-par betener to datasenter, og nokon må avgjere kor mange interconnect-ESI-verdiar designet treng. Svaret er éin per gateway-gruppe, ikkje éin per fabric og ikkje éin per gateway. Gjer ein det feil, får ein eit fabric som ser konfigurert ut og vel feil forwarder, eller slår saman to sites som skulle haldast åtskilde. Regelen og unntaka er verd å skrive ned ved sida av gateway-lista.

To omfang, to reglar

Innanfor eit site opptrer dei redundante interconnect-gatewayane som eitt multihomed-endepunkt, så dei deler éin interconnect-ESI. Peerane deira må sjå eitt logisk medlem i staden for to uavhengige. Det er heile poenget med den delte verdien.

Mellom sites får kvar gateway-gruppe sin eigen verdi. To datasenter som deler ein identifikator blir éi multihomed-gruppe i kontrollplanet, noko som vanlegvis ikkje er det eit syingsdesign over eit WAN tek sikte på. To sites i éi gruppe arvar òg kvarandre sine feilmodi.

Innanfor eit site: éin identitet for gruppa

Gje paret same verdi på begge peers, i same tenestekontekst, og registrer han i identifikatorinventaret til nettet i staden for i ein chat-tråd. Avvik mellom dei to medlemmene er feilmodusen som gjev ei gruppe på éin og ingen tydeleg alarm. Samanlikn begge medlemmene før du trur på ein fungerande sesjon.

Den støtta modellen er all-active. Same referanse utelukkar single-active drift, automatisk utleidde LACP-identifikatorar og source-bmac-alternativ for denne syingsidentiteten, så eit design som anteke eitt av desse, må reviderast før identifikatoren i det heile blir vald. Den avgrensinga er eit designinput, ikkje ei fotnote.

På tvers av sites: ulike verdiar eller ei medviten samanslåing

Ein unik verdi per site held dei to gateway-gruppene åtskilde. Viss hensikta verkeleg er å utvide éi multihomed-gruppe på tvers av sites, er det ein annan arkitektur med eigne konsekvensar for latens, feil og vidaresending, og han bør avgjerast som ein arkitektur og ikkje som eit identifikatorval. Be om den avgjerda skriftleg før vedlikehaldsvindauget.

Skriv den tiltenkte skilnaden inn i planen, slik at ein seinare ingeniør som kopierer ein fungerande site-mal, ikkje importerer identifikatoren med.

Peer-uttala er ein del av identiteten

Kvar gateway i gruppa listar dei lokale peerane sine etter loopback-adresse, og det tilhøvet lever på globalt EVPN-nivå i staden for inne i ein individuell MAC-VRF. Å plassere det i feil hierarki er ein vanleg måte å lage ein konfigurasjon som committar, men aldri dannar gruppa. Les referansehierarkiet éin gong, og hald deg til det.

Namnet på uttala flytta òg. Juniper endra namnet på interconnect peer-gateways-uttala i 24.2R1 og gjenoppretta den interconnect-spesifikke forma for datasenter-interconnect i 24.4R1. Eit utdrag teke frå mellomutgivinga kan derfor bruke eit namn den utrulla versjonen ikkje godtar, eller omvendt. Noter utgivinga utdraget kjem frå, ved sida av sjølve utdraget.

Kva deling av ein iESI ikkje gjer

Han definerer ikkje route targets, VNI-ar eller den lokale EVPN-førekomsten for deg. Dei blir verande separat konfigurasjon som må stemme på begge sider, og ein identifikator som stemmer medan ein route target ikkje gjer det, gjev ei gruppe som dannar seg og ikkje ber noko. Samanlikn begge sidene av desse innstillingane i same gjennomgang.

Han beviser heller ikkje peer-nåbarheit eller val av designated forwarder. Test unicast og den påkravde broadcast- og multicast-åferda i normaltilfellet, og gjenta deretter med éin gateway fjerna, slik at det overlevande medlemmet ber gruppa åleine.

Det er den andre køyringa som beviser at gruppa er reell.

Ta vare på det observerte medlemskapet og tenestekonteksten saman med testresultata. Ei seinare identifikatorendring kan då gjennomgåast som ei multihoming-endring, som ho er, i staden for som ei kosmetisk retting av ein streng. Resultata er det einaste beviset for at identifikatoren gjer det teikninga seier.