Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konventionen

Netzwerkdiagramm

Router-Konfigurationen

Problem

Ursache des LSP-Fehlers

Lösungen

Zugehörige Informationen

Einführung

In diesem Dokument wird davon ausgegangen, dass Sie bereits über grundlegende MPLS-Konzepte (Multiprotocol Label Switching) verfügen. MPLS-Switched-Pakete werden basierend auf Informationen weitergeleitet, die in der Label Forwarding Information Base (LFIB) enthalten sind. Ein Paket, das einen Router über eine Label-Switched-Schnittstelle verlässt, empfängt Labels mit vom LFIB angegebenen Werten. Labels sind mit Zielen im LFIB gemäß Forwarding Equivalence Classes (FECs) verknüpft. Ein FEC ist eine Gruppierung von IP-Paketen, die über denselben Pfad übertragen werden und dieselbe Weiterleitungsbehandlung erhalten. Das einfachste Beispiel eines FEC sind alle Pakete, die zu einem bestimmten Subnetz gesendet werden. Ein weiteres Beispiel könnten alle Pakete mit einer bestimmten IP-Priorität sein, die an einen Next Hop des Interior Gateway Protocol (IGP) weitergeleitet werden, der einer Gruppe von Border Gateway Protocol (BGP)-Routen zugeordnet ist.

Die Label Information Base (LIB) ist eine Struktur, in der Labels gespeichert werden, die von allen LDP- (Label Distribution Protocol) oder TDP-Nachbarn (Tag Distribution Protocol) empfangen wurden. Für die Cisco Implementierung werden Labels für alle Routen in der Routing-Tabelle eines Routers (mit Ausnahme von BGP-Routen) an alle LDP- oder TDP-Nachbarn gesendet. Alle Labels, die von Nachbarn empfangen werden, bleiben in der LIB erhalten, unabhängig davon, ob sie verwendet werden oder nicht. Wenn die Labels von einem Downstream-Nachbarn für ihren FEC empfangen werden, werden die in der LIB gespeicherten Labels für die Paketweiterleitung durch den LFIB verwendet. Das bedeutet, dass die für die Weiterleitung verwendeten Labels die vom nächsten Hop des Routers an ein Ziel empfangen werden, entsprechend der Cisco Express Forwarding (CEF)- und Routing-Tabellen des Routers.

Wenn Label-Bindungen von einem Downstream-Nachbarn für Präfixe (einschließlich Subnetzmaske) empfangen werden, die nicht in der Routing- und CEF-Tabelle eines Routers enthalten sind, werden diese Bindungen nicht verwendet. Wenn ein Router Etiketten für ein Subnetz-/Subnetzmaske-Paar ankündigt, die nicht den Routing-Updates entsprechen, die dieser Router für dasselbe Subnetz-/Subnetzmaske-Paar ebenfalls ankündigt, werden diese Labels nicht von Upstream-Nachbarn verwendet, und der Label Switched Path (LSP) zwischen diesen Geräten schlägt fehl.

Dieses Dokument enthält ein Beispiel für diesen LSP-Ausfall und einige mögliche Lösungen. Das Dokument behandelt ein Szenario, in dem Label-Bindungen, die von einem Router empfangen werden, nicht für die Weiterleitung von MPLS-Switched-Paketen verwendet werden. Die zur Diagnose und Behebung dieses Problems verwendeten Schritte gelten jedoch für alle Probleme im Zusammenhang mit Label-Bindungen und dem LFIB auf Routern, die für MPLS konfiguriert sind.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf dieser Softwareversion:

- Cisco IOS® Softwareversion 12.0(21)ST2

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).

Netzwerkdiagramm

Router-Konfigurationen

PE1 Router-Konfiguration

ip vrf aqua

rd 100:1

route-target export 1:1

route-target import 1:1

!

interface Loopback0

ip address 10.2.2.2 255.255.255.255

no ip directed-broadcast

!

interface Ethernet2/0/1

ip vrf forwarding aqua

ip address 10.1.1.2 255.255.255.0

no ip directed-broadcast

ip route-cache distributed

!--- The VPN Routing and Forwarding (VRF) interface !--- toward the customer edge (CE) router.

interface Ethernet2/0/2

ip address 10.7.7.2 255.255.255.0

no ip directed-broadcast

ip route-cache distributed

tag-switching ip

!

router ospf 1

log-adjacency-changes

network 0.0.0.0 255.255.255.255 area 0

!

router bgp 1

bgp log-neighbor-changes

neighbor 10.5.5.5 remote-as 1

neighbor 10.5.5.5 update-source Loopback0

no auto-summary

!

address-family vpnv4

neighbor 10.5.5.5 activate

neighbor 10.5.5.5 send-community extended

exit-address-family

!

address-family ipv4

neighbor 10.5.5.5 activate

no auto-summary

no synchronization

exit-address-family

!

address-family ipv4 vrf aqua

redistribute connected

no auto-summary

no synchronization

exit-address-family

P Router-Konfiguration

interface Loopback0

ip address 10.7.7.7 255.255.255.255

no ip directed-broadcast

!

interface Ethernet2/0

ip address 10.8.8.7 255.255.255.0

no ip directed-broadcast

tag-switching ip

!

interface Ethernet2/1

ip address 10.7.7.7 255.255.255.0

no ip directed-broadcast

tag-switching ip

!

router ospf 1

log-adjacency-changes

network 0.0.0.0 255.255.255.255 area 0

!--- BGP is not run on this router.

PE2 Router-Konfiguration

ip vrf aqua

rd 100:1

route-target export 1:1

route-target import 1:1

!

interface Loopback0

ip address 10.5.5.5 255.255.255.0

no ip directed-broadcast

!

interface Ethernet0/0

ip vrf forwarding aqua

ip address 10.10.10.5 255.255.255.0

no ip directed-broadcast

!--- The VRF interface toward the CE router.

!

interface Ethernet0/3

ip address 10.8.8.5 255.255.255.0

no ip directed-broadcast

tag-switching ip

!

router ospf 1

log-adjacency-changes

network 0.0.0.0 255.255.255.255 area 0

!

router rip

version 2

!

address-family ipv4 vrf aqua

version 2

network 10.0.0.0

no auto-summary

exit-address-family

!

router bgp 1

bgp log-neighbor-changes

neighbor 10.2.2.2 remote-as 1

neighbor 10.2.2.2 update-source Loopback0

no auto-summary

!

address-family vpnv4

neighbor 10.2.2.2 activate

neighbor 10.2.2.2 send-community extended

exit-address-family

!

address-family ipv4

neighbor 10.2.2.2 activate

no auto-summary

no synchronization

exit-address-family

!

address-family ipv4 vrf aqua

redistribute connected

redistribute rip

no auto-summary

no synchronization

exit-address-family

Konfiguration des CE2-Routers

interface Loopback0

ip address 192.168.1.196 255.255.255.192

no ip directed-broadcast

!

interface Ethernet1

ip address 10.10.10.6 255.255.255.0

no ip directed-broadcast

!

router rip

version 2

network 10.0.0.0

network 192.168.1.0

no auto-summary

!--- Routing Information Protocol (RIP) is used for the advertisement !--- of routes between the CE and the provider edge (PE) router.

!

ip route 0.0.0.0 0.0.0.0 10.10.10.5

Hinweis: Die CE1-Konfiguration wurde weggelassen. Die Konfiguration besteht nur aus der IP-Adressierung an der Ethernet-Schnittstelle und einer statischen Standardroute zu 10.2.2.2.

Problem

Die Verbindung zwischen CE1 und der Loopback-Schnittstelle von CE2 wurde unterbrochen, wie im folgenden Beispiel gezeigt.

CE1#ping 192.168.1.196

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.196, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

CE1 verfügt jedoch über einen gültigen Routing-Eintrag für dieses Ziel, wie im folgenden Beispiel gezeigt.

CE1#show ip route 0.0.0.0

Routing entry for 0.0.0.0/0, supernet

Known via "static", distance 1, metric 0, candidate default path

Redistributing via ospf 100

Routing Descriptor Blocks:

* 10.1.1.2

Route metric is 0, traffic share count is 1

In PE1 (dem mit CE1 verbundenen PE-Router) können Sie MPLS-VPN-spezifische Informationen überprüfen. Die folgenden Beispiele zeigen, dass eine gültige Route zum Ziel in der VRF-Tabelle für dieses VPN vorhanden ist.

PE1#show ip route vrf aqua 192.168.1.196

Routing entry for 192.168.1.192/26

Known via "bgp 1", distance 200, metric 1, type internal

Last update from 10.5.5.5 00:09:52 ago

Routing Descriptor Blocks:

* 10.5.5.5 (Default-IP-Routing-Table), from 10.5.5.5, 00:09:52 ago

Route metric is 1, traffic share count is 1

AS Hops 0, BGP network version 0

PE1#show tag-switching forwarding-table vrf aqua 192.168.1.196 detail

Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop

tag    tag or VC   or Tunnel Id      switched   interface

None   16          192.168.1.192/26  0          Et2/0/2    10.7.7.7

MAC/Encaps=14/22, MTU=1496, Tag Stack{16 32}

00603E2B02410060835887428847 0001000000020000

No output feature configured

PE1#show ip bgp vpnv4 vrf aqua 192.168.1.192

BGP routing table entry for 100:1:192.168.1.192/26, version 43

Paths: (1 available, best #1, table aqua)

Not advertised to any peer

Local

10.5.5.5 (metric 21) from 10.5.5.5 (10.5.5.5)

Origin incomplete, metric 1, localpref 100, valid, internal, best

Extended Community: RT:1:1

PE1#show tag-switching forwarding-table 10.5.5.5 detail

Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop

tag    tag or VC   or Tunnel Id      switched   interface

18     16          10.5.5.5/32       0          Et2/0/2    10.7.7.7

MAC/Encaps=14/18, MTU=1500, Tag Stack{16}

00603E2B02410060835887428847 00010000

No output feature configured

Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Wie in diesem Beispiel gezeigt, verfügt PE1 nicht über eine Route für den BGP Next Hop mit der richtigen Maske.

PE1#

PE1#show ip route 10.5.5.5 255.255.255.0

% Subnet not in table

PE1#show ip route 10.5.5.5 255.255.255.255

Routing entry for 10.5.5.5/32

Known via "ospf 1", distance 110, metric 21, type intra area

Last update from 10.7.7.7 on Ethernet2/0/2, 00:38:55 ago

Routing Descriptor Blocks:

* 10.7.7.7, from 10.5.5.5, 00:38:55 ago, via Ethernet2/0/2

Route metric is 21, traffic share count is 1

Die IGP-Routing-Informationen, die PE1 zum Erreichen dieses BGP Next Hop verwendet, werden vom P-Router empfangen. Wie im folgenden Beispiel gezeigt, zeigt dieser Router auch eine falsche Maske für den PE2-Loopback an und verfügt über keine Route für dieses Präfix mit der richtigen Maske.

P#show ip route 10.5.5.5

Routing entry for 10.5.5.5/32

Known via "ospf 1", distance 110, metric 11, type intra area

Last update from 10.8.8.5 on Ethernet2/0, 00:47:48 ago

Routing Descriptor Blocks:

* 10.8.8.5, from 10.5.5.5, 00:47:48 ago, via Ethernet2/0

Route metric is 11, traffic share count is 1

P#show ip route 10.5.5.5 255.255.255.0

% Subnet not in table

Ursache des LSP-Fehlers

Die LFIB- und Tag-Bindungen am P-Router zeigen die Ursache für den LSP-Ausfall zwischen diesem Router und PE2 an. Für 10.5.5.5 gibt es kein ausgehendes Label. Wenn das Paket PE1 verlässt, enthält es zwei Labels, das vom P-Router (16) generierte BGP Next Hop Label und das vom PE2 generierte VPN-Label (32). Da dieser Eintrag auf dem P-Router nicht gekennzeichnete, Label-vermittelte Pakete für dieses Ziel anzeigt, wird er ohne Label versendet. Da das VPN-Label 32 verloren ging, wird es nie von PE2 empfangen, und PE2 verfügt nicht über die richtigen Informationen für die Weiterleitung des Pakets an das entsprechende VPN-Ziel.

P#show tag-switching forwarding-table 10.5.5.5 detail

Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop

tag    tag or VC   or Tunnel Id      switched   interface

16     Untagged    10.5.5.5/32       5339       Et2/0      10.8.8.5

MAC/Encaps=0/0, MTU=1504, Tag Stack{}

No output feature configured

Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Wie im folgenden Beispiel gezeigt, zeigt die Label-Bindungstabelle des P-Routers, dass PE2 (tsr: 10.8.8.5:0) kündigt nur eine Bindung für 10.5.5.5 mit einer /24-Maske an. Ein Label für die /32-Route wird vom P-Router und PE1 angekündigt (tsr: 10.2.2.2:0), jedoch nicht PE2. Da die vom PE2 angegebene Bindung nicht mit der von ihm ebenfalls angegebenen Route übereinstimmt, ist im LFIB des P-Routers kein Label vorhanden, das Pakete an dieses Ziel weiterleitet.

P#show tag-switching tdp bindings detail

tib entry: 10.5.5.0/24, rev 67(no route)

remote binding: tsr: 10.8.8.5:0, tag: imp-null

tib entry: 10.5.5.5/32, rev 62

local binding:  tag: 16

Advertised to:

10.2.2.2:0             10.8.8.5:0

remote binding: tsr: 10.2.2.2:0, tag: 18

Der Grund für die Diskrepanz zwischen den Routing-Updates und den vom PE2 angekündigten Label-Bindungen ist in der Routing-Tabelle und der Tag-Bindungstabelle dieses Routers zu finden. Das direkt verbundene Loopback zeigt die richtige /24-Maske an, die vom Router beim Generieren der Label-Bindung verwendet wird. Da dieses Netzwerk Open Shortest Path First (OSPF) verwendet, kündigt der Router diese Schnittstelle mit einer /32-Maske an, wie im folgenden Beispiel gezeigt.

PE2#show ip route 10.5.5.5

Routing entry for 10.5.5.0/24

Known via "connected", distance 0, metric 0 (connected, via interface)

Routing Descriptor Blocks:

* directly connected, via Loopback0

Route metric is 0, traffic share count is 1

PE2#show tag-switching tdp bindings detail

tib entry: 10.5.5.0/24, rev 142

local binding:  tag: imp-null

Advertised to:

10.7.7.7:0

tib entry: 10.5.5.5/32, rev 148

remote binding: tsr: 10.7.7.7:0, tag: 16

PE2#show ip ospf interface loopback 0

Loopback0 is up, line protocol is up

Internet Address 10.5.5.5/24, Area 0

Process ID 1, Router ID 10.5.5.5, Network Type LOOPBACK, Cost: 1

Loopback interface is treated as a stub Host

!--- OSPF advertises all interfaces of Network Type LOOPBACK as host !--- routes (/32).

Lösungen

Da der Ausfall des LSP zwischen dem P-Router und PE1 auf eine Diskrepanz zwischen der für den Loopback angekündigten Route und der von PE1 generierten Label-Bindung zurückzuführen ist, besteht die einfachste Lösung darin, die Maske des Loopbacks so zu ändern, dass sie der von OSPF für alle Netzwerke des LOOPBACK-Typs angegebenen Maske entspricht.

Lösung 1: Änderung der Subnetzmaske auf PE2

PE2#configure terminal

Enter configuration commands, one per line.  End with CNTL/Z.

PE2(config)#int lo 0

PE2(config-if)#ip add 10.5.5.5 255.255.255.255

PE2(config-if)#end

PE2#

Die Informationen auf PE1 sind mit den Informationen im Szenario identisch, in dem ein LSP-Ausfall auftritt, wie im folgenden Beispiel gezeigt.

PE1#show tag-switching forwarding-table vrf aqua 192.168.1.196 detail

Local  Outgoing    Prefix                 Bytes tag  Outgoing   Next Hop

tag    tag or VC   or Tunnel Id           switched   interface

None   16               192.168.1.192/26  0          Et2/0/2    10.7.7.7

MAC/Encaps=14/22, MTU=1496, Tag      Stack{16 32}

00603E2B02410060835887428847 0001000000020000

No output feature configured

PE1#show tag-switching forwarding-table 10.5.5.5 detail

Local  Outgoing    Prefix                 Bytes tag  Outgoing   Next Hop

tag    tag or VC   or Tunnel Id           switched   interface

18     16               10.5.5.5/32       0          Et2/0/2    10.7.7.7

MAC/Encaps=14/18, MTU=1500, Tag      Stack{16}

00603E2B02410060835887428847 00010000

No output feature configured

Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10      11 12 13 14 15

Der P-Router zeigt an, dass die Bedingungen, die den LSP-Ausfall verursacht haben, nicht mehr gegeben sind. Die ausgehende Bezeichnung ist jetzt ein Pop-Tag. Das bedeutet, dass das oberste Label für den nächsten BGP-Hop bei der Übertragung der Pakete durch den Router blockiert wird, die Pakete jedoch weiterhin das zweite VPN-Label besitzen (die Pakete werden nicht mehr unmarkiert versendet).

Die Tag-Bindungstabelle zeigt ein Label (imp-null), das vom PE2 (tsr: 10.8.8.5:0) für die /32-Route.

P#show tag-switching forwarding-table 10.5.5.5 detail

Local  Outgoing    Prefix               Bytes tag  Outgoing   Next Hop

tag    tag or VC   or Tunnel Id         switched   interface

16     Pop tag     10.5.5.5/32          3493       Et2/0         10.8.8.5

MAC/Encaps=14/14, MTU=1504, Tag Stack{}

006009E08B0300603E2B02408847

No output feature configured

Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11    12 13 14 15

P#show tag-switching tdp bindings detail

tib entry: 10.5.5.5/32, rev 71

local binding:  tag: 16

Advertised to:

10.2.2.2:0                  10.8.8.5:0

remote binding: tsr: 10.2.2.2:0,      tag: 18

remote binding: tsr: 10.8.8.5:0,      tag: imp-null

Lösung 2: OSPF-Netzwerktypänderung

Die zweite Lösung besteht darin, den OSPF-Netzwerktyp der Loopback-Schnittstelle zu ändern. Wenn der OSPF-Netzwerktyp der Loopback-Schnittstelle von PE2 auf Point-to-Point geändert wird, wird das Loopback-Präfix nicht mehr automatisch mit einer /32-Maske angekündigt. Dies bedeutet, dass die vom PE2 generierte Label-Bindung bei Verweisen auf das direkt verbundene Subnetz in seiner Routing-Tabelle (die eine /24-Subnetzmaske enthält) mit der OSPF-Route des P-Routers übereinstimmt, der vom PE2 empfangen wurde (die eine /24-Subnetzmaske für dieses Präfix enthält).

Der Befehl ip ospf network point-to-point kann verwendet werden, um den Netzwerktyp an der PE2-Loopback-Schnittstelle zu ändern, wie im folgenden Beispiel gezeigt.

PE2#configure terminal

Enter configuration commands, one per line.  End with CNTL/Z.

PE2(config)#interface loopback 0

PE2(config-if)#ip ospf network point-to-point

PE2(config-if)#

Wie unten gezeigt, enthält die Tag-Weiterleitungstabelle auf PE1 einen Eintrag für den nächsten BGP-Hop, der mit der tatsächlichen Maske der Loopback-Schnittstelle auf PE2 übereinstimmt. Die Routing-Tabelle zeigt an, dass die diesem Weiterleitungseintrag zugeordnete OSPF-Route ebenfalls korrekt ist.

PE1#show tag-switching forwarding-table 10.5.5.5 detail

Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop

tag    tag or VC   or Tunnel Id      switched   interface

22     17          10.5.5.0/24       0          Et2/0/2    10.7.7.7

MAC/Encaps=14/18, MTU=1500, Tag Stack{17}

00603E2B02410060835887428847 00011000

No output feature configured

Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

PE1#show ip route 10.5.5.5

Routing entry for 10.5.5.0/24

Known via "ospf 1", distance 110, metric 21, type intra area

Last update from 10.7.7.7 on Ethernet2/0/2, 00:36:53 ago

Routing Descriptor Blocks:

* 10.7.7.7, from 10.5.5.5, 00:36:53 ago, via Ethernet2/0/2

Route metric is 21, traffic share count is 1

Im Beispiel unten zeigt der Tag Forwarding-Eintrag des P-Routers das ausgehende Tag als Pop-Tag an, wie in Lösung 1 gezeigt, wie im Beispiel unten. Auch hier wird das oberste Label für den nächsten BGP-Hop entfernt, wenn das Paket diesen Router durchläuft. Das zweite VPN-Label wird jedoch beibehalten, und der LSP wird nicht ausfallen. Die Bindung mit der richtigen Subnetzmaske ist ebenfalls vorhanden.

P#show tag-switching forwarding-table 10.5.5.5 detail

Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop

tag    tag or VC   or Tunnel Id      switched   interface

17     Pop tag     10.5.5.0/24       4261       Et2/0      10.8.8.5

MAC/Encaps=14/14, MTU=1504, Tag Stack{}

006009E08B0300603E2B02408847

No output feature configured

Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

P#show tag-switching tdp bindings detail

tib entry: 10.5.5.0/24, rev 68

local binding:  tag: 17

Advertised to:

10.2.2.2:0             10.8.8.5:0

remote binding: tsr: 10.8.8.5:0, tag: imp-null

remote binding: tsr: 10.2.2.2:0, tag: 22

Wie unten gezeigt, bestätigt die Ausgabe dieses Befehls, dass der Netzwerktyp in Punkt-zu-Punkt geändert wurde. Von CE1 bis zur Loopback-Schnittstelle von CE2 besteht vollständige Konnektivität.

PE2#show ip ospf interface loopback 0

Loopback0 is up, line protocol is up

Internet Address 10.5.5.5/24, Area 0

Process ID 1, Router ID 10.5.5.5, Network Type POINT_TO_POINT, Cost: 1

Transmit Delay is 1 sec, State POINT_TO_POINT,

Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

Index 3/3, flood queue length 0

Next 0x0(0)/0x0(0)

Last flood scan length is 0, maximum is 0

Last flood scan time is 0 msec, maximum is 0 msec

Neighbor Count is 0, Adjacent neighbor count is 0

Suppress hello for 0 neighbor(s)

CE1#ping 192.168.1.196

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.196, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

CE1.

Zugehörige Informationen

- Unterstützung der IP-Routing-Technologie

- Fehlerbehebung für MPLS-VPN

- Unterstützung von MPLS-Technologie

- Technischer Support und Dokumentation - Cisco Systems