Isti iESI znotraj lokacije, edinstven med lokacijami: Junos prešivanje
En interconnect ESI poveže prehode, ki oskrbujejo lokacijo; druga lokacija potrebuje svojega. Peer stavek, ki nosi to identiteto, se je med izdajami premaknil.
Dva para prehodov oskrbujeta dva podatkovna centra, in nekdo mora odločiti, koliko vrednosti interconnect ESI potrebuje zasnova. Odgovor je ena na skupino prehodov, ne ena na fabric in ne ena na prehod. Napaka pri tem ustvari fabric, ki je videti konfiguriran in izbere napačen forwarder, ali združi dve lokaciji, ki bi morali ostati ločeni. Pravilo in njegove izjeme je vredno zapisati ob seznam prehodov.
Dva obsega, dve pravili
Znotraj lokacije redundantni interconnect prehodi delujejo kot ena multihomed končna točka, zato si delijo en sam interconnect ESI. Njihovi peeri morajo videti enega logičnega člana namesto dveh neodvisnih. To je ves smisel skupne vrednosti.
Med lokacijami dobi vsaka skupina prehodov svojo vrednost. Dva podatkovna centra, ki si delita identifikator, postaneta ena multihomed skupina v krmilni ravnini, kar običajno ni tisto, kar zasnova prešivanja čez WAN namerava. Dve lokaciji v eni skupini podedujeta tudi načine okvare druga druge.
Znotraj lokacije: ena identiteta za skupino
Dajte paru enako vrednost na obeh peerih, v istem kontekstu storitve, in jo zabeležite v popis identifikatorjev omrežja, ne v klepet. Neujemanje med dvema članoma je način okvare, ki ustvari skupino z enim članom in brez očitnega alarma. Primerjajte oba člana, preden verjamete delujoči seji.
Podprti model je all-active. Ista referenca izključuje delovanje single-active, samodejno izpeljane identifikatorje LACP in možnosti source-bmac za to identiteto prešivanja, zato je treba zasnovo, ki je predpostavila eno od tega, pregledati še pred izbiro identifikatorja. Ta omejitev je vhod zasnove, ne opomba pod črto.
Med lokacijami: različne vrednosti ali namerno združitev
Edinstvena vrednost na lokacijo ohranja obe skupini prehodov ločeni. Če je namen res razširiti eno multihomed skupino med lokacijami, je to druga arhitektura z lastnimi posledicami za zakasnitev, okvare in posredovanje, in o njej je treba odločiti kot o arhitekturi, ne kot o izbiri identifikatorja. Zahtevajte to odločitev pisno pred servisnim oknom.
Zapišite predvideno razliko v načrt, da poznejši inženir, ki kopira delujočo predlogo lokacije, ne uvozi tudi njenega identifikatorja.
Peer stavek je del identitete
Vsak prehod v skupini našteje svoje lokalne peere po naslovu loopback, in ta odnos živi na globalni ravni EVPN, ne znotraj posameznega MAC-VRF. Postavljanje v napačno hierarhijo je pogost način, da nastane konfiguracija, ki se potrdi, a skupine nikoli ne oblikuje. Preberite referenčno hierarhijo enkrat in se je potem držite.
Tudi ime stavka se je premaknilo. Juniper je v 24.2R1 preimenoval stavek interconnect peer-gateways in v 24.4R1 obnovil obliko, specifično za interconnect podatkovnih centrov. Izsek iz vmesne izdaje lahko zato uporablja ime, ki ga nameščena različica ne sprejema, ali obratno. Zabeležite izdajo, iz katere izsek prihaja, poleg samega izseka.
Česa deljenje iESI ne naredi
Ne določi namesto vas route targetov, VNI-jev ali lokalne instance EVPN. Ti ostanejo ločena konfiguracija, ki se mora ujemati na obeh straneh, in identifikator, ki se ujema, medtem ko se route target ne, ustvari skupino, ki se oblikuje in nič ne prenaša. Primerjajte obe strani teh nastavitev v istem prehodu.
Prav tako ne dokazuje dosegljivosti peerov ali izbire designated forwarderja. Preizkusite unicast in zahtevano vedenje broadcast in multicast v običajnem primeru, nato ponovite z odstranjenim enim prehodom, da preostali član skupino nosi sam.
Prav drugi zagon dokazuje, da je skupina resnična.
Ohranite opaženo članstvo in kontekst storitve skupaj z rezultati preizkusov. Poznejšo spremembo identifikatorja je potem mogoče pregledati kot spremembo multihominga, kar je, in ne kot kozmetični popravek niza. Rezultati so edini dokaz, da identifikator dela to, kar pravi risba.