Mateix iESI dins d'un lloc, únic entre llocs: cosit de Junos

Dues parelles de passarel·les serveixen dos centres de dades, i algú ha de decidir quants valors interconnect ESI necessita el disseny. La resposta és una per grup de passarel·les, no una per fabric ni una per passarel·la. Fer-ho malament produeix un fabric que sembla configurat i tria el forwarder equivocat, o fusiona dos llocs que havien de romandre separats. Val la pena escriure la regla i les seves excepcions al costat de la llista de passarel·les.

Dos àmbits, dues regles

Dins d'un lloc, les passarel·les interconnect redundants actuen com un sol punt final multihomed, de manera que comparteixen un sol interconnect ESI. Els seus peers han de veure un sol membre lògic en lloc de dos d'independents. Aquest és tot el sentit del valor compartit.

Entre llocs, cada grup de passarel·les obté el seu propi valor. Dos centres de dades que comparteixen un identificador es converteixen en un sol grup multihomed al pla de control, cosa que normalment no és el que pretén un disseny de cosit per un WAN. Dos llocs en un grup també hereten els modes de fallada de l'altre.

Dins d'un lloc: una identitat per al grup

Doneu a la parella el mateix valor als dos peers, en el mateix context de servei, i registreu-lo a l'inventari d'identificadors de la xarxa en lloc d'un fil de xat. Una discrepància entre els dos membres és el mode de fallada que produeix un grup d'un sol membre i cap alarma òbvia. Compareu tots dos membres abans de creure-us una sessió que funciona.

El model suportat és all-active. La mateixa referència exclou l'operació single-active, els identificadors LACP derivats automàticament i les opcions source-bmac per a aquesta identitat de cosit, de manera que un disseny que va assumir una d'aquestes necessita revisió abans que es triï l'identificador. Aquesta restricció és una entrada del disseny, no una nota a peu de pàgina.

Entre llocs: valors diferents, o una fusió deliberada

Un valor únic per lloc manté els dos grups de passarel·les separats. Si la intenció és realment estendre un grup multihomed entre llocs, això és una arquitectura diferent amb les seves pròpies conseqüències de latència, fallada i reenviament, i cal decidir-la com a arquitectura, no com a elecció d'identificador. Demaneu aquesta decisió per escrit abans de la finestra de manteniment.

Escriviu la distinció prevista al pla, perquè un enginyer posterior que copiï una plantilla de lloc que funciona no n'importi també l'identificador.

La declaració de peer forma part de la identitat

Cada passarel·la del grup llista els seus peers locals per adreça de loopback, i aquesta relació viu al nivell global d'EVPN i no dins d'un MAC-VRF individual. Posar-la a la jerarquia equivocada és una manera habitual de produir una configuració que es confirma però que mai no forma el grup. Llegiu la jerarquia de referència una vegada i després manteniu-vos-hi.

El nom de la declaració també es va moure. Juniper va canviar el nom de la declaració interconnect peer-gateways a la 24.2R1 i va restaurar la forma específica d'interconnect per a la interconnexió de centres de dades a la 24.4R1. Un fragment pres de la versió intermèdia pot, per tant, fer servir un nom que la versió desplegada no accepta, o al revés. Registreu la versió d'on prové el fragment al costat del mateix fragment.

Què no fa compartir un iESI

No defineix per vosaltres els route targets, les VNI ni la instància EVPN local. Aquests romanen com a configuració separada que ha de coincidir als dos costats, i un identificador que coincideix mentre un route target no ho fa produeix un grup que es forma i no transporta res. Compareu els dos costats d'aquests paràmetres en la mateixa passada.

Tampoc no demostra l'abastabilitat dels peers ni l'elecció del designated forwarder. Proveu l'unicast i el comportament de broadcast i multicast necessari en el cas normal, i repetiu-ho amb una passarel·la retirada perquè el membre supervivent porti el grup sol.

Aquesta segona execució és la que demostra que el grup és real.

Conserveu la pertinença observada i el context de servei amb els resultats de les proves. Un canvi posterior d'identificador es podrà revisar llavors com a canvi de multihoming, que és el que és, i no com una edició cosmètica d'una cadena. Els resultats són l'única prova que l'identificador fa el que diu el dibuix.