Heeft VPNv4 MPLS in de kern nodig? Niet per se
BGP VPNv4 onderhandelt een routedistributiecontext, geen doorstuurpad. Scheid de import, de resolutie van de volgende hop en de inkapseling die je kunt draaien.
Het aanzetten van de VPNv4-adresfamilie tussen twee routers creëert alleen een routedistributiecontext en niets meer. Het installeert geen doorstuurpad en zegt niet welke inkapseling een klantpakket naar het externe eindpunt brengt. Zodra die twee feiten gescheiden zijn, wordt de vraag «heeft dit MPLS in de kern nodig» een smallere en beantwoordbare vraag over het dataplane dat het platform ondersteunt.
Wat de adresfamilie werkelijk onderhandelt
Multiprotocol-BGP draagt de bereikbaarheidsinformatie van de VPNv4-netwerklaag onder AFI 1 en SAFI 128, en elke vermelding koppelt een routedistinguisher aan een prefix en een label. De sessie onderhandelt dat beide sprekers die informatie kunnen coderen en decoderen. Wat zij niet onderhandelt, is een dataplane. Alles na deze alinea gaat over doorsturen, en niets daarvan wordt beslecht door het opkomen van de sessie.
Een geslaagde sessie is dus bewijs van het vermogen van het controleplane, niet van doorsturen. Een router kan duizenden VPNv4-vermeldingen houden en toch elk klantpakket laten vallen, en dat is waarom de twee foutklassen überhaupt worden verward.
Let op het label in de NLRI. Het is een servicelabel, gebonden aan een prefix binnen een VRF, en het heeft een doorstuurrol zodra het pakket het uitgaande eindpunt bereikt. Of een transportapparaat het leest, is een aparte ontwerpbeslissing.
Ontvangst, import en doorsturen zijn drie stappen
Een route ontvangen, er toestemming voor hebben en ermee kunnen doorsturen wordt door verschillende delen van het apparaat gedaan. BGP slaat op wat het hoort; importbeleid en route-target-overeenkomst bepalen welke VRF hem mag overwegen; daarna moet het doorstuurplane de aangekondigde volgende hop oplossen in iets wat het echt op een draad kan zetten.
| Step in the chain | What has to be true | How it fails quietly |
|---|---|---|
| NLRI exchange | Both speakers negotiate the VPNv4 capability | Session stays up while the family is never activated |
| Import eligibility | A route target on the received route matches the VRF import policy | The route exists in the table but never enters the VRF |
| Next-hop resolution | The advertised next hop resolves to a usable tunnel or label path | Best path is selected, then marked unreachable or unusable |
| Encapsulation | The egress endpoint can decapsulate what the ingress produced | Packets arrive and are discarded for a format mismatch |
In die middelste stap leven de meest verrassende fouten. Een route kan aanwezig zijn in de BGP-tabel, geldig en zelfs de beste, terwijl de VRF-routetabel leeg blijft omdat geen enkel route-target overeenkwam met de importlijst. Niets logt een protocolfout, omdat er geen protocolfout optrad.
De laatste stap is waar platformondersteuning zichtbaar wordt. Een volgende hop die bereikbaar is in de underlay is niet automatisch oplosbaar als VPN-servicetransport, en het apparaat kan een bepaald tunneltype, een bepaalde labeloperatie of beide vereisen. De resolutiestatus lezen is informatiever dan het aantal routes lezen.
Een IP-kern kan een stack dragen die hij nooit schakelt
Het onderscheid dat de moeite waard is, is tussen «de kern draait geen MPLS» en «er bestaat nergens in de dienst een label». Dat zijn verschillende beweringen, en alleen de eerste gaat over transportapparaten. RFC 4023 definieert het dragen van MPLS door IP- of GRE-tunnels, en dat is het mechanisme dat de tweede bewering mogelijk maakt op een volledig IP-kern.
customer packet + service label
encapsulated in GRE, addressed to the egress tunnel endpoint
forwarded by ordinary IP routers on the outer header
decapsulated at the endpoint, label still meaningfulTransportrouters sturen door op de buitenste IP-bestemming en hebben noch de klantprefixen noch native labelschakeling nodig. Aan de verre kant wordt de buitenste tunnel verwijderd en hervat het servicelabel zijn werk. De kern verplaatste een ondoorzichtige lading, en dat is precies waar een IP-netwerk goed in is.
Wat dit ontwerp je niet geeft, is een universele garantie. Het is geen bewijs dat elke router elke VPNv4-volgende-hop via welke GRE-interface dan ook oplost, en het is geen reden om een werkende native MPLS-configuratie te verwijderen. Het is een tegenvoorbeeld voor de universele bewering, en de praktische vraag blijft lokaal voor het platform. Noteer die vraag als een platformbeperking en niet als een protocolregel.
Loop de keten op de doos door tot hij breekt
Begin bij de ontvangen route en stop bij de eerste stap die faalt, want de latere stappen kunnen niet worden gediagnosticeerd zolang een eerdere kapot is. Vier opdrachten dekken het meeste daarvan in een typische implementatie.
show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_ALees ze als een reeks en niet als vier onafhankelijke controles. De eerste bevestigt dat de familie actief is en dat de peer routes uitwisselt; de tweede laat zien of het prefix aankwam met een bruikbare volgende hop; de derde bewijst importgeschiktheid; de vierde laat zien of het doorstuurplane er een label of tunnel aan verbond.
Test daarna het pad van de werkbelasting in beide richtingen, met een MTU die inkapseling overleeft. GRE voegt headerbytes toe, en een pad dat kleine probes haalt, kan op pakketten van volledige grootte in slechts één richting falen, wat op een applicatiefout lijkt en niet op een transportfout.
Twee operationele notities sluiten de cirkel. GRE is inkapseling, geen vertrouwelijkheid, dus een niet-vertrouwd transportnetwerk heeft een ondersteunde beveiligingsregeling erbovenop nodig en geen aanname. En noteer welke inkapseling het platform werkelijk ondersteunt vóór de ontwerpbespreking, want dat ene antwoord bepaalt of een alleen-IP-kern een geldige keuze is of een plan dat niet kan doorsturen.