Vissa L2VPN-rutter försvinner när du lägger till ruttreflektorer

Sessionerna hålls uppe, IGP:n är stabil och ändå dyker några få L2VPN-rutter aldrig upp på två av de fyra leverantörskanterna. Mönstret hör till ett reflektionsproblem och inte ett transportproblem, eftersom en bruten session misslyckas helt medan en återanvänd reflektionsgräns misslyckas selektivt. Den fysiska ringen har inget med det att göra; den logiska distributionsgrafen är där dessa rutter stannade. Att hitta den punkten kräver inte att du bygger om kontrollplanet.

Förlusten är selektiv, vilket snävar in sökningen

Fyra leverantörskanter på en fysisk ring behöver sex logiska sessioner för ett fullt mesh, eftersom varje router paras med de andra tre. Dessa sessioner går över den routade transporten, så kableringen säger ingenting om hur många grannskaper som finns eller vilka av dem som reflekterar. När två kanter missar en viss uppsättning prefix medan allt annat konvergerar är kabeln inte den misstänkta.

Selektiv förlust pekar mot slingförebyggande, policy eller relationsriktning, där vissa rutter korsar en gräns och andra kastas på vägen. Total förlust pekar mot sessionen eller adressfamiljen. Att avgöra vilken av de två du tittar på är det första användbara steget, och det tar ett enda kommando.

Vad reflektion faktiskt ändrar

Ruttreflektion mjukar upp regeln att en iBGP-talare inte får annonsera om en rutt som lärts från en annan iBGP-talare. RFC 4456 uttrycker undantaget genom relationen mellan talaren och ruttens källa, och riktningen på den relationen betyder mer än de flesta sammanfattningar antyder. En rutt som lärts från en klient får reflekteras till andra klienter och till icke-klienter, medan en rutt som lärts från en icke-klient bara får reflekteras till klienter. Läs asymmetrin två gånger, för den förklarar hur tillägget av en klientrelation kan dölja ett designfel: det öppnar en väg som topologin aldrig avsåg.

Attributet CLUSTER_LIST registrerar reflektionshistoriken, och en reflektor som hittar sitt eget kluster-ID i den listan måste ignorera annonsen. Det är slingförebyggande, och det är också mekanismen som raderar rutter när identifierare återanvänds av misstag. ORIGINATOR_ID spelar en besläktad roll genom att namnge den router som först annonserade rutten.

Återanvända kluster-ID:n är hur rutter försvinner

Ett litet nätverk inbjuder till en genväg: ge varje router ett kluster-ID lika med dess loopback, lägg senare till ännu en reflektor och återanvänd en befintlig loopback eftersom den är praktiskt tillgänglig. Om den identifieraren nu dyker upp i två oberoende reflektionsteg, ser det andra steget sitt eget ID i CLUSTER_LIST och kastar rutten. Ingenting loggar ett fel, eftersom kastandet är rätt svar på en slinga.

Överflödiga reflektorer som betjänar ett kluster är det legitima undantaget: de delar avsiktligt ett ID så att vilken som helst av dem kan betjäna samma klienter. Identifieraren måste matcha reflektionsdesignen i stället för att skilja på chassienamn.

Rita den avsedda grafen innan du rör någon konfiguration: vem som skapar prefixet, vilken klientrelation som tillåter den första reflektionen, vilken reflektor som bär den till nästa steg och var den sista klienten sitter. Varje hopp i den grafen är en plats där en återanvänd identifierare, en saknad klientrelation eller ett policyfilter kan stoppa rutten. När grafen är ritad har en saknad rutt en plats i stället för ett mysterium.

Motstå frestelsen att göra varje granne till klient

Den snabba reparationen för en saknad rutt är att göra varje granne till klient hos varje reflektor. Spridningen kommer tillbaka och designen slutar berätta något för dig: den mångfaldigar rutterna som varje talare bär samtidigt som den döljer vilken relation som skulle göra arbetet.

Ett litet nätverk behöver vanligtvis en av två former. Ett fullt iBGP-mesh är sex sessioner för fyra routrar helt utan reflektion, och ett utpekat par reflektorer som betjänar de återstående kanterna är den andra. Båda är lättare att resonera kring än ett partiellt mesh där varje router reflekterar lite. Välj form efter skala och felbeteende, inte efter kablingsschemat.

Kontrollera adressfamiljen innan du skyller på reflektionen

En TCP-session på port 179 bevisar att de två talarna kan prata, och ingenting om huruvida VPN-adressfamiljen utbytte en enda rutt. Fastställ sessionens tillstånd, sedan familjen, sedan det enskilda prefixet.

vtysh -c "show bgp summary"
vtysh -c "show bgp l2vpn evpn summary"
vtysh -c "show bgp l2vpn evpn"

Dessa tre utdata skiljer ett grannskapsproblem från ett utbytesproblem och från ett saknat prefix. Om familjen inte visar några prefix alls, undersök grannens aktiveringstillstånd och exportpolicy innan du tittar på reflektionen. Om prefix dyker upp på en kant men inte på en annan, jämför klusterlistan och originatorn på mottagarsidan och gå sedan igenom grafen från föregående avsnitt.

Håll nästa hopps nåbarhet och vidarebefordringstillståndet utanför den kontrollen. En reflekterad rutt med ett onåbart nästa hopp finns och är oanvändbar, vilket ser ut som ett reflektionsfel tills du tittar på kolumnen för nästa hopp. Lös nästa hopp, bekräfta vidarebefordringsposten och avgör först då om distributionsgrafen behöver ännu en reflektor.