Stejné iESI uvnitř lokality, jedinečné mezi lokalitami: propojení Junos

Dva páry bran obsluhují dvě datová centra a někdo musí rozhodnout, kolik hodnot interconnect ESI návrh potřebuje. Odpověď je jedna na skupinu bran, ne jedna na fabric a ne jedna na bránu. Chyba zde vytvoří fabric, který vypadá nakonfigurovaný a volí špatný forwarder, nebo sloučí dvě lokality, které měly zůstat oddělené. Pravidlo a jeho výjimky stojí za to zapsat vedle seznamu bran.

Dva rozsahy, dvě pravidla

Uvnitř lokality vystupují redundantní interconnect brány jako jeden multihomed koncový bod, takže sdílejí jediné interconnect ESI. Jejich peerové musí vidět jednoho logického člena místo dvou nezávislých. V tom je celý smysl sdílené hodnoty.

Mezi lokalitami dostává každá skupina bran svou vlastní hodnotu. Dvě datová centra, která sdílejí identifikátor, se v řídicí rovině stanou jednou multihomed skupinou, což obvykle není to, co návrh propojení přes WAN zamýšlí. Dvě lokality v jedné skupině také dědí poruchové režimy té druhé.

Uvnitř lokality: jedna identita pro skupinu

Dejte páru stejnou hodnotu na obou peerech, ve stejném kontextu služby, a zaznamenejte ji do inventáře identifikátorů sítě, ne do chatu. Neshoda mezi dvěma členy je poruchový režim, který vytvoří skupinu o jednom členu a bez zjevného alarmu. Porovnejte oba členy, než uvěříte funkční relaci.

Podporovaný model je all-active. Stejná referenční příručka vylučuje single-active provoz, automaticky odvozené identifikátory LACP a volby source-bmac pro tuto identitu propojení, takže návrh, který předpokládal jedno z toho, je třeba přezkoumat ještě před volbou identifikátoru. Toto omezení je vstupem návrhu, ne poznámkou pod čarou.

Mezi lokalitami: různé hodnoty, nebo úmyslné sloučení

Jedinečná hodnota na lokalitu udržuje obě skupiny bran oddělené. Pokud je záměrem skutečně rozšířit jednu multihomed skupinu mezi lokality, je to jiná architektura s vlastními důsledky pro latenci, poruchy a předávání a mělo by se o ní rozhodovat jako o architektuře, ne jako o volbě identifikátoru. Vyžádejte si to rozhodnutí písemně před servisním oknem.

Zapište zamýšlený rozdíl do plánu, aby pozdější inženýr kopírující funkční šablonu lokality s ní nepřevzal i její identifikátor.

Peer příkaz je součástí identity

Každá brána ve skupině vypisuje své lokální peery podle loopback adresy a tento vztah žije na globální úrovni EVPN, ne uvnitř jednotlivého MAC-VRF. Umístění do špatné hierarchie je běžný způsob, jak vytvořit konfiguraci, která se commitne, ale skupinu nikdy nevytvoří. Přečtěte si referenční hierarchii jednou a pak se jí držte.

Přesunul se i název příkazu. Juniper v 24.2R1 přejmenoval příkaz interconnect peer-gateways a v 24.4R1 obnovil podobu specifickou pro interconnect datových center. Úryvek z mezilehlé verze tak může používat název, který nasazená verze nepřijímá, nebo naopak. Zapište verzi, ze které úryvek pochází, vedle samotného úryvku.

Co sdílení iESI nedělá

Nedefinuje za vás route targets, VNI ani místní instanci EVPN. Ty zůstávají samostatnou konfigurací, která musí souhlasit na obou stranách, a identifikátor, který sedí, zatímco route target ne, vytvoří skupinu, jež se sice vytvoří, ale nic nepřenáší. Porovnejte obě strany těchto nastavení v jednom průchodu.

Nedokazuje ani dostupnost peerů, ani volbu designated forwarder. Otestujte unicast a požadované chování broadcastu a multicastu v běžném případě a poté to zopakujte s odebranou jednou branou, aby zbývající člen nesl skupinu sám.

Právě druhý běh dokazuje, že skupina je skutečná.

Uchovejte pozorované členství a kontext služby spolu s výsledky testů. Pozdější změna identifikátoru se pak dá posuzovat jako změna multihomingu, čímž také je, a ne jako kosmetická úprava řetězce. Výsledky jsou jediným důkazem, že identifikátor dělá to, co říká nákres.