Sama iESI ene de ejo, unika inter ejoj: Junos-kudrado

Du paroj da pordegoj servas du datencentrojn, kaj iu devas decidi kiom da interconnect ESI-valoroj la dezajno bezonas. La respondo estas unu por pordega grupo, ne unu por fabric kaj ne unu por pordego. Erari pri tio produktas fabric, kiu ŝajnas agordita kaj elektas la malĝustan forwarder, aŭ kunfandas du ejojn, kiuj devis resti apartaj. La regulo kaj ĝiaj esceptoj indas esti skribitaj apud la pordega listo.

Du skopoj, du reguloj

Ene de ejo, la redundaj interconnect-pordegoj agas kiel unu multihomed finpunkto, do ili kunhavas unu interconnect ESI. Iliaj peer-oj devas vidi unu logikan membron anstataŭ du sendependajn. Jen la tuta senco de la komuna valoro.

Inter ejoj, ĉiu pordega grupo ricevas sian propran valoron. Du datencentroj, kiuj kunhavas identigilon, fariĝas unu multihomed grupo en la rega ebeno, kio kutime ne estas tio, kion kudra dezajno tra WAN celas. Du ejoj en unu grupo ankaŭ heredas la misfunkciajn reĝimojn de la alia.

Ene de ejo: unu identeco por la grupo

Donu al la paro la saman valoron ĉe ambaŭ peer-oj, en la sama serva kunteksto, kaj registru ĝin en la identigila inventaro de la reto anstataŭ en babila fadeno. Malkongruo inter la du membroj estas la misfunkcia reĝimo, kiu produktas grupon de unu kaj neniun evidentan alarmon. Komparu ambaŭ membrojn antaŭ ol kredi pri funkcianta seanco.

La subtenata modelo estas all-active. La sama referenco ekskludas single-active funkciadon, aŭtomate derivitajn LACP-identigilojn kaj source-bmac-opciojn por ĉi tiu kudra identeco, do dezajno, kiu supozis unu el tiuj, devas esti reviziita antaŭ ol la identigilo eĉ elektiĝos. Tiu limigo estas dezajna enigo, ne piednoto.

Trans ejoj: malsamaj valoroj aŭ intenca kunfando

Unika valoro por ejo tenas la du pordegajn grupojn apartaj. Se la intenco vere estas etendi unu multihomed grupon trans ejoj, tio estas alia arkitekturo kun propraj sekvoj pri latento, misfunkcio kaj plusendado, kaj ĝi devus esti decidita kiel arkitekturo, ne kiel elekto de identigilo. Petu tiun decidon skribe antaŭ la bontenada fenestro.

Skribu la celatan distingon en la planon, por ke posta inĝeniero kopianta funkciantan ejan ŝablonon ne importu ankaŭ ĝian identigilon.

La peer-deklaro estas parto de la identeco

Ĉiu pordego en la grupo listigas siajn lokajn peer-ojn laŭ loopback-adreso, kaj tiu rilato vivas je la tutmonda EVPN-nivelo anstataŭ ene de unuopa MAC-VRF. Meti ĝin en la malĝustan hierarkion estas ordinara maniero produkti agordon, kiu commitiĝas sed neniam formas la grupon. Legu la referencan hierarkion unufoje, poste tenu vin al ĝi.

Ankaŭ la nomo de la deklaro moviĝis. Juniper alinomis la deklaron interconnect peer-gateways en 24.2R1 kaj restarigis la interconnect-specifan formon por datencentra interconnect en 24.4R1. Kodpeceto prenita el la meza eldono do povas uzi nomon, kiun la deplojita versio ne akceptas, aŭ inverse. Registru la eldonon, el kiu venas la kodpeceto, apud la kodpeceto mem.

Kion kunhavigo de iESI ne faras

Ĝi ne difinas por vi route targets, VNI-ojn aŭ la lokan EVPN-instancon. Tiuj restas aparta agordo, kiu devas kongrui ambaŭflanke, kaj identigilo, kiu kongruas dum route target ne kongruas, produktas grupon, kiu formiĝas kaj portas nenion. Komparu ambaŭ flankojn de tiuj agordoj en la sama trairo.

Ĝi ankaŭ ne pruvas atingeblon de peer-oj aŭ elekton de designated forwarder. Testu unicast kaj la postulatan broadcast- kaj multicast-konduton en la normala kazo, poste ripetu kun unu pordego forigita, por ke la restanta membro portu la grupon sola.

Ĝuste tiu dua rulo pruvas, ke la grupo estas reala.

Konservu la observitan membrecon kaj la servan kuntekston kune kun la testrezultoj. Posta ŝanĝo de identigilo tiam povas esti reviziata kiel multihoming-ŝanĝo, kio ĝi estas, kaj ne kiel kosmetika redakto de signoĉeno. La rezultoj estas la sola pruvo, ke la identigilo faras tion, kion diras la desegnaĵo.