Warum Ihr L2VPN den gerade gebauten RSVP-TE-LSP ignoriert

Zwei Ingenieure können dasselbe Wartungsfenster verlassen, überzeugt davon, der neue Pfad sei in Betrieb, und beide aus unterschiedlichen Gründen falsch liegen. Der eine baute das LSP und nahm an, der Dienst würde folgen. Der andere ließ den Dienst in Ruhe und nahm an, nichts habe sich geändert. Ein Pseudowire nutzt immer nur den Transport, auf den seine Peer-Adresse in diesem Moment aufgelöst wird, die eigentliche Frage ist also, was diese Auflösung gerade produziert, und die beiden Entwürfe beantworten sie unterschiedlich.

Ein Label benennt einen Dienst, das andere bewegt ein Paket

Das Pseudowire-Label, signalisiert durch gezieltes LDP wie in RFC 4447 beschrieben, sagt dem empfangenden Provider-Edge, welche Attachment-Circuit den Frame erhalten soll. Wie der Frame dorthin kam, sagt es nicht. Das Label darunter gehört zum Transport, und dieser Stack wird von dem gebaut, was Erreichbarkeit für das Peer-Loopback angekündigt hat, ob LDP, RSVP-TE oder ein segmentgerouteter Pfad. Weil unterschiedliche Protokolle die beiden Schichten signalisieren, kann eine gesund sein, während die andere veraltet ist. Diese Trennung ist die gesamte Quelle der Verwirrung.

Man sollte es klar sagen: Das Pseudowire wählt das LSP nicht aus. Es übergibt einen Frame an den Transport, und der Transport entscheidet anhand der Zieladresse, die er bekommen hat.

Das ist auch der Grund, warum ein sauberer Ping über das neue LSP so wenig beweist. Das LSP kann oben, gelabelt und andere Dienste tragend sein, während Ihr Pseudowire sich noch über einen anderen nächsten Hop auflöst. Bis Sie die Bindung lesen, haben diese beiden Fakten nichts miteinander zu tun.

Option A: das Pseudowire an einen gewählten Transport anheften

Anheften heißt, die Transportauflösung des Dienstes deterministisch zu machen. Je nach Plattform geschieht das als Tunnelauswahlrichtlinie, als expliziter Transportendpunkt am Dienst oder als Routenrichtlinie, die den nächsten Hop für die Peer-Adresse umschreibt. Alle drei tun unter der Oberfläche dasselbe: Sie erzwingen die Auflösung eines Ziels auf ein bestimmtes LSP. Das macht das Ergebnis später prüfbar.

Der Preis ist der Umfang. Eine Richtlinie, die auf eine Peer-Adresse passt, betrifft jeden Dienst, der auf diesen Peer zeigt, nicht nur das Pseudowire, das Sie im Sinn hatten.

Der Rückfall verdient eine Entscheidung vor dem Änderungsfenster, nicht währenddessen. Fällt das angeheftete LSP aus, lassen Sie den Dienst entweder über einen anderen genehmigten Pfad laufen oder Sie lassen ihn stoppen. Eine Richtlinie, die still auf einen Pfad zurückfällt, der eine Latenz- oder Disjunktheitsvorgabe verletzt, hat einen sauberen Ausfall in etwas verwandelt, das jedem viel schwerer zu erklären ist.

Option B: den IGP wählen lassen und beobachten, was passiert

Den Dienst in Ruhe zu lassen ist ein legitimer Entwurf und oft der bessere. Das Pseudowire folgt derselben Auflösung wie jeder andere Verkehr zum Peer-Loopback, erbt also IGP-Konvergenz, Präfixunterdrückung und die Redundanz, die der Kern ohnehin bietet. Weniger Richtlinien bedeuten weniger Stellen, an denen sich ein veralteter Treffer verstecken kann. Der Handel ist, dass Sie nicht mehr steuern, welchen Pfad der Dienst nimmt, sondern nur, dass überhaupt ein Pfad existiert.

Equal-Cost-Multipath verschärft diesen Handel stärker, als es zunächst scheint. Hashing erfolgt pro Fluss, sodass zwei Gespräche in einem Pseudowire über verschiedene äußere Labels abgehen können.

Lesen Sie die installierte Weiterleitung, bevor Sie einem von beiden trauen

Beginnen Sie mit der Peer-Adresse statt mit dem Dienst. Auf Junos gibt show route 203.0.113.1 detail den ausgewählten nächsten Hop und die Label-Operation aus, und show route table mpls.0 ordnet das eingehende Label dieser Operation zu. Auf IOS XR liefert show mpls l2transport vc 100 detail den Pseudowire-Zustand zusammen mit dem auferlegten Stack.

Bestätigen Sie das LSP, das der Transport tatsächlich nutzt, nicht das, das Ihr Designdokument nennt. traceroute mpls ipv4 203.0.113.1/32 auf IOS XR läuft den labelvermittelten Pfad ab und listet die Labels und ausgehenden Schnittstellen entlang ihm, was dem eigenen Beobachten des Pfades am nächsten kommt. Wiederholen Sie die Übung dann vom fernen Provider-Edge, denn die Rückrichtung wird unabhängig aufgelöst, und Asymmetrie ist nach einem teilweisen Richtlinien-Rollout üblich. Ein Pfad, der in eine Richtung richtig und in der anderen falsch ist, ist schlimmer als einer, der durchgehend falsch ist, weil die Hälfte Ihrer Tests bestehen wird.

Bewahren Sie die Belege beim Dienst-Datensatz auf: Peer-Adresse, nächster Hop, äußeres Label und das Datum der Prüfung. Routenrichtlinien altern schlecht, und niemand erinnert sich, welche vor zwei Quartalen galt.

Nach Fehlermodus wählen, nicht nach Vorliebe

Anheften passt zu Diensten mit einer Vorgabe, die der IGP nicht ausdrücken kann, und zu Teams, die die Richtlinie durch jede Änderung hindurch pflegen können. Es dem IGP zu überlassen passt zu Diensten, die jeden einzelnen Ausfall ohne einen Menschen in der Schleife überstehen müssen.

Die entscheidende Frage ist, was Sie ein falscher Pfad kostet. Wenn ein Dienst auf dem falschen LSP nur etwas schlechter läuft, lassen Sie den IGP entscheiden und stecken Sie den Aufwand in die Überwachung. Wenn ein falscher Pfad einen Vertrag, einen Prüfungsbefund oder eine Disjunktheitsanforderung bricht, heften Sie ihn an und schreiben Sie den Rückfall auf. Testen Sie dann den Rückfall, denn ein ungetesteter Rückfall ist eine Annahme und kein Plan. So oder so: Lesen Sie die installierte Bindung nach jeder Änderung am Kern neu, und behandeln Sie ein hochgekommenes Pseudowire als Beleg für nichts außer dass die Signalisierung funktioniert.