Mismo iESI dentro de un sitio, único entre sitios: costura de Junos

Dos parejas de puertas de enlace sirven a dos centros de datos, y alguien tiene que decidir cuántos valores interconnect ESI necesita el diseño. La respuesta es uno por grupo de puertas de enlace, no uno por fabric ni uno por puerta de enlace. Equivocarse produce un fabric que parece configurado y elige el forwarder incorrecto, o fusiona dos sitios que debían permanecer separados. La regla y sus excepciones merecen escribirse junto a la lista de puertas de enlace.

Dos ámbitos, dos reglas

Dentro de un sitio, las puertas de enlace interconnect redundantes actúan como un único extremo multihomed, por lo que comparten un solo interconnect ESI. Sus peers deben ver un único miembro lógico en lugar de dos independientes. Ese es todo el sentido del valor compartido.

Entre sitios, cada grupo de puertas de enlace recibe su propio valor. Dos centros de datos que comparten un identificador se convierten en un solo grupo multihomed en el plano de control, lo que normalmente no es lo que pretende un diseño de costura a través de una WAN. Dos sitios en un mismo grupo también heredan los modos de fallo del otro.

Dentro de un sitio: una identidad para el grupo

Dé a la pareja el mismo valor en ambos peers, en el mismo contexto de servicio, y regístrelo en el inventario de identificadores de la red en lugar de en un hilo de chat. Una discrepancia entre los dos miembros es el modo de fallo que produce un grupo de uno solo y ninguna alarma evidente. Compare ambos miembros antes de creerse una sesión que funciona.

El modelo admitido es all-active. La misma referencia excluye el funcionamiento single-active, los identificadores LACP derivados automáticamente y las opciones source-bmac para esta identidad de costura, así que un diseño que asumió una de ellas debe revisarse antes incluso de elegir el identificador. Esa restricción es un dato de diseño, no una nota a pie de página.

Entre sitios: valores distintos o una fusión deliberada

Un valor único por sitio mantiene separados los dos grupos de puertas de enlace. Si la intención es realmente extender un grupo multihomed entre sitios, eso es otra arquitectura con sus propias consecuencias de latencia, fallo y reenvío, y debe decidirse como arquitectura y no como elección de identificador. Pida esa decisión por escrito antes de la ventana de mantenimiento.

Escriba la distinción prevista en el plan, para que un ingeniero posterior que copie una plantilla de sitio que funciona no importe también su identificador.

La sentencia peer forma parte de la identidad

Cada puerta de enlace del grupo enumera sus peers locales por dirección de loopback, y esa relación vive en el nivel global de EVPN y no dentro de un MAC-VRF individual. Colocarla en la jerarquía equivocada es una forma habitual de producir una configuración que se confirma pero que nunca forma el grupo. Lea la jerarquía de referencia una vez y luego atiénase a ella.

El nombre de la sentencia también se movió. Juniper renombró la sentencia interconnect peer-gateways en la 24.2R1 y restauró la forma específica de interconnect para la interconexión de centros de datos en la 24.4R1. Un fragmento tomado de la versión intermedia puede, por tanto, usar un nombre que la versión desplegada no acepta, o al revés. Registre la versión de la que procede el fragmento junto al propio fragmento.

Lo que no hace compartir un iESI

No define por usted los route targets, las VNI ni la instancia EVPN local. Siguen siendo configuración aparte que debe coincidir en ambos lados, y un identificador que coincide mientras un route target no lo hace produce un grupo que se forma y no transporta nada. Compare ambos lados de esos ajustes en la misma pasada.

Tampoco demuestra la alcanzabilidad de los peers ni la elección del designated forwarder. Pruebe el unicast y el comportamiento de broadcast y multicast requerido en el caso normal, y repita con una puerta de enlace retirada para que el miembro superviviente lleve el grupo solo.

Esa segunda ejecución es la que demuestra que el grupo es real.

Guarde la pertenencia observada y el contexto de servicio junto con los resultados de las pruebas. Un cambio posterior de identificador podrá revisarse entonces como un cambio de multihoming, que es lo que es, y no como una edición cosmética de una cadena. Los resultados son la única prueba de que el identificador hace lo que dice el dibujo.