Samme iESI inden for et site, unik på tværs af sites: Junos-sammenføjning

To gateway-par betjener to datacentre, og nogen skal beslutte, hvor mange interconnect-ESI-værdier designet har brug for. Svaret er én pr. gateway-gruppe, ikke én pr. fabric og ikke én pr. gateway. Gør man det forkert, får man et fabric, der ser konfigureret ud og vælger den forkerte forwarder, eller man sammenlægger to sites, der var ment som adskilte. Reglen og dens undtagelser er værd at skrive ned ved siden af gateway-listen.

To scopes, to regler

Inden for et site optræder de redundante interconnect-gateways som ét multihomed-endepunkt, så de deler én interconnect-ESI. Deres peers skal se ét logisk medlem i stedet for to uafhængige. Det er hele pointen med den fælles værdi.

Mellem sites får hver gateway-gruppe sin egen værdi. To datacentre, der deler en identifikator, bliver én multihomed-gruppe i kontrolplanet, hvilket normalt ikke er, hvad et sammenføjningsdesign over et WAN sigter mod. To sites i én gruppe arver også hinandens fejltilstande.

Inden for et site: én identitet til gruppen

Giv parret den samme værdi på begge peers, i samme servicekontekst, og registrér den i nettets identifikatorinventar i stedet for i en chattråd. Uoverensstemmelse mellem de to medlemmer er den fejltilstand, der giver en gruppe på ét medlem og ingen tydelig alarm. Sammenlign begge medlemmer, før du tror på en fungerende session.

Den understøttede model er all-active. Samme reference udelukker single-active drift, automatisk udledte LACP-identifikatorer og source-bmac-muligheder for denne sammenføjningsidentitet, så et design, der antog en af disse, skal revideres, før identifikatoren overhovedet vælges. Den begrænsning er et designinput, ikke en fodnote.

På tværs af sites: forskellige værdier eller en bevidst sammenlægning

En unik værdi pr. site holder de to gateway-grupper adskilt. Hvis hensigten reelt er at udvide én multihomed-gruppe på tværs af sites, er det en anden arkitektur med sine egne konsekvenser for latenstid, fejl og videresendelse, og det bør besluttes som en arkitektur og ikke som et identifikatorvalg. Bed om den beslutning skriftligt før vedligeholdelsesvinduet.

Skriv den tilsigtede forskel ind i planen, så en senere ingeniør, der kopierer en fungerende site-skabelon, ikke importerer dens identifikator med.

Peer-sætningen er en del af identiteten

Hver gateway i gruppen lister sine lokale peers efter loopback-adresse, og det forhold lever på globalt EVPN-niveau i stedet for inde i en individuel MAC-VRF. At placere det i den forkerte hierarki er en almindelig måde at lave en konfiguration, der committer, men aldrig danner gruppen. Læs referencehierarkiet én gang, og hold dig så til det.

Sætningens navn flyttede også. Juniper omdøbte interconnect peer-gateways-sætningen i 24.2R1 og gendannede den interconnect-specifikke form til datacenter-interconnect i 24.4R1. Et uddrag fra den mellemliggende udgivelse kan derfor bruge et navn, som den udrullede version ikke accepterer, eller omvendt. Notér den udgivelse, uddraget kommer fra, ved siden af selve uddraget.

Hvad deling af en iESI ikke gør

Den definerer ikke route targets, VNI'er eller den lokale EVPN-instans for dig. De forbliver separat konfiguration, som skal stemme på begge sider, og en identifikator, der matcher, mens et route target ikke gør, giver en gruppe, der dannes og ikke bærer noget. Sammenlign begge sider af de indstillinger i samme gennemløb.

Den beviser heller ikke peer-rækkevidde eller valg af designated forwarder. Test unicast og den krævede broadcast- og multicast-adfærd i normaltilfældet, og gentag så med én gateway fjernet, så det overlevende medlem bærer gruppen alene.

Det andet gennemløb er det, der beviser, at gruppen er reel.

Gem det observerede medlemskab og servicekonteksten sammen med testresultaterne. En senere identifikatorændring kan så gennemgås som en multihoming-ændring, hvilket den er, i stedet for som en kosmetisk rettelse af en streng. Resultaterne er det eneste bevis for, at identifikatoren gør, hvad tegningen siger.