Sjekk EVPN-ruter-MAC-en før du gir underlaget skylden

To MAC-adresser vises i samme VXLAN-pakke, og bare én av dem tilhører destinasjonsverten. I et EVPN VXLAN IP-VRF-til-IP-VRF-design er den indre destinasjons-MAC-en den utgående ruteren sin annonserte ruter-MAC, mens den ytre destinasjons-MAC-en tilhører det som leverer pakken på neste underlagslenke. Å forveksle de to sender folk ned i underlaget for å lete etter en feil som ikke er der. Ta kontrollene i rekkefølge.

Hvert trinn svarer på ett spørsmål, og det første svaret avgjør om de senere er relevante i det hele tatt.

1. Les prefiksruten og dens communities

Start ved ruten i stedet for ved pakkefangsten:

show bgp l2vpn evpn route type prefix 10.20.0.0/24

En Type 5-rute annonserer et IP-prefiks. I den grensesnittløse IP-VRF-modellen bærer den også L3 VNI-en og den utvidede ruter-MAC-communityen, og det er den communityen som identifiserer det utgående rutingendepunktet. Les communityen i stedet for å anta at MAC-en er innebygd i prefiks-NLRI-en, for det er den ikke. Hvis ruten finnes og communityen er festet, har kontrollplanet allerede gjort sitt.

2. Bekreft hvilken videresendingsmodell som brukes

Den grensesnittløse modellen og overlay-indeksrekursjon er forskjellige støttede oppsett. Den grensesnittløse modellen ruter pakken, bygger en indre ramme for det eksterne rutingendepunktet og innkapsler den mot den utgående VTEP-en.

Med overlay-indeksrekursjon trenger den inngående ruteren et ekstra oppslag for å løse neste hopp før den kan videresende. Begge modellene er gyldige, og prosedyren som gjelder avhenger av hvilken nettet ditt bruker. Å bruke resonnementet om direkte neste hopp på et nett bygget på den andre måten gir en konklusjon som ser riktig ut i fangsten og feil ut i designgjennomgangen.

3. Forvent to forskjellige MAC-roller

Den indre destinasjons-MAC-en er den utgående ruteren sin annonserte ruter-MAC. Den ytre destinasjons-MAC-en er neste hopp for den lokale leveringen, som kan være en underlagsruter og kan endre seg ved hvert hopp. At de er forskjellige er normalt, og at de er like er et sammentreff og ikke et krav. En fangst som viser en chassisaktig adresse på innsiden og en fysisk neste-hopp-adresse på utsiden, beskriver nøyaktig den tilsiktede innkapslingen.

4. Behandle en chassis-avledet verdi som et implementeringsvalg

En plattform kan utlede sin annonserte ruter-MAC fra en system- eller chassisidentitet, og det er en implementeringsbeslutning og ikke en protokollregel. Sjekk leverandørens allokerings- og redundansmodell før du leser noe inn i adresseformatet.

To implementasjoner som begge er i samsvar kan annonsere ulikt utseende ruter-MAC-er, og derfor beviser en sammenligning på tvers av leverandører svært lite.

5. Ikke endre noe før tilstanden er uenig

For en gjennomgang, sammenlign den valgte prefiksruten, dens utvidede communities, BGP-neste-hoppet, L3 VNI-en og den resulterende videresendingstilstanden. Merk deretter de indre og ytre hodene i fangsten.

Hvis de fem stemmer overens, gjør MAC-en som ser rar ut jobben sin, og å endre den vil bryte et rutingendepunkt i stedet for å rette en adresseringsfeil. Hvis de ikke stemmer, vet du nå hvilket felt som er feil, og endringen er målrettet i stedet for spekulativ. Spesifikasjonen for IP-prefikser i EVPN er referansen som bør siteres i den diskusjonen, fordi den beskriver både modellen og communityen som bærer verdien.