Controleer de EVPN-router-MAC voordat je de underlay de schuld geeft

Twee MAC-adressen verschijnen in hetzelfde VXLAN-pakket, en slechts één ervan hoort bij de bestemmingshost. In een EVPN-VXLAN-IP-VRF-naar-IP-VRF-ontwerp is de binnenste bestemmings-MAC de aangekondigde router-MAC van de uitgaande router, terwijl de buitenste bestemmings-MAC toebehoort aan wat het pakket op de volgende underlay-link aflevert. De twee verwarren stuurt mensen de underlay in op zoek naar een fout die er niet is. Werk de controles op volgorde af.

Elke stap beantwoordt één vraag, en het eerste antwoord bepaalt of de latere überhaupt relevant zijn.

1. Lees de prefix-route en zijn communities

Begin bij de route en niet bij de packet capture:

show bgp l2vpn evpn route type prefix 10.20.0.0/24

Een Type 5-route adverteert een IP-prefix. In het interface-loze IP-VRF-model draagt die ook de L3 VNI en de uitgebreide router-MAC-community, en juist die community identificeert het uitgaande routing-eindpunt. Lees de community in plaats van aan te nemen dat de MAC in de prefix-NLRI is ingebed, want dat is niet zo. Als de route aanwezig is en de community is aangehecht, heeft het controlevlak zijn deel al gedaan.

2. Bevestig welk doorstuurmodel wordt gebruikt

Het interface-loze model en overlay-index-recursie zijn verschillende ondersteunde opstellingen. Het interface-loze model routeert het pakket, bouwt een binnenframe voor het externe routing-eindpunt en encapsuleert dat richting de uitgaande VTEP.

Bij overlay-index-recursie heeft de ingress-router een extra lookup nodig om de next hop op te lossen voordat hij kan doorsturen. Beide modellen zijn geldig, en de toe te passen procedure hangt af van welke jouw fabric gebruikt. De redenering van de directe next hop toepassen op een fabric die anders is gebouwd, levert een conclusie op die in de capture juist lijkt en in de designreview onjuist.

3. Verwacht twee verschillende MAC-rollen

De binnenste bestemmings-MAC is de aangekondigde router-MAC van de uitgaande router. De buitenste bestemmings-MAC is de next hop van de lokale aflevering, die een underlay-router kan zijn en bij elke hop kan veranderen. Ze verschillend zien is normaal, en ze gelijk zien is toeval en geen vereiste. Een capture die binnen een chassisachtig adres en buiten een fysiek next-hop-adres laat zien, beschrijft precies de bedoelde encapsulatie.

4. Behandel een van chassis afgeleide waarde als een implementatiekeuze

Een platform kan zijn aangekondigde router-MAC afleiden uit een systeem- of chassisidentiteit, en dat is een implementatiebeslissing en geen protocolregel. Controleer het allocatie- en redundantiemodel van de leverancier voordat je iets in het adresformaat leest.

Twee implementaties die beide voldoen kunnen verschillend uitziende router-MAC's adverteren, en daarom bewijst vergelijking tussen leveranciers heel weinig.

5. Wijzig niets tot de toestand het oneens is

Vergelijk voor een review de geselecteerde prefix-route, de uitgebreide communities, de BGP-next-hop, de L3 VNI en de resulterende doorstuurstaat. Label daarna de binnenste en buitenste header in de capture.

Als die vijf overeenkomen, doet de MAC die er vreemd uitziet zijn werk, en hem wijzigen breekt een routing-eindpunt in plaats van een adresseringsfout te herstellen. Als ze niet overeenkomen, weet je nu welk veld verkeerd is, en de wijziging is gericht in plaats van speculatief. De EVPN-specificatie voor IP-prefixen is de referentie die in dat gesprek moet worden aangehaald, want die beschrijft zowel het model als de community die de waarde draagt.