Kvifor ein EVPN-leigetakar kan visa fleire route distinguisher
To RD-ar i ein leigetakar er ikkje ein konflikt. Gå frå CLI-utskrifta til MAC-VRF-en eller IP-VRF-en som oppretta ruta, og kontroller deretter RT-import og VNI.
Du filtrerer EVPN-tabellen for ein leigetakar, og rutene ber to ulike route distinguisher. Den første reaksjonen er ein konfigurasjonskonflikt, og den reaksjonen er vanlegvis feil. Eit leigetakarnamn er ei forretningsetikett, ikkje eitt einskilt objekt i kontrollplanet, så brukonteksten og rutekonteksten inni det kan lovleg annonsera under separate identifikatorar. Gå gjennom éi rute om gongen frå utskrifta tilbake til tenesteobjektet som oppretta ho, og den andre RD-en sluttar å sjå ut som ein feil.
Start ved utskrifta som forvirra deg
Vel éi rute i staden for heile tabellen. Noter rutetypen, RD-en, dei eksporterte route target-ane og neste hopp. Dei fire felta er nok til å identifisera kva lokalt objekt som annonserte ho, og kva fjernpolicy som bør importera ho.
På ein eining i NX-OS-stil nås detaljvisinga med show bgp l2vpn evpn route-type 2 detail eller show bgp l2vpn evpn route-type 5 detail. På Junos finst den same informasjonen i show route table bgp.evpn.0 detail. Annan syntaks, same felt.
Ikkje byrja med å gjera kvart viste tal likt. Å jamna ut RD-ar er endringa som bryt importpolicyen på eit fungerande fabric.
Gi kvar identifikator si oppgåve
| 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 |
Ein MAC-VRF held MAC-vidaresendingsinformasjon for ei bru-teneste. Ein IP-VRF gjev ein IP-rutekontekst for ei ruta teneste. Ein leigetakar kan innehalda begge, og difor kan éin leigetakar produsera meir enn éin RD utan nokon feilkonfigurasjon.
RFC 7432 tildeler RD-en til den annonserande MAC-VRF-en til EVPN NLRI-en hans og krev ulike RD-ar på tvers av MAC-VRF-ar på same PE. Route-target-prosedyrane er separate: dei tillèt éin eller fleire RT-attributtar og støttar seg på importpolicyen for medlemskap. RD-likskap er ikkje det som skaper delt medlemskap, og å handsama det slik er rota til denne forvirringa.
Gå gjennom éi rute frå annonsering til import
Følg ruta i éin retning. Stadfest rutetypen, tenesta som oppretta ho, RD-en, dei eksporterte RT-ane og deretter importpolicyen på PE-en som tek imot. Kvart steg svarar på eit anna spørsmål, og ein feil på eit kva som helst steg ser ut som det same manglande prefikset på den andre sida.
Når ruta er til stades, gransk den installerte vidaresendingskonteksten og VNI-tildelinga. At ein VNI stemmer i begge endar viser at dataplanet er samd; det viser ikkje at kontrollplanet importerte ruta gjennom den tiltenkte policyen.
Viss ruta dukkar opp på den eksterne PE-en, men ingen trafikk flyt, har problemet flytta seg forbi EVPN. Kontroller VNI-til-VLAN- eller VNI-til-VRF-bindinga og underlay-stien før du redigerer route target-ar igjen. Start ved tildelinga, deretter underlayet og først deretter kontrollplanet. Å rulle tilbake ei route-target-endring for å jaga ein dataplansfeil er ein påliteleg måte å bryta ein fungerande import.
Lag 3-prefiks er framleis EVPN-ruter
Eit IP-prefiks i EVPN-tabellen er ikkje vanleg IPv4-unicast BGP. EVPN IP Prefix-ruta er sin eigen rutetype, og MAC/IP- og IP-prefiksannonseringar reiser i EVPN-adressefamilien, som RFC 7432 identifiserer som AFI 25 og SAFI 70.
Den skilnaden betyr noko når du samanliknar ei rute i EVPN-tabellen med ei i unicast-tabellen. Dei kan skildra same destinasjon og likevel bli produserte, filtrerte og importerte av ulik policy. Å lesa den eine som prov om den andre er korleis eit korrekt fabric ser øydelagt ut under ein migrasjon.
Kontroller utleiinga til leverandøren før du samanliknar tal
RFC 9136 utvidar EVPN med IP Prefix-ruter og angir om den gjeldande RD-en kjem frå MAC-VRF- eller IP-VRF-konteksten. Difor bør ein L2-tenestelabel og ein label for ei ruta teneste i same utskrift lesast mot objekta dei høyrer til, ikkje reduserast til éin RD per leigetakar.
Automatisk utleiing av RD og RT er leverandørspesifikk. Les referansen til den utrulla leverandøren for formelen som vert brukt; ein automatisk generert verdi sett på éin svitsj er ikkje ei universell koding, og å samanlikna tal frå to leverandørar beviser sjeldan noko.
Avslutt med eit skriftleg spor for ruta du starta med: type, opprettande objekt, RD, eksportert RT, importpolicy, installert VNI. Seks felt forklarer annonseringa for den som les saka neste gong, og ingen av dei krev at tala til leigetakaren stemmer overeins.