Hvorfor én EVPN-leietaker kan vise flere route distinguishers
To RD-er i én leietaker er ikke en konflikt. Gå fra CLI-utskriften til MAC-VRF-en eller IP-VRF-en som opprettet ruten, og kontroller deretter RT-import og VNI.
Du filtrerer EVPN-tabellen for én leietaker, og rutene bærer to forskjellige route distinguishers. Den første reaksjonen er en konfigurasjonskonflikt, og den reaksjonen er vanligvis feil. Et leietakernavn er en forretningsetikett, ikke ett enkelt objekt i kontrollplanet, så brokonteksten og rutingskonteksten inni det kan lovlig annonsere under separate identifikatorer. Gå gjennom én rute om gangen fra utskriften tilbake til tjenesteobjektet som opprettet den, og den andre RD-en slutter å se ut som en feil.
Start ved utskriften som forvirret deg
Velg én rute i stedet for hele tabellen. Noter rutetypen, RD-en, de eksporterte route targetene og neste hopp. De fire feltene er nok til å identifisere hvilket lokalt objekt som annonserte den, og hvilken fjernpolicy som bør importere den.
På en enhet i NX-OS-stil nås detaljvisningen med show bgp l2vpn evpn route-type 2 detail eller show bgp l2vpn evpn route-type 5 detail. På Junos finnes den samme informasjonen i show route table bgp.evpn.0 detail. Annen syntaks, samme felter.
Ikke begynn med å gjøre hvert viste tall likt. Å utjevne RD-er er endringen som bryter importpolicyen på et fungerende fabric.
Gi hver identifikator sin oppgave
| 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 |
En MAC-VRF holder MAC-videresendingsinformasjon for en brotjeneste. En IP-VRF gir en IP-rutingskontekst for en rutet tjeneste. En leietaker kan inneholde begge, og derfor kan én leietaker produsere mer enn én RD uten noen feilkonfigurasjon.
RFC 7432 tildeler RD-en til den annonserende MAC-VRF-en til dens EVPN NLRI og krever forskjellige RD-er på tvers av MAC-VRF-er på samme PE. Route-target-prosedyrene er separate: de tillater én eller flere RT-attributter og støtter seg på importpolicyen for medlemskap. RD-likhet er ikke det som skaper delt medlemskap, og å behandle det slik er roten til denne forvirringen.
Gå gjennom én rute fra annonsering til import
Følg ruten i én retning. Bekreft rutetypen, tjenesten som opprettet den, RD-en, de eksporterte RT-ene og deretter importpolicyen på PE-en som mottar. Hvert steg svarer på et annet spørsmål, og en feil på et hvilket som helst steg ser ut som det samme manglende prefikset på den andre siden.
Når ruten er til stede, undersøk den installerte videresendingskonteksten og VNI-tilordningen. At en VNI stemmer i begge ender viser at dataplanet er enig; det viser ikke at kontrollplanet importerte ruten gjennom den tiltenkte policyen.
Hvis ruten vises på den eksterne PE-en, men ingen trafikk flyter, har problemet flyttet seg forbi EVPN. Kontroller VNI-til-VLAN- eller VNI-til-VRF-bindingen og underlay-stien før du redigerer route target-er igjen. Start ved tilordningen, deretter underlayet og først deretter kontrollplanet. Å rulle tilbake en route-target-endring for å jage en dataplansfeil er en pålitelig måte å bryte en fungerende import.
Lag 3-prefikser er fortsatt EVPN-ruter
Et IP-prefiks i EVPN-tabellen er ikke vanlig IPv4-unicast BGP. EVPN IP Prefix-ruten er sin egen rutetype, og MAC/IP- og IP-prefiksannonseringer reiser i EVPN-adressefamilien, som RFC 7432 identifiserer som AFI 25 og SAFI 70.
Den forskjellen betyr noe når du sammenligner en rute i EVPN-tabellen med en i unicast-tabellen. De kan beskrive samme destinasjon og likevel bli produsert, filtrert og importert av ulik policy. Å lese den ene som bevis om den andre er hvordan et korrekt fabric ser ødelagt ut under en migrering.
Kontroller leverandørens utledning før du sammenligner tall
RFC 9136 utvider EVPN med IP Prefix-ruter og angir om den gjeldende RD-en kommer fra MAC-VRF- eller IP-VRF-konteksten. Derfor bør en L2-tjenestelabel og en label for en rutet tjeneste i samme utskrift leses mot objektene de tilhører, ikke reduseres til én RD per leietaker.
Automatisk utledning av RD og RT er leverandørspesifikk. Les referansen til den utrullede leverandøren for formelen som brukes; en automatisk generert verdi sett på én svitsj er ikke en universell koding, og å sammenligne tall fra to leverandører beviser sjelden noe.
Avslutt med et skriftlig spor for ruten du startet med: type, opprettende objekt, RD, eksportert RT, importpolicy, installert VNI. Seks felter forklarer annonseringen for den som leser saken neste gang, og ingen av dem krever at leietakerens tall stemmer overens.