Braucht VPNv4 MPLS im Kern? Nicht unbedingt

Das Aktivieren der VPNv4-Adressfamilie zwischen zwei Routern erzeugt nur einen Routenverteilungskontext und nichts weiter. Es installiert keinen Weiterleitungspfad und sagt nicht, welche Kapselung ein Kundenpaket zum entfernten Endpunkt bringt. Sobald diese beiden Tatsachen getrennt sind, wird aus der Frage „braucht das MPLS im Kern“ eine engere und beantwortbare Frage zur unterstützten Datenebene der Plattform.

Was die Adressfamilie tatsächlich aushandelt

Multiprotokoll-BGP transportiert die Erreichbarkeitsinformationen der VPNv4-Netzwerkschicht unter AFI 1 und SAFI 128, und jeder Eintrag verbindet einen Route Distinguisher mit einem Präfix und einem Label. Die Sitzung handelt aus, dass beide Sprecher diese Informationen kodieren und dekodieren können. Was sie nicht aushandelt, ist eine Datenebene. Alles nach diesem Absatz betrifft die Weiterleitung, und nichts davon wird durch das Zustandekommen der Sitzung entschieden.

Eine erfolgreiche Sitzung ist also ein Beleg für die Fähigkeit der Steuerungsebene, nicht für die Weiterleitung. Ein Router kann Tausende VPNv4-Einträge halten und dennoch jedes Kundenpaket verwerfen, weshalb die beiden Fehlerklassen überhaupt verwechselt werden.

Beachten Sie das Label in der NLRI. Es ist ein Service-Label, an ein Präfix innerhalb einer VRF gebunden, und es hat eine Weiterleitungsrolle, sobald das Paket den Ausgangsendpunkt erreicht. Ob ein Transitgerät es liest, ist eine separate Designentscheidung.

Empfang, Import und Weiterleitung sind drei Schritte

Eine Route zu empfangen, sie verwenden zu dürfen und mit ihr weiterleiten zu können, übernehmen verschiedene Teile des Geräts. BGP speichert, was es hört; Importrichtlinie und Route-Target-Abgleich entscheiden, welche VRF sie berücksichtigen darf; danach muss die Weiterleitungsebene den angekündigten Next Hop in etwas auflösen, das sie tatsächlich auf eine Leitung legen kann.

Genau in diesem mittleren Schritt liegen die überraschendsten Fehler. Eine Route kann in der BGP-Tabelle vorhanden, gültig und sogar beste sein, während die VRF-Routentabelle leer bleibt, weil kein Route-Target zur Importliste passte. Nichts protokolliert einen Protokollfehler, weil kein Protokollfehler aufgetreten ist.

Der letzte Schritt ist der Ort, an dem die Plattformunterstützung sichtbar wird. Ein im Underlay erreichbarer Next Hop ist nicht automatisch als VPN-Servicetransport auflösbar, und das Gerät kann einen bestimmten Tunneltyp, eine bestimmte Label-Operation oder beides verlangen. Den Auflösungsstatus zu lesen ist aussagekräftiger als die Routenzahl zu lesen.

Ein IP-Kern kann einen Stack tragen, den er nie vermittelt

Die Unterscheidung, die man behalten sollte, ist die zwischen „der Kern betreibt kein MPLS“ und „im Dienst existiert nirgends ein Label“. Das sind verschiedene Aussagen, und nur die erste betrifft Transitgeräte. RFC 4023 definiert das Tragen von MPLS durch IP- oder GRE-Tunnel, und das ist der Mechanismus, der die zweite Aussage auf einem reinen IP-Kern möglich macht.

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 meaningful

Transitrouter leiten anhand des äußeren IP-Ziels weiter und brauchen weder die Kundenpräfixe noch natives Label-Switching. Am fernen Ende wird der äußere Tunnel entfernt, und das Service-Label nimmt seine Aufgabe wieder auf. Der Kern hat eine undurchsichtige Nutzlast bewegt, und genau dafür ist ein IP-Netz gut.

Was dieses Design Ihnen nicht gibt, ist eine universelle Garantie. Es ist kein Beweis dafür, dass jeder Router jeden VPNv4-Next-Hop über jede GRE-Schnittstelle auflöst, und kein Grund, eine funktionierende native MPLS-Konfiguration zu löschen. Es ist ein Gegenbeispiel zur universellen Aussage, und die praktische Frage bleibt lokal zur Plattform. Notieren Sie diese Frage als Plattformbeschränkung statt als Protokollregel.

Gehen Sie die Kette auf der Box durch, bis sie bricht

Beginnen Sie bei der empfangenen Route und halten Sie beim ersten Schritt an, der fehlschlägt, denn die späteren Schritte lassen sich nicht diagnostizieren, solange ein früherer defekt ist. Vier Befehle decken das meiste davon in einer typischen Implementierung ab.

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_A

Lesen Sie sie als Abfolge und nicht als vier unabhängige Prüfungen. Der erste bestätigt, dass die Familie aktiv ist und der Peer Routen austauscht; der zweite zeigt, ob das Präfix mit einem brauchbaren Next Hop ankam; der dritte belegt die Importberechtigung; der vierte zeigt, ob die Weiterleitungsebene ein Label oder einen Tunnel daran gebunden hat.

Testen Sie dann den Arbeitslastpfad in beide Richtungen, mit einer MTU, die die Kapselung übersteht. GRE fügt Header-Bytes hinzu, und ein Pfad, der kleine Proben besteht, kann bei paketgroßen Paketen nur in einer Richtung scheitern, was wie ein Anwendungsfehler statt eines Transportfehlers aussieht.

Zwei Betriebshinweise schließen den Kreis. GRE ist Kapselung, nicht Vertraulichkeit, daher braucht ein nicht vertrauenswürdiges Transitnetz eine unterstützte Sicherheitsregelung obenauf statt einer Annahme. Und notieren Sie vor der Designprüfung, welche Kapselung die Plattform tatsächlich unterstützt, denn diese eine Antwort entscheidet, ob ein reiner IP-Kern eine gültige Wahl ist oder ein Plan, der nicht weiterleiten kann.