BGP en MPLS in een VPN: welk deel draagt het pakket

De vraag of een VPN op BGP of MPLS draait, mengt twee lagen in één beslissing. BGP verdeelt bereikbaarheid en beleid. MPLS stuurt pakketten door met behulp van de geïnstalleerde labelstatus. In een BGP/MPLS-VPN werken beide samen, en het verwijderen van een van de twee laat helemaal geen dienst over. De controles hieronder leiden dezelfde prefix door beide lagen, zodat u precies ziet waar de uwe is gestopt.

Controle 1: staat de prefix in de juiste VRF

Begin bij de inkomende rand van de provider en vraag bij welke VRF de klantprefix hoort. Overlappende klantadressen zijn normaal in dit ontwerp, dus de VRF is de context die twee klanten die beide 10.0.0.0/8 gebruiken gescheiden houdt.

Ontbreekt de prefix daar, dan kan niets later correct zijn en zijn de resterende controles verspilde moeite.

Controle 2: is de VPN-route verdeeld en geïmporteerd

De provider verdeelt klantroutes met MP-BGP. Elke route draagt een routeonderscheider, die anders identieke prefixen uniek maakt, en routedoelen, die bepalen welke VRF's de route importeren. Een route die aankomt maar niet wordt geïmporteerd, laat de ontvangende VRF leeg voor die prefix. Controleer het importbeleid voordat u de verre kant de schuld geeft.

Routekeuze is ook van belang: een voorkeurspad via een andere providerrand vervangt het pad dat u verwachtte te zien.

Controle 3: wat de inkomende rand met het pakket doet

Wanneer een pakket aankomt, doet de inkomende rand een IP-opzoeking in de VRF en hangt vervolgens labels aan het gekozen pad. De stapel heeft twee logische rollen, ook wanneer een opname een ander aantal labels toont.

transport label toward the egress edge
VPN service label for the egress forwarding action
customer IP packet

De specificatie voor BGP/MPLS-VPN's beschrijft die opstelling. Het poppen van het label op de voorlaatste hop kan het transportlabel vóór de laatste hop verwijderen, dus een opname met twee labels uit het midden van het netwerk is geen bewijs van een storing.

Controle 4: stuurt het onderliggende netwerk die labels door

Transitrouters schakelen op basis van hun geïnstalleerde labelvermeldingen. Ze lezen geen BGP-updates om te beslissen wat er met uw individuele pakket gebeurt. Daarom kan een klantroute aanwezig zijn terwijl doorsturen nog steeds mislukt: de opgeloste volgende hop of het transportlabel kan onafhankelijk breken. Een VPN-prefix leren repareert het onderliggende netwerk eronder niet.

Controleer de labelbinding richting de uitgaande rand, niet alleen het bestaan van de route.

Controle 5: de actie aan de uitgang en de retourroute

Aan de uitgang bepaalt het servicelabel de doorstuuractie, wordt het pakket gedecapsuleerd en gaat het richting de klantbestemming. Vanaf daar moet ook de retourroute werken, inclusief het toegangsbeleid aan klantzijde op die interface.

Succes in één richting is meestal een retourroute of een filter, niet de labelstapel.

Lees uw symptoom in een van die controles

Een route die ontbreekt in de ontvangende VRF betekent aankondiging, importbeleid of routekeuze. Een route die aanwezig is terwijl pakketten falen betekent de opgeloste volgende hop, het labeldoorsturen of de retourroute aan klantzijde. Pakketten die op de verkeerde bestemming aankomen betekenen meestal dat u de verkeerde VRF onderzoekt. Niets hiervan is een reden om het routingprotocol te wijzigen.

Nog één ding is de moeite waard om ronduit te zeggen: dit ontwerp scheidt klanten en stuurt hun verkeer efficiënt door. Het versleutelt niet, en het als een vertrouwelijkheidsdienst behandelen is een aparte fout.