Farbbasierte Traffic-Engineering-Konfiguration
BGP Classful Transport Planes – Übersicht
- Vorteile von BGP Classful Transport Planes
- Terminologie der BGP-Classful-Transportebenen
- Grundlegendes zu BGP Classful Transport Planes
- AS-interne Implementierung von BGP Classful Transport Planes
- Inter-AS-Implementierung von BGP Classful Transport Planes
- BGP Classful Transport (BGP-CT) mit zugrunde liegenden farbigen SR-TE-Tunneln – Übersicht
- Vorteile von BGP-CT mit darunter liegenden farbigen SR-TE-Tunneln
Vorteile von BGP Classful Transport Planes
-
Network-Slicing: Service- und Transportschichten sind voneinander entkoppelt und legen mit dem End-to-End-Slicing über mehrere Domänen hinweg den Grundstein für Network-Slicing und Virtualisierung, wodurch die Investitionskosten erheblich reduziert werden.
- Interoperabilität zwischen Domänen: Erweitert die Bereitstellung von Transportklassen über kooperierende Domänen hinweg, sodass die verschiedenen Transportsignalisierungsprotokolle in jeder Domäne zusammenarbeiten können. Gleichen Sie alle Unterschiede zwischen erweiterten Communitynamespaces ab, die in den einzelnen Domänen verwendet werden können.
-
Farbige Auflösung mit Fallback: Ermöglicht die Auflösung über farbige Tunnel (RSVP, IS-IS-flexibler Algorithmus) mit flexiblen Fallback-Optionen über Best-Effort-Tunnel oder andere Farbtunnel.
- Quality-of-Service:Passt das Netzwerk an und optimiert es, um die End-to-End-SLA-Anforderungen zu erfüllen.
- Nutzung vorhandener Bereitstellungen: Unterstützt gut implementierte Tunneling-Protokolle wie RSVP sowie neue Protokolle, wie z. B. den flexiblen IS-IS-Algorithmus, wodurch der ROI erhalten bleibt und die Betriebskosten gesenkt werden.
Terminologie der BGP-Classful-Transportebenen
Dieser Abschnitt enthält eine Zusammenfassung häufig verwendeter Begriffe zum Verständnis der BGP-Classful-Transportebene.
-
Serviceknoten: Ingress Provider Edge (PE)-Geräte, die Servicerouten (Internet und Layer 3-VPN) senden und empfangen.
-
Border Node– Gerät am Verbindungspunkt verschiedener Domänen (IGP-Bereiche oder ASs).
-
Transportknoten: Gerät, das LU-Routen (BGP-Labeled Unicast) sendet und empfängt.
-
BGP-VPN: VPNs, die mit RFC4364-Mechanismen erstellt wurden.
-
Route Target (RT):Typ der erweiterten Community, die zum Definieren der VPN-Mitgliedschaft verwendet wird.
-
Route Distinguisher (RD)– Kennung, die verwendet wird, um zu unterscheiden, zu welchem VPN oder Virtual Private LAN Service (VPLS) eine Route gehört. Jeder Routinginstanz muss ein eindeutiger Routenunterscheidungsmerkmal zugeordnet sein.
- Auflösungsschema: Wird verwendet, um die Protokoll-Next-Hop-Adresse (PNH) in Auflösungs-RIBs aufzulösen, die Fallback bereitstellen.
Sie ordnen die Routen den verschiedenen Transport-RIBs im System auf der Grundlage einer Mapping-Community zu.
-
Servicefamilie: BGP-Adressfamilie, die für die Ankündigung von Routen für Datenverkehr verwendet wird, im Gegensatz zu Tunneln.
-
Transportfamilie : BGP-Adressfamilie, die für Ankündigungstunnel verwendet wird, die wiederum von Dienstrouten zur Auflösung verwendet werden.
-
Transporttunnel: Ein Tunnel, über den ein Dienst Datenverkehr leiten kann, z. B. GRE, UDP, LDP, RSVP, SR-TE, BGP-LU.
-
Tunneldomäne: Eine Domäne des Netzwerks, die Serviceknoten und Grenzknoten unter einer einzigen administrativen Kontrolle enthält, zwischen der ein Tunnel besteht. Ein End-to-End-Tunnel, der sich über mehrere benachbarte Tunneldomänen erstreckt, kann erstellt werden, indem die Knoten mithilfe von Beschriftungen zusammengefügt werden.
-
Transportklasse: Eine Gruppe von Transporttunneln, die den gleichen Servicetyp anbieten.
Transportklasse RT –Ein neues Format des Routenziels, das zur Identifizierung einer bestimmten Transportklasse verwendet wird.
Ein neues Format von Route Target, das zur Identifizierung einer bestimmten Transportklasse verwendet wird.-
Transport-RIB: Am Service-Knoten und am Grenzknoten verfügt eine Transportklasse über ein zugeordnetes Transport-RIB, das ihre Tunnelrouten enthält.
-
Transport RTI– Eine Routing-Instanz; Container der Transport-RIB und der zugehörigen Transportklasse Route Target und Route Distinguisher.
-
Transportebene: Gruppe von Transport-RTIs, die dieselbe Transportklasse RT importieren. Diese werden wiederum zusammengefügt, um sich über Tunneldomänengrenzen hinweg zu erstrecken, wobei ein Mechanismus ähnlich dem Inter-AS option-b verwendet wird, um Beschriftungen an Grenzknoten (nexthop-self) auszutauschen und eine End-to-End-Transportebene zu bilden.
-
Mapping community: Community auf einer Dienstroute, die für die Auflösung über eine Transportklasse zugeordnet werden soll.
Grundlegendes zu BGP Classful Transport Planes
Sie können BGP-Classful-Transportebenen verwenden, um Transportklassen für die Klassifizierung einer Gruppe von Transporttunneln in einem AS-internen Netzwerk basierend auf den Traffic-Engineering-Merkmalen zu konfigurieren und diese Transporttunnel zu verwenden, um Servicerouten mit dem gewünschten SLA und dem beabsichtigten Fallback abzubilden.
BGP-Classful-Transportebenen können diese Tunnel auf domänenübergreifende Netzwerke ausdehnen, die sich über mehrere Domänen (ASs oder IGP-Bereiche) erstrecken, während die Transportklasse erhalten bleibt. Dazu müssen Sie die BGP-BGP-Familie Classful Trasport Transport Layer zwischen den Border- und Service-Knoten konfigurieren.
Sowohl in Inter-AS- als auch in Intra-AS-Implementierungen können viele Transporttunnel (MPLS LSPs, IS-IS flexibler Algorithmus, SR-TE) aus den Service- und Border-Knoten erstellt werden. Die LSPs können mit unterschiedlichen Signalisierungsprotokollen in verschiedenen Domänen signalisiert und mit unterschiedlichen Traffic-Engineering-Merkmalen (Klasse oder Farbe) konfiguriert werden. Der Transporttunnelendpunkt fungiert auch als Dienstendpunkt und kann sich in derselben Tunneldomäne wie der Eingangsknoten des Diensts oder in einer benachbarten oder nicht benachbarten Domäne befinden. Sie können BGP-Classful-Transportebenen verwenden, um Services über LSPs mit bestimmten Traffic-Engineering-Merkmalen entweder innerhalb einer einzelnen Domäne oder über mehrere Domänen hinweg zu ersetzen.
BGP-Transportebenen der Klasse verwenden die BGP-VPN-Technologie wieder, wodurch die Tunneling-Domänen lose gekoppelt und koordiniert bleiben.
- Die NLRI (Network Layer Reachability Information) sind RD:TunnelEndpoint , die zum Ausblenden von Pfaden verwendet werden.
- Das Routenziel gibt die Transportklasse der LSPs an und leitet Routen an das entsprechende Transport-RIB auf dem Zielgerät weiter.
- Jedes Transporttunneling-Protokoll installiert eine Eingangsroute in die Routing-Tabelle transport-class.inet.3, modelliert die Tunnel-Transportklasse als VPN-Routenziel und sammelt die LSPs derselben Transportklasse in der Transport-rib-Routing-Tabelle transport-class.inet.3.
-
Routen in dieser Routinginstanz werden in der BGP-Classful-Transportebene (inet transport) AFI-SAFI nach ähnlichen Verfahren wie RFC-4364 angekündigt.
-
Wenn Sie die Grenze zwischen AS-Verbindungen überschreiten, müssen Sie die Option-b-Verfahren befolgen, um die Transporttunnel in diesen benachbarten Domänen zu verknüpfen.
Ebenso müssen Sie beim Überqueren von AS-Regionen die Option-b-Verfahren befolgen, um die Transporttunnel in den verschiedenen TE-Domänen zu verknüpfen.
-
Sie können Auflösungsschemata definieren, um die Absicht für die Vielzahl von Transportklassen in einer Fallback-Reihenfolge anzugeben.
- Sie können Servicerouten und BGP-Classful-Transportrouten über diese Transportklassen auflösen, indem Sie die Mapping-Community auf sie übertragen.
Die BGP-Transportfamilie der Klasse läuft parallel zur BGP-LU-Transportschichtfamilie. In einem nahtlosen MPLS-Netzwerk mit BGP-LU ist es eine Herausforderung, die strengen SLA-Anforderungen von 5G zu erfüllen, da die verkehrstechnischen Eigenschaften der Tunnel nicht über Domänengrenzen hinweg bekannt sind oder erhalten bleiben. BGP-Classful-Transportebenen bieten eine betriebseinfache und skalierbare Möglichkeit, mehrere Pfade für Remote-Loopbacks zusammen mit den Transportklasseninformationen in der nahtlosen MPLS-Architektur anzukündigen. In BGP-Routen der Classful-Tranport-Familie werden verschiedene SLA-Pfade mithilfe der erweiterten Community Transport Route-Target dargestellt, die die Farbe der Transportklasse trägt. Dieses Transportroutenziel wird von den empfangenden BGP-Routern verwendet, um die BGP-Classful-Transportroute der entsprechenden Transportklasse zuzuordnen. Bei der erneuten Ankündigung der BGP-Classful-Transportrouten tauscht MPLS die Routen, verbindet die AS-internen Tunnel derselben Transportklasse miteinander und bildet so einen End-to-End-Tunnel, der die Transportklasse beibehält.
AS-interne Implementierung von BGP Classful Transport Planes
Abbildung 1 veranschaulicht eine Netzwerktopologie mit Vorher-Nachher-Szenarien zur Implementierung von BGP-Classful-Transportebenen in einer AS-internen Domäne. Die Geräte PE11 und PE12 verwenden RSVP-LSPs als Transporttunnel und alle Transporttunnelrouten sind in inet.3 RIB installiert. Durch die Implementierung von BGP-Classful-Transort-Ebenen können RSVP-Transporttunnel ähnlich wie Segment-Routing-Tunnel farbsensibel sein.
So klassifizieren Sie Transporttunnel in einer AS-internen Einrichtung in BGP-Transportklassen:
- Definieren Sie die Transportklasse am Serviceknoten (Eingangs-PE-Geräte), z. B. Gold und Bronze, und weisen Sie der definierten Transportklasse Farbgemeinschaftswerte zu.
Beispielkonfiguration:
pe11# show routing-options route-distinguisher-id 172.16.1.1; transport-class { name gold { color 100; } name bronze { color 200; - Ordnen Sie den Transporttunnel einer bestimmten Transportklasse am Eingangsknoten der Tunnel zu.
Beispielkonfiguration:
pe11# show protocols mpls label-switched-path toPE12-bronze { transport-class bronze; } label-switched-path toPE12-gold { transport-class gold; }
Intra-AS BGP-Funktionen der Classful-Transportebene:
- BGP Classful Transport erstellt vordefinierte Transport-RIBs pro benannter Transportklasse (Gold und Bronze) und leitet automatisch die Mapping-Community aus ihrem Farbwert (100 und 200) ab.
- AS-interne Transportrouten werden vom Tunneling-Protokoll in Transport-RIBs aufgefüllt, wenn es einer Transportklasse zugeordnet ist.
In diesem Beispiel werden RSVP-LSP-Routen, die der Transportklasse Gold (Farbe 100) und der Transportklasse Bronze (Farbe 200) zugeordnet sind, in den Transport-RIBs junos-rti-tc-<100>.inet.3 bzw. junos-rti-tc-<200>.inet.3installiert.
- Serviceknoten (Eingangs-PEs) gleichen die erweiterte Farbgemeinschaft (color:0:100 und color:0:200) der Serviceroute mit der Zuordnungs-Community in vordefinierten Auflösungs-RIBs ab und lösen den Protocol Next Hop (PNH) in entsprechende Transport-RIBs auf (entweder junos-rti-tc-<100>.inet.3 oder junos-rti-tc-<200>.inet.3).
- BGP-Routen werden an ein Auflösungsschema gebunden, indem sie die zugehörige Mapping-Community übertragen.
- Jede Transportklasse erstellt automatisch zwei vordefinierte Auflösungsschemata und leitet automatisch die Mapping-Community ab.
Ein Auflösungsschema dient zum Auflösen von Servicerouten, die Color:0:<val> als Zuordnungs-Community verwenden.
Das andere Auflösungsschema dient zum Auflösen von Transportrouten, die Transport-Target:0:<val> als Zuordnungs-Community verwenden.
- Wenn Service-Route-PNH nicht mit RIBs aufgelöst werden kann, die im vordefinierten Auflösungsschema aufgeführt sind, kann auf die inet.3-Routing-Tabelle zurückgegriffen werden.
- Sie können auch Fallback zwischen verschiedenfarbigen Transport-RIBs konfigurieren, indem Sie benutzerdefinierte Auflösungsschemata in der [edit routing-options resolution scheme] Konfigurationshierarchie verwenden.
Inter-AS-Implementierung von BGP Classful Transport Planes
In einem AS-übergreifenden Netzwerk wird BGP-LU in ein BGP-Classful-Transportnetzwerk konvertiert, nachdem mindestens zwei Transportklassen (Gold und Bronze) auf allen Service-Knoten oder PE-Geräten und Grenzknoten (ABRs und ASBRs) konfiguriert wurden.
So konvertieren Sie die Transporttunnel in BGP Classful Transport:
- Definieren Sie die Transportklasse an den Serviceknoten (Eingangs-PE-Geräte) und den Grenzknoten (ABRs und ASBRs), z. B. Gold und Broze.
Beispielkonfiguration:
pe11# show routing-options route-distinguisher-id 172.16.1.1; transport-class { name gold { color 100; } name bronze { color 200; - Ordnen Sie die Transporttunnel einer bestimmten Transportklasse am Eingangsknoten der Tunnel zu (Eingangs-PEs, ABRs und ASBRs).
Beispielkonfiguration:
Für RSVP-LSPs
abr23# show protocols mpls label-switched-path toASBR21-bronze { transport-class bronze; } label-switched-path toASBR22-gold { transport-class gold;Für IS-IS flxible-Algorithmus
asbr13# show routing-options flex-algorithm 128 { … color 100; use-transport-class; } flex-algorithm 129 { … color 200; use-transport-class; } - Aktivieren Sie die neue Familie für den BGP-Classful-Transport (inet transport) und BGP-LU (inet labeled-unicast) im Netzwerk.
Beispielkonfiguration:
abr23# show protocols bgp group toAs2-RR27 { family inet { labeled-unicast { … } transport { … } cluster 172.16.2.3; neighbor 172.16.2.7; } - Kündigen Sie Servicerouten vom ausgehenden PE-Gerät mit einer entsprechenden erweiterten Farbgemeinschaft an.
Beispielkonfiguration:
pe11# show policy-options policy-statement red term 1 { from { route-filter 192.168.3.3/32 exact; } then { community add map2gold; next-hop self; accept; } } term 2 { from { route-filter 192.168.33.33/32 exact; } then { community add map2bronze; next-hop self; accept; } } community map2bronze members color:0:200; community map2gold members color:0:100;
Inter-AS BGP Classful Transport Plane-Funktionalität:
- BGP-Classful-Transportebenen erstellen vordefinierte Transport-RIBs pro benannter Transportklasse (Gold und Bronze) und leiten automatisch die Mapping-Community aus ihrem Farbwert ab.
-
AS-interne Transportrouten werden in Transport-RIBs durch Tunneling-Protokolle aufgefüllt, wenn sie einer Transportklasse zugeordnet sind.
Beispielsweise werden Transporttunnelrouten, die der Transportklasse Gold und Bronze zugeordnet sind, in den Transport-RIBs junos-rti-tc-<100>.inet.3 bzw. junos-rti-tc-<200>.inet.3installiert.
- BGP-Classful-Transportebenen verwenden eindeutige Route Distinguisher und Route Target, wenn die Transporttunnelrouten von jedem Transport-RIB in die Routing-Tabelle bgp.transport.3 kopiert werden.
- Border-Knoten kündigen Routen von der Routing-Tabelle bgp.transport.3 an ihre Peers in anderen Domänen an, wenn der Familien-inet-Transport in der BGP-Sitzung ausgehandelt wird.
- Der empfangende Grenzknoten installiert diese bgp-ct-Routen in der Routing-Tabelle bgp.transport.3 und kopiert diese Routen basierend auf dem Transportroutenziel in die entsprechenden Transport-RIBs.
- Der Serviceknoten vergleicht die Farbgemeinschaft in der Serviceroute mit einer Zuordnungsgemeinschaft in den Auflösungsschemata und löst PNH im entsprechenden Transport-RIB auf (entweder junos-rti-tc-<100>.inet.3oder junos-rti-tc-<200>.inet.3).
- Border-Knoten verwenden vordefinierte Auflösungsschemata für die PNH-Auflösung des Transportwegs.
- Beide Auflösungsschemata sind vordefiniert oder benutzerdefiniert und unterstützen die PNH-Auflösung für die Dienstroute. Predefined verwendet inet.3 als Fallback, und das benutzerdefinierte Auflösungsschema ermöglicht die Verwendung einer Liste von Transport-RIBs in der Reihenfolge, die beim Auflösen von PNH angegeben ist.
- Wenn Service-Route-PNH nicht mit RIBs aufgelöst werden kann, die im benutzerdefinierten Auflösungsschema aufgeführt sind, wird die Route verworfen.
BGP Classful Transport (BGP-CT) mit zugrunde liegenden farbigen SR-TE-Tunneln – Übersicht
Vorteile von BGP-CT mit darunter liegenden farbigen SR-TE-Tunneln
- Löst Skalierungsprobleme, die in Zukunft auftreten können, wenn das Netzwerk wächst.
- Bietet Interkonnektivität für Domänen, die unterschiedliche Technologien verwenden.
- Entkoppelt Services und Transportschichten, was zu einem vollständig verteilten Netzwerk führt.
- Bietet unabhängiges Bandbreitenmanagement durch einen domäneninternen Traffic-Engineering-Controller für SR-TE.
Große Netzwerke, die ständig wachsen und sich weiterentwickeln, erfordern eine nahtlose Segment-Routing-Architektur. Ab Junos OS Version 21.2,R1 unterstützen wir BGP-CT mit zugrunde liegendem Transport als farbige SR-TE-Tunnel. BGP-CT kann Servicerouten mithilfe der Transport-RIBs auflösen und den nächsten Hop berechnen. Services, die derzeit über BGP-CT unterstützt werden, können auch die zugrunde liegenden farbigen SR-TE-Tunnel für die Routenauflösung verwenden. Die Services können nun die zugrunde liegenden farbigen SR-TE-Tunnel verwenden, wie z. B. die statischen farbigen, BGP-SR-TE-, programmierbaren rpd- und PCEP-farbigen Tunnel. BGP-CT nutzt die Erreichbarkeit des nächsten Hops, um Dienstrouten über die gewünschte Transportklasse aufzulösen.
Um die BGP-CT-Service-Routenauflösung über zugrunde liegende farbige SR-TE-Tunnel zu aktivieren, fügen Sie die use-transport-class Anweisung auf Hierarchieebene [edit protocols source-packet-routing] ein.
- Aktivieren Sie die
use-transport-classAnweisungauf der
zusammen mit der[edit protocols source-packet-routing]Hierarchieebene.auto-createAnweisung auf der[edit routing-options transport-class]Hierarchieebene. - Wir unterstützen keine RIB-Gruppen für farbige SR-TE-Tunnel mit
use-transport-classund nur farbige SR-TE-Tunnel mit dieser Funktion.
Beispiel: Konfigurieren von Classful-Transportebenen (domänenintern)
- Vorbereitungen
- Funktionsübersicht
- Topologieübersicht
- Topologie-Illustrationen
- PE1-Konfigurationsschritte
- Classful-Transportebenen verifizieren
- Anlage 1: Fehlerbehebung
- Anlage 2: Festlegen von Befehlen auf allen Geräten
- Anlage 3: Konfigurationsausgabe auf PE1 anzeigen
Vorbereitungen
| Hardware- und Softwareanforderungen |
Junos OS Version 21.1R1 oder höher. HINWEIS:
Nur die Provider-Edge-Router (PE1 und PE2) benötigen Junos OS Release-Unterstützung für die BGP-CT-Funktion. |
|
Geschätzte Lesezeit |
45 Minuten |
|
Geschätzte Konfigurationszeit |
1 Stunde |
|
Was erwartet Sie? |
Ein funktionierendes BGP-CT-Netzwerk mit drei Service-Leveln, die unterschiedlich gerouteten LSP-Pfaden zugeordnet sind. Eine Junos-Konfiguration, die bestimmten Datenverkehr (VPN-Kundenrouten) mithilfe von BGP-Farbattribut-Extended Communities der gewünschten Transportklasse zuordnet. Grundlegendes LSP-Traffic-Engineering zum Erzwingen von Datenverkehrsklassen auf verschiedenen Pfaden im Provider-Netzwerk |
|
Auswirkungen auf das Geschäft |
Verwenden Sie dieses Konfigurationsbeispiel, um die BGP Classful Transport (BGP-CT)-Funktion innerhalb eines einzelnen autonomen Netzwerks (domänenintern) zu konfigurieren und zu überprüfen. BGP-CT ordnet Kundenrouten Netzwerkpfaden zu, die so konstruiert werden können, dass sie unterschiedliche Leistungsniveaus bieten. Ein typischer Anwendungsfall für domäneninternes BGP-CT ist die Bereitstellung von BGP-CT durch einen Service Provider, um seinen Kunden abgestufte VPN-Servicelevel anzubieten. |
|
Nützliche Ressourcen: |
|
|
Mehr erfahren |
Informationen zum besseren Verständnis von BGP-CT finden Sie unter Übersicht über BGP Classful Transport Planes |
|
Juniper vLabs |
Besuchen Sie die virtuellen Labore (vLabs) von Juniper, um eine vorkonfigurierte Sandbox zu reservieren. Verwenden Sie die Sandbox, um mit der BGP-CT-Funktion zu interagieren und sie zu verstehen. Die Demonstration "Classful Transport Planes (Intra-Domain Scenario)" finden Sie im Abschnitt "Routing". |
|
Mehr erfahren |
Junos Class of Service (JCOS) On-Demand |
Funktionsübersicht
Tabelle 1 Enthält eine kurze Zusammenfassung der in diesem Beispiel bereitgestellten Konfigurationskomponenten.
|
Routing- und Signalisierungsprotokolle |
|
|
OSPF |
Auf allen Routern wird OSPF als IGP ausgeführt. Alle Router gehören zum Bereich 0 (auch Backbone-Bereich genannt). Die einzelne OSPF-Routing-Domäne stellt die Loopback-Konnektivität im Provider-Netzwerk bereit. |
|
Internes und externes BGP |
Die Kunden-Edge-Geräte (CE) verwenden EBGP-Peering, um Routen mit ihrem Provider-Edge-Gerät als Teil eines Layer-3-VPN-Service auszutauschen. Die PE-Geräte verwenden IBGP, um IPv4-Layer-3-VPN-Routen mit dem Remote-PE auszutauschen. Diese Routen enthalten auch eine Farbgemeinschaft, die verwendet wird, um den Datenverkehr dem richtigen Datenebenentunnel zuzuordnen. In unserem Beispiel wird kein Routenreflektor verwendet, sondern direktes PE-PE-Peering. HINWEIS:
Der Provider-Router (P-Router) führt kein BGP aus. Es ist Teil eines BGP-freien Kerns, um die Skalierung zu fördern. Das P-Gerät verwendet MPLS-Label-basiertes Switching, um den Kunden-VPN-Datenverkehr zwischen den PE-Geräten zu transportieren. |
|
RSVP |
Jedes PE-Gerät signalisiert drei LSPs an die Remote-PE. Diese Sprachdienstleister sind den entsprechenden Serviceklassen Gold, Bronze und Best-Effort (BE) zugeordnet. RSVP unterstützt Rich Traffic Engineering, um Datenverkehr auf die gewünschten Pfade im Provider-Netzwerk zu zwingen. Diese Pfade können wiederum so gestaltet werden, dass sie unterschiedliche CoS-Verarbeitungsanforderungen (Class of Service) bieten, um die SLA für jede Transportklasse durchzusetzen. Unsere Basistopologie bietet drei Pfade zwischen den PE-Geräten. Wir verwenden einen benannten Pfad mit einem ERO, um ein vielfältiges Routing der LSPs über den Kern zu gewährleisten. Junos unterstützt eine Vielzahl von Funktionen für das Traffic Engineering. Weitere Informationen finden Sie unter MPLS Traffic Engineering Konfiguration HINWEIS:
Die Classful-Transportfunktion wird auch von LSPs unterstützt, die über Segment-Routing-Traffic-Engineering (SR-TE)- und IS-IS-Flex-Algorithmus-Tunnel eingerichtet wurden. |
|
MPLS |
Das Provider-Netzwerk verwendet eine MPLS-basierte Label-Switching-Datenebene. Durch die Verwendung von MPLS mit TE-Pfaden wird sichergestellt, dass jede Serviceklasse über disjunkte Pfade mit den gewünschten Leistungsstufen geroutet werden kann. Wie bereits erwähnt, bietet MPLS auch Unterstützung für einen BGP-freien Kern. |
| Transporttunnel | |
|
Zwischen den PE-Geräten werden drei MPLS-Tunnel (LSPs) eingerichtet: |
Jeder Tunnel ist den folgenden Transportklassen zugeordnet:
|
| Service-Familie | |
|
Layer-3-VPN ( |
BGP-CT funktioniert auch mit anderen Servicefamilien, wie z. B. BGP mit der Bezeichnung Unicast, Flowspec oder Layer 2 VPN. |
| Primäre Verifizierungsaufgaben | |
|
Überprüfen Sie, ob IGP, RSVP, MPLS, BGP und L3VPN funktionieren. |
|
Ändern Sie das Netzwerk so, dass der Datenverkehr zwischen Tunneln der Transportklasse gesteuert wird, um den Ausfall eines Diensttunnels und das anschließende Failover auf den BE-Pfad/die BE-Klasse zu simulieren. |
Topologieübersicht
Dieses Konfigurationsbeispiel basiert auf einem einfachen MPLS-basierten Layer-3-VPN mit zwei Kunden-Edge-Geräten (CE), die über das Netzwerk des Service Providers kommunizieren. Der Netzwerkkern verfügt über drei Provider-Router (P), die den VPN-Kundendatenverkehr mithilfe von Labeled-based Switching transportieren. Die beiden Provider-Edge-Geräte (PE) stellen einen Layer-3-VPN-Service für ihre angeschlossenen CEs bereit. Die PEs verwenden RSVP-signalisierte MPLS-LSPs, um VPN-Datenverkehr über den Core zu transportieren. Hier finden Sie Example: Configure a Basic MPLS-Based Layer 3 VPN Hintergrundinformationen zum Betrieb und zur Konfiguration eines MPLS-basierten L3VPN.
Wir konzentrieren uns auf den Datenverkehrsfluss von links nach rechts von CE1 zu CE2 und darauf, wie PE1 eine BGP-Farbgemeinschaft verwendet, die an die von PE2 gelernten Routen angehängt ist, um den an die Remote-CE gesendeten Datenverkehr über die gewünschten LSP-Weiterleitungs-nächsten Hops zuzuordnen. In unserem Beispiel verwendet PE1 explizite Routenobjekte (ERO), um das Routing dieser LSPs über verschiedene Pfade zu erzwingen. Wir überspringen diesen Schritt bei PE2, sodass die LSPs basierend auf IGP-Load-Balancing geroutet werden können. Damit der Datenverkehr von CE1 zu CE2 fließt, muss CE1 über eine Route verfügen, um CE2 zu erreichen. Die Routen für CE2 verlaufen in die entgegengesetzte Richtung des Verkehrs, den sie von CE1 anzieht. Das heißt, die Route zum Loopback von CE2 verläuft von rechts nach links.
In unserem Beispiel ist die Gold-Serviceklasse LSP auf den PE1-P1-PE2-Pfad beschränkt. Die Bronze-Serviceklasse verwendet den PE1-P2-PE2-Pfad. Der bestmögliche LSP wird entlang des PE1-P3-PE2-Pfads geroutet. Das Topologiediagramm verwendet farbige Links, um die drei Pfade darzustellen.
In unserem Beispiel fügen wir die protocols mpls icmp-tunneling Anweisung hinzu. Dies soll es den CE-Geräten ermöglichen, den Pfad durch das Provider-Netzwerk zu verfolgen, selbst wenn dieser Pfad MPLS-Switching beinhaltet, wie es beim Layer-3-VPN-Datenverkehr der Fall ist. Mit dieser Option können Sie bestätigen, dass der erwartete Weiterleitungspfad in Abhängigkeit von der verwendeten Transportklasse verwendet wird.
Tabelle 2 Beschreibt die Rolle und Funktionalität der einzelnen Geräte im Kontext dieser Topologie. Klicken Sie auf einen beliebigen Gerätenamen, um die Schnellkonfiguration anzuzeigen.
| Gerätename |
Rolle |
Funktion |
| CE1 | Lokales CE-Gerät (R1) . | EBGP-Peer zum PE1-Router, um Loopback-Adressen von CE-Geräten anzukündigen und zu lernen. Testen Sie die Dienstkonnektivität mit Pings an die Loopback-Adresse von CE2. |
| CE2 | CE-Fernbedienung (R7) | EBGP-Peering zum PE2-Router, um Loopback-Adressen von CE-Geräten anzukündigen und zu lernen. Konfiguriert und fügt die Color-Mapping-Community an. |
| PE1 (Prüfling) | lokales PE-Gerät (R2). | PE1 ordnet die farblich gekennzeichneten Servicerouten, die an CE2 beginnen, einer Co-Sponsoring-Transportklasse (TC) zu. PE1 empfängt die Color-Tag-Routen über seine IBGP-Sitzung zu PE2. In diesem Beispiel verwendet PE1 ERO-basierte Einschränkungen, um ein diverses Routing seiner drei LSPs über den Core des Anbieters zu erzwingen. |
| PE2 | Remote-PE-Gerät (R6). | PE2 kündigt die von CE2 bis PE1 empfangenen farblich gekennzeichneten Routen mithilfe von IBGP erneut an. Diese Routen nutzen die inet-vpn Produktfamilie zur Unterstützung von Layer-3-VPN-Diensten mit farblich zugeordneten TCs. |
| P1 P2 P3 | Anbietergeräte P1, P2 und P3 (R3, R4 und R5). | Die P1-P3-Geräte stellen das Kernnetzwerk des Service Providers dar. Dabei handelt es sich um reine Transitgeräte, die MPLS-Label-Switching durchführen, um den über das L3-VPN gesendeten CE-Datenverkehr zu transportieren. |
Topologie-Illustrationen
PE1-Konfigurationsschritte
Weitere Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus
Eine vollständige Konfiguration auf allen Geräten finden Sie unter:
In diesem Abschnitt werden die wichtigsten Konfigurationsaufgaben beschrieben, die zur Konfiguration des PE1-Geräts für dieses Beispiel erforderlich sind. Der erste Schritt ist üblich bei der Konfiguration eines einfachen Layer-3-VPN-Service. Die folgenden Schritte beziehen sich speziell auf das Hinzufügen der BGP-CT-Funktion zu Ihrem Layer-3-VPN. Beide PE-Geräte haben eine ähnliche Konfiguration, hier konzentrieren wir uns auf PE1.
-
Stellen Sie zunächst das allgemeine Layer-3-VPN bereit:
-
Konfigurieren und nummerieren Sie die Loopback-, Core- und CE-Schnittstellen für IPv4. Stellen Sie sicher, dass die
mplsProduktfamilie auf den Core-Schnittstellen, die mit den P-Geräten verbunden sind, aktiviert ist, um MPLS-Switching zu unterstützen. -
Konfigurieren Sie eine autonome Systemnummer.
-
Konfigurieren Sie Einzelbereichs-OSPF auf den Loopback- und Core-Schnittstellen.
-
Konfigurieren Sie RSVP auf den Loopback- und Core-Schnittstellen.
-
Konfigurieren Sie die IBGP-Peering-Sitzung mit dem Remote-PE-Gerät PE2. Fügen Sie die
inet-vpnAdressfamilie zur Unterstützung eines IPv4-Layer-3-VPN hinzu. -
Konfigurieren Sie eine VRF-basierte Routing-Instanz für das CE1-Gerät. Verwenden Sie EBGP als PE-CE-Routing-Protokoll.
[edit] set interfaces ge-0/0/1 unit 0 family inet address 10.1.23.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 description "Link from PE1 to P2" set interfaces ge-0/0/2 unit 0 family inet address 10.1.24.1/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 description "Link from PE1 to P3" set interfaces ge-0/0/3 unit 0 family inet address 10.1.25.1/24 set interfaces ge-0/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.1/32
[edit] set routing-instances CE1_L3vpn instance-type vrf set routing-instances CE1_L3vpn protocols bgp group CE1 type external set routing-instances CE1_L3vpn protocols bgp group CE1 peer-as 64510 set routing-instances CE1_L3vpn protocols bgp group CE1 neighbor 172.16.1.1 set routing-instances CE1_L3vpn interface ge-0/0/0.0 set routing-instances CE1_L3vpn route-distinguisher 192.168.0.1:12 set routing-instances CE1_L3vpn vrf-target target:65412:12
[edit] set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 192.168.0.1 set protocols bgp group ibgp family inet unicast set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp neighbor 192.168.0.2 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/1.0 set protocols rsvp interface ge-0/0/2.0 set protocols rsvp interface ge-0/0/3.0
[edit] set routing-options route-distinguisher-id 192.168.0.1 set routing-options autonomous-system 65412
-
-
Fügen Sie dem Layer-3-VPN Classful-Transportebenen hinzu.
Konfigurieren Sie die Gold- und Bronze-Transportklassen.
Dies ist ein wichtiger Schritt bei der Konfiguration der Classful-Transportfunktion. Diese Transportklassen werden RSVP-signalisierten (und möglicherweise datenverkehrstechnischen) LSPs zugeordnet, die den Provider-Kern durchlaufen. Die von CE2 erlernten Remote-Routen werden mit Farbgemeinschaften versehen, die diesen Transportklassen und damit dem gewünschten LSP zwischen den PE-Geräten zugeordnet sind.
[edit] set routing-options transport-class name gold color 100 set routing-options transport-class name bronze color 200 set routing-options resolution preserve-nexthop-hierarchy
-
Konfigurieren Sie drei Sprachdienstleister von PE1 bis PE2 mit eingeschränktem Routing, das jeden zwingt, einen anderen P-Router zu durchqueren. Zwei dieser LSPs werden der gold Transportklasse und bronze zugeordnet. Der Gold-LSP wird durch P1 geleitet, der Bronze-LSP durch P2 und der Best-Effort durch das P3-Gerät.
Nach der Zuordnung zu Transportklassen ist der Service Provider in der Lage, spezifischen Kundendatenverkehr, der durch eine BGP-Farbgemeinschaft angezeigt wird, auf einem bestimmten LSP zu platzieren. Mit dieser farblichen LSP-Zuordnung kann der Service Provider einen abgestuften Service mit unterschiedlichen SLAs anbieten.
In unserem Beispiel verwenden wir eine strikte ERO, um sicherzustellen, dass die drei LSPs unterschiedlich über die drei in der Topologie verfügbaren Pfade geroutet werden.
[edit] set protocols mpls label-switched-path lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path lsp_to_pe2 primary best-effort set protocols mpls label-switched-path gold_lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path gold_lsp_to_pe2 preference 5 set protocols mpls label-switched-path gold_lsp_to_pe2 primary gold set protocols mpls label-switched-path gold_lsp_to_pe2 transport-class gold set protocols mpls label-switched-path bronze_lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path bronze_lsp_to_pe2 preference 5 set protocols mpls label-switched-path bronze_lsp_to_pe2 primary bronze set protocols mpls label-switched-path bronze_lsp_to_pe2 transport-class bronze set protocols mpls path gold 10.1.23.2 strict set protocols mpls path bronze 10.1.24.2 strict set protocols mpls path best-effort 10.1.25.2 strict set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols mpls interface ge-0/0/3.0
-
Um den Fallback auf den Standard-Serviceklassen-Tunnel (Best-Effort) zu erleichtern, konfigurieren wir die Gold- und Bronze-Transportklassen-Tunnel mit einer niedrigeren globalen Präferenz. In diesem Beispiel wird der Voreinstellungswert von der Standardeinstellung 7 in 5 geändert. Dies ermöglicht die Verwendung des Best-Effort-Tunnels als Fallback für den Fall, dass die Gold- oder Bronzetunnel unbrauchbar werden. Durch das Festlegen einer niedrigeren (bevorzugteren) Präferenz für die Gold- und Bronzetunnel wird sichergestellt, dass sie für die Weiterleitung ausgewählt werden, auch wenn die Serviceroute in den Best-Effort-Tunnel aufgelöst werden kann.
HINWEIS:Dieser Abschnitt konzentrierte sich auf die Konfiguration, die auf dem PE1-Gerät erforderlich ist. Es ist zu beachten, dass die Remote-CE2-Geräterouten mit einer Farbgemeinschaft gekennzeichnet sein müssen, damit die Classful-Transport-Next-Hop-Auswahlfunktion bei PE1 funktioniert. Diese Kennzeichnung kann auf dem Remote-PE2-Gerät oder auf dem Remote-CE2-Gerät erfolgen. Letzteren Ansatz zeigen wir hier der Vollständigkeit halber:
-
Ordnen Sie die Farbgemeinschafts-Tags, die auf der Remote-CE2 hinzugefügt wurden, den Transportklassendefinitionen für die Bronze- und Gold-TCs zu.
[edit] set policy-options policy-statement adv_direct term 1 from protocol direct set policy-options policy-statement adv_direct term 1 from route-filter 172.16.0.0/16 orlonger set policy-options policy-statement adv_direct term 1 then community add map2bronze set policy-options policy-statement adv_direct term 1 then accept set policy-options community map2bronze members color:0:200 set policy-options community map2gold members color:0:100
Classful-Transportebenen verifizieren
In diesem Abschnitt konzentrieren wir uns auf Befehle, die eine funktionierende Classful-Transportfunktion veranschaulichen. Siehe Anhang 1: Fehlerbehebung für Befehle, die verwendet werden, um die zugrunde liegende Funktionalität zu überprüfen, die von der Classful-Transportfunktion benötigt wird.
Mit diesen Befehlen können Sie überprüfen, ob BGP Classful Transport ordnungsgemäß funktioniert.
| Befehl |
Verifizierungsaufgabe |
| Routing-Transportklasse anzeigen | Überprüfen Sie die Transportklassen und die zugehörigen Attribute. Dazu gehören die Mapping-Community und die Routing-Instanz. |
| Routenauflösungsschema anzeigen | Zeigen Sie an, wie Serviceklassenrouten in die nächsten LSP-Hops aufgelöst werden. Überprüfen Sie die Auflösungs-Routing-Tabellen für eine bestimmte Route. |
| show route receiving-protocol bgp pe2-loopback-address | Stellen Sie sicher, dass an die von PE1 empfangenen VPN-Routen eine BGP-Farbcommunity angehängt ist. |
| show route und show route forwarding-table vpn vpn | Überprüfen Sie die Auswahl des Transporttunnels, indem Sie den Protokoll-Nexthop (PNH) für die Routen bei PE1 anzeigen. |
| MPLS-LSP-Statistiken anzeigen und show route forwarding-table | Überprüfen Sie den Transporttunnel, der von einer bestimmten Transportklassenroute verwendet wird. |
- Überprüfen von Transportklassen und Transporttunneln
- Überprüfen der Auflösungsschemata für den nächsten Hop
- Überprüfen der Farbmarkierung und der Auswahl des nächsten Hops für CE2-Routen
- Überprüfen der End-to-End-Konnektivität
- Bestätigen des Failovers auf Best-Effort
Überprüfen von Transportklassen und Transporttunneln
Zweck
PE1 und PE2 verwenden RSVP-signalisierte MPLS-Transporttunnel, um einen Layer-3-VPN-Service zu unterstützen, der differenzierte Servicelevel anbieten kann. Die nächsten Hops dieser Dienstrouten werden basierend auf der entsprechenden Serviceklasse in einen bestimmten MPLS-Tunnel aufgelöst. Die Serviceklasse wird signalisiert, indem eine BGP-Farbgemeinschaft an VPN-Kundenrouten angehängt wird.
In diesem Teil bestätigen Sie, dass alle drei LSPs von PE1 betriebsbereit sind, dass sie der richtigen Transportklasse zugeordnet sind und dass sie korrekt über den Core des Anbieters geroutet sind.
Action!
Geben Sie im Betriebsmodus den show route 192.168.0.2 Befehl ein.
user@PE1 show route 192.168.0.2
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.2/32 *[OSPF/10] 00:27:20, metric 2
to 10.1.24.2 via ge-0/0/2.0
> to 10.1.25.2 via ge-0/0/3.0
to 10.1.23.2 via ge-0/0/1.0
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.2/32 *[RSVP/7/1] 00:13:09, metric 2
> to 10.1.25.2 via ge-0/0/3.0, label-switched-path lsp_to_pe2
junos-rti-tc-100.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.2/32 *[RSVP/5/1] 00:13:11, metric 2
> to 10.1.23.2 via ge-0/0/1.0, label-switched-path gold_lsp_to_pe2
junos-rti-tc-200.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.2/32 *[RSVP/5/1] 00:13:08, metric 2
> to 10.1.24.2 via ge-0/0/2.0, label-switched-path bronze_lsp_to_pe2Bedeutung
Die Ausgabe bestätigt, dass PE1 drei Pfade zum Loopback von PE2 über OSPF gelernt hat. Diese Routen sind in der inet.0 Tabelle aufgeführt. Sie beachten auch, dass alle drei LSPs als brauchbare nächste Hops dargestellt werden, um PE2 zu erreichen. Beachten Sie, dass sich jeder dieser Sprachdienstleister in einer anderen Routing-Tabelle befindet. Der hervorgehobene Teil der nächsten IP-Hops (und der entsprechende Schnittstellenname) bestätigt das gewünschte vielfältige LSP-Routing über den Core. Der Datenverkehr, der dem Gold-Pfad zugeordnet ist, wird an 10.1.23.2 gesendet, während der Datenverkehr für Bronze und BE an 10.1.24.2 bzw. 10.1.25.2 gesendet wird.
Die folgenden Transport-RIBs und Transporttunnel werden erstellt.
-
junos-rti-tc-100.inet.3für gold_lsp_to_pe2 -
junos-rti-tc-200.inet.3für bronze_lsp_to_pe2 -
inet.3für lsp_to_pe2
Überprüfen der Auflösungsschemata für den nächsten Hop
Zweck
Überprüfen Sie die Auflösungsschemas für Dienstrouten, die zugeordnete Zuordnungs-Community und die Auflösung des nächsten Hops über die beitragenden Routingtabellen.
Action!
Geben Sie im Betriebsmodus den show route resolution scheme all Befehl ein.
user@PE1> show route resolution scheme all Resolution scheme: junos-resol-schem-tc-100-v4-service References: 1 Mapping community: color:0:100 Resolution Tree index 1, Nodes: 1 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-100.inet.3 inet.3 Resolution scheme: junos-resol-schem-tc-100-v4-transport References: 1 Mapping community: transport-target:0:100 Resolution Tree index 3, Nodes: 1 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-100.inet.3 Resolution scheme: junos-resol-schem-tc-100-v6-service References: 1 Mapping community: color:0:100 Resolution Tree index 2, Nodes: 0 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-100.inet6.3 inet6.3 Resolution scheme: junos-resol-schem-tc-100-v6-transport References: 1 Mapping community: transport-target:0:100 Resolution Tree index 4, Nodes: 0 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-100.inet6.3 Resolution scheme: junos-resol-schem-tc-200-v4-service References: 1 Mapping community: color:0:200 Resolution Tree index 5, Nodes: 1 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-200.inet.3 inet.3 Resolution scheme: junos-resol-schem-tc-200-v4-transport References: 1 Mapping community: transport-target:0:200 Resolution Tree index 7, Nodes: 1 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-200.inet.3 Resolution scheme: junos-resol-schem-tc-200-v6-service References: 1 Mapping community: color:0:200 Resolution Tree index 6, Nodes: 0 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-200.inet6.3 inet6.3 Resolution scheme: junos-resol-schem-tc-200-v6-transport References: 1 Mapping community: transport-target:0:200 Resolution Tree index 8, Nodes: 0 Policy: [__resol-schem-common-import-policy__] Contributing routing tables: junos-rti-tc-200.inet6.3
Bedeutung
Wenn Sie sich auf die IPv4-Teile der Ausgabe konzentrieren, sehen Sie, dass die junos-tc-100 (gold) Transportklasse über zwei Auflösungsschemata verfügt – junos-resol-schem-tc-100-v4-service und junos-resol-schem-tc-100-v4-transport – die für die Dienst- bzw. Transportrouten verwendet werden.
Das Auflösungsschema für Gold-Servicerouten (junos-resol-schem-tc-100-v4-service) bietet eine Auflösung sowohl für die Routing- als auch für die junos-rti-tc-100.inet.3inet.3 Routing-Tabelle (in der Beispielausgabe hervorgehoben). Die Auflistung der Dienst- und der BE-Auflösungstabelle ist die Art und Weise, wie ein Fallback erfolgt, wenn die Dienstklasse ausgefallen ist. Erinnern Sie sich daran, dass wir aus diesem Grund den Präferenzwert der Service-LSPs geändert haben (indem wir die Präferenz auf 5 statt auf die Standardeinstellung 7 festgelegt haben), um sicherzustellen, dass die Serviceroute immer dem BE-Fallback vorgezogen wird.
Überprüfen der Farbmarkierung und der Auswahl des nächsten Hops für CE2-Routen
Zweck
Vergewissern Sie sich, dass PE2 die Loopback-Route für CE2 mit einer Farbcommunity ankündigt, die die Bronze-Serviceklasse (Farbe 200) auswählt.
In unserem Beispiel konfigurieren wir das CE2-Gerät so, dass es die Farbgemeinschaft anfügt. PE2 lässt diese Community bestehen, wenn es die Route zu PE1 erneut ankündigt. Dies bedeutet, dass der VPN-Kunde in der Lage ist, seine eigenen Serviceklassenzuordnungen vorzunehmen. Auf Wunsch kann der PE-Router alle von der CE erhaltenen Gemeinschaften bleichen oder entfernen. In diesem Fall muss das PE-Gerät so konfiguriert werden, dass es die gewünschte Farbzuordnungs-Community an CE-Routen anhängt, bevor es sie erneut an PE1 ankündigt.
Action!
Geben Sie im Betriebsmodus den show route receive-protocol bgp 192.168.0.2 172.16.255.2 detail Befehl ein.
user@PE1> show route receive-protocol bgp 192.168.0.2 172.16.255.2 detail
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
* 172.16.255.2/32 (1 entry, 1 announced)
Import Accepted
Route Distinguisher: 192.168.0.2:12
VPN Label: 299808
Nexthop: 192.168.0.2
Localpref: 100
AS path: 64520 I
Communities: target:65412:12 color:0:200
Zeigen Sie den Eintrag in der Weiterleitungstabelle für das CE2-Loopback in der VPN-Routing-Instanz bei PE1 an. Vergewissern Sie sich, dass der nächste Hop der Weiterleitung mit der gewünschten Transportklasse (Bronze) übereinstimmt. Verwenden Sie den show route forwarding-table vpn CE1_L3vpn destination 172.16.255.2 extensive Befehl.
user@PE1> show route forwarding-table vpn CE1_L3vpn destination 172.16.255.2 extensive
Routing table: CE1_L3vpn.inet [Index 10]
Internet:
Destination: 172.16.255.2/32
Route type: user
Route reference: 0 Route interface-index: 0
Multicast RPF nh index: 0
P2mpidx: 0
Flags: sent to PFE, prefix load balance
Next-hop type: indirect Index: 1048574 Reference: 2
Nexthop:
Next-hop type: composite Index: 662 Reference: 2
Load Balance Label: Push 299808, None
Nexthop: 10.1.24.2
Next-hop type: Push 299872 Index: 653 Reference: 2
Load Balance Label: None
Next-hop interface: ge-0/0/2.0 Bedeutung
Die hervorgehobenen Einträge bestätigen, dass Datenverkehr, der der CE2-Loopback-Route entspricht, über die Schnittstelle ge-0/0/2 an 10.1.24.2 gesendet wird. Rückruf von den EROs, die für die LSPs verwendet werden, diese Schnittstelle und der nächste Hop sind dem Bronze-LSP und der Transportklasse zugeordnet. Die 299808 Bezeichnung wird verwendet, um die Dienst-VRF zu identifizieren. Die äußere RSVP-Transportbezeichnung lautet 299872.
Sie bestätigen schnell mit einem show rsvp session detail name bronze_lsp_to_pe2 Befehl, dass dies die richtige RSVP-Transportbezeichnung für die Bronzeklasse ist
root@PE1> show rsvp session detail name bronze_lsp_to_pe2 Ingress RSVP: 3 sessions 192.168.0.2 From: 192.168.0.1, LSPstate: Up, ActiveRoute: 0 LSPname: bronze_lsp_to_pe2, LSPpath: Primary LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 299872 Resv style: 1 FF, Label in: -, Label out: 299872 Time left: -, Since: Tue Aug 16 12:17:12 2022 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 2 receiver 23256 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 10.1.24.2 (ge-0/0/2.0) 1 pkts RESV rcvfrom: 10.1.24.2 (ge-0/0/2.0) 1 pkts, Entropy label: Yes Explct route: 10.1.24.2 10.1.46.2 Record route: <self> 10.1.24.2 10.1.46.2 Total 1 displayed, Up 1, Down 0
Die hervorgehobenen Abschnitte weisen darauf hin, dass der bronzene LSP über das P2-Gerät geroutet wird und mit dem angegebenen RSVP-Transportlabel (299856) verknüpft ist, das Sie zuvor in der VPN-Weiterleitungstabelle für die CE2-Loopback-Adresse bestätigt haben.
Überprüfen der End-to-End-Konnektivität
Zweck
Überprüfen Sie die End-to-End-Konnektivität in der Domäne des Anbieters, indem Sie zwischen CE1 und CE2 pingen. Sie untersuchen MPLS-Datenverkehrsstatistiken, um eine zusätzliche Bestätigung dafür zu erhalten, dass die Bronze-Transportklasse verwendet wird.
Action!
Geben Sie im Betriebsmodus den ping Befehl ein.
user@CE1> ping 172.16.255.2 source 172.16.255.1 count 100 rapid PING 172.16.255.2 (172.16.255.2): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! --- 172.16.255.2 ping statistics --- 100 packets transmitted, 100 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.647/3.589/30.264/2.695 ms
Geben Sie im Betriebsmodus bei PE1 den show mpls lsp statistics Befehl ein.
user@PE1> show mpls lsp statistics Ingress LSP: 3 sessions To From State Packets Bytes LSPname 192.168.0.2 192.168.0.1 Up 100 8400 bronze_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 0 gold_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 0 lsp_to_pe2 Total 3 displayed, Up 3, Down 0 <output truncated for brevity>
Action!
Verfolgen Sie die Route von CE1 bis zum Loopback von CE2. Unsere Konfiguration enthält die icmp-tunneling Anweisung, eine ICMP-basierte Trace-Route mit MPLS-Hops im Provider-Kern zu unterstützen.
user@CE1> traceroute no-resolve 172.16.255.2
traceroute to 172.16.255.2 (172.16.255.2), 30 hops max, 52 byte packets
1 172.16.1.2 2.174 ms 1.775 ms 1.917 ms
2 10.1.24.2 5.171 ms 5.768 ms 4.900 ms
MPLS Label=299872 CoS=0 TTL=1 S=0
MPLS Label=299808 CoS=0 TTL=1 S=1
3 10.1.46.2 4.707 ms 4.347 ms 4.419 ms
MPLS Label=299808 CoS=0 TTL=1 S=1
4 172.16.255.2 5.640 ms 5.851 ms 44.777 ms
Bedeutung
Der Ping-Austausch ist erfolgreich und die Statistiken bestätigen die Nutzung des bronzenen Transporttunnels. Dies ist zu erwarten, da der Weg zu CE2 die 200-Farben-Community beigefügt hat. Die Ergebnisse der Ablaufverfolgungsroute bestätigen, dass der Datenverkehr über einen LSP weitergeleitet wird und dass dieser LSP über 10.1.24.2 weiterleitet. Dies ist die IP-Adresse, die dem P2-Gerät zugewiesen ist. Der nächste Hop für die Weiterleitung und der äußere Bezeichnungswert bestätigen, dass dieser Datenverkehr an die Bronze-Serviceklasse LSP gesendet wird.
Bestätigen des Failovers auf Best-Effort
Zweck
Schalten Sie den Bronze-Transport-LSP herunter, um zu überprüfen, ob für den an CE2 gesendeten Datenverkehr ein Failover auf den BE-Pfad ausgeführt wird.
Action!
Wechseln Sie in den Konfigurationsmodus, und geben Sie einen ungültigen nächsten Hop als ERO für den Bronze-Transporttunnel an. Die Unfähigkeit, die ERO-Anforderung zu erfüllen, führt zu einem Rückgang des entsprechenden LSP.
[edit] user@PE1# set protocols mpls path bronze 10.1.66.6 strict
Sobald die Änderung festgeschrieben ist, wird der Bronzetunnel nach unten angezeigt:
root@PE1> show mpls lsp ingress Ingress LSP: 3 sessions To From State Rt P ActivePath LSPname 192.168.0.2 0.0.0.0 Dn 0 - bronze_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 * gold gold_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 * best-effort lsp_to_pe2
Wiederholen Sie die Befehle und verfolgen Sie die ping Route von CE1 bis zum Loopback von CE2.
root@CE1> ping 172.16.255.2 source 172.16.255.1 count 100 rapid
PING 172.16.255.2 (172.16.255.2): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
--- 172.16.255.2 ping statistics ---
100 packets transmitted, 100 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.164/5.345/12.348/1.240 ms
root@CE1> traceroute no-resolve 172.16.255.2
traceroute to 172.16.255.2 (172.16.255.2), 30 hops max, 52 byte packets
1 172.16.1.2 2.493 ms 1.766 ms 1.913 ms
2 10.1.25.2 5.211 ms 5.016 ms 5.514 ms
MPLS Label=299808 CoS=0 TTL=1 S=0
MPLS Label=299808 CoS=0 TTL=1 S=1
3 10.1.56.2 4.216 ms 4.467 ms 4.551 ms
MPLS Label=299808 CoS=0 TTL=1 S=1
4 172.16.255.2 5.492 ms 5.543 ms 5.112 msZeigen Sie erneut MPLS-Statistiken auf PE1 an.
user@PE1> show mpls lsp statistics root@PE1> show mpls lsp statistics Ingress LSP: 3 sessions To From State Packets Bytes LSPname 192.168.0.2 0.0.0.0 Dn NA NA bronze_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 0 gold_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 100 8400 lsp_to_pe2 Total 3 displayed, Up 2, Down 1 . . .
Bedeutung
Der Ping-Austausch ist immer noch erfolgreich, wenn auch jetzt auf einem Best-Effort-Pfad. Auf der PE bestätigt die Statistik den Einsatz des Best-Effort-Transporttunnels. Die Ablaufverfolgungsroute zeigt, dass PE1 jetzt über PE3 an den nächsten Hop von 10.1.25.2 weitergeleitet wird. Dadurch wird das Failover von einer farbigen Transportklasse auf die Best-Effort-Klasse im Falle eines Ausfalls des Transporttunnels bestätigt.
In diesem Abschnitt haben wir ein Failover auf die BE-Klasse durchgeführt, indem wir den LSP heruntergefahren haben, der der Bronze-Serviceklasse zugeordnet ist. Alternativ können Sie die EBGP-Exportrichtlinie auf dem CE2-Gerät ändern, damit es die Farbgemeinschaft Gold (100) anfügt. Bei diesem Ansatz erwarten Sie, dass der Ping-Datenverkehr von CE1 zu CE2 den Gold-LSP übernimmt, anstatt ein Failover auf BE durchzuführen. Das Folgende macht den Trick bei CE2, wenn Sie diesen Ansatz bevorzugen. Stellen Sie sicher, dass Sie die Änderungen bei CE2 übernehmen.
[edit] root@CE2# delete policy-options policy-statement adv_direct term 1 then community add map2bronze root@CE2# set policy-options policy-statement adv_direct term 1 then community add map2gold
Anlage 1: Fehlerbehebung
Unser Verifizierungsabschnitt basiert auf der Annahme, dass Sie über ein funktionierendes Netzwerk verfügen, sodass der Schwerpunkt auf die Bestätigung des Betriebs von BGP-CT gelegt werden kann. Die BGP-CT-Funktion in einem MPLS-basierten Layer-3-VPN-Kontext ist von einem Netzwerk mit funktionierenden Schnittstellen (IGP, RSVP, MPLS und BGP) abhängig.
Tabelle 4 bietet eine Anleitung, was zu beachten ist, wenn Ihre BGP-CT-Lösung nicht wie erwartet funktioniert. Die Tabelle ist von unten nach oben strukturiert, beginnend mit der grundlegenden Schnittstellenkonnektivität bis hin zum erfolgreichen BGP-Routenaustausch zwischen den PE-Geräten.
In diesem Beispiel konfigurieren Sie eine Loopback-Adresse und eine Router-ID. Wenn das Gerät zuvor eine andere RID hatte, kann es einige Zeit dauern, bis sich die Dinge stabilisiert haben. Das Ändern der RID ist sehr störend und kommt nicht oft vor. Wenn Sie sich in einer Laborumgebung befinden, wird empfohlen, den restart routing Betriebsmodusbefehl auf allen Geräten direkt nach dem Commit der neuen RID auszugeben.
| Funktionale Schicht |
Verifizierungsansatz |
| Schnittstellen und IP-Adressierung | Stellen Sie sicher, dass alle Schnittstellen in Ihrer Topologie betriebsbereit sind. Stellen Sie sicher, dass Sie sowohl das lokale als auch das Remote-Ende jeder Verbindung anpingen können. Wie für die meisten Netzwerke erfordern die Protokolle und Dienste in diesem Beispiel eine funktionierende IPv4-Infrastruktur.root@PE1> show interfaces terse | match "(ge-0/0/0|ge-0/0/1|ge-0/0/2|ge-0/0/3)"
ge-0/0/0 up up
ge-0/0/0.0 up up inet 172.16.1.2/30
ge-0/0/1 up up
ge-0/0/1.0 up up inet 10.1.23.1/24
ge-0/0/2 up up
ge-0/0/2.0 up up inet 10.1.24.1/24
ge-0/0/3 up up
ge-0/0/3.0 up up inet 10.1.25.1/24
root@PE1> ping 10.1.23.2 count 1
PING 10.1.23.2 (10.1.23.2): 56 data bytes
64 bytes from 10.1.23.2: icmp_seq=0 ttl=64 time=2.951 ms
--- 10.1.23.2 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.951/2.951/2.951/0.000 ms
root@PE1> ping 172.16.1.1 routing-instance CE1_L3vpn count 1
PING 172.16.1.1 (172.16.1.1): 56 data bytes
64 bytes from 172.16.1.1: icmp_seq=0 ttl=64 time=2.755 ms
--- 172.16.1.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.755/2.755/2.755/0.000 ms
|
| OSPF (IGP)-Routing | Vergewissern Sie sich, dass alle Provider-Geräte über alle erwarteten OSPF-Nachbarschaften verfügen. Verwenden Sie die show ospf interfaces Befehle und show ospf neighbors Betriebsmodus. Zeigen Sie die Routen für die Provider-Loopback-Adressen an und bestätigen Sie gültige OSPF-Pfade für alle Remote-Loopback-Adressen (show route protocol ospf | match 192.168.0). Ping vom lokalen Loopback zu den Remote-Loopback-Adressen aller Provider-Router.In diesem Beispiel werden CSPF-basierte Sprachdienstleister verwendet. Dies erfordert, dass OSPF mit der root@PE1> show ospf interface Interface State Area DR ID BDR ID Nbrs ge-0/0/1.0 BDR 0.0.0.0 192.168.0.11 192.168.0.1 1 ge-0/0/2.0 BDR 0.0.0.0 192.168.0.12 192.168.0.1 1 ge-0/0/3.0 DR 0.0.0.0 192.168.0.1 192.168.0.13 1 lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0 root@PE1> show ospf neighbor Address Interface State ID Pri Dead 10.1.23.2 ge-0/0/1.0 Full 192.168.0.11 128 34 10.1.24.2 ge-0/0/2.0 Full 192.168.0.12 128 32 10.1.25.2 ge-0/0/3.0 Full 192.168.0.13 128 37 root@PE1> show route protocol ospf| match 192.168.0 192.168.0.2/32 *[OSPF/10] 00:10:15, metric 2 192.168.0.11/32 *[OSPF/10] 00:18:40, metric 1 192.168.0.12/32 *[OSPF/10] 00:18:35, metric 1 192.168.0.13/32 *[OSPF/10] 00:10:15, metric 1 root@PE1> ping 192.168.0.2 source 192.168.0.1 count 1 PING 192.168.0.2 (192.168.0.2): 56 data bytes 64 bytes from 192.168.0.2: icmp_seq=0 ttl=63 time=3.045 ms --- 192.168.0.2 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.045/3.045/3.045/0.000 ms |
| MPLS und RSVP | Vergewissern Sie sich, dass alle Core-Schnittstellen für die mpls Produktfamilie aktiviert sind. mit einem show interfaces terse Befehl. Stellen Sie außerdem sicher, dass alle Anbieterschnittstellen unter den protocols mpls Hierarchien und protocols RSVP aktiviert sind. Verwenden Sie die show mpls interfaces Befehle und show rsvp interfaces . HINWEIS:
Vergewissern Sie sich, dass die korrekten Nummern der Schnittstelleneinheiten für die MPLS-Familie und für jedes Protokoll aufgeführt sind. In diesem Beispiel wird auf allen Schnittstellen Einheit 0 verwendet, bei der es sich um die Standardeinheitennummer handelt. root@PE1> show rsvp interface
RSVP interface: 4 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
ge-0/0/1.0 Up 1 100% 1000Mbps 1000Mbps 0bps 0bps
ge-0/0/2.0 Up 1 100% 1000Mbps 1000Mbps 0bps 0bps
ge-0/0/3.0 Up 1 100% 1000Mbps 1000Mbps 0bps 0bps
lo0.0 Up 0 100% 0bps 0bps 0bps 0bps
root@PE1> show mpls interface
Interface State Administrative groups (x: extended)
ge-0/0/1.0 Up <none>
ge-0/0/2.0 Up <none>
ge-0/0/3.0 Up <none>Vergewissern Sie sich auf den PE-Routern, dass die LSPs korrekt für den Ausgang an der Loopback-Adresse des Remote-PE-Geräts definiert sind. Vergewissern Sie sich, dass die EROs und alle anderen TE-Einschränkungen gültig sind. Verwenden Sie die HINWEIS: In unseren Beispielen werden CSPF-basierte Sprachdienstleister verwendet. Dies setzt voraus, dass die IGP eine TE-Datenbank (TED) unterstützt. Wenn OSPF die IGP ist, stellen Sie sicher, dass Sie die
traffic-engieering Konfigurationsanweisung angeben. Alternativ können Sie die no-cspf Anweisung in der LSP-Definition verwenden, um CSPF aus der Gleichung zu entfernen.root@PE1> show mpls lsp Ingress LSP: 3 sessions To From State Rt P ActivePath LSPname 192.168.0.2 192.168.0.1 Up 0 * bronze bronze_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 * gold gold_lsp_to_pe2 192.168.0.2 192.168.0.1 Up 0 * best-effort lsp_to_pe2 Total 3 displayed, Up 3, Down 0 Egress LSP: 3 sessions To From State Rt Style Labelin Labelout LSPname 192.168.0.1 192.168.0.2 Up 0 1 FF 3 - bronze_lsp_to_pe1 192.168.0.1 192.168.0.2 Up 0 1 FF 3 - gold_lsp_to_pe1 192.168.0.1 192.168.0.2 Up 0 1 FF 3 - lsp_to_pe1 Total 3 displayed, Up 3, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0 |
| BGP | Verwenden Sie den show bgp summaryBefehl auf den PE-Geräten, um zu bestätigen, dass sowohl ihre EBGP-Sitzung zum CE als auch die IBGP-Sitzung zum Remote-PE eingerichtet wurde. Wenn BGP ausfällt, obwohl ein Ping möglich ist, vermuten Sie eine schlechte Peer-Definition. Denken Sie daran, dass Loopback-Peering (für IBGP) die local-address Anweisung erfordert. Geben Sie für EBGP direkt verbundene nächste Hops an, und bestätigen Sie, dass die lokale AS-Nummer unter edit routing-options und die Remote-AS-Nummer unter der EBGP-Peergruppe angegeben sind.Vergewissern Sie sich, dass in der PE-PE-Sitzung die root@PE1> show bgp summary
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 2 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
0 0 0 0 0 0
bgp.l3vpn.0
2 2 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
172.16.1.1 64510 55 55 0 0 23:13 Establ
CE1_L3vpn.inet.0: 1/2/2/0
192.168.0.2 65412 57 56 0 0 23:11 Establ
inet.0: 0/0/0/0
bgp.l3vpn.0: 2/2/2/0
CE1_L3vpn.inet.0: 2/2/2/0Die Befehle show route advertising und receiving protocol sind nützlich, wenn Sie bestätigen möchten, welche Routen ein bestimmter BGP-Lautsprecher ankündigt bzw. empfängt. root@PE1> show route advertising-protocol bgp 192.168.0.2 CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.1.0/30 Self 100 I * 172.16.255.1/32 Self 100 64510 I root@PE1> show route receive-protocol bgp 192.168.0.2 inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden) inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.2.0/30 192.168.0.2 100 I * 172.16.255.2/32 192.168.0.2 100 64520 I junos-rti-tc-100.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) junos-rti-tc-200.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 192.168.0.2:12:172.16.2.0/30 * 192.168.0.2 100 I 192.168.0.2:12:172.16.255.2/32 * 192.168.0.2 100 64520 I |
| Layer 3-VPN | Stellen Sie sicher, dass die IBGP-Sitzung Routen unterstützt family inet-vpn . Vergewissern Sie sich, dass die vom Remote-PE angekündigten Routen basierend auf dem Routenziel in die richtige Instanz importiert werden. Stellen Sie sicher, dass die Import- und Exportrichtlinie, die in der Routing-Instanz jedes PE verwendet wird, übereinstimmt, und kündigen Sie die richtigen Routen an. Einige der Anzeigen im BGP-Verifizierungsabschnitt bestätigen den Empfang von Remote-CE-Routen und den Import dieser Routen in die VRF-Instanz. root@PE1> show bgp neighbor 192.168.0.2 | match nlri
NLRI for restart configured on peer: inet-unicast inet-vpn-unicast
NLRI advertised by peer: inet-unicast inet-vpn-unicast
NLRI for this session: inet-unicast inet-vpn-unicast
root@PE1> show route table CE1_L3vpn.inet
root@PE1> show route receive-protocol bgp 192.168.0.2 172.16.255.2 detail
. . .
CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
* 172.16.255.2/32 (1 entry, 1 announced)
Import Accepted
Route Distinguisher: 192.168.0.2:12
VPN Label: 299776
Nexthop: 192.168.0.2
Localpref: 100
AS path: 64520 I
Communities: target:65412:12 color:0:200
root@PE1> show route table CE1_L3vpn.inet
CE1_L3vpn.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.1.0/30 *[Direct/0] 00:30:11
> via ge-0/0/0.0
[BGP/170] 00:29:57, localpref 100
AS path: 64510 I, validation-state: unverified
> to 172.16.1.1 via ge-0/0/0.0
172.16.1.2/32 *[Local/0] 00:30:11
Local via ge-0/0/0.0
172.16.2.0/30 *[BGP/170] 00:21:26, localpref 100, from 192.168.0.2
AS path: I, validation-state: unverified
> to 10.1.25.2 via ge-0/0/3.0, label-switched-path lsp_to_pe2
172.16.255.1/32 *[BGP/170] 00:29:57, localpref 100
AS path: 64510 I, validation-state: unverified
> to 172.16.1.1 via ge-0/0/0.0
172.16.255.2/32 *[BGP/170] 00:29:40, localpref 100, from 192.168.0.2
AS path: 64520 I, validation-state: unverified
> to 10.1.24.2 via ge-0/0/2.0, label-switched-path bronze_lsp_to_pe2Vergewissern Sie sich, dass das CE-Gerät die erwarteten Routen empfängt und ankündigt, indem Sie die für die BGP-Fehlerbehebung beschriebenen Methoden verwenden. |
Anlage 2: Festlegen von Befehlen auf allen Geräten
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für Ihre Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie in die CLI auf der Hierarchieebene [edit] ein.
CE1
set interfaces ge-0/0/0 unit 0 description "Link from CE1 to PE1 for Layer 3 VPN" set interfaces ge-0/0/0 unit 0 family inet address 172.16.1.1/30 set interfaces lo0 unit 0 family inet address 172.16.255.1/32 set policy-options policy-statement adv_direct term 1 from protocol direct set policy-options policy-statement adv_direct term 1 from route-filter 172.16.0.0/16 orlonger set policy-options policy-statement adv_direct term 1 then accept set protocols bgp group ToPE1 type external set protocols bgp group ToPE1 export adv_direct set protocols bgp group ToPE1 peer-as 65412 set protocols bgp group ToPE1 neighbor 172.16.1.2 set routing-options router-id 172.16.255.1 set routing-options autonomous-system 64510 set system host-name CE1
CE2
set interfaces ge-0/0/0 unit 0 description "Link from CE2 to PE2 for Layer 3 VPN" set interfaces ge-0/0/0 unit 0 family inet address 172.16.2.1/30 set interfaces lo0 unit 0 family inet address 172.16.255.2/32 set policy-options policy-statement adv_direct term 1 from protocol direct set policy-options policy-statement adv_direct term 1 from route-filter 172.16.0.0/16 orlonger set policy-options policy-statement adv_direct term 1 then community add map2bronze set policy-options policy-statement adv_direct term 1 then accept set policy-options community map2bronze members color:0:200 set policy-options community map2gold members color:0:100 set protocols bgp group PE2 type external set protocols bgp group PE2 export adv_direct set protocols bgp group PE2 peer-as 65412 set protocols bgp group PE2 neighbor 172.16.2.2 set routing-options router-id 172.16.255.2 set routing-options autonomous-system 64520 set system host-name CE2
PE1 (Prüfling)
set interfaces ge-0/0/0 unit 0 description "Link from PE1 to CE1" set interfaces ge-0/0/0 unit 0 family inet address 172.16.1.2/30 set interfaces ge-0/0/1 unit 0 description "Link from PE1 to P1" set interfaces ge-0/0/1 unit 0 family inet address 10.1.23.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 description "Link from PE1 to P2" set interfaces ge-0/0/2 unit 0 family inet address 10.1.24.1/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 description "Link from PE1 to P3" set interfaces ge-0/0/3 unit 0 family inet address 10.1.25.1/24 set interfaces ge-0/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.1/32 set routing-instances CE1_L3vpn instance-type vrf set routing-instances CE1_L3vpn protocols bgp group CE1 type external set routing-instances CE1_L3vpn protocols bgp group CE1 peer-as 64510 set routing-instances CE1_L3vpn protocols bgp group CE1 neighbor 172.16.1.1 set routing-instances CE1_L3vpn interface ge-0/0/0.0 set routing-instances CE1_L3vpn route-distinguisher 192.168.0.1:12 set routing-instances CE1_L3vpn vrf-target target:65412:12 set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 192.168.0.1 set protocols bgp group ibgp family inet unicast set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp neighbor 192.168.0.2 set protocols mpls icmp-tunneling set protocols mpls label-switched-path lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path lsp_to_pe2 primary best-effort set protocols mpls label-switched-path gold_lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path gold_lsp_to_pe2 preference 5 set protocols mpls label-switched-path gold_lsp_to_pe2 primary gold set protocols mpls label-switched-path gold_lsp_to_pe2 transport-class gold set protocols mpls label-switched-path bronze_lsp_to_pe2 to 192.168.0.2 set protocols mpls label-switched-path bronze_lsp_to_pe2 preference 5 set protocols mpls label-switched-path bronze_lsp_to_pe2 primary bronze set protocols mpls label-switched-path bronze_lsp_to_pe2 transport-class bronze set protocols mpls path gold 10.1.23.2 strict set protocols mpls path bronze 10.1.24.2 strict set protocols mpls path best-effort 10.1.25.2 strict set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols mpls interface ge-0/0/3.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/1.0 set protocols rsvp interface ge-0/0/2.0 set protocols rsvp interface ge-0/0/3.0 set routing-options route-distinguisher-id 192.168.0.1 set routing-options resolution preserve-nexthop-hierarchy set routing-options router-id 192.168.0.1 set routing-options autonomous-system 65412 set routing-options transport-class name gold color 100 set routing-options transport-class name bronze color 200 set system host-name PE1
PE2
set interfaces ge-0/0/0 unit 0 description "Link from PE2 to P1" set interfaces ge-0/0/0 unit 0 family inet address 10.1.36.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 description "Link from PE2 to P2" set interfaces ge-0/0/1 unit 0 family inet address 10.1.46.2/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 description "Link from PE2 to P3" set interfaces ge-0/0/2 unit 0 family inet address 10.1.56.2/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 description "Link from PE2 to CE2" set interfaces ge-0/0/3 unit 0 family inet address 172.16.2.2/30 set interfaces lo0 unit 0 family inet address 192.168.0.2/32 set routing-instances CE2_L3vpn instance-type vrf set routing-instances CE2_L3vpn protocols bgp group CE2 type external set routing-instances CE2_L3vpn protocols bgp group CE2 peer-as 64520 set routing-instances CE2_L3vpn protocols bgp group CE2 neighbor 172.16.2.1 set routing-instances CE2_L3vpn interface ge-0/0/3.0 set routing-instances CE2_L3vpn route-distinguisher 192.168.0.2:12 set routing-instances CE2_L3vpn vrf-target target:65412:12 set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 192.168.0.2 set protocols bgp group ibgp family inet unicast set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp neighbor 192.168.0.1 set protocols mpls icmp-tunneling set protocols mpls label-switched-path lsp_to_pe1 to 192.168.0.1 set protocols mpls label-switched-path gold_lsp_to_pe1 to 192.168.0.1 set protocols mpls label-switched-path gold_lsp_to_pe1 transport-class gold set protocols mpls label-switched-path gold_lsp_to_pe1 preference 5 set protocols mpls label-switched-path bronze_lsp_to_pe1 to 192.168.0.1 set protocols mpls label-switched-path bronze_lsp_to_pe1 transport-class bronze set protocols mpls label-switched-path bronze_lsp_to_pe1 preference 5 set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface ge-0/0/1.0 set protocols rsvp interface ge-0/0/2.0 set routing-options route-distinguisher-id 192.168.0.2 set routing-options router-id 192.168.0.2 set routing-options autonomous-system 65412 set routing-options transport-class name gold color 100 set routing-options transport-class name bronze color 200 set system host-name PE2
P1
set interfaces ge-0/0/0 unit 0 description "Link from P1 to PE1" set interfaces ge-0/0/0 unit 0 family inet address 10.1.23.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 description "Link from P1 to PE2" set interfaces ge-0/0/1 unit 0 family inet address 10.1.36.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.11/32 set protocols mpls icmp-tunneling set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface ge-0/0/1.0 set routing-options router-id 192.168.0.11 set system host-name P1
Platz 2
set interfaces ge-0/0/0 unit 0 description "Link from P2 to PE1" set interfaces ge-0/0/0 unit 0 family inet address 10.1.24.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 description "Link from P2 to PE2" set interfaces ge-0/0/1 unit 0 family inet address 10.1.46.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.12/32 set protocols mpls icmp-tunneling set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface ge-0/0/1.0 set routing-options router-id 192.168.0.12 set system host-name P2
P3
set interfaces ge-0/0/0 unit 0 description "Link from P3 to PE1" set interfaces ge-0/0/0 unit 0 family inet address 10.1.25.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 description "Link from P3 to PE2" set interfaces ge-0/0/1 unit 0 family inet address 10.1.56.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.0.13/32 set protocols mpls icmp-tunneling set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface ge-0/0/1.0 set routing-options router-id 192.168.0.13 set system host-name P3
Anlage 3: Konfigurationsausgabe auf PE1 anzeigen
Die vollständige PE1-Konfiguration im Curly Brace-Format
user@PE1# show | no-more
system {
host-name PE1;
}
interfaces {
ge-0/0/0 {
unit 0 {
description "Link from PE1 to CE1";
family inet {
address 172.16.1.2/30;
}
}
}
ge-0/0/1 {
unit 0 {
description "Link from PE1 to P1";
family inet {
address 10.1.23.1/24;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
description "Link from PE1 to P2";
family inet {
address 10.1.24.1/24;
}
family mpls;
}
}
ge-0/0/3 {
unit 0 {
description "Link from PE1 to P3";
family inet {
address 10.1.25.1/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.1/32;
}
}
}
}
routing-instances {
CE1_L3vpn {
instance-type vrf;
protocols {
bgp {
group CE1 {
type external;
peer-as 64510;
neighbor 172.16.1.1;
}
}
}
interface ge-0/0/0.0;
route-distinguisher 192.168.0.1:12;
vrf-target target:65412:12;
}
}
routing-options {
route-distinguisher-id 192.168.0.1;
resolution {
preserve-nexthop-hierarchy;
}
router-id 192.168.0.1;
autonomous-system 65412;
transport-class {
name gold {
color 100;
}
name bronze {
color 200;
}
}
}
protocols {
bgp {
group ibgp {
type internal;
local-address 192.168.0.1;
family inet {
unicast;
}
family inet-vpn {
unicast;
}
neighbor 192.168.0.2;
}
}
mpls {
label-switched-path lsp_to_pe2 {
to 192.168.0.2;
primary best-effort;
}
label-switched-path gold_lsp_to_pe2 {
to 192.168.0.2;
preference 5;
primary gold;
transport-class gold;
}
label-switched-path bronze_lsp_to_pe2 {
to 192.168.0.2;
preference 5;
primary bronze;
transport-class bronze;
}
path gold {
10.1.23.2 strict;
}
path bronze {
10.1.24.2 strict;
10.1.66.6 strict;
}
path best-effort {
10.1.25.2 strict;
}
icmp-tunneling;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
}
}
rsvp {
interface lo0.0;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
}
}BGP Classful Transport (BGP-CT) mit zugrunde liegenden farbigen SR-TE-Tunneln – Übersicht
Vorteile von BGP-CT mit darunter liegenden farbigen SR-TE-Tunneln
- Löst Skalierungsprobleme, die in Zukunft auftreten können, wenn das Netzwerk wächst.
- Bietet Interkonnektivität für Domänen, die unterschiedliche Technologien verwenden.
- Entkoppelt Services und Transportschichten, was zu einem vollständig verteilten Netzwerk führt.
- Bietet unabhängiges Bandbreitenmanagement durch einen domäneninternen Traffic-Engineering-Controller für SR-TE.
Große Netzwerke, die ständig wachsen und sich weiterentwickeln, erfordern eine nahtlose Segment-Routing-Architektur. Ab Junos OS Version 21.2,R1 unterstützen wir BGP-CT mit zugrunde liegendem Transport als farbige SR-TE-Tunnel. BGP-CT kann Servicerouten mithilfe der Transport-RIBs auflösen und den nächsten Hop berechnen. Services, die derzeit über BGP-CT unterstützt werden, können auch die zugrunde liegenden farbigen SR-TE-Tunnel für die Routenauflösung verwenden. Die Services können nun die zugrunde liegenden farbigen SR-TE-Tunnel verwenden, wie z. B. die statischen farbigen, BGP-SR-TE-, programmierbaren rpd- und PCEP-farbigen Tunnel. BGP-CT nutzt die Erreichbarkeit des nächsten Hops, um Dienstrouten über die gewünschte Transportklasse aufzulösen.
Um die BGP-CT-Service-Routenauflösung über zugrunde liegende farbige SR-TE-Tunnel zu aktivieren, fügen Sie die use-transport-class Anweisung auf Hierarchieebene [edit protocols source-packet-routing] ein.
- Aktivieren Sie die
use-transport-classAnweisungauf der
zusammen mit der[edit protocols source-packet-routing]Hierarchieebene.auto-createAnweisung auf der[edit routing-options transport-class]Hierarchieebene. - Wir unterstützen keine RIB-Gruppen für farbige SR-TE-Tunnel mit
use-transport-classund nur farbige SR-TE-Tunnel mit dieser Funktion.
Siehe auch
Farbbasiertes Mapping von VPN-Diensten im Überblick
Sie können Farbe als Protokolleinschränkung für den nächsten Hop (zusätzlich zur IPv4- oder IPv6-Adresse) für die Auflösung von Transporttunneln über statische, farbige und BGP-Segment-Routing-SR-TE-LSPs (Traffic Engineering) angeben. Dies wird als Next-Hop-Auflösung des Color-IP-Protokolls bezeichnet, bei dem Sie eine Auflösungszuordnung konfigurieren und auf die VPN-Dienste anwenden müssen. Mit dieser Funktion können Sie die farbbasierte Datenverkehrssteuerung von Layer-2- und Layer-3-VPN-Diensten aktivieren.
Junos OS unterstützt farbige SR-TE-LSPs, die einer einzigen Farbe zugeordnet sind. Die Funktion "Farbbasierte Zuordnung von VPN-Diensten" wird für statisch gefärbte LSPs und BGP SR-TE LSPs unterstützt.
- VPN-Dienst-Coloring
- Festlegen des VPN-Dienstzuordnungsmodus
- Color-IP-Protokoll Next Hop Auflösung
- Fallback auf IP-Protokoll Next Hop Resolution
- Farbbasiertes Unicast-Mapping mit BGP-Kennzeichnung über SR-TE- und IS-IS-Underlay
- Unterstützte und nicht unterstützte Funktionen für die farbbasierte Zuordnung von VPN-Diensten
VPN-Dienst-Coloring
Im Allgemeinen kann einem VPN-Dienst auf dem Ausgangsrouter, auf dem der VPN-NLRI angekündigt wird, oder auf einem Eingangsrouter, auf dem der VPN-NLRI empfangen und verarbeitet wird, eine Farbe zugewiesen werden.
Sie können den VPN-Diensten auf verschiedenen Ebenen eine Farbe zuweisen:
-
Pro Routing-Instanz.
-
Pro BGP-Gruppe.
-
Pro BGP-Nachbar.
-
Pro Präfix.
-
Satz von Präfixen.
Sobald Sie eine Farbe zugewiesen haben, wird die Farbe in Form einer erweiterten BGP-Farbcommunity an einen VPN-Dienst angehängt.
Sie können einem VPN-Dienst mehrere Farben zuweisen, die als mehrfarbige VPN-Dienste bezeichnet werden. In solchen Fällen wird der kleinste Farbwert als Farbe des VPN-Dienstes betrachtet, und alle anderen Farben werden ignoriert.
Mehrere Farben werden von Ausgangs- und/oder Eingangsgeräten über mehrere Richtlinien in der folgenden Reihenfolge zugewiesen:
-
BGP-Exportrichtlinie auf dem Ausgangsgerät.
-
BGP-Importrichtlinie auf dem Eingangsgerät.
-
VRF-Importrichtlinie auf dem Eingangsgerät.
Die beiden Modi der VPN-Dienstfärbung sind:
Farbzuweisung für Ausgang
In diesem Modus ist das Ausgangsgerät (d. h. der Werbetreibende des VPN-NLRI) für die Einfärbung des VPN-Dienstes verantwortlich. Um diesen Modus zu aktivieren, können Sie eine Routing-Richtlinie definieren und diese in der Routing-Instanz vrf-export, group export oder group neighbor export des VPN-Dienstes auf der Hierarchieebene [edit protocols bgp] anwenden. Das VPN NLRI wird von BGP mit der angegebenen Farbe Extended Community beworben.
Zum Beispiel:
[edit policy-options]
community red-comm {
members color:0:50;
}[edit policy-options]
policy-statement pol-color {
term t1 {
from {
[any match conditions];
}
then {
community add red-comm;
accept;
}
}
}[edit routing-instances]
vpn-X {
...
vrf-export pol-color ...;
}ODER
Wenn Sie die Routing-Richtlinie als Exportrichtlinie einer BGP-Gruppe oder eines BGP-Nachbarn anwenden, müssen Sie die vpn-apply-export Anweisung auf BGP-, BGP-Gruppen- oder BGP-Nachbarebene einschließen, damit die Richtlinie auf die VPN-NLRI wirksam wird.
[edit protocols bgp]
group PEs {
...
neighbor PE-A {
export pol-color ...;
vpn-apply-export;
}
}Die Routing-Richtlinien werden auf NLRIs mit Layer-3-VPN-Präfix, Layer-2-VPN-NRLIs und EVPN-NLRIs angewendet. Die farbige erweiterte Community wird von allen VPN-Routen geerbt, importiert und in den Ziel-VRFs auf einem oder mehreren Eingangsgeräten installiert.
Zuweisung von Eingangsfarben
In diesem Modus ist das Eingangsgerät (d. h. der Empfänger des VPN-NLRI) für die Farbgebung des VPN-Dienstes verantwortlich. Um diesen Modus zu aktivieren, können Sie eine Routing-Richtlinie definieren und diese auf die Routing-Instanz vrf-import, den Gruppenimport oder den Gruppennachbarimport des VPN-Diensts auf Hierarchieebene [edit protocols bgp] anwenden. Alle VPN-Routen, die der Routing-Richtlinie entsprechen, werden mit der angegebenen Farbe der erweiterten Community verknüpft.
Zum Beispiel:
[edit policy-options]
community red-comm {
members color:0:50;
}[edit policy-options]
policy-statement pol-color {
term t1 {
from {
[any match conditions];
}
then {
community add red-comm;
accept;
}
}
}[edit routing-instances]
vpn-Y {
...
vrf-import pol-color ...;
}ODER
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-color ...;
}
}Festlegen des VPN-Dienstzuordnungsmodus
Um flexible VPN-Dienstzuordnungsmodi anzugeben, müssen Sie eine Richtlinie mithilfe der resolution-map-Anweisung definieren und die Richtlinie in der Routing-Instanz vrf-import, group import oder group neighbor import eines VPN-Dienstes auf der Hierarchieebene [edit protocols bgp] referenzieren. Alle VPN-Routen, die der Routing-Richtlinie entsprechen, werden mit der angegebenen Auflösungskarte verknüpft.
Zum Beispiel:
[edit policy-options]
resolution-map map-A {
<mode-1>;
<mode-2>;
...
}
policy-statement pol-resolution {
term t1 {
from {
[any match conditions];
}
then {
resolution-map map-A;
accept;
}
}
}Sie können die Importrichtlinie auf die Routing-Instanz des VPN-Dienstes anwenden.
[edit routing-instances]
vpn-Y {
...
vrf-import pol-resolution ...;
}Sie können die Importrichtlinie auch auf eine BGP-Gruppe oder einen BGP-Nachbarn anwenden.
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-resolution ...;
}
}Jeder VPN-Dienstzuordnungsmodus sollte einen eindeutigen Namen haben, der in der Auflösungszuordnung definiert ist. In der Auflösungskarte wird nur ein einziger Eintrag von IP-color unterstützt, wobei die VPN-Route(n) mit einem Next-Hop des colored-IP-Protokolls in Form von ip-address:color über die Routing-Tabellen inetcolor.0 und inet6color.0 aufgelöst werden.
Color-IP-Protokoll Next Hop Auflösung
Der Protokoll-Next-Hop-Auflösungsprozess wurde verbessert, um die Next-Hop-Auflösung des Colored-IP-Protokolls zu unterstützen. Bei einem farbigen VPN-Dienst nimmt der Protokollauflösungsprozess für den nächsten Hop eine Farbe und eine Auflösungszuordnung an, erstellt einen farbigen IP-Protokoll-nächsten Hop in Form von ip-address:colorund löst den nächsten Protokoll-Hop in den Routing-Tabellen inetcolor.0 und inet6color.0 auf.
Sie müssen eine Richtlinie so konfigurieren, dass sie die Multipath-Auflösung von farbigen Layer-2-VPN-, Layer-3-VPN- oder EVPN-Services über farbige LSPs unterstützt. Die Richtlinie muss dann mit der entsprechenden RIB-Tabelle als Resolver-Importrichtlinie angewendet werden.
Zum Beispiel:
[edit policy-options]
policy-statement mpath {
then multipath-resolve;
}[edit routing-options]
resolution {
rib bgp.l3vpn.0 {
inetcolor-import mpath;
}
}
resolution {
rib bgp.l3vpn-inet6.0 {
inet6color-import mpath;
}
}
resolution {
rib bgp.l2vpn.0 {
inetcolor-import mpath;
}
}
resolution {
rib mpls.0 {
inetcolor-import mpath;
}
}
resolution {
rib bgp.evpn.0 {
inetcolor-import mpath;
}
}Fallback auf IP-Protokoll Next Hop Resolution
Wenn auf einen farbigen VPN-Dienst keine Auflösungszuordnung angewendet wurde, ignoriert der VPN-Dienst seine Farbe und greift auf die IP-Protokollauflösung für den nächsten Hop zurück. Umgekehrt gilt: Wenn auf einen nicht farbigen VPN-Dienst eine Auflösungszuordnung angewendet wurde, wird die Auflösungszuordnung ignoriert, und der VPN-Dienst verwendet die IP-Protokollauflösung für den nächsten Hop.
Das Fallback ist ein einfacher Prozess von farbigen SR-TE-LSPs zu LDP-LSPs, indem eine RIB-Gruppe für LDP verwendet wird, um Routen in inet{6}color.0-Routing-Tabellen zu installieren. Eine längste Präfixübereinstimmung für einen Next-Hop mit farbigem IP-Protokoll stellt sicher, dass eine LDP-Route mit einer übereinstimmenden IP-Adresse zurückgegeben wird, wenn keine farbige SR-TE LSP-Route vorhanden ist.
Farbbasiertes Unicast-Mapping mit BGP-Kennzeichnung über SR-TE- und IS-IS-Underlay
Ab Junos OS Version 20.2R1 kann BGP Labeled Unicast (BGP-LU) IPv4- oder IPv6-Routen über Segment-Routing-Traffic Engineering (SR-TE) mit IS-IS-Underlay sowohl für IPv4- als auch für IPv6-Adressfamilien auflösen. BGP-LU unterstützt die Zuordnung einer BGP-Community-Farbe und die Definition einer resolution map für SR-TE. Es wird ein nächster Hop für ein farbiges Protokoll erstellt, das in einem farbigen SR-TE-Tunnel in der inetcolor.0 Tabelle "oder inet6color.0 " aufgelöst wird. So löst BGP-LU den nächsten Hop des Protokolls über SR-TE-Tunnel für den Pakettransport auf. BGP-Verwendungen inet.3 und inet6.3 -Tabellen für nicht-farbbasiertes Mapping.
Unterstützte und nicht unterstützte Funktionen für die farbbasierte Zuordnung von VPN-Diensten
Die folgenden Merkmale und Funktionen werden von der farbbasierten Zuordnung von VPN-Diensten unterstützt:
-
BGP-Layer-3-VPN
-
BGP Layer 2 VPN (Kompella Layer 2 VPN)
-
BGP-EVPN
-
Auflösungskarte mit einer einzigen IP-Farboption.
-
Farbige IPv4- und IPv6-Protokollauflösung für den nächsten Hop.
-
Routing-Informationsdatenbank (auch als Routing-Tabelle bezeichnet) gruppenbasiertes Fallback auf LDP-LSP in den Routing-Tabellen inetcolor.0 oder inet6color.0.
-
Farbiges SR-TE LSP.
-
Virtuelle Plattformen.
-
64-Bit-Junos-Betriebssystem.
-
Logische Systeme.
-
BGP-gekennzeichnetes Unicast
Die folgenden Merkmale und Funktionen werden von der farbbasierten Zuordnung von VPN-Diensten nicht unterstützt:
-
Farbige MPLS-LSPs, z. B. RSVP, LDP, BGP-LU, statisch.
-
Layer-2-Schaltung
-
Automatisch erkanntes FEC-129 BGP und LDP-signalisiertes Layer-2-VPN.
-
VPLS
-
MVPN
-
IPv4 und IPv6 mit Resolution-Map.