Rovnaké iESI v rámci lokality, jedinečné medzi lokalitami: prešívanie Junos

Dva páry brán obsluhujú dve dátové centrá a niekto musí rozhodnúť, koľko hodnôt interconnect ESI návrh potrebuje. Odpoveď je jedna na skupinu brán, nie jedna na fabric a nie jedna na bránu. Chyba tu vytvorí fabric, ktorý vyzerá nakonfigurovaný a volí nesprávny forwarder, alebo zlúči dve lokality, ktoré mali zostať oddelené. Pravidlo a jeho výnimky stojí za to zapísať vedľa zoznamu brán.

Dva rozsahy, dve pravidlá

V rámci lokality vystupujú redundantné interconnect brány ako jeden multihomed koncový bod, takže zdieľajú jediné interconnect ESI. Ich peery musia vidieť jedného logického člena namiesto dvoch nezávislých. V tom je celý zmysel zdieľanej hodnoty.

Medzi lokalitami dostáva každá skupina brán svoju vlastnú hodnotu. Dve dátové centrá, ktoré zdieľajú identifikátor, sa v riadiacej rovine stanú jednou multihomed skupinou, čo zvyčajne nie je to, čo návrh prešívania cez WAN zamýšľa. Dve lokality v jednej skupine tiež dedia poruchové režimy tej druhej.

V rámci lokality: jedna identita pre skupinu

Dajte páru rovnakú hodnotu na oboch peer-och, v tom istom kontexte služby, a zaznamenajte ju do inventára identifikátorov siete, nie do chatu. Nezhoda medzi dvoma členmi je poruchový režim, ktorý vytvorí skupinu o jednom členovi a bez zjavného alarmu. Porovnajte oboch členov, kým uveríte fungujúcej relácii.

Podporovaný model je all-active. Rovnaká referencia vylučuje prevádzku single-active, automaticky odvodené identifikátory LACP a volby source-bmac pre túto identitu prešívania, takže návrh, ktorý predpokladal jedno z toho, treba preskúmať ešte pred voľbou identifikátora. Toto obmedzenie je vstupom návrhu, nie poznámkou pod čiarou.

Medzi lokalitami: rôzne hodnoty alebo úmyselné zlúčenie

Jedinečná hodnota na lokalitu udržiava obe skupiny brán oddelené. Ak je zámerom skutočne rozšíriť jednu multihomed skupinu medzi lokalitami, je to iná architektúra s vlastnými dôsledkami pre latenciu, poruchy a preposielanie, a malo by sa o nej rozhodovať ako o architektúre, nie ako o voľbe identifikátora. Vyžiadajte si to rozhodnutie písomne pred servisným oknom.

Zapíšte zamýšľaný rozdiel do plánu, aby neskorší inžinier kopírujúci fungujúcu šablónu lokality neprevzal aj jej identifikátor.

Peer príkaz je súčasťou identity

Každá brána v skupine vypisuje svoje lokálne peery podľa loopback adresy a tento vzťah žije na globálnej úrovni EVPN, nie vnútri jednotlivého MAC-VRF. Umiestnenie do nesprávnej hierarchie je bežný spôsob, ako vytvoriť konfiguráciu, ktorá sa commitne, ale skupinu nikdy nevytvorí. Prečítajte si referenčnú hierarchiu raz a potom sa jej držte.

Presunul sa aj názov príkazu. Juniper v 24.2R1 premenoval príkaz interconnect peer-gateways a v 24.4R1 obnovil podobu špecifickú pre interconnect dátových centier. Úryvok z medzivydania tak môže používať názov, ktorý nasadená verzia neprijíma, alebo naopak. Zapíšte vydanie, z ktorého úryvok pochádza, vedľa samotného úryvku.

Čo zdieľanie iESI nerobí

Nedefinuje za vás route targets, VNI ani miestnu inštanciu EVPN. Tie zostávajú samostatnou konfiguráciou, ktorá musí súhlasiť na oboch stranách, a identifikátor, ktorý sedí, kým route target nie, vytvorí skupinu, ktorá sa vytvorí, ale nič neprenáša. Porovnajte obe strany týchto nastavení v jednom prechode.

Nedokazuje ani dostupnosť peerov, ani voľbu designated forwarder. Otestujte unicast a požadované správanie broadcastu a multicastu v bežnom prípade a potom to zopakujte s odobranou jednou bránou, aby zostávajúci člen niesol skupinu sám.

Práve druhý beh dokazuje, že skupina je skutočná.

Uchovajte pozorované členstvo a kontext služby spolu s výsledkami testov. Neskoršiu zmenu identifikátora potom možno posudzovať ako zmenu multihomingu, čím aj je, a nie ako kozmetickú úpravu reťazca. Výsledky sú jediným dôkazom, že identifikátor robí to, čo hovorí nákres.