Varför en Junos L2VPN visar en etikett men inte vidarebefordrar något

Kundrapporter kommer in och säger att L2VPN-anslutningen är Up, anslutningen är uppe och ingen ram passerar. Statuslamporna är ärliga; ramen klassificeras i en tjänst som inte har något användbart vidarebefordringstillstånd i fjärränden. I en BGP-signaliserad punkt-till-punkt-L2VPN tillhör det första beslutet anslutningen och inte en rutsökning. Kundramen anländer på ett logiskt gränssnitt, och det gränssnittet namnger förbindelsen och därmed fjärrplatsen. Allt därefter är etikett-vidarebefordringstillstånd byggt av det peerarna annonserade.

Ramen gör aldrig en rutsökning

Signaleringen förberedde tillståndet; behandlingen per paket är en etikettsökning på en förbindelse som redan valts. Därför är frågan varför en rutt saknas fel fråga, och den döljer de två värden som spelar roll: anslutningens förbindelse och den tjänsteetikett den använder.

Det förklarar också asymmetrin i ansträngningen. Konfigurationsgranskning säger vad som borde ha installerats, medan förbindelsevyn säger vad som faktiskt härleddes, och bara den senare överlever en avvikelse i etikettblocket.

Två etiketter, två riktningar

Varje PE tilldelar ett etikettblock lokalt, annonserar dess bas och storlek, och peerarna lägger till en förskjutning för att härleda etiketten för en viss plats. Tilldelningarna är därför lokalt betydelsefulla: två PE:er kan använda olika baser och olika blockstorlekar för samma tjänst. Läs förbindelsen från båda ändarna innan du ändrar något. Ett block som dimensionerats en etikett för litet ser exakt ut som en förbindelse som aldrig installeras.

show l2vpn connections instance CUST-A extensive

I den utskriften är den inkommande etiketten den som denna PE tilldelade och bad sin peer att använda, medan den utgående etiketten är peerns tilldelning som denna PE skjuter. Att läsa de två baklänges är det klassiska misstaget, och det skickar dig att leta efter ett värde som aldrig borde ha dykt upp på den här sidan. Förbindelsereferensen dokumenterar fälten bredvid etiketterna, inklusive plats, status och blockinformation.

Vad etikettsökningen bevisar

När du har det inkommande värdet är den lokala sökningen ett enda kommando:

show route label 160042

Den utskriften bör visa en l2vpn-post med nästa hopp, och etikettoperationen berättar om ramen skjuts, byts eller poppas innan den lämnar. Om den inte visar något installerades tjänstetillståndet aldrig trots att förbindelsen visar Up, och avvikelsen ligger i signaleringen och inte i transporten.

Följ en ram

Ett enda paket som skjuts in i anslutningen avgör mer än någon konfigurationsgranskning. Tjänsteetikettrutten bör peka på transport-LSP:n mot den fjärran PE:n, och de två etiketterna bör stämma med de värden som peern rapporterade. När transporten är frisk och tjänsteetiketten är fel når ramen rätt router och kastas där, och det är därför räknarna i fjärränden ser tomma ut medan de i näränden ser upptagna ut.

Kontrollera anslutningens inkapsling, styrordsinställningen och MTU:n samtidigt, eftersom det är förhandlade egenskaper och inte beteende per hopp.

Håll tjänstemodellerna åtskilda

VPLS lär sig MAC-adresser och EVPN annonserar slutpunkter, medan en punkt-till-punkt-L2VPN inte gör något av dem, så deras ramvalsprocedurer är inte utbytbara trots att de rider på samma BGP- och MPLS-infrastruktur. Att lyfta ett felsökningssteg från en modell till en annan ger självsäkra slutsatser utan grund.

För en saknad väg, registrera båda peerarnas förbindelsestatus, anslutningen, båda etikettriktningarna, inkapslingen, styrordsinställningen och MTU:n. Den registreringen kopplar det annonserade till vad vidarebefordringsplanet faktiskt gör, vilket är den enda länken som spelar roll, och det är också vad nästa ingenjör kommer att fråga efter.