VPNv4 zwischen AS: Was der Vertrag zur Labelweiterleitung verlangt

Ein VPNv4-Label auf einem AS-Grenzrouter zu lesen sagt wenig, bis man weiß, welches Inter-AS-Modell die Übergabe umsetzt. Das Label ist keine Eigenschaft der Route allein; es hält eine Vereinbarung über Kapselung und Zustellung zwischen zwei Routern fest. Bestimmen Sie das Modell, bevor Sie die Anzeige lesen. Sonst debuggen Sie einen Vertrag, den niemand aufgeschrieben hat.

Welches Modell die Grenze umsetzt

Die VRF-zu-VRF-Anordnung verbindet passende VRFs über geroutete Anbindungen. Jede Seite sieht die andere als Kundenrand-Nachbarn, und sie tauschen gewöhnliche IPv4-Routen aus, sodass an dieser Grenze nichts MPLS braucht.

Eine zweite Anordnung tauscht gelabelte VPNv4-Routen zwischen den Grenzroutern selbst. Das funktioniert nur mit einem zusammenhängenden labelvermittelten Pfad über die Zwischenverbindung und mit einer Route-Target-Verteilung samt Vertrauensmodell, das beide Seiten akzeptieren. Fehlt einer der Teile, ist das Modell nicht im Einsatz, was die Konfiguration auch immer nahelegt.

Die dritte verteilt gelabelte PE-Erreichbarkeit, während die VPN-Routen zwischen Endpunkten oder Routereflektoren über AS hinweg laufen. Jede der drei hinterlässt andere Arbeit an der Grenze, und die Steuerungsebene der einen mit den Schnittstellenannahmen der anderen zu mischen ist der klassische Fehler. Diese Unstimmigkeit zeigt sich meist als ein Label, das auf einer Seite richtig aussieht und auf der anderen verschwindet.

Ein Präfix von Ende zu Ende lesen

Nehmen Sie ein einzelnes autorisiertes Kundenpräfix und gehen Sie es durch. Sehen Sie, was angekündigt wurde, was ankam, den nächsten Hop, das Label und die Importrichtlinie, die es zuließ. Sehen Sie dann nach, wie der Router die Weiterleitung zu diesem nächsten Hop auflöst, denn dort wird aus einem Label ein Paket. Lassen Sie eine der beiden Hälften aus, beschreiben Sie eine Steuerungsebene, die möglicherweise keinen Verkehr bewegt. Die beiden Lesarten ergeben nur zusammen Sinn.

Die Zahl ist lokal. Sie bedeutet etwas im Verhältnis zu dem Router, der sie vergeben hat, und zu dem Pfad, der Pakete dorthin trägt, weshalb derselbe Wert zweimal auftauchen und zwei verschiedene Dinge meinen kann. Vergleichen Sie ihn mit dem, was die empfangende Seite zu haben angibt.

Das Label ist lokal, und das Versprechen auch

Die Fähigkeit wird an beiden Enden der Zwischenverbindung geprüft, nicht an einem. Ein Befehl auf Ihrer Schnittstelle bewirkt nichts an der Schnittstelle des benachbarten Anbieters, und eine von BGP akzeptierte Route verpflichtet den Nachbarn nicht von sich aus, ein gelabeltes Paket weiterzuleiten.

RFC 4364 beschränkt gelabeltes VPNv4-Peering auf vertrauenswürdige Anordnungen und warnt davor, Labels zu akzeptieren, die diesem Peer nie angekündigt wurden. Das ist eine Sicherheitsaussage ebenso wie eine Protokollaussage. Halten Sie die öffentliche Internet-Routingbeziehung vom privaten VPN-Routenaustausch fern. Ist die Zwischenverbindung reines IP, erwarten Sie nicht, dass ein Label sie übersteht. Und wo die Strecke gelabelt ist, bestätigen Sie, dass das äußere Transportlabel an jedem Hop korrekt getauscht wird.

Ein Label, das auf einer Seite richtig aussieht und auf der anderen verschwindet, ist meist diese Unstimmigkeit, kein Routingfehler.

Was bei der Abnahme festzuhalten ist

Abnahme ist ein Pakettest, keine Tabellenprüfung. Verfolgen Sie ein Kundenpaket in die entfernte VRF und seine Antwort zurück, und notieren Sie dann, welches Modell die Übergabe umsetzt. Ergänzen Sie die Übergabeverantwortlichen auf beiden Seiten und ob die Grenze reines IP oder gelabelten Verkehr trägt.

Diese Notiz ist es, die den nächsten Betreiber dieselbe Labelanzeige richtig lesen lässt. Ohne sie wird das Modell aus der Konfiguration abgeleitet, und abgeleitete Annahmen sind der Weg, auf dem derselbe Fehler wiederholt wird. Der Inter-AS-Abschnitt von RFC 4364 ist der Ort, an dem zu klären ist, welches Modell gemeint war.