To MAC-adresser viser seg i same VXLAN-pakke, og berre éi av dei høyrer til målverten. I eit EVPN VXLAN IP-VRF-til-IP-VRF-design er den indre mål-MAC-en den annonserte rutar-MAC-en til den utgåande rutaren, medan den ytre mål-MAC-en høyrer til det som leverer pakka på neste underlagslenkje. Å blande dei to sender folk ned i underlaget for å leite etter ein feil som ikkje er der. Ta kontrollane i rekkjefølgje.

Kvart steg svarar på eitt spørsmål, og det første svaret avgjer om dei seinare er relevante i det heile.

1. Les prefiksruta og communitiane hennar

Start ved ruta i staden for ved pakkefangsten:

show bgp l2vpn evpn route type prefix 10.20.0.0/24

Ei Type 5-rute annonserer eit IP-prefiks. I den grensesnittlause IP-VRF-modellen ber ho òg L3 VNI-en og den utvida rutar-MAC-communityen, og det er den communityen som identifiserer det utgåande rutingendepunktet. Les communityen i staden for å gå ut frå at MAC-en er innebygd i prefiks-NLRI-en, for det er han ikkje. Om ruta finst og communityen er fest, har kontrollplanet alt gjort sin del.

2. Stadfest kva videresendingsmodell som blir brukt

Den grensesnittlause modellen og overlay-indeksrekursjon er ulike støtta oppsett. Den grensesnittlause modellen rutar pakka, byggjer ei indre ramme for det eksterne rutingendepunktet og kapslar ho inn mot den utgåande VTEP-en.

Med overlay-indeksrekursjon treng den inngåande rutaren eit ekstra oppslag for å løyse neste hopp før han kan videresende. Begge modellane er gyldige, og prosedyren som gjeld, er avhengig av kva nettverket ditt brukar. Å bruke resonnementet om direkte neste hopp på eit nett bygd på den andre måten gir ei slutning som ser rett ut i fangsten og feil ut i designgjennomgangen.

3. Vent to ulike MAC-roller

Den indre mål-MAC-en er den annonserte rutar-MAC-en til den utgåande rutaren. Den ytre mål-MAC-en er neste hopp for den lokale leveringa, som kan vere ein underlagsrutar og kan endre seg ved kvar hopp. At dei er ulike er normalt, og at dei er like er eit samantreff og ikkje eit krav. Ein fangst som viser ei chassisaktig adresse på innsida og ei fysisk neste-hopp-adresse på utsida, skildrar nøyaktig den tilsikta innkapslinga.

4. Behandle ein chassis-avleidd verdi som eit implementeringsval

Ein plattform kan avleie den annonserte rutar-MAC-en sin frå ein system- eller chassisidentitet, og det er eit implementeringsvedtak og ikkje ei protokollregel. Sjekk allokerings- og redundansmodellen til leverandøren før du les noko inn i adresseformatet.

To implementasjonar som begge er i samsvar kan annonsere ulikt utsjåande rutar-MAC-ar, og difor beviser ein samanlikning på tvers av leverandørar svært lite.

5. Ikkje endre noko før tilstanden er usamd

For ein gjennomgang, samanlikn den valde prefiksruta, dei utvida communitiane hennar, BGP-neste-hoppet, L3 VNI-en og den resulterande videresendingstilstanden. Merk deretter dei indre og ytre hovuda i fangsten.

Om dei fem stemmer overeins, gjer MAC-en som ser rar ut jobben sin, og å endre han vil bryte eit rutingendepunkt i staden for å rette ein adresseringsfeil. Om dei ikkje stemmer, veit du no kva felt som er feil, og endringa er målretta i staden for spekulativ. Spesifikasjonen for IP-prefiks i EVPN er referansen som bør siterast i den diskusjonen, fordi han skildrar både modellen og communityen som ber verdien.

Relaterte artiklar