L3VPN-Übergabe: private Routen, eine Default-Route oder eine volle Tabelle?

Ihre Leitung steht, die VRF ist konfiguriert, und der Anbieter stellt eine kurze Frage, die den Rest des Designs entscheidet: was soll die Kundenseite erhalten? Drei Antworten sind üblich, und keine von ihnen folgt daraus, dass ein Labelstack existiert. Es sind Serviceentscheidungen darüber, wo der Verkehr die Filiale verlässt.

Die Übergabe der Reihe nach durchzugehen ist der billigste Weg, das richtig zu machen. Sie beginnen damit, was mit Verkehr geschieht, der nichts trifft, schreiben dann die privaten Präfixe und ihr Fehlerverhalten auf, und erst danach sprechen Sie darüber, wie groß ein Feed sein darf, den Sie tragen wollen.

Beginnen Sie mit dem Verkehr, den niemand eingeplant hat

Stellen Sie eine Frage, bevor irgendeine Präfixliste auftaucht: Wenn ein Paket keine private Route trifft, wohin soll es gehen? Eine Filiale mit eigener Internetleitung behält meist eine lokale Default-Route, sodass gewöhnlicher Webverkehr über die lokale Firewall hinausgeht und den Anbieter nie berührt. In diesem Design trägt das VPN nur die entfernten privaten Standorte, und die spezifischeren Präfixe treffen die Auswahl.

Eine Filiale, die einen zentralen Ausgang nutzen soll, ist der umgekehrte Fall. Dort zeigt die Default-Route in den Dienst, und der Anbieter oder der zentrale Standort verantwortet Weiterleitung, Rückweg und jede Übersetzung. "Default ins VPN" zu sagen, ohne diesen Verantwortlichen zu haben, erzeugt eine Filiale, die Namen auflöst und nichts erreicht.

Die beiden Designs unterscheiden sich darin, wie ein Routingfehler aussieht, und deshalb ist Raten teuer. Mit einer lokalen Default-Route schickt eine verlorene private Route diesen Verkehr ins Internet, wo die Firewall ihn verwirft oder, schlimmer, etwas antwortet, das Sie nicht beabsichtigt hatten. Mit einer zentralen Default-Route nimmt derselbe Verlust den Internetzugang vollständig weg, und das Ticket kommt als "die ganze Filiale ist down" an. Keiner der beiden Fehler ist für sich falsch, aber nur einer passt zu dem Service, den Sie verkauft haben, und eine BGP-Konfiguration allein sagt Ihnen nicht, welchen Sie gebaut haben.

Schreiben Sie die privaten Präfixe mit ihrem Fehlerfall auf

Listen Sie die Präfixe auf, die die Filiale erreichen muss, und notieren Sie, welche davon zusammengefasst sind. Ein Aggregat, das ein Bit zu breit ist, zieht unbekannte Ziele ins VPN, was nur dann in Ordnung ist, wenn die Gegenseite sie tatsächlich besitzt und weiterleitet.

Beschreiben Sie dann das beabsichtigte Verhalten, wenn der private Dienst ausfällt. Eine gehaltene Discard-Route hält Verkehr von einem nicht autorisierten Pfad fern und erzeugt einen sauberen, erwarteten Ausfall. Eine schwebende Default-Route kann die Verfügbarkeit erhalten, indem sie auf einen Sicherungspfad ausweicht, aber nur, wenn der Sicherungspfad berechtigt ist, diesen Verkehr zu tragen.

Halten Sie Verfügbarkeit und erlaubten Rückfall im Übergabedokument als zwei getrennte Anforderungen. Teams, die beides zusammenwerfen, streiten am Ende darüber, ob die Filiale hätte ausfallen sollen, statt zu prüfen, ob die vereinbarte Richtlinie umgesetzt wurde.

Prüfen Sie, was der CE wirklich installiert hat

Konfigurationsabsicht und Weiterleitungszustand weichen oft genug voneinander ab, dass die Überprüfung in die Übergabe gehört und nicht in die Incident-Review. An einer IOS-XE-Kundenseite beantworten die drei Befehle unten drei verschiedene Fragen: was angeboten wurde, was akzeptiert wurde und was tatsächlich genutzt wird.

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

Führen Sie alle drei am Tag der Übergabe aus und nicht einen Monat später, solange noch jemand weiß, was vereinbart wurde. Die erste Ausgabe hängt von soft-reconfiguration inbound oder einer gespeicherten Routenaktualisierung ab; ohne eines von beiden kann der CE Ihnen nicht zeigen, was er verworfen hat. Die zweite zeigt akzeptierte und beste Pfade nach der Richtlinie. Die dritte sagt Ihnen, wohin die Default-Route wirklich geht, und das ist die nützlichste Zeile der ganzen Übergabe.

Führen Sie dieselben Prüfungen an einem zweiten CE aus, wenn der Standort dual-homed ist. Asymmetrische Annahme zwischen zwei Kanten ist eine häufige Ursache für "es funktioniert von einem Server und vom anderen nicht", und sie ist in einem Konfigurationsdiff, der symmetrisch aussieht, unsichtbar.

Qualifizieren Sie einen größeren Feed, statt ihn anzunehmen

Manchmal braucht der Kunde wirklich Internetpfadinformationen innerhalb der VRF, für Policy-Routing oder für einen zentralen Ausgang, der nach Präfix steuert. Das ist eine Anforderung, die man benennt, abgrenzt und bepreist, kein versteckter Default. Sie kommt mit Speicher für RIB und FIB, CPU für Updates, Filterpflege und einem Eigentümer für die resultierende Tabelle.

Kapazitätsargumente gehen in beide Richtungen schief. Eine volle Tabelle ist innerhalb einer VRF nicht verboten, und sie ist auch nicht kostenlos. Ebenso lässt sich der heutige Aufwand nicht aus einer alten Routenzahl ableiten, und eine kleinere Labelzuweisung beseitigt die Kosten für das Speichern von Routen nicht.

Die Spezifikation BGP/MPLS IP VPN erörtert mehrere Internetzugangsarrangements neben dem VPN-Dienst selbst und erklärt weder eine volle Tabelle noch einen Default für jeden Kunden für verbindlich, und das ist der Abschnitt, auf den man zeigen sollte, wenn eine Behauptung über "Standardpraxis" auftaucht: RFC 4364.

Schließen Sie die Übergabe ab, indem Sie das angekündigte Set, das empfangene Set und das ausgewählte Set neben der vereinbarten Ausgangsrichtlinie festhalten und ein privates Ziel, ein beabsichtigtes öffentliches Ziel und einen Routenverlustfall testen. Ein unterschriebenes Protokoll dieser drei Tests klärt mehr Streit als jede Aussage darüber, was die meisten Netze tun.