RSVP-TE-tunneln är uppe, men kundens L3VPN har ingen väg

Transport och tjänst är två separata beslut. Läs etikettstacken, kontrollera nästa hopps uppslagning och VRF-kopplingen var för sig och testa sedan ett verkligt kundflöde.

Två team kan båda ha rätt när kunden rapporterar att VPN:et ligger nere och transportteamet rapporterar att tunneln är i ordning. En trafiktekniskt uppsatt LSP och ett MPLS L3VPN svarar på olika frågor: den ena flyttar märkta paket genom kärnan, den andra avgör vilken routingkontext ett paket tillhör. När de blandas ihop går diskussionen i cirklar, eftersom varje sida mäter ett annat objekt och båda mätningarna är giltiga.

Transport uppe och tjänst nere är ett normalt tillstånd

En LSP kan vara etablerad, bära trafik och synas i alla övervakningssystem, medan kundtjänsten förblir oanvändbar. Inget i den kombinationen är självmotsägande, eftersom tunneln inte har någon åsikt om huruvida ett avlägset prefix finns, om en importpolicy accepterade det eller om den anslutna kretsen släpper igenom ramar.

Symtomet som vanligtvis avslöjar förvirringen är asymmetriskt: ping från PE-loopbacken lyckas medan en värd på kundens LAN inte får något, eller tvärtom. Skriv ner vilka adresser som fungerade innan du bildar en teori. När du väl märker att du testar två olika objekt är nästa steg att läsa etikettstacken i stället för att diskutera vems graf som är korrekt. Två adresser, två ägare och vanligtvis två olika personer som var och en tror att den andra har förstört något.

Läs stacken som två ansvar

Den nedre etiketten tillhör tjänsten och den övre etiketten tillhör vägen. RFC 4364 beskriver sekvensen enkelt: först läggs VPN-rutens etikett på, därefter tunnlas det märkta paketet mot BGP:s nästa hopp, där en trafiktekniktunnel trycker sin egen etikett ovanpå.

ObjectDecision it encodesWho owns it
Attachment and VRFWhich customer context receives the arriving packetEdge configuration
VPN route and service labelWhich remote forwarding context handles the destinationBGP VPN signalling
Transport LSP and tunnel labelHow the core carries the packet to the BGP next hopRSVP-TE or another tunnel mechanism

Vid den avlägsna PE:n väljer tjänsteetiketten behandlingen, som kan vara en VRF-sökning eller ett anslutningsbeslut. Den etiketten kan inte bytas ut mot en som bara korsar kärnan, och de två är inte utbytbara ens när båda förekommer i samma stack på samma gränssnitt.

Vad RSVP-framgång bevisar och inte bevisar

RSVP-TE etablerar explicit routade LSP:er, med eller utan resursreservationer, vilket är en konkret och användbar garanti för den väg ett paket tar genom kärnan. Det är inte ett påstående om kundrutter, och ett konfigurerat tunnelnamn är inte alls en rutt.

Inte heller ger närvaron av RSVP ett löfte om prestanda från ände till ände. Bandbreddsreservation på en LSP säger ingenting om den anslutna kretsen, kundens egen åtkomstlinje eller köbeteendet vid den avlägsna kanten. Att behandla det som en garanti ger självsäkra svar på frågor som ingen ställde. Om kravet verkligen är ett bandbreddsåtagande måste det sättas ihop av de delar som faktiskt upprätthåller ett sådant, och LSP:n är bara mitten av den kedjan.

Kontrollera i ordning och stanna sedan

Arbeta från transporten och utåt och stanna vid det första steget som misslyckas, eftersom varje senare steg förutsätter att de tidigare höll. Bekräfta först att LSP:n är etablerad och att vidarebefordringsposten för tjänsteprefixet faktiskt pekar på den. Bekräfta sedan att VPN-rutten finns i rätt tabell, att dess etikettbindning är närvarande och att importpolicyn accepterade den. Bekräfta sedan anslutningen: gränssnittet, inkapslingen och, där det gäller, VLAN-identifieraren som hör till det kontraktet.

show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMER

Kommandosyntaxen varierar mellan plattformar, så behandla de fyra raderna som de fyra frågorna och inte som ett skript. Det viktiga är att var och en av dem frågar ett annat objekt, och det är det som får ett fel att peka på en viss ägare.

Följ en tillåten begäran och behåll de goda bevisen

Avsluta med en enda verklig kundbegäran, tillåten av policyn, och svaret på den. Ett fungerande flöde från ände till ände avgör mer än en sida räknaravläsningar, och det prövar kombinationen i stället för varje del isolerat.

När ett senare steg misslyckas, bevara den lyckade LSP-observationen i stället för att bygga om transporten. Att bygga om en fungerande tunnel kan inte reparera ett saknat avlägset prefix, en felaktig VRF-koppling eller en åtkomstregel för destinationen, och det förstör beviset som ursprungligen sade att transporten var frisk.

Relaterade artiklar