Itselde iESI binnen in side, unyk oer siden: Junos-stikwurk

Twa gateway-pearen betsjinje twa datacenters, en immen moat beslute hoefolle interconnect-ESI-wearden it ûntwerp nedich hat. It antwurd is ien per gateway-groep, net ien per fabric en net ien per gateway. Dat ferkeard dwaan leveret in fabric op dat konfigurearre liket en de ferkearde forwarder kiest, of it foeget twa siden gear dy't bedoeld wiene apart te bliuwen. De regel en syn útsûnderingen binne de muoite wurdich njonken de gateway-list delskreaun te wurden.

Twa berikken, twa regels

Binnen in side fungearje de redundante interconnect-gateways as ien multihomed einpunt, sadat se ien interconnect-ESI diele. Har peers moatte ien logysk lid sjogge yn stee fan twa ûnôfhinklike. Dat is it hiele punt fan 'e dielde wearde.

Tusken siden krijt elke gateway-groep syn eigen wearde. Twa datacenters dy't in identifikaasje diele, wurde ien multihomed-groep yn it kontrôleflak, wat net is wat in stikûntwerp oer in WAN ornaris bedoelt. Twa siden yn ien groep ervje ek elkoars faalmodi.

Binnen in side: ien identiteit foar de groep

Jou it pear deselde wearde op beide peers, yn deselde tsjinstkontekst, en registrearje it yn 'e identifikaasje-ynventaris fan it netwurk yn stee fan yn in chat-tried. In mismatch tusken de twa leden is de faalmodus dy't in groep fan ien opsmyt en gjin dúdlik alarm. Fergelykje beide leden foardat jo in wurkjende sesje leauwe.

It stipe model is all-active. Deselde referinsje slút single-active operaasje, automatysk ôflate LACP-identifikaasjes en source-bmac-opsjes foar dizze stikidentiteit út, sadat in ûntwerp dat ien fan dy oannaam, oanpast wurde moat foardat de identifikaasje sels keazen wurdt. Dy beheining is in ûntwerpyngongspunt, gjin fuotnoat.

Oer siden: ferskillende wearden, of in bewuste gearfoeging

In unike wearde per side hâldt de twa gateway-groepen apart. As de bedoeling echt is om ien multihomed-groep oer siden út te wreidzjen, is dat in oare arsjitektuer mei syn eigen latinsje-, faal- en trochstjoergefolgen, en it moat as arsjitektuer besletten wurde, net as identifikaasjekar. Freegje dy beslissing skriftlik oan foar it ûnderhâldsfinster.

Skriuw it bedoelde ûnderskied yn it plan, sadat in lettere yngenieur dy't in wurkjend side-sjabloan kopiearret, net syn identifikaasje meinomt.

De peer-útspraak is diel fan 'e identiteit

Elke gateway yn 'e groep listet syn lokale peers op loopback-adres, en dy relaasje libbet op it globale EVPN-nivo yn stee fan binnen in yndividuele MAC-VRF. It yn 'e ferkearde hiërargy pleatse is in gewoane manier om in konfiguraasje te meitsjen dy't commit mar nea de groep foarmet. Lês de referinsjehiërargy ien kear, en hâld dy dan oan.

De namme fan 'e útspraak ferhuze ek. Juniper neamde de interconnect peer-gateways-útspraak om yn 24.2R1 en sette de interconnect-spesifike foarm foar datacenter-interconnect werom yn 24.4R1. In fragmint út 'e tuskenlizzende release kin dêrom in namme brûke dy't de útrôle ferzje net akseptearret, of oarsom. Registrearje de release dêr't it fragmint wei komt njonken it fragmint sels.

Wat it dielen fan in iESI net docht

It definiearret net foar jo route targets, VNI's of de lokale EVPN-ynstânsje. Dy bliuwe aparte konfiguraasje dy't oan beide kanten oerienkomme moat, en in identifikaasje dy't oerienkomt wylst in route target dat net docht, leveret in groep op dy't foarmet en neat draacht. Fergelykje beide kanten fan dy ynstellings yn deselde pass.

It bewiist ek net peer-berikberens of designated-forwarder-ferkiezing. Test unicast en it frege broadcast- en multicast-gedrach yn it normale gefal, en werhelje dan mei ien gateway fuortsmiten sadat it oerbleaune lid de groep allinne draacht.

Dy twadde run is dejinge dy't bewiist dat de groep echt is.

Hâld it waarnommen lidmaatskip en de tsjinstkontekst by de testresultaten. In lettere identifikaasjeferoaring kin dan as multihoming-feroaring besjoen wurde, wat it is, yn stee fan as in kosmetyske bewurking fan in string. De resultaten binne it iennige bewiis dat de identifikaasje docht wat de tekening seit.