Por que un só tenant EVPN pode mostrar varios route distinguishers
Dous RD nun mesmo tenant non son un conflito. Percorra desde a saída da CLI ata o MAC-VRF ou o IP-VRF que orixinou a ruta e despois revise a importación de RT e o VNI.
Filtra a táboa EVPN para un só tenant e as rutas levan dous route distinguishers distintos. O primeiro impulso é pensar nun conflito de configuración, e ese impulso adoita ser erróneo. O nome do tenant é unha etiqueta de negocio, non un obxecto único do plano de control, así que o contexto de ponte e o contexto de encamiñamento que contén poden anunciarse lexitimamente baixo identificadores separados. Percorra unha ruta cada vez desde a saída ata o obxecto de servizo local que a orixinou e o segundo RD deixa de parecer un erro.
Comece pola saída que o confundiu
Escolla unha ruta en lugar de toda a táboa. Anote o seu tipo de ruta, o seu RD, os seus route targets exportados e o seguinte salto. Eses catro campos abondan para identificar que obxecto local a anunciou e que política remota debería importala.
Nun dispositivo ao estilo NX-OS a vista detallada acádase con show bgp l2vpn evpn route-type 2 detail ou show bgp l2vpn evpn route-type 5 detail. En Junos a mesma información está en show route table bgp.evpn.0 detail. Sintaxe distinta, os mesmos campos.
Non comece facendo iguais todos os números mostrados. Igualar os RD é o cambio que rompe a política de importación nun fabric que funciona.
Déalle a cada identificador o seu traballo
| 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 garda a información de reenvío MAC dun servizo de ponte. Un IP-VRF proporciona un contexto de encamiñamento IP para un servizo encamiñado. Un tenant pode incluír ambos, por iso un só tenant pode producir máis dun RD sen ningún erro de configuración.
O RFC 7432 asigna o RD do MAC-VRF anunciante ao seu EVPN NLRI e esixe RD distintos entre MAC-VRF do mesmo PE. Os procedementos de route-target son independentes: permiten un ou varios atributos RT e apoianse na política de importación para a pertenza. A igualdade de RD non é o que crea a pertenza compartida, e tratala así é a raíz desta confusión.
Percorra unha ruta do anuncio á importación
Siga a ruta nunha dirección. Confirme o tipo de ruta, o servizo de orixe, o RD, os RT exportados e despois a política de importación no PE receptor. Cada paso responde a unha pregunta distinta, e un fallo en calquera paso parece o mesmo prefixo ausente no outro extremo.
Unha vez que a ruta está presente, inspeccione o contexto de reenvío instalado e a asignación do VNI. Que un VNI coincida nos dous extremos demostra que o plano de datos está de acordo; non demostra que o plano de control importase a ruta mediante a política prevista.
Se a ruta aparece no PE remoto pero non flúe tráfico, o problema foi máis alá de EVPN. Revise a vinculación VNI con VLAN ou VNI con VRF e a ruta de underlay antes de volver editar route targets. Comece pola asignación, logo o underlay e só despois o plano de control. Reter un cambio de route-target para perseguir un fallo do plano de datos é unha forma fiable de romper unha importación que funciona.
Os prefixos de capa 3 seguen sendo rutas EVPN
Un prefixo IP na táboa EVPN non é BGP IPv4-unicast corrente. A ruta EVPN IP Prefix é un tipo de ruta propio, e os anuncios de MAC/IP e de prefixo IP viaxan na familia de enderezos EVPN, que o RFC 7432 identifica como AFI 25 e SAFI 70.
Esa distinción importa cando compara unha ruta da táboa EVPN cunha da táboa unicast. Poden describir o mesmo destino e aínda así ser producidas, filtradas e importadas por políticas distintas. Ler unha como proba da outra é como un fabric correcto parece roto durante unha migración.
Revise a derivación do fabricante antes de comparar números
O RFC 9136 amplía EVPN con rutas IP Prefix e especifica se o RD aplicable procede do contexto MAC-VRF ou do IP-VRF. Por iso unha etiqueta de servizo L2 e unha etiqueta de servizo encamiñado na mesma saída deben lerse fronte aos obxectos aos que pertencen, non reducirse a un RD por tenant.
A derivación automática de RD e RT depende do fabricante. Lea a referencia do fabricante despregado para a fórmula en uso; un valor xerado automaticamente visto nun só conmutador non é unha codificación universal, e comparar os números de dous fabricantes raras veces demostra algo.
Termine cun rastro escrito para a ruta coa que comezou: tipo, obxecto de orixe, RD, RT exportado, política de importación, VNI instalado. Seis campos explican o anuncio a quen lea o tique despois, e ningún deles esixe que os números do tenant coincidan.