Tas pats iESI vietoje, unikalus tarp vietų: Junos susiuvimas

Dvi vartų poros aptarnauja du duomenų centrus, ir kažkas turi nuspręsti, kiek interconnect ESI reikšmių projektui reikia. Atsakymas yra viena vartų grupei, ne viena fabric, ir ne viena vartams. Suklydus gaunamas fabric, kuris atrodo sukonfigūruotas ir pasirenka netinkamą forwarder, arba sujungiamos dvi vietos, kurios turėjo likti atskiros. Taisyklę ir jos išimtis verta užsirašyti prie vartų sąrašo.

Dvi apimtys, dvi taisyklės

Vietos viduje pertekliniai interconnect vartai veikia kaip vienas multihomed galinis taškas, todėl jie dalijasi vienu interconnect ESI. Jų peerai turi matyti vieną loginį narį, o ne du nepriklausomus. Tai ir yra visa bendros reikšmės esmė.

Tarp vietų kiekviena vartų grupė gauna savo reikšmę. Du duomenų centrai, besidalijantys identifikatoriumi, valdymo plokštumoje tampa viena multihomed grupe, o to paprastai neketina sujungimo per WAN projektas. Dvi vietos vienoje grupėje taip pat paveldi viena kitos gedimų režimus.

Vietos viduje: viena tapatybė grupei

Duokite porai tą pačią reikšmę abiejuose peeruose, tame pačiame paslaugos kontekste, ir užrašykite ją tinklo identifikatorių inventoriuje, o ne pokalbių gijoje. Dviejų narių neatitikimas yra gedimo režimas, sukuriantis vieno nario grupę ir be jokio aiškaus aliarmo. Palyginkite abu narius prieš tikėdami veikiančia sesija.

Palaikomas modelis yra all-active. Ta pati nuoroda neleidžia single-active veikimo, automatiškai išvestų LACP identifikatorių ir source-bmac parinkčių šiai siuvimo tapatybei, todėl projektas, kuris numatė vieną iš jų, turi būti peržiūrėtas dar prieš pasirenkant identifikatorių. Šis apribojimas yra projektavimo įvestis, o ne išnaša.

Tarp vietų: skirtingos reikšmės arba tyčinis sujungimas

Unikali reikšmė kiekvienai vietai išlaiko abi vartų grupes atskirai. Jei ketinimas tikrai yra išplėsti vieną multihomed grupę tarp vietų, tai yra kita architektūra su savo vėlavimo, gedimų ir persiuntimo pasekmėmis, ir apie ją reikia spręsti kaip apie architektūrą, o ne kaip apie identifikatoriaus pasirinkimą. Paprašykite šio sprendimo raštu prieš techninės priežiūros langą.

Įrašykite numatomą skirtumą į planą, kad vėlesnis inžinierius, kopijuodamas veikiantį vietos šabloną, neįsivežtų ir jo identifikatoriaus.

peer teiginys yra tapatybės dalis

Kiekvieni grupės vartai išvardija savo vietinius peerus pagal loopback adresą, ir šis ryšys gyvena globaliame EVPN lygmenyje, o ne atskiro MAC-VRF viduje. Įdėjus jį į netinkamą hierarchiją, dažnai gaunama konfigūracija, kuri įsipareigojama, bet niekada nesudaro grupės. Perskaitykite nuorodos hierarchiją vieną kartą ir tada jos laikykitės.

Teiginio pavadinimas taip pat pasikeitė. Juniper 24.2R1 pervadino interconnect peer-gateways teiginį ir 24.4R1 atkūrė interconnect būdingą formą duomenų centrų interconnectui. Todėl iš tarpinio leidimo paimtas fragmentas gali naudoti pavadinimą, kurio įdiegta versija nepriima, arba atvirkščiai. Užrašykite leidimą, iš kurio fragmentas paimtas, prie paties fragmento.

Ko bendras iESI naudojimas nedaro

Jis neapibrėžia už jus route target, VNI ar vietinės EVPN instancijos. Jie lieka atskira konfigūracija, kuri turi sutapti abiejose pusėse, ir identifikatorius, kuris sutampa, kai route target nesutampa, sukuria grupę, kuri susidaro ir nieko neneša. Palyginkite abi šių nustatymų puses tame pačiame praėjime.

Jis taip pat neįrodo peer pasiekiamumo ar designated forwarder rinkimų. Išbandykite unicast ir reikiamą broadcast bei multicast elgseną įprastu atveju, tada pakartokite pašalinę vienus vartus, kad likęs narys grupę neštų vienas.

Būtent antrasis paleidimas įrodo, kad grupė yra tikra.

Išsaugokite stebėtą narystę ir paslaugos kontekstą kartu su bandymų rezultatais. Vėlesnį identifikatoriaus pakeitimą tada galima peržiūrėti kaip multihoming pakeitimą, kuo jis ir yra, o ne kaip kosmetinį eilutės taisymą. Rezultatai yra vienintelis įrodymas, kad identifikatorius daro tai, ką sako brėžinys.