MPLS-Filialrouting: was die CE lernt und von wem

Ein Host in einer Filiale öffnet eine Verbindung zu einem Server in einer anderen, und beide Standorte liegen hinter derselben verwalteten MPLS-VPN der Schicht 3. Der Host kennt nur sein eigenes Standardgateway und sonst nichts, was korrekt ist. Entscheidend ist, dass die lokale Kundenkante das Paket an ihre Anbieterkante übergibt und dass der VPN-Routingzustand des Anbieters es zu der Filiale bringt, die das Zielpräfix besitzt.

Ein Paket den Pfad entlang zu verfolgen ist der schnellste Weg zu sehen, welcher Teil Kundenverantwortung ist und welcher Teil zum Dienst gehört.

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

Wo der Auftrag jedes Hops endet

CE-A braucht eine Route für das entfernte LAN, die auf ihren lokalen Anbieteranschluss zeigt, nicht auf die WAN-Adresse der entfernten Filiale. Der Anbieter trägt das Paket dann über seinen eigenen Kern mit VPN-Routingzustand, und CE-B liefert es in das Ziel-LAN. An keiner Stelle muss ein Host Labels, VRFs oder die Internetanbindung der Gegenseite verstehen.

Der Fehler, der in Tickets immer wieder auftaucht, ist die WAN-Adresse von Filiale B als nächsten Hop in Filiale A zu konfigurieren. Beide Filialen haben denselben Dienst gekauft, also fühlt es sich an, als müssten sie Nachbarn sein. Sie sind es nicht: Ein nächster Hop muss über das Routingdesign erreichbar sein, das Sie tatsächlich haben, und die entfernte CE liegt meist viele Hops entfernt hinter Geräten, die Sie nicht administrieren. Eine statische Route, die auf dieser Annahme aufbaut, erscheint als aktiv und löst sich in nichts auf, was schlimmer ist als eine fehlende Route, weil sie in der Tabelle korrekt aussieht.

RFC 4364 trennt den Austausch zwischen Kunden- und Anbieterkante von der Verteilung der VPN-Routen durch den Anbieter, und genau diese Grenze behandelt dieses Runbook. Die Aufgabe des Kunden ist es, seiner Kante zu sagen, was sie liefern kann, und die Erreichbarkeit anzunehmen, die der Dienst zurück anbietet.

Worauf sich die Übergabe einigen muss

Wählen Sie den Mechanismus mit dem Anbieter statt um ihn herum. Statische Routen, BGP oder eine Routingprotokoll-Vereinbarung zwischen CE und PE sind alle legitim, und OSPF hat ein definiertes MPLS-VPN-Modell für diese Übergabe. Nichts davon ist ein Grund, eine OSPF-Nachbarschaft zwischen zwei entfernten Kundenkanten über einen nicht spezifizierten Anbieterkern zu bauen, denn das ist ein Design, dem der Anbieter nicht zugestimmt hat und das er nicht unterstützen kann.

Bevor ein neues LAN in Betrieb geht, schreiben Sie vier Dinge auf: das Präfix, die lokale Weiterroute auf der CE, die Ankündigung, die der Anbieter akzeptiert, und die Routen, die der Anbieter zurückgibt. Ergänzen Sie jede Filterung, Präfixgrenze oder Standort-zu-Standort-Beschränkung, die der Vertrag auferlegt. Eine gesunde Nachbarschaft ist ein Kanal für den Informationsaustausch und kein Beweis dafür, dass ein bestimmtes Präfix akzeptiert wurde; die Sitzung kann stehen, während Ihr neues Subnetz in einem Filter hängt.

Folgen Sie dann der Antwort. Filiale B braucht eine Route zurück zum Quell-LAN, und der Host auf der Empfangsseite braucht sein eigenes Gateway und seine eigenen Dienstberechtigungen. Eine Route, die auf CE-A erscheint, begründet einen halben Roundtrip, und ein halber Roundtrip ist der Grund, warum eine Richtung eines Ping-Tests gesund aussieht, während die Anwendung weiterhin scheitert.

Beide Übergaben vor der Abnahme prüfen

Sammeln Sie den Routingzustand an beiden Kundenkanten, bestätigen Sie mit dem Anbieter, dass die vorgesehenen LAN-Präfixe ins VPN übernommen wurden, und testen Sie dann eine erlaubte Anwendung in jede Richtung. Routentabellen allein beweisen nicht, dass die Anwendung funktioniert, und ein Anwendungstest allein sagt Ihnen nicht, welche Steuerungsebene versagt hat, wenn sie nicht funktioniert.

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

Lesen Sie die drei Ausgaben zusammen. Die erste sagt, was die Kante glaubt, die zweite sagt, was sie gelernt hat und von welchem Peer, und die dritte sagt, was sie tatsächlich weiterleiten wird. Uneinigkeit zwischen ihnen ist meist ein Politik- oder Rekursionsproblem statt einer fehlenden Ankündigung, und es lohnt sich, das zu klären, bevor der Anbieter um Untersuchung gebeten wird. Bringen Sie diese drei Ausgaben in das Gespräch mit dem Carrier, denn sie beantworten die meisten Fragen, die ein Support-Ingenieur Ihnen sonst stellen würde.

Wissen, was der Dienst nicht bietet

Dies ist gerouteter Zugang auf Schicht 3. Es ist keine Verbindung auf Schicht 2, die Broadcasts zwischen Standorten ausdehnt, daher reisen Discovery-Protokolle, broadcastabhängige Anwendungen und Annahmen über gemeinsame Segmente nicht mit. Drucken, Namensbrowsen und alles, was von einem lokalen Segment abhängt, braucht ein eigenes Design.

VPN-Trennung ist auch keine Verschlüsselung. Label-Switching hält Kunden im Netz des Anbieters auseinander und macht die Nutzlast nicht vertraulich, wenn der Vertrag Vertraulichkeit verlangt. Wo das zählt, muss die Anwendung oder ein Overlay sie liefern.

Schließlich sollten Sie das Dienstmodell neben der Routingkonfiguration des Standorts schriftlich halten. Der nächste Ingenieur, der ein Subnetz hinzufügt, sollte lesen können, welche Präfixe angekündigt werden, wer sie akzeptiert und wie der erwartete Rückweg aussieht: die BGP/MPLS-IP-VPN-Spezifikation ist die Referenz für das Modell dahinter.