Läsa en VPNv4-etikett på en AS-gränsrouter

Att läsa en VPNv4-etikett på en AS-gränsrouter säger lite förrän du vet vilken modell mellan AS som överlämningen använder. Etiketten är ingen egenskap hos rutten i sig; den registrerar en överenskommelse om inkapsling och leverans mellan två routrar. Identifiera modellen innan du läser av displayen. Annars felsöker du ett avtal som ingen har skrivit ned.

Vilken modell gränsen använder

VRF-till-VRF-uppställningen kopplar ihop matchande VRF:er via routade anslutningar. Varje sida ser den andra som en grannrouter på kundsidan och de utbyter vanliga IPv4-rutter, så inget vid den gränsen behöver MPLS.

En andra uppställning utbyter märkta VPNv4-rutter mellan gränsroutrarna själva. Det fungerar bara med en sammanhängande etikettväxlad väg över förbindelsen och en distribution av route-target plus en förtroendemodell som båda sidor accepterar. Om någon del saknas används inte modellen, vad konfigurationen än antyder.

Den tredje distribuerar märkt PE-nåbarhet medan VPN-rutterna färdas mellan ändpunkter eller route-reflektorer över AS. Var och en av de tre lämnar olika arbete vid gränsen, och att blanda kontrollplanet från en med gränssnittsantagandena från en annan är det klassiska felet. Den missmatchningen visar sig oftast som en etikett som ser rätt ut på ena sidan och försvinner på den andra.

Läs ett prefix från början till slut

Ta ett enda auktoriserat kundprefix och gå igenom det. Titta på vad som annonserades, vad som kom fram, nästa hopp, etiketten och den importpolicy som släppte in det. Titta sedan på hur routern löser vidarebefordran mot det nästa hoppet, för det är där en etikett blir ett paket. Hoppa över någon halva och du beskriver ett kontrollplan som kanske inte flyttar trafik. De två läsningarna betyder bara något tillsammans.

Numret är lokalt. Det betyder något i förhållande till routern som tilldelade det och vägen som bär paket dit, vilket är varför samma värde kan förekomma två gånger och betyda två olika saker. Jämför det med vad mottagarsidan säger att den tog emot.

Etiketten är lokal, och löftet också

Förmågan kontrolleras i båda ändar av förbindelsen, inte i en. Ett kommando på ditt gränssnitt gör ingenting på leverantörens grannanslutning, och en rutt som BGP accepterade förbinder inte i sig grannen att vidarebefordra ett märkt paket.

RFC 4364 begränsar märkt VPNv4-peering till betrodda uppställningar och varnar för att acceptera etiketter som aldrig annonserades till den grannen. Det är ett säkerhetspåstående lika mycket som ett protokollpåstående. Håll den publika internetroutningsrelationen borta från det privata VPN-ruttutbytet. Om förbindelsen är vanlig IP, förvänta dig inte att någon etikett överlever den. Och där länken är märkt, bekräfta att den yttre transportetiketten byts ut korrekt vid varje hopp.

En etikett som ser rätt ut på ena sidan och försvinner på den andra är oftast den missmatchningen, inte en routningsbugg.

Vad du skriver ned vid acceptans

Acceptans är ett pakettest, inte en tabellgranskning. Följ ett kundpaket in i den avlägsna VRF:en och följ dess svar tillbaka, skriv sedan ned vilken modell överlämningen använder. Lägg till överlämningens ägare på båda sidor och om gränsen bär vanlig IP eller märkt trafik.

Den anteckningen är det som låter nästa operatör läsa samma etikettdisplay korrekt. Utan den härleds modellen från konfigurationen, och härledda antaganden är hur samma misstag upprepas. RFC 4364:s avsnitt om mellan-AS är där du avgör vilken modell som var avsedd.