Konfigurieren des VRF-Label-Modus mit Carrier-unterstützendem Carrier

Einleitung

In diesem Dokument wird erläutert, warum der VRF- (Per-Virtual Routing and Forwarding) oder CE-Labelmodus (Per-Customer Equipment) im CSC-Szenario (Carrier Supporting Carrier) nicht unterstützt wird. Außerdem wird beschrieben, wie sich die Weiterleitungsebene verhält, wenn Sie einen CSC-Kunden von Per-Prefix in einen anderen VRF-Labelmodus migrieren.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netz Live ist, überprüfen Sie, ob Sie die mögliche Auswirkung jedes möglichen Befehls verstehen.

Hintergrundinformationen

BGP-Layer-3-VPNs unterstützen im Allgemeinen die folgenden MPLS-Label-Zuweisungsmodi für den PE:

Pro Präfix: Standardmäßig verwenden alle vom CE abgefragten Routen den Präfixmodus. Pro jedes VPNv4-Präfix wird ein VPN-Label generiert.

Im CE-Modus wird jedem BGP Next-Hop ein VPN-Label zugewiesen (d. h. der CE-Router pro VRF-Modus weist jedem VRF ein VPN-Label zu. Standardmäßig wird für alle verbundenen Schnittstellen, die auf PE neu verteilt werden, ein VRF-Aggregatlabel verwendet (einschließlich: verbunden, neu verteilt, statisch zu null0- und BGP-Aggregaten).

Dieses Dokument soll als Leitfaden dafür dienen, welche Label-Zuweisungsmethode im CSC-Szenario verwendet werden kann.

Beförderer unterstützende Beförderer (CSC) werden unter Umständen implementiert, in denen ein Dienstleister die von einem anderen Diensteanbieter erbrachten Transportleistungen nutzen muss. Der Service Provider, der den Transport bereitstellt, wird Backbone Carrier genannt, und der Service Provider, der die vom Backbone Carrier bereitgestellten Services nutzt, wird als KundenCarrier bezeichnet. Der Kundenanbieter kann entweder ein ISP-Provider oder ein MPLS-VPN-Service Provider sein.

Im CSC-Modell sind die Verbindungen zwischen dem Backbone und dem Kundenbetreiber MPLS aktiviert, um einen End-to-End-LSP-Pfad zwischen den beiden POP-Standorten im Carrier-Netzwerk des Kunden bereitzustellen. Im CSC-Modell kennt der Backbone-Carrier, der MPLS-VPN-Services für den KundenCarrier bereitstellt, nur die internen Routen des Kundenträgers. Diese Routen sind für die Erstellung des LSP-Pfads zwischen den beiden POP-Standorten und für die Erstellung der iBGP- oder MP-iBGP-Sitzung zwischen den POP-Standorten relevant. Benutzernetzwerke werden dann über diese iBGP- oder MP-iBGP-Sitzung übertragen.

Beispiel: Im Diagramm wird SP1 als Backbone-Carrier und SP2 als KundenCarrier dargestellt.

Label Exchange-Methoden in der CSC-Architektur: Es gibt zwei Möglichkeiten, IGP-Labels in einem CSC-basierten MPLS-VPN-Netzwerk auszutauschen:

• Verwendung von IGP für Label Exchange (TDP/LDP)
• Verwendung von BGP für Label Exchange (eBGP LU)

BGP wurde in diesem Beispiel für den Label-Austausch verwendet.

Konfigurieren

Netzwerkdiagramm

Konfigurationen

Zunächst wird der Standard-VRF-Label-Modus (pro Präfix) für PE111, PE112, PE121 und PE122 verwendet.

Überprüfung

In diesem Abschnitt überprüfen Sie, ob Ihre Konfiguration ordnungsgemäß funktioniert.

Standardmäßig weist der PE-Router separate lokale Labels für jedes Präfix (Label-Modus pro Präfix) zu, das vom eBGP-Nachbarn gelernt wurde. Sie wird in diesen Ausgabefunktionen angezeigt.

RP/0/0/CPU0:PE111#show bgp vpnv4 unicast vrf SP2-CSC 172.16.1.11/32 | i Local Label
Local Label: 24006
RP/0/0/CPU0:PE111#show bgp vpnv4 unicast vrf SP2-CSC 172.16.1.12/32 | i Local Label
Local Label: 24014
RP/0/0/CPU0:PE111#show bgp vpnv4 unicast vrf SP2-CSC 172.16.1.13/32 | i Local Label
Local Label: 24007 

LFIB table operation for respective Local Label is SWAP (with Outgoing Label) and send the packet towards Outgoing interface Gi0/0/0/0 (towards eBGP neighbor).

RP/0/0/CPU0:PE111#show mpls forwarding labels 24006
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes 
Label  Label       or ID              Interface                    Switched 
------ ----------- ------------------ ------------ --------------- ------------
24006  Pop         172.16.1.11/32[V]  Gi0/0/0/0    10.11.111.11    0 

Similar results can be verified at other PE routers (PE112, PE121, PE122) for the BGP LU routes learned from eBGP neighbor.

Trace results from CE11 to CE12

CE11#traceroute 192.168.112.1 source lo0 numeric 
Type escape sequence to abort.
Tracing the route to 192.168.112.1
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.11.13 2 msec 1 msec 2 msec
2 10.12.13.12 [MPLS: Labels 24010/24012 Exp 0] 36 msec 47 msec 36 msec
3 10.12.112.112 [MPLS: Labels 24013/24012 Exp 0] 39 msec 36 msec 39 msec
4 10.1.112.1 [MPLS: Labels 24003/24011/24012 Exp 0] 43 msec 43 msec 38 msec
5 10.1.121.121 [MPLS: Labels 24011/24012 Exp 0] 39 msec 39 msec 37 msec
6 10.21.121.21 [MPLS: Labels 24001/24012 Exp 0] 36 msec 34 msec 36 msec
7 10.21.23.23 [MPLS: Label 24012 Exp 0] 36 msec 37 msec 38 msec
8 192.168.12.12 [AS 65012] 36 msec * 39 msec

In diesem Bild wird der entsprechende Label-Stack während der Datenebenenweiterleitung angezeigt:

Label-Modus pro VRF

Nach dem Wechsel zu Label Mode zu Per-VRF bei PE11, PE112, PE121 und PE122.

PE1XX:

RP/0/0/CPU0:PE111(config)#router bgp 65001
RP/0/0/CPU0:PE111(config-bgp)#vrf SP2-CSC 
RP/0/0/CPU0:PE111(config-bgp-vrf)#address-family ipv4 unicast 
RP/0/0/CPU0:PE111(config-bgp-vrf-af)#label mode per-vrf 
RP/0/0/CPU0:PE111(config-bgp-vrf-af)#root
RP/0/0/CPU0:PE111(config)#show 
Tue Jan 25 13:45:43.444 UTC
Building configuration...
router bgp 65001
 vrf SP2-CSC
  address-family ipv4 unicast
   label mode per-vrf
  !
 !
!
end
RP/0/0/CPU0:PE111(config)#commit

Jeder PE-Router weist nun für alle ursprünglichen VPNv4-Präfixe dasselbe MPLS-Label zu (VRF-Label-Modus). Sie wird in diesen Ausgabefunktionen angezeigt.

Beispielsweise stammt PE111.

RP/0/0/CPU0:PE111#sh bgp vpnv4 unicast vrf SP2-CSC 172.16.1.11/32 | i Local Label
Local Label: 24003
RP/0/0/CPU0:PE111#sh bgp vpnv4 unicast vrf SP2-CSC 172.16.1.12/32 | i Local Label
Local Label: 24003
RP/0/0/CPU0:PE111#sh bgp vpnv4 unicast vrf SP2-CSC 172.16.1.13/32 | i Local Label
Local Label: 24003

MPLS-Weiterleitungsebene

Die LFIB-Tabellenoperation für das entsprechende lokale Label ist "Aggregate" (Outgoing Label), d. h. "Untag" (Ausgehend-Label), d. h. "Untag" (Tags entfernen), und eine FIB-Suche nach der ausgehenden Schnittstelle wird durchgeführt.

RP/0/0/CPU0:PE111#sh mpls forwarding labels 24003
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes 
Label  Label       or ID              Interface                    Switched 
------ ----------- ------------------ ------------ --------------- ------------
24003  Aggregate   SP2-CSC: Per-VRF   Aggr[V] \
                                      SP2-CSC                      8798 

Let us try to Ping from CE11 to CE21

CE11#ping 192.168.112.1 source lo0 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.112.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.111.1 
.....
Success rate is 0 percent (0/5))

Wireshark Capture am PE121 (Gi0/0/0/5)

ICMP-Echo (Ping)-Anforderungspakete werden empfangen, aber keine Antwort gefunden.

Source IP: 192.168.111.1,
Destination IP: 192.168.112.1
Top Label: 24006
Bottom Label: 24012

Da der LFIB-Vorgang aggregiert ist, d. h. das eingehende MPLS-Paket in ein IP-Paket konvertiert und dann eine FIB-Suche nach dem Paket durchführt, um die ausgehende Schnittstelle zu ermitteln. Für die zuvor erwähnten ICMP-Anforderungspakete entfernt PE121 alle Labels und versucht, die FIB-Suche in "VRF: SP2-CSC" für 192.168.112.1/32. Da kein CEF-Eintrag vorhanden ist, wird das Paket einfach verworfen.

Aus diesem Grund wird der Label-Modus pro VRF für das CSC-Szenario nicht unterstützt.

Label-Modus pro CE

Nach dem Wechsel in den Label-Modus wird für PE111, PE112, PE121 und PE122 "per-ce" festgelegt.

PE1XX:

RP/0/0/CPU0:PE111(config)#router bgp 65001
RP/0/0/CPU0:PE111(config-bgp)#vrf SP2-CSC
RP/0/0/CPU0:PE111(config-bgp-vrf)#address-family ipv4 unicast 
RP/0/0/CPU0:PE111(config-bgp-vrf-af)#label mode per-ce 
RP/0/0/CPU0:PE111(config-bgp-vrf-af)#root
RP/0/0/CPU0:PE111(config)#show 
Building configuration...
router bgp 65001
 vrf SP2-CSC
  address-family ipv4 unicast
   label mode per-ce
  !
 !
!
end
RP/0/0/CPU0:PE111(config)#commit

Rest of the routers will be configured similarly

Jeder PE-Router weist jetzt pro Next-Hop ein MPLS-Label zu (also pro angeschlossener CE-Nachbarschaft). Sie wird in diesen Ausgabefunktionen angezeigt.

e.g. PE111 originates these prefixes and allocated same label - 24006

RP/0/0/CPU0:PE111#sh bgp vpnv4 unicast vrf SP2-CSC 172.16.1.11/32 | i Local Label
Local Label: 24006
RP/0/0/CPU0:PE111#sh bgp vpnv4 unicast vrf SP2-CSC 172.16.1.12/32 | i Local Label
Local Label: 24006
RP/0/0/CPU0:PE111#sh bgp vpnv4 unicast vrf SP2-CSC 172.16.1.13/32 | i Local Label
Local Label: 24006

MPLS-Weiterleitungsebene

Es gibt keinen LFIB-Eintrag für das lokale Label 24006.

RP/0/0/CPU0:PE111#sh mpls forwarding labels 24006
RP/0/0/CPU0:PE111#

Let us try to Ping from CE11 to CE12

CE11#ping 192.168.112.1 source lo0 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.112.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.111.1 
.....
Success rate is 0 percent (0/5)

Wireshark Capture am PE121 (Gi0/0/0/5)

ICMP-Echo (Ping)-Anforderungspakete werden empfangen, aber keine Antwort gefunden.

Source IP: 192.168.111.1,
Destination IP: 192.168.112.1
Top Label: 24009
Bottom Label: 24012

Aktivieren des Debuggens von MPLS-Dropdown auf PE121, und Sie sehen, dass ICMP-Pakete auf PE121 verworfen werden, da kein LFIB-Eintrag verfügbar ist.

RP/0/0/CPU0:PE121#debug mpls drop

RP/0/0/CPU0:PE121#show logging | i 24009
RP/0/0/CPU0:Jan 25 16:13:59.016 : netio[314]: ~mpls_netio_switch.c:2795~ Pkt Drop: GigabitEthernet0_0_0_5, No LFIB entry found for in_label 24009
RP/0/0/CPU0:Jan 25 16:14:01.016 : netio[314]: ~mpls_netio_switch.c:2795~ Pkt Drop: GigabitEthernet0_0_0_5, No LFIB entry found for in_label 24009
RP/0/0/CPU0:Jan 25 16:14:03.026 : netio[314]: ~mpls_netio_switch.c:2795~ Pkt Drop: GigabitEthernet0_0_0_5, No LFIB entry found for in_label 24009
RP/0/0/CPU0:Jan 25 16:14:05.016 : netio[314]: ~mpls_netio_switch.c:2795~ Pkt Drop: GigabitEthernet0_0_0_5, No LFIB entry found for in_label 24009
RP/0/0/CPU0:Jan 25 16:14:07.015 : netio[314]: ~mpls_netio_switch.c:2795~ Pkt Drop: GigabitEthernet0_0_0_5, No LFIB entry found for in_label 24009

Auf diese Weise wird der Label-Modus pro CE für das CSC-Szenario nicht unterstützt.

Fehlerbehebung

Für diese Konfiguration sind derzeit keine spezifischen Informationen zur Fehlerbehebung verfügbar.

Schlussfolgerung

Daher können Sie für einen CSC-Kunden keinen Per-VRF- oder Per-CE VRF-Labelmodus verwenden. Pro-Präfix ist der einzige VRF-Labelmodus, der für einen CSC-Kunden unterstützt wird.

Zugehörige Informationen

• Technischer Support und Dokumentation für Cisco Systeme