MPLS-vestigingsrouting: wat de CE leert, en van wie

Een host op de ene vestiging opent een verbinding naar een server op een andere, en beide locaties staan achter dezelfde beheerde MPLS VPN op laag 3. De host kent alleen zijn eigen standaardgateway en niets anders, wat correct is. Het belangrijkste is dat de lokale klantrand het pakket naar zijn providerrand overdraagt, en dat de VPN-routingstatus van de provider het naar de vestiging brengt die het bestemmingsprefix bezit.

Eén pakket langs het pad volgen is de snelste manier om te zien welk deel verantwoordelijkheid van de klant is en welk deel bij de dienst hoort.

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

Waar het werk van elke hop eindigt

De CE-A heeft een route naar het verre LAN nodig die naar zijn lokale provideraansluiting wijst, niet naar het WAN-adres van de verre vestiging. Daarna draagt de provider het pakket via zijn eigen kern met de VPN-routingstatus, en de CE-B levert het af op het doel-LAN. Op geen enkel moment hoeft een host labels, VRF's of het internetcircuit van de andere kant te begrijpen.

De fout die steeds terugkomt in tickets is het WAN-adres van vestiging B als volgende hop op vestiging A configureren. Beide vestigingen hebben dezelfde dienst gekocht, dus het voelt alsof ze buren zouden moeten zijn. Dat zijn ze niet: een volgende hop moet bereikbaar zijn via het routingontwerp dat u werkelijk hebt, en de verre CE staat meestal vele hops verder achter apparatuur die u niet beheert. Een statische route die op die aanname is gebouwd, verschijnt als actief en lost naar niets op, wat erger is dan een ontbrekende route omdat hij in de tabel correct lijkt.

RFC 4364 scheidt de uitwisseling tussen klant- en providerrand van de verspreiding van VPN-routes door de provider, en dat is precies de grens waarover deze handleiding gaat. De taak van de klant is zijn rand vertellen wat hij kan leveren en de bereikbaarheid accepteren die de dienst terug biedt.

Waarover de overdracht het eens moet worden

Kies het mechanisme samen met de provider, niet eromheen. Statische routes, BGP of een routingprotocolafspraak tussen CE en PE zijn allemaal legitiem, en OSPF heeft een gedefinieerd MPLS VPN-model voor die overdracht. Geen daarvan is een reden om een OSPF-buurschap te bouwen tussen twee verre klantranden over een niet-gespecificeerde providerkern, want dat is een ontwerp waar de provider niet mee heeft ingestemd en dat hij niet kan ondersteunen.

Voordat een nieuw LAN in bedrijf gaat, schrijft u vier dingen op: het prefix, de lokale vervolgroute op de CE, de aankondiging die de provider accepteert, en de routes die de provider teruggeeft. Voeg alle filtering, prefixlimieten of beperkingen tussen locaties toe die het contract oplegt. Een gezond buurschap is een kanaal om informatie uit te wisselen, en het is geen bewijs dat een bepaald prefix is geaccepteerd; de sessie kan omhoog staan terwijl uw nieuwe subnet in een filter zit.

Volg dan het antwoord. Vestiging B heeft een route terug naar het bron-LAN nodig, en de host aan de ontvangende kant heeft zijn eigen gateway en zijn eigen dienstmachtigingen nodig. Een route die op de CE-A verschijnt, legt de helft van een retourreis vast, en die halve reis is de reden dat één richting van een ping-test gezond lijkt terwijl de toepassing nog steeds faalt.

Controleer beide overdrachten vóór acceptatie

Verzamel de routingstatus op beide klantranden, bevestig met de provider dat de bedoelde LAN-prefixen in de VPN zijn geaccepteerd, en test dan één toegestane toepassing in elke richting. Routetabellen alleen bewijzen niet dat de toepassing werkt, en een toepassingstest alleen vertelt u niet welk controleplan faalde toen het niet werkte.

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

Lees de drie uitvoer samen. De eerste zegt wat de rand gelooft, de tweede zegt wat hij heeft geleerd en van welke peer, en de derde zegt wat hij werkelijk doorstuurt. Onenigheid daartussen is meestal een beleids- of recursieprobleem in plaats van een ontbrekende aankondiging, en het is de moeite waard dat op te lossen voordat de provider wordt gevraagd te onderzoeken. Neem die drie uitvoer mee naar het gesprek met de carrier, want ze beantwoorden de meeste vragen die een supportengineer u anders zou stellen.

Weet wat de dienst niet levert

Dit is gerouteerde toegang op laag 3. Dit is geen circuit op laag 2 dat broadcasts tussen kantoren uitbreidt, dus discoveryprotocollen, broadcastafhankelijke toepassingen en aannames over een gedeeld segment reizen niet mee. Afdrukken, naambladeren en alles wat van een lokaal segment afhangt, hebben hun eigen ontwerp nodig.

VPN-scheiding is ook geen versleuteling. Labelschakeling houdt klanten gescheiden binnen het netwerk van de provider, en het maakt de payload niet vertrouwelijk als het contract vertrouwelijkheid eist. Waar dat telt, moet de toepassing of een overlay het leveren.

Ten slotte houdt u het dienstmodel schriftelijk naast de routingconfiguratie van de locatie. De volgende engineer die een subnet toevoegt, moet kunnen lezen welke prefixen worden aangekondigd, wie ze accepteert en wat het verwachte retourpad is: de BGP/MPLS IP VPN-specificatie is de referentie voor het model erachter.