Por qué un solo tenant EVPN puede mostrar varios route distinguishers
Dos RD en un mismo tenant no son un conflicto. Recorra desde la salida de la CLI hasta el MAC-VRF o el IP-VRF que originó la ruta y luego revise la importación de RT y el VNI.
Filtra la tabla EVPN para un solo tenant y las rutas llevan dos route distinguishers distintos. El primer impulso es pensar en un conflicto de configuración, y ese impulso suele ser erróneo. El nombre del tenant es una etiqueta de negocio, no un objeto único del plano de control, así que el contexto de puente y el contexto de encaminamiento que contiene pueden anunciarse legítimamente bajo identificadores separados. Recorra una ruta cada vez desde la salida hasta el objeto de servicio local que la originó y el segundo RD deja de parecer un error.
Empiece por la salida que le confundió
Elija una ruta en lugar de toda la tabla. Anote su tipo de ruta, su RD, sus route targets exportados y el siguiente salto. Esos cuatro campos bastan para identificar qué objeto local la anunció y qué política remota debería importarla.
En un dispositivo al estilo NX-OS la vista detallada se alcanza con show bgp l2vpn evpn route-type 2 detail o show bgp l2vpn evpn route-type 5 detail. En Junos la misma información está en show route table bgp.evpn.0 detail. Sintaxis distinta, los mismos campos.
No empiece haciendo iguales todos los números mostrados. Igualar los RD es el cambio que rompe la política de importación en un fabric que funciona.
Dé a cada identificador su trabajo
| Identifier | Question it answers | Where it is used |
|---|---|---|
| Route distinguisher | Which distinct route context contributed this advertisement? | Makes otherwise identical prefixes unique in BGP |
| Route target | Which importing service policy should receive the route? | Extended community matched by import policy |
| VNI | Which VXLAN service context carries the traffic? | Data plane encapsulation and mapping |
Un MAC-VRF guarda la información de reenvío MAC de un servicio de puente. Un IP-VRF proporciona un contexto de encaminamiento IP para un servicio encaminado. Un tenant puede incluir ambos, por eso un solo tenant puede producir más de un RD sin ningún error de configuración.
El RFC 7432 asigna el RD del MAC-VRF anunciante a su EVPN NLRI y exige RD distintos entre MAC-VRF del mismo PE. Los procedimientos de route-target son independientes: permiten uno o varios atributos RT y se apoyan en la política de importación para la pertenencia. La igualdad de RD no es lo que crea la pertenencia compartida, y tratarla así es la raíz de esta confusión.
Recorra una ruta del anuncio a la importación
Siga la ruta en una dirección. Confirme el tipo de ruta, el servicio de origen, el RD, los RT exportados y después la política de importación en el PE receptor. Cada paso responde a una pregunta distinta, y un fallo en cualquier paso parece el mismo prefijo ausente en el otro extremo.
Una vez que la ruta está presente, inspeccione el contexto de reenvío instalado y el mapeo del VNI. Que un VNI coincida en ambos extremos demuestra que el plano de datos está de acuerdo; no demuestra que el plano de control haya importado la ruta mediante la política prevista.
Si la ruta aparece en el PE remoto pero no fluye tráfico, el problema ha ido más allá de EVPN. Revise la vinculación VNI a VLAN o VNI a VRF y la ruta de underlay antes de volver a editar route targets. Empiece por el mapeo, luego el underlay y solo después el plano de control. Revertir un cambio de route-target para perseguir un fallo del plano de datos es una forma fiable de romper una importación que funciona.
Los prefijos de capa 3 siguen siendo rutas EVPN
Un prefijo IP en la tabla EVPN no es BGP IPv4-unicast corriente. La ruta EVPN IP Prefix es un tipo de ruta propio, y los anuncios de MAC/IP y de prefijo IP viajan en la familia de direcciones EVPN, que el RFC 7432 identifica como AFI 25 y SAFI 70.
Esa distinción importa cuando compara una ruta de la tabla EVPN con una de la tabla unicast. Pueden describir el mismo destino y aun así ser producidas, filtradas e importadas por políticas distintas. Leer una como prueba de la otra es como un fabric correcto parece roto durante una migración.
Revise la derivación del fabricante antes de comparar números
El RFC 9136 amplía EVPN con rutas IP Prefix y especifica si el RD aplicable procede del contexto MAC-VRF o del IP-VRF. Por eso una etiqueta de servicio L2 y una etiqueta de servicio encaminado en la misma salida deben leerse frente a los objetos a los que pertenecen, no reducirse a un RD por tenant.
La derivación automática de RD y RT depende del fabricante. Lea la referencia del fabricante desplegado para la fórmula en uso; un valor generado automáticamente visto en un solo conmutador no es una codificación universal, y comparar los números de dos fabricantes rara vez demuestra algo.
Termine con un rastro escrito para la ruta con la que empezó: tipo, objeto de origen, RD, RT exportado, política de importación, VNI instalado. Seis campos explican el anuncio a quien lea el tique después, y ninguno exige que los números del tenant coincidan.