Varför en EVPN-hyresgäst kan visa flera route distinguisher
Två RD i en hyresgäst är ingen konflikt. Gå från CLI-utdata till MAC-VRF:en eller IP-VRF:en som skapade rutten och kontrollera sedan RT-import och VNI.
Du filtrerar EVPN-tabellen för en hyresgäst, och rutterna bär två olika route distinguisher. Den första reaktionen är en konfigurationskonflikt, och den reaktionen är oftast fel. Ett hyresgästnamn är en affärsetikett, inte ett enda objekt i kontrollplanet, så bryggkontexten och routingkontexten inuti det kan lagligt annonsera under separata identifierare. Gå igenom en rutt i taget från utdata tillbaka till det lokala tjänsteobjektet som skapade den, och den andra RD:n slutar se ut som ett fel.
Börja vid utdata som förvirrade dig
Välj en rutt i stället för hela tabellen. Notera ruttypen, RD:n, de exporterade route targetarna och nästa hopp. De fyra fälten räcker för att identifiera vilket lokalt objekt som annonserade den och vilken fjärrpolicyn som borde importera den.
På en enhet i NX-OS-stil nås detaljvyn med show bgp l2vpn evpn route-type 2 detail eller show bgp l2vpn evpn route-type 5 detail. På Junos finns samma information i show route table bgp.evpn.0 detail. Annan syntax, samma fält.
Börja inte med att göra varje visat tal lika. Att jämna ut RD:n är ändringen som bryter importpolicyn på ett fungerande fabric.
Ge varje identifierare dess uppgift
| 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 håller MAC-vidarebefordringsinformation för en bryggtjänst. En IP-VRF ger en IP-routningskontext för en routad tjänst. En hyresgäst kan innehålla båda, därför kan en hyresgäst producera mer än en RD utan någon felkonfiguration.
RFC 7432 tilldelar RD:n för den annonserande MAC-VRF:en till dess EVPN NLRI och kräver olika RD:n mellan MAC-VRF:er på samma PE. Route-target-procedurerna är separata: de tillåter en eller flera RT-attribut och förlitar sig på importpolicyn för medlemskap. RD-likhet är inte det som skapar delat medlemskap, och att behandla det så är roten till denna förvirring.
Gå igenom en rutt från annonsering till import
Följ rutten i en riktning. Bekräfta ruttypen, tjänsten som skapade den, RD:n, de exporterade RT:erna och sedan importpolicyn på den mottagande PE:n. Varje steg svarar på en annan fråga, och ett fel i vilket steg som helst ser ut som samma saknade prefix på andra sidan.
När rutten finns, granska den installerade vidarebefordringskontexten och VNI-mappningen. Att en VNI stämmer i båda ändar visar att dataplanet är överens; det visar inte att kontrollplanet importerade rutten genom den avsedda policyn.
Om rutten dyker upp på den fjärran PE:n men ingen trafik flyter har problemet flyttat sig förbi EVPN. Kontrollera VNI-till-VLAN- eller VNI-till-VRF-bindningen och underlay-vägen innan du redigerar route target igen. Börja vid mappningen, sedan underlay och först därefter kontrollplanet. Att rulla tillbaka en route-target-ändring för att jaga ett dataplansfel är ett pålitligt sätt att bryta en fungerande import.
Lager 3-prefix är fortfarande EVPN-rutter
Ett IP-prefix i EVPN-tabellen är inte vanlig IPv4-unicast BGP. EVPN IP Prefix-rutten är sin egen ruttyp, och MAC/IP- och IP-prefixannonser färdas i EVPN-adressfamiljen, som RFC 7432 identifierar som AFI 25 och SAFI 70.
Den skillnaden spelar roll när du jämför en rutt i EVPN-tabellen med en i unicast-tabellen. De kan beskriva samma destination och ändå produceras, filtreras och importeras av olika policy. Att läsa den ena som bevis om den andra är hur ett korrekt fabric ser trasigt ut under en migrering.
Kontrollera leverantörens härledning innan du jämför tal
RFC 9136 utökar EVPN med IP Prefix-rutter och anger om den tillämpliga RD:n kommer från MAC-VRF- eller IP-VRF-kontexten. Därför bör en L2-tjänsteetikett och en etikett för en routad tjänst i samma utdata läsas mot de objekt de tillhör, inte reduceras till en RD per hyresgäst.
Automatisk härledning av RD och RT är leverantörsspecifik. Läs referensen för den driftsatta leverantören för formeln som används; ett automatiskt genererat värde sett på en enda switch är inte en universell kodning, och att jämföra två leverantörers tal bevisar sällan något.
Avsluta med ett skriftligt spår för rutten du började med: typ, skapande objekt, RD, exporterad RT, importpolicy, installerad VNI. Sex fält förklarar annonseringen för den som läser ärendet härnäst, och inget av dem kräver att hyresgästens tal stämmer.