De ce un singur tenant EVPN poate afișa mai multe route distinguisher
Două RD într-un singur tenant nu sunt un conflict. Mergeți de la ieșirea CLI la MAC-VRF sau IP-VRF care a creat ruta, apoi verificați importul RT și VNI.
Filtrați tabela EVPN pentru un singur tenant, iar rutele poartă două route distinguisher diferite. Primul impuls este un conflict de configurare, iar acel impuls este de obicei greșit. Numele tenantului este o etichetă de business, nu un singur obiect al planului de control, așa că contextul de punte și contextul de rutare din interiorul lui pot anunța în mod legitim sub identificatori separați. Parcurgeți o rută pe rând de la ieșire înapoi la obiectul de serviciu local care a creat-o, iar al doilea RD nu mai pare o eroare.
Începeți cu ieșirea care v-a încurcat
Alegeți o rută în locul întregului tabel. Notați tipul rutei, RD-ul, route targeturile exportate și următorul salt. Aceste patru câmpuri sunt suficiente pentru a identifica ce obiect local a anunțat-o și ce politică de la distanță ar trebui să o importe.
Pe un dispozitiv în stil NX-OS, vizualizarea detaliată se obține cu show bgp l2vpn evpn route-type 2 detail sau show bgp l2vpn evpn route-type 5 detail. Pe Junos, aceleași informații se află în show route table bgp.evpn.0 detail. Sintaxă diferită, aceleași câmpuri.
Nu începeți prin a face egale toate numerele afișate. Egalizarea RD-urilor este schimbarea care rupe politica de import pe un fabric funcțional.
Dați fiecărui identificator sarcina lui
| 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 păstrează informațiile de expediere MAC pentru un serviciu de punte. Un IP-VRF oferă un context de rutare IP pentru un serviciu rutat. Un tenant poate include ambele, de aceea un singur tenant poate produce mai mult de un RD fără nicio eroare de configurare.
RFC 7432 atribuie RD-ul MAC-VRF-ului care anunță către EVPN NLRI al acestuia și cere RD-uri distincte între MAC-VRF-urile de pe același PE. Procedurile route-target sunt separate: permit unul sau mai multe atribute RT și se bazează pe politica de import pentru apartenență. Egalitatea RD-urilor nu este ceea ce creează apartenența comună, iar tratarea ei astfel este rădăcina acestei confuzii.
Parcurgeți o rută de la anunț la import
Urmați ruta într-o singură direcție. Confirmați tipul rutei, serviciul care a creat-o, RD-ul, RT-urile exportate și apoi politica de import de pe PE-ul care o primește. Fiecare pas răspunde la o întrebare diferită, iar o eroare la orice pas arată ca același prefix lipsă de cealaltă parte.
Odată ce ruta există, inspectați contextul de expediere instalat și maparea VNI. Un VNI identic la ambele capete demonstrează că planul de date este de acord; nu demonstrează că planul de control a importat ruta prin politica dorită.
Dacă ruta apare pe PE-ul de la distanță dar nu curge trafic, problema a trecut dincolo de EVPN. Verificați legătura VNI-la-VLAN sau VNI-la-VRF și calea de underlay înainte de a edita din nou route targeturile. Începeți cu maparea, apoi underlay-ul și abia apoi planul de control. A anula o modificare de route-target pentru a urmări o defecțiune a planului de date este o modalitate sigură de a rupe un import funcțional.
Prefixele de nivel 3 rămân rute EVPN
Un prefix IP din tabelul EVPN nu este BGP IPv4-unicast obișnuit. ruta EVPN IP Prefix este un tip de rută propriu, iar anunțurile MAC/IP și de prefix IP călătoresc în familia de adrese EVPN, pe care RFC 7432 o identifică drept AFI 25 și SAFI 70.
Această distincție contează când comparați o rută din tabelul EVPN cu una din tabelul unicast. Ele pot descrie aceeași destinație și totuși pot fi produse, filtrate și importate de politici diferite. Citirea uneia ca dovadă despre cealaltă face ca un fabric corect să pară stricat în timpul unei migrări.
Verificați derivarea producătorului înainte de a compara numere
RFC 9136 extinde EVPN cu rute IP Prefix și specifică dacă RD-ul aplicabil provine din contextul MAC-VRF sau IP-VRF. De aceea o etichetă de serviciu L2 și o etichetă de serviciu rutat din aceeași ieșire trebuie citite față de obiectele cărora le aparțin, nu reduse la un singur RD pe tenant.
Derivarea automată a RD și RT depinde de producător. Citiți referința producătorului implementat pentru formula folosită; o valoare generată automat văzută pe un singur switch nu este o codificare universală, iar compararea numerelor a doi producători rareori dovedește ceva.
Încheiați cu o urmă scrisă pentru ruta cu care ați început: tip, obiect de origine, RD, RT exportat, politică de import, VNI instalat. Șase câmpuri explică anunțul oricui va citi tichetul în continuare, iar niciunul nu cere ca numerele tenantului să coincidă.