Sama iESI innan svæðis, einkvæmt milli svæða: Junos-saumur

Tvö gáttapör þjóna tveimur gagnaverum, og einhver verður að ákveða hversu mörg interconnect ESI-gildi hönnunin þarf. Svarið er eitt á hverja gáttahópa, ekki eitt á hvert fabric og ekki eitt á hverja gátt. Að gera það rangt framleiðir fabric sem lítur út fyrir að vera stillt og velur rangt forwarder, eða sameinar tvö svæði sem áttu að haldast aðskilin. Regluna og undantekningar hennar er þess virði að skrifa niður við hlið gáttalistans.

Tvö svið, tvær reglur

Innan svæðis hegða varagáttirnar í interconnect sér sem einn multihomed endapunktur, þannig að þær deila einu interconnect ESI. Peerarnir þeirra verða að sjá einn rökréttan meðlim í stað tveggja sjálfstæðra. Það er allur tilgangurinn með sameiginlega gildinu.

Milli svæða fær hver gáttahópur sitt eigið gildi. Tvö gagnaver sem deila sama auðkenni verða einn multihomed hópur í stýrisléttunni, sem er venjulega ekki það sem saumahönnun yfir WAN stefnir að. Tvö svæði í sama hópi erfa líka bilanatilvik hvort annars.

Innan svæðis: eitt auðkenni fyrir hópinn

Gefðu parinu sama gildið á báðum peerum, í sama þjónustusamhengi, og skráðu það í auðkenningarskrá netkerfisins í stað spjallþráðar. Ósamræmi milli meðlimanna tveggja er bilanatilvikið sem framleiðir hóp úr einum og enga augljósa viðvörun. Berðu saman báða meðlimi áður en þú trúir virkri lotu.

Studda módelið er all-active. Sama tilvísun útilokar single-active rekstur, sjálfkrafa leidd LACP-auðkenni og source-bmac valkosti fyrir þetta saumaauðkenni, svo hönnun sem gerði ráð fyrir einu þeirra þarf að endurskoða áður en auðkennið er jafnvel valið. Það skilyrði er hönnunarinntak, ekki neðanmálsgrein.

Yfir svæði: mismunandi gildi eða viljandi sameining

Einkvæmt gildi á hvert svæði heldur gáttahópunum tveimur aðskildum. Ef ætlunin er raunverulega að teygja einn multihomed hóp yfir svæði, er það önnur arkitektúr með eigin afleiðingum fyrir biðtíma, bilun og framsendingu, og ákveða ætti hana sem arkitektúr en ekki sem auðkennisval. Biddu um þá ákvörðun skriflega fyrir viðhaldsgluggann.

Skrifaðu fyrirhugaða aðgreiningu í áætlunina, svo síðari verkfræðingur sem afritar virkt svæðissniðmát flytji ekki inn auðkennið með því.

Peer-yfirlýsingin er hluti auðkennisins

Hver gátt í hópnum listar staðbundna peera sína eftir loopback-heimilisfangi, og það samband lifir á alþjóðlegu EVPN-stigi í stað inni í einstöku MAC-VRF. Að setja það í rangt stigveldi er algeng leið til að búa til stillingu sem commitast en myndar aldrei hópinn. Lestu tilvísunarstigveldið einu sinni og haltu þig svo við það.

Nafn yfirlýsingarinnar flutti líka. Juniper endurnefndi interconnect peer-gateways yfirlýsinguna í 24.2R1 og endurreisti interconnect-sértæka myndina fyrir interconnect gagnavera í 24.4R1. Bútur tekinn úr milliútgáfunni getur því notað nafn sem uppsetta útgáfan samþykkir ekki, eða öfugt. Skráðu útgáfuna sem búturinn kemur úr við hlið bútsins sjálfs.

Hvað deiling iESI gerir ekki

Hún skilgreinir ekki route targets, VNI eða staðbundið EVPN-tilvik fyrir þig. Þau eru áfram sérstök stilling sem verður að stemma á báðum hliðum, og auðkenni sem stemmir á meðan route target stemmir ekki framleiðir hóp sem myndast og ber ekkert. Berðu saman báðar hliðar þessara stillinga í sama ferli.

Hún sannar heldur ekki aðgengi peera eða val designated forwarder. Prófaðu unicast og nauðsynlega broadcast- og multicast-hegðun í venjulegu tilfelli, endurtaktu svo með eina gátt fjarlægða þannig að eftirlifandi meðlimur beri hópinn einn.

Það er seinni keyrslan sem sannar að hópurinn er raunverulegur.

Geymdu athugaða aðild og þjónustusamhengi með prófunarniðurstöðunum. Síðari auðkennisbreyting getur þá verið endurskoðuð sem multihoming-breyting, sem hún er, en ekki sem kosmetísk breyting á streng. Niðurstöðurnar eru eina sönnunin fyrir því að auðkennið gerir það sem teikningin segir.