Per què un sol tenant EVPN pot mostrar diversos route distinguishers
Dos RD en un mateix tenant no són cap conflicte. Recorreu de la sortida de la CLI fins al MAC-VRF o l'IP-VRF que va originar la ruta i després reviseu la importació d'RT i el VNI.
Filtreu la taula EVPN per a un sol tenant i les rutes porten dos route distinguishers diferents. El primer impuls és pensar en un conflicte de configuració, i aquest impuls sol ser erroni. El nom del tenant és una etiqueta de negoci, no un objecte únic del pla de control, de manera que el context de bridge i el context d'encaminament que hi ha a dins poden anunciar-se legítimament sota identificadors separats. Recorreu una ruta alhora des de la sortida fins a l'objecte de servei local que la va originar i el segon RD deixa de semblar un error.
Comenceu per la sortida que us va confondre
Triï una ruta en lloc de tota la taula. Anoteu-ne el tipus de ruta, el RD, els route targets exportats i el següent salt. Aquests quatre camps són suficients per identificar quin objecte local la va anunciar i quina política remota l'hauria d'importar.
En un dispositiu a l'estil NX-OS la vista detallada s'assoleix amb show bgp l2vpn evpn route-type 2 detail o show bgp l2vpn evpn route-type 5 detail. A Junos la mateixa informació és a show route table bgp.evpn.0 detail. Sintaxi diferent, els mateixos camps.
No comenceu fent que tots els números mostrats siguin iguals. Igualar els RD és el canvi que trenca la política d'importació en un fabric que funciona.
Doneu a cada identificador la seva feina
| 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 conté la informació de reenviament MAC d'un servei de bridge. Un IP-VRF proporciona un context d'encaminament IP per a un servei encaminat. Un tenant pot incloure tots dos, i per això un sol tenant pot produir més d'un RD sense cap error de configuració.
L'RFC 7432 assigna el RD del MAC-VRF anunciant al seu EVPN NLRI i exigeix RD diferents entre MAC-VRF del mateix PE. Els procediments de route-target són separats: permeten un o més atributs RT i confien en la política d'importació per a la pertinença. La igualtat de RD no és el que crea pertinença compartida, i tractar-la així és l'origen d'aquesta confusió.
Recorreu una ruta de l'anunci a la importació
Seguiu la ruta en una direcció. Confirmeu el tipus de ruta, el servei d'origen, el RD, els RT exportats i després la política d'importació al PE que la rep. Cada pas respon una pregunta diferent, i una fallada en qualsevol pas sembla el mateix prefix absent a l'altre costat.
Un cop la ruta hi és, inspeccioneu el context de reenviament instal·lat i el mapatge del VNI. Que un VNI coincideixi als dos extrems demostra que el pla de dades hi està d'acord; no demostra que el pla de control hagi importat la ruta per la política prevista.
Si la ruta apareix al PE remot però no hi circula trànsit, el problema ha anat més enllà d'EVPN. Reviseu la vinculació VNI-a-VLAN o VNI-a-VRF i el camí d'underlay abans de tornar a editar route targets. Comenceu pel mapatge, després l'underlay i només llavors el pla de control. Revertir un canvi de route-target per perseguir una fallada del pla de dades és una manera fiable de trencar una importació que funciona.
Els prefixos de capa 3 segueixen sent rutes EVPN
Un prefix IP a la taula EVPN no és BGP IPv4-unicast corrent. La ruta EVPN IP Prefix és un tipus de ruta propi, i els anuncis de MAC/IP i de prefix IP viatgen per la família d'adreces EVPN, que l'RFC 7432 identifica com a AFI 25 i SAFI 70.
Aquesta distinció importa quan compareu una ruta de la taula EVPN amb una de la taula unicast. Poden descriure la mateixa destinació i tot i així ser produïdes, filtrades i importades per polítiques diferents. Llegir una com a prova de l'altra és com un fabric correcte sembla trencat durant una migració.
Reviseu la derivació del fabricant abans de comparar números
L'RFC 9136 amplia EVPN amb rutes IP Prefix i especifica si el RD aplicable prové del context MAC-VRF o de l'IP-VRF. Per això una etiqueta de servei L2 i una etiqueta de servei encaminat a la mateixa sortida s'han de llegir contra els objectes a què pertanyen, no reduir-se a un RD per tenant.
La derivació automàtica de RD i RT depèn del fabricant. Llegiu la referència del fabricant desplegat per a la fórmula en ús; un valor generat automàticament vist en un sol commutador no és una codificació universal, i comparar els números de dos fabricants poques vegades demostra res.
Acabeu amb un rastre escrit per a la ruta amb què vau començar: tipus, objecte d'origen, RD, RT exportat, política d'importació, VNI instal·lat. Sis camps expliquen l'anunci a qui llegeixi el tiquet després, i cap d'ells no requereix que els números del tenant coincideixin.