Der RSVP-TE-Tunnel steht, aber das Kunden-L3VPN hat keinen Pfad
Transport und Dienst sind getrennte Entscheidungen. Lesen Sie den Labelstapel, prüfen Sie Next-Hop-Auflösung und VRF-Anbindung getrennt und testen Sie dann einen echten Kundenfluss.
Zwei Teams können beide recht haben, wenn der Kunde meldet, dass das VPN ausgefallen ist, und das Transportteam meldet, dass der Tunnel in Ordnung ist. Ein verkehrstechnisch gelenkter LSP und ein MPLS L3VPN beantworten unterschiedliche Fragen: Der eine bewegt markierte Pakete durch den Kern, der andere entscheidet, welchem Routing-Kontext ein Paket angehört. Werden sie vermischt, dreht sich die Diskussion im Kreis, weil jede Seite ein anderes Objekt misst und beide Messungen gültig sind.
Transport oben und Dienst unten ist ein normaler Zustand
Ein LSP kann aufgebaut sein, Verkehr führen und in jedem Überwachungssystem sichtbar sein, während der Kundendienst unbrauchbar bleibt. Nichts an dieser Kombination ist widersprüchlich, denn der Tunnel hat keine Meinung dazu, ob ein entferntes Präfix existiert, ob eine Importrichtlinie es akzeptiert hat oder ob die Anbindungsschaltung Frames weiterleitet.
Das Symptom, das die Verwechslung meist aufdeckt, ist asymmetrisch: Pings vom PE-Loopback gelingen, während ein Host im Kundennetz nichts bekommt, oder umgekehrt. Notieren Sie, welche Adressen funktioniert haben, bevor Sie eine Theorie bilden. Sobald Sie bemerken, dass Sie zwei verschiedene Objekte testen, besteht der nächste Schritt darin, den Labelstapel zu lesen, statt darüber zu streiten, wessen Grafik korrekt ist. Zwei Adressen, zwei Verantwortliche und meist zwei verschiedene Menschen, die jeweils glauben, der andere habe etwas kaputt gemacht.
Lesen Sie den Stapel als zwei Zuständigkeiten
Das untere Label gehört zum Dienst und das obere Label gehört zum Pfad. RFC 4364 beschreibt die Reihenfolge schlicht: Zuerst wird das VPN-Routenlabel aufgedrückt, dann wird dieses markierte Paket zum BGP-Next-Hop getunnelt, wo ein Verkehrstechnik-Tunnel sein eigenes Label obenauf legt.
| Object | Decision it encodes | Who owns it |
|---|---|---|
| Attachment and VRF | Which customer context receives the arriving packet | Edge configuration |
| VPN route and service label | Which remote forwarding context handles the destination | BGP VPN signalling |
| Transport LSP and tunnel label | How the core carries the packet to the BGP next hop | RSVP-TE or another tunnel mechanism |
Am entfernten PE wählt das Dienstlabel die Behandlung, die ein VRF-Lookup oder eine Anbindungsentscheidung sein kann. Dieses Label lässt sich nicht gegen eines tauschen, das nur den Kern durchquert, und die beiden sind nicht austauschbar, selbst wenn beide im selben Stapel auf derselben Schnittstelle erscheinen.
Was RSVP-Erfolg beweist und was nicht
RSVP-TE baut explizit geroutete LSPs auf, mit oder ohne Ressourcenreservierung, was eine konkrete und nützliche Zusage über den Weg eines Pakets durch den Kern ist. Es ist keine Aussage über Kundenrouten, und ein konfigurierter Tunnelname ist überhaupt keine Route.
Auch die Existenz von RSVP liefert kein Ende-zu-Ende-Leistungsversprechen. Eine Bandbreitenreservierung auf einem LSP sagt nichts über die Anbindungsschaltung, die eigene Zugangsleitung des Kunden oder das Warteschlangenverhalten am fernen Rand. Wer sie als Garantie behandelt, erhält zuversichtliche Antworten auf Fragen, die niemand gestellt hat. Wenn die Anforderung tatsächlich eine Bandbreitenzusage ist, muss sie aus den Teilen zusammengesetzt werden, die eine solche tatsächlich durchsetzen, und der LSP ist nur die Mitte dieser Kette.
In der Reihenfolge prüfen, dann aufhören
Arbeiten Sie vom Transport nach außen und halten Sie beim ersten Schritt an, der scheitert, weil jeder spätere Schritt voraussetzt, dass die früheren gehalten haben. Bestätigen Sie zuerst, dass der LSP aufgebaut ist und dass der Weiterleitungseintrag für das Dienstpräfix tatsächlich darauf zeigt. Bestätigen Sie dann, dass die VPN-Route in der richtigen Tabelle existiert, dass ihre Labelbindung vorhanden ist und dass die Importrichtlinie sie akzeptiert hat. Bestätigen Sie dann die Anbindung: die Schnittstelle, die Kapselung und, wo zutreffend, die VLAN-Kennung, die zu diesem Vertrag gehört.
show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMERDie Befehlssyntax variiert je nach Plattform, behandeln Sie diese vier Zeilen daher als die vier Fragen und nicht als Skript. Wichtig ist, dass jede von ihnen ein anderes Objekt abfragt, und genau das lässt einen Fehler auf einen bestimmten Verantwortlichen zeigen.
Verfolgen Sie eine erlaubte Anfrage und bewahren Sie die guten Belege
Schließen Sie mit einer einzigen echten Kundenanfrage, die die Richtlinie zulässt, und ihrer Antwort ab. Ein funktionierender Fluss von Ende zu Ende klärt mehr als eine Seite Zählerstände, und er prüft die Kombination statt jedes Teil isoliert.
Wenn eine spätere Stufe scheitert, bewahren Sie die erfolgreiche LSP-Beobachtung, statt den Transport neu aufzubauen. Der Neuaufbau eines funktionierenden Tunnels kann ein fehlendes entferntes Präfix, eine falsche VRF-Anbindung oder eine Ziel-Zugriffsregel nicht reparieren, und er zerstört den Beleg, der Ihnen ursprünglich gesagt hat, dass der Transport gesund war.