Hvorfor én EVPN-lejer kan vise flere route distinguishers
To RD'er i én lejer er ikke en konflikt. Gå fra CLI-outputtet til den MAC-VRF eller IP-VRF, der skabte ruten, og kontrollér derefter RT-import og VNI.
Du filtrerer EVPN-tabellen for én lejer, og ruterne bærer to forskellige route distinguishers. Den første tanke er en konfigurationskonflikt, og den tanke er som regel forkert. Et lejernavn er et forretningsmæssigt mærke, ikke et enkelt kontrolplansobjekt, så brokonteksten og routingkonteksten inde i det kan med rette annoncere under separate identifikatorer. Gå én rute ad gangen fra outputtet tilbage til det lokale serviceobjekt, der skabte den, og den anden RD holder op med at ligne en fejl.
Start ved det output, der forvirrede dig
Vælg én rute i stedet for hele tabellen. Notér rutetype, RD, de eksporterede route targets og næste hop. De fire felter er nok til at afgøre, hvilket lokalt objekt der annoncerede den, og hvilken fjernpolitik der bør importere den.
På en enhed i NX-OS-stil nås detaljevisningen med show bgp l2vpn evpn route-type 2 detail eller show bgp l2vpn evpn route-type 5 detail. På Junos findes de samme oplysninger i show route table bgp.evpn.0 detail. Anden syntaks, samme felter.
Begynd ikke med at gøre hvert vist tal ens. At udligne RD'er er den ændring, der ødelægger importpolitikken på et fungerende fabric.
Giv hver identifikator sin opgave
| 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-videresendelsesinformation for en broservice. En IP-VRF leverer en IP-routingkontekst for en rutet service. En lejer kan indeholde begge, og derfor kan én lejer producere mere end én RD uden nogen fejlkonfiguration.
RFC 7432 tildeler den annoncerende MAC-VRF's RD til dens EVPN NLRI og kræver forskellige RD'er på tværs af MAC-VRF'er på samme PE. Route-target-procedurer er adskilte: de tillader én eller flere RT-attributter og afhænger af importpolitik for medlemskab. RD-lighed er ikke det, der skaber delt medlemskab, og at behandle det sådan er roden til denne forvirring.
Gå én rute fra annoncering til import
Følg ruten i én retning. Bekræft rutetypen, den service der skabte den, RD'en, de eksporterede RT'er og derefter importpolitikken på den modtagende PE. Hvert trin besvarer et forskelligt spørgsmål, og en fejl på et hvilket som helst trin ser ud som det samme manglende præfiks på den anden side.
Når ruten er til stede, skal du undersøge den installerede videresendelseskontekst og VNI-mappingen. At en VNI matcher i begge ender viser, at dataplanet er enigt; det viser ikke, at kontrolplanet importerede ruten gennem den tilsigtede politik.
Hvis ruten vises på den fjern PE, men der ikke flyder trafik, er problemet flyttet forbi EVPN. Kontrollér VNI-til-VLAN- eller VNI-til-VRF-bindingen og underlay-stien, før du redigerer route targets igen. Start ved mappingen, derefter underlay og først derefter kontrolplanet. At rulle en route-target-ændring tilbage for at jage en dataplansfejl er en pålidelig måde at ødelægge en fungerende import.
Lag 3-præfikser er stadig EVPN-ruter
Et IP-præfiks i EVPN-tabellen er ikke almindelig IPv4-unicast BGP. EVPN IP Prefix-ruten er sin egen rutetype, og MAC/IP- og IP-præfiksannonceringer rejser i EVPN-adressefamilien, som RFC 7432 identificerer som AFI 25 og SAFI 70.
Den forskel betyder noget, når du sammenligner en rute i EVPN-tabellen med en i unicast-tabellen. De kan beskrive samme destination og stadig blive produceret, filtreret og importeret af forskellig politik. At læse den ene som bevis om den anden er, hvordan et korrekt fabric ser ødelagt ud under en migrering.
Kontrollér leverandørens afledning, før du sammenligner tal
RFC 9136 udvider EVPN med IP Prefix-ruter og angiver, om den gældende RD kommer fra MAC-VRF- eller IP-VRF-konteksten. Derfor bør et L2-service-label og et rutet service-label i samme output læses mod de objekter, de hører til, og ikke reduceres til én RD pr. lejer.
Automatisk afledning af RD og RT er leverandørspecifik. Læs den udrullede leverandørs reference for den anvendte formel; en automatisk genereret værdi set på én switch er ikke en universel kodning, og at sammenligne to leverandørers tal beviser sjældent noget.
Afslut med et skriftligt spor for den rute, du startede med: type, oprindelsesobjekt, RD, eksporteret RT, importpolitik, installeret VNI. Seks felter forklarer annonceringen for den, der læser sagen næste gang, og ingen af dem kræver, at lejerens tal stemmer overens.