L3VPN-överlämning: privata rutter, en standardrutt eller en full tabell?

Din förbindelse är uppe, VRF:en är konfigurerad och leverantören ställer en kort fråga som avgör resten av designen: vad kundkanten ska ta emot? Tre svar är vanliga och inget av dem följer av att det finns en etikettstack. De är tjänstebeslut om var trafiken lämnar filialen.

Att gå igenom överlämningen i ordning är det billigaste sättet att göra detta rätt. Du börjar med vad som händer med trafik som inte matchar något, skriver sedan ned de privata prefixen och deras beteende vid fel, och pratar först därefter om hur stor feed du är beredd att bära.

Börja med trafiken som ingen planerade för

Ställ en fråga innan någon prefixlista dyker upp: när ett paket inte matchar någon privat rutt, vart ska det ta vägen? En filial med egen internetförbindelse behåller oftast en lokal standardrutt, så vanlig webbtrafik går ut genom den lokala brandväggen och rör aldrig leverantören. I den designen bär VPN:en bara de avlägsna privata platserna, och de mer specifika prefixen gör urvalet.

En filial som ska använda en central utgång är det motsatta fallet. Där pekar standardrutten in i tjänsten, och leverantören eller den centrala platsen äger vidarebefordran, returrutning och eventuell översättning. Att säga "standard till VPN" utan den ägaren ger en filial som löser namn och inte når något.

De två designerna skiljer sig i hur ett routingfel ser ut, och därför är gissning dyrt. Med en lokal standardrutt skickar en förlorad privat rutt den trafiken ut på internet, där brandväggen slänger den eller, värre, något du inte avsåg svarar. Med en central standardrutt tar samma förlust bort internetåtkomsten helt och ärendet kommer in som "hela filialen är nere". Inget av felen är fel i sig, men bara ett stämmer med tjänsten du sålde, och en BGP-konfiguration ensam berättar inte vilket du byggde.

Skriv ned de privata prefixen med deras felfall

Lista prefixen som filialen måste nå och notera vilka som är sammanfattade. Ett aggregat som är en bit för brett drar in okända destinationer i VPN:en, och det är bara okej om den andra sidan faktiskt äger dem och vidarebefordrar dem.

Beskriv sedan det avsedda beteendet när den privata tjänsten fallerar. En bibehållen förkastningsrutt håller trafiken borta från en obehörig väg och ger ett rent, förväntat avbrott. En flytande standardrutt kan behålla tillgängligheten genom att flytta till en reservväg, men bara om reservvägen har tillstånd att bära den trafiken.

Håll tillgänglighet och tillåten reservväg som två separata krav i överlämningsdokumentet. Team som slår ihop dem slutar med att diskutera om filialen borde ha fallit, i stället för att kontrollera om den avtalade policyn genomfördes.

Kontrollera vad CE faktiskt installerade

Konfigurationsavsikt och vidarebefordringstillstånd divergerar tillräckligt ofta för att verifieringen hör hemma i överlämningen, inte i incidentgranskningen. På en IOS-XE-kundkant svarar de tre kommandona nedan på tre olika frågor: vad som erbjöds, vad som accepterades och vad som faktiskt används.

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

Kör alla tre på överlämningsdagen och inte en månad senare, medan någon ännu minns vad som avtalades. Den första utdata beror på soft-reconfiguration inbound eller en lagrad route refresh; utan något av dem kan CE inte visa dig vad den avvisade. Den andra visar accepterade och bästa rutter efter policy. Den tredje berättar vart standardrutten egentligen går, och det är den mest användbara raden i hela överlämningen.

Kör samma kontroller på en andra CE om platsen är dubbelansluten. Asymmetrisk acceptans mellan två kanter är en vanlig orsak till "det fungerar från en server och inte från den andra", och det är osynligt i en konfigurationsdiff som ser symmetrisk ut.

Kvalificera en större feed i stället för att förutsätta den

Ibland behöver kunden verkligen internetruttinformation inne i VRF:en, för policy routing eller för en central utgång som styr efter prefix. Det är ett krav som ska anges, avgränsas och prissättas, inte en dold standardrutt. Det kommer med minne för RIB och FIB, CPU för uppdateringar, filterunderhåll och en ägare för den resulterande tabellen.

Kapacitetsargument går fel i båda riktningarna. En full tabell är inte förbjuden inne i en VRF, och den är inte gratis heller. På samma sätt kan du inte härleda dagens kostnad från ett gammalt ruttantal, och en mindre etikettilldelning tar inte bort kostnaden för att lagra rutter.

Specifikationen BGP/MPLS IP VPN diskuterar flera internetanslutningsarrangemang vid sidan av själva VPN-tjänsten och förklarar inte en full tabell eller en standardrutt obligatorisk för varje kund, och det är det avsnittet som är värt att peka på när ett påstående om "standardpraxis" dyker upp: RFC 4364.

Avsluta överlämningen genom att registrera den annonserade mängden, den mottagna mängden och den valda mängden bredvid den avtalade utgångspolicyn, och genom att testa en privat destination, en avsedd offentlig destination och ett fall av ruttförlust. Ett signerat protokoll från de tre testerna avgör fler diskussioner än något påstående om vad de flesta nätverk gör.