Waarom één EVPN-tenant meerdere route distinguishers kan tonen
Twee RD's in één tenant zijn geen conflict. Loop van de CLI-uitvoer naar de MAC-VRF of IP-VRF die de route heeft gemaakt en controleer daarna RT-import en VNI.
U filtert de EVPN-tabel voor één tenant, en de routes dragen twee verschillende route distinguishers. De eerste reactie is een configuratieconflict, en die reactie is meestal onjuist. Een tenantnaam is een bedrijfslabel, geen enkel object van het controlevlak, dus de bridgecontext en de routingcontext erin kunnen legitiem onder afzonderlijke identificatoren adverteren. Loop één route per keer van de uitvoer terug naar het lokale serviceobject dat deze heeft gemaakt, en de tweede RD ziet er niet langer als een fout uit.
Begin bij de uitvoer die u in de war bracht
Kies één route in plaats van de hele tabel. Noteer het routetype, de RD, de geëxporteerde route targets en de volgende hop. Die vier velden zijn genoeg om te bepalen welk lokaal object deze heeft geadverteerd en welk beleid op afstand deze zou moeten importeren.
Op een apparaat in NX-OS-stijl bereikt u de detailweergave met show bgp l2vpn evpn route-type 2 detail of show bgp l2vpn evpn route-type 5 detail. Op Junos staat dezelfde informatie in show route table bgp.evpn.0 detail. Andere syntaxis, dezelfde velden.
Begin niet met elk weergegeven getal gelijk te maken. RD's gelijk maken is de wijziging die het importbeleid op een werkende fabric breekt.
Geef elke identificator zijn taak
| 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 |
Een MAC-VRF houdt MAC-doorstuurinformatie voor een bridgeservice. Een IP-VRF levert een IP-routingcontext voor een gerouteerde service. Een tenant kan beide bevatten, daarom kan één tenant meer dan één RD produceren zonder enige verkeerde configuratie.
RFC 7432 kent de RD van de adverterende MAC-VRF toe aan zijn EVPN NLRI en vereist verschillende RD's over MAC-VRF's op dezelfde PE. Route-targetprocedures staan los daarvan: ze staan één of meer RT-attributen toe en vertrouwen voor lidmaatschap op het importbeleid. RD-gelijkheid is niet wat gedeeld lidmaatschap creëert, en het zo behandelen is de wortel van deze verwarring.
Loop één route van advertentie naar import
Volg de route in één richting. Bevestig het routetype, de service die deze heeft gemaakt, de RD, de geëxporteerde RT's en dan het importbeleid op de ontvangende PE. Elke stap beantwoordt een andere vraag, en een fout bij welke stap dan ook ziet er aan de andere kant uit als hetzelfde ontbrekende prefix.
Zodra de route aanwezig is, inspecteert u de geïnstalleerde doorstuurcontext en de VNI-toewijzing. Een overeenkomende VNI aan beide uiteinden toont aan dat het dataplane het eens is; het toont niet aan dat het controleplane de route via het bedoelde beleid heeft geïmporteerd.
Als de route op de externe PE verschijnt maar er geen verkeer stroomt, is het probleem voorbij EVPN. Controleer de VNI-naar-VLAN- of VNI-naar-VRF-binding en het underlay-pad voordat u weer route targets bewerkt. Begin bij de toewijzing, dan de underlay en pas daarna het controleplane. Een route-targetwijziging terugdraaien om een dataplanestoring te achtervolgen is een betrouwbare manier om een werkende import te breken.
Laag 3-prefixen zijn nog steeds EVPN-routes
Een IP-prefix in de EVPN-tabel is geen gewone IPv4-unicast BGP. De EVPN IP Prefix-route is een eigen routetype, en MAC/IP- en IP-prefixadvertenties reizen in de EVPN-adresfamilie, die RFC 7432 identificeert als AFI 25 en SAFI 70.
Dat onderscheid is belangrijk wanneer u een route in de EVPN-tabel vergelijkt met een in de unicast-tabel. Ze kunnen dezelfde bestemming beschrijven en toch door verschillend beleid worden geproduceerd, gefilterd en geïmporteerd. De ene als bewijs over de andere lezen is hoe een correcte fabric tijdens een migratie kapot lijkt.
Controleer de afleiding van de leverancier voordat u getallen vergelijkt
RFC 9136 breidt EVPN uit met IP Prefix-routes en specificeert of de toepasselijke RD uit de MAC-VRF- of IP-VRF-context komt. Daarom moeten een L2-servicelabel en een label van een gerouteerde service in dezelfde uitvoer worden gelezen tegen de objecten waartoe ze behoren, niet worden teruggebracht tot één RD per tenant.
Automatische afleiding van RD en RT is leverancierspecifiek. Lees de referentie van de geïmplementeerde leverancier voor de gebruikte formule; een automatisch gegenereerde waarde op één switch is geen universele codering, en het vergelijken van getallen van twee leveranciers bewijst zelden iets.
Sluit af met een schriftelijk spoor voor de route waarmee u begon: type, oorspronkelijk object, RD, geëxporteerde RT, importbeleid, geïnstalleerde VNI. Zes velden leggen de advertentie uit aan wie het ticket hierna leest, en geen ervan vereist dat de getallen van de tenant overeenkomen.