Dieses Dokument zeigt den Paketfluss über eine MPLS-Cloud (Multiprotocol Label Switching). Außerdem wird das Konzept eingeführt, mehrere Labels in einem Paket zu enthalten.
Bei Verwendung von VPN mit MPLS können mehrere Standorte transparent über das Netzwerk eines Service Providers miteinander verbunden werden. Ein Service-Provider-Netzwerk kann mehrere verschiedene IP-VPNs unterstützen. Jeder dieser Netzwerke erscheint für seine Benutzer als privates Netzwerk, das von allen anderen Netzwerken getrennt ist. Innerhalb eines VPN kann jeder Standort IP-Pakete an einen anderen Standort im selben VPN senden.
Jedes VPN ist mit einer oder mehreren VPN-Routing- oder -Weiterleitungsinstanzen (VRFs) verknüpft. Eine VRF besteht aus einer IP-Routing-Tabelle, einer abgeleiteten CEF-Tabelle (Cisco Express Forwarding) und einer Reihe von Schnittstellen, die diese Weiterleitungstabelle verwenden.
Der Router verwaltet eine separate Routing- und CEF-Tabelle für jede VRF-Instanz. Dadurch wird verhindert, dass Informationen außerhalb des VPN gesendet werden, und dasselbe Subnetz kann in mehreren VPNs verwendet werden, ohne dass doppelte IP-Adressprobleme auftreten.
Der Router, der Border Gateway Protocol (BGP) verwendet, verteilt die VPN-Routing-Informationen über die erweiterten BGP-Communitys.
Weitere Informationen zur Weitergabe von Updates über ein VPN finden Sie in den folgenden Dokumenten:
Die MPLS-VPN-Funktion wurde in der Cisco IOS® Softwareversion 12.0(5)T eingeführt.
Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.
Für dieses Dokument bestehen keine besonderen Voraussetzungen.
Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.
Die in diesem Dokument enthaltenen Informationen wurden aus Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Sie in einem Live-Netzwerk arbeiten, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen, bevor Sie es verwenden.
Um zu verstehen, wie VPN MPLS funktioniert, nehmen wir die folgende Beispielkonfiguration vor:
In dieser Konfiguration:
Rapid und Pound sind die CE-Geräte (Customer Edge), auf denen MPLS nicht ausgeführt wird. Sie sind mit dem VPN VRF101 verknüpft. Zur Vereinfachung wird hier nur eine VRF-Instanz verwendet.
Farm und Medina sind die Provider Edge-Geräte (PEs).
Meilen und Yard sind LightStream 1010-Router. Sie bilden den MPLS-Backbone.
Die folgende Ausgabe zeigt, was passiert, wenn Rapid Pakete innerhalb des VPN VRF101 an Pound sendet:
rapid#ping 11.5.5.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 11.5.5.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms rapid#show ip route 11.5.5.5 Routing entry for 11.5.5.4/30 Known via "rip", distance 120, metric 1 Redistributing via rip Last update from 150.150.0.1 on FastEthernet0/1, 00:00:16 ago Routing Descriptor Blocks: * 150.150.0.1, from 150.150.0.1, 00:00:16 ago, via FastEthernet0/1 Route metric is 1, traffic share count is 1
Farm erhält die Adresse 11.5.5.5 von Med in China über BGP-Anzeigen:
Farm#show ip bgp vpnv4 vrf vrf101 11.5.5.5 BGP routing table entry for 1:101:11.5.5.4/30, version 56 Paths: (1 available, best #1, table vrf101) Not advertised to any peer Local 125.2.2.2 (metric 4) from 125.2.2.2 (125.2.2.2) Origin incomplete, metric 1, localpref 100, valid, internal, best Extended Community: RT:1:101 Farm#show ip route vrf vrf101 11.5.5.5 Routing entry for 11.5.5.4/30 Known via "bgp 1", distance 200, metric 1, type internal Redistributing via rip Advertised by rip metric 0 Last update from 125.2.2.2 01:29:20 ago Routing Descriptor Blocks: * 125.2.2.2 (Default-IP-Routing-Table), from 125.2.2.2, 01:29:20 ago Route metric is 1, traffic share count is 1 AS Hops 0
Hinweis: 125.2.2.2 ist ein Loopback auf Medina und wird zur Erstellung der BGP-Kopplung mit Farm verwendet.
Um das für 11.5.5.5 vorgesehene Paket an Medina weiterzuleiten, verwendet Farm zwei Labels. Die Weiterleitungstabelle für CEF- und VPN-Labels in der Farm bietet hierzu folgende Möglichkeiten:
Farm#show tag forwarding -table vrf vrf101 11.5.5.5 detail Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface None 2/91 11.5.5.4/30 0 AT4/0.1 point2point MAC/Encaps=4/12, MTU=4466, Tag Stack{2/91(vcd=69) 40} 00458847 0004500000028000 Farm#show ip cef vrf vrf101 11.5.5.5 11.5.5.4/30, version 25, cached adjacency to ATM4/0.1 0 packets, 0 bytes tag information set local tag: VPN-route-head fast tag rewrite with AT4/0.1, point2point, tags imposed: {2/91(vcd=69) 40} via 125.2.2.2, 0 dependencies, recursive next hop 10.0.0.14, ATM4/0.1 via 125.2.2.2/32 valid cached adjacency tag rewrite with AT4/0.1, point2point, tags imposed: {2/91(vcd=69) 40}
Auf die Pakete, die die Farm verlassen und für 11.5.5.5 bestimmt sind, werden zwei Etiketten angewendet. Diese können wie folgt dargestellt werden:
Das Label 40 wird dem Paket hinzugefügt und anschließend in Zellen mit 2/91 als VPI/VCI-Werte segmentiert. Das bedeutet, dass das Label auch 2/91 genannt wird.
Hinweis: Beim Empfang eines Frames mit mehreren Etiketten prüft das Empfangsgerät nur das erste.
Die Labels werden wie folgt zugewiesen:
2/91 wird von Yard zugewiesen und entspricht der Adresse 125.2.2.2. Diese Adresse wird zum Erstellen der BGP-Kopplung mit Farm verwendet. Weitere Informationen finden Sie unter MPLS VPN over ATM: BGP oder RIP am Kundenstandort für weitere Informationen. Das Label wird im MPLS-Core verwendet, um Frames von der Farm an die Medina 125.2.2.2 zu senden.
40 wird von Medina 11.5.5.5 zugewiesen. Erhält ein PE (in diesem Fall Medina) ein IP-Präfix von einem CE (Pound), weist der PE dieser Route ein spezifisches Label zu. Das Label ist abhängig von dem VPN-VRF, das die Route gelernt hat. Die Route und das Label werden anderen PEs mithilfe von BGP Enhanced Communities mitgeteilt.
Werfen wir einen Blick auf Medina:
Medina#show tag forwarding -table vrf vrf101 11.5.5.5 detail Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 40 Untagged 11.5.5.4/30[V] 570 Et1/1 11.3.3.2 MAC/Encaps=0/0, MTU=1500, Tag Stack{} VPN route: vrf101 Per-packet load-sharing
Nun, da wir wissen, woher die Labels kommen, können wir sehen, was mit den Paketen geschieht, die für 11.5.5.5 bestimmt sind. Farm sendet das segmentierte Paket über VC 2/91. Yard erhält das. Um zu sehen, was Yard mit diesen Zellen macht, verwenden Sie den folgenden Befehl:
Yard#show tag atm -tdp bindings 125.2.2.2 32 Destination: 125.2.2.2/32 Transit ATM0/1/1 2/91 Active -> ATM4/0/0 1/82 Active
Nach Erhalt dieser Zellen auf der VC 2/91 (Zellen, die für 125.2.2.2 bestimmt sind, auch bekannt als Medina) schaltet Yard diese Zellen mithilfe der ausgehenden VC 1/82 auf Meilen um.
Hinweis: Das Etikett 40 wurde nicht geprüft oder geändert.
Dasselbe passiert auf Meilen, indem die Zellen auf dem VC 1/33 nach Medina geschaltet werden:
Miles#show tag atm -tdp bindings 125.2.2.2 32 Destination: 125.2.2.2/32 Transit ATM0/1/3 1/82 Active -> ATM0/1/1 1/33 Active
Das bei Medina eintreffende Paket kann wie folgt dargestellt werden:
Beim Empfang der Zellen auf dem VC 1/33 überprüft Medina das Label 1/33 und stellt fest, dass dieses Label lokal am Router vorhanden ist. Dabei erkennt Medina, dass das Paket für eine seiner eigenen Adressen bestimmt ist:
Medina#show tag -switching atm-tdp bindings local-tag 1 33 Destination: 125.2.2.2/32 Tailend Router ATM2/0.66 1/33 Active, VCD=406
Medina entfernt daher das erste Label (1/33) und sieht, dass das Paket ein weiteres Label (40) hat. Anschließend wird überprüft, was dieses Label entspricht, und das Paket wird entsprechend umgeschaltet:
Medina#show tag -switching forwarding-table tags 40 Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 40 Untagged 11.5.5.4/30[V] 570 Et1/1 11.3.3.2
In diesem Fall erkennt Medina, dass das Paket für einen Standort bestimmt ist, der über eine normale IP-Verbindung verbunden ist. Er verwirft das Label und leitet das IP-Paket an das Ethernet 1/1 der Schnittstelle weiter.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
05-Jun-2005 |
Erstveröffentlichung |