Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Convenzioni

Esempio di rete

Configurazioni router

Problema

Causa dell'errore LSP

Soluzioni

Informazioni correlate

Introduzione

in questo documento si presume che l'utente abbia già acquisito una conoscenza dei concetti base di Multiprotocol Label Switching (MPLS). I pacchetti a commutazione MPLS vengono inoltrati in base alle informazioni contenute nella base LFIB (Label Forwarding Information Base). Un pacchetto che lascia un router su un'interfaccia a commutazione di etichetta riceverà etichette con i valori specificati dall'LFIB. Le etichette sono associate alle destinazioni nell'LFIB in base alle FEC (Forwarding Equivalence Classes). La funzione FEC è un raggruppamento di pacchetti IP che viaggiano attraverso lo stesso percorso e ricevono lo stesso trattamento di inoltro. L'esempio più semplice di FEC sono tutti i pacchetti che viaggiano verso una determinata subnet. Un altro esempio potrebbe essere quello di tutti i pacchetti con una data precedenza IP diretti all'hop successivo IGP (Interior Gateway Protocol) associato a un gruppo di route BGP (Border Gateway Protocol).

Label Information Base (LIB) è una struttura in cui vengono memorizzate le etichette ricevute da tutti i router adiacenti Label Distribution Protocol (LDP) o Tag Distribution Protocol (TDP). Per l'implementazione Cisco, le etichette vengono inviate per tutte le route nella tabella di routing di un determinato router (ad eccezione delle route BGP), a tutti i router adiacenti LDP o TDP. Tutte le etichette ricevute dai vicini vengono conservate nel LIB, indipendentemente dal fatto che vengano utilizzate o meno. Se le etichette vengono ricevute da un router adiacente a valle per la relativa FEC, le etichette memorizzate nella LIB vengono utilizzate per l'inoltro dei pacchetti da parte dell'LFIB. Significa che le etichette utilizzate per l'inoltro sono quelle ricevute dall'hop successivo di un router a una destinazione, in base al Cisco Express Forwarding (CEF) e alle tabelle di routing del router.

Se le associazioni di etichette vengono ricevute da un router adiacente a valle per i prefissi (inclusa la subnet mask) che non vengono visualizzati nel routing di un router e nelle tabelle CEF, tali associazioni non verranno utilizzate. Analogamente, se un router pubblicizza le etichette per una coppia subnet/subnet mask che non corrispondono agli aggiornamenti del routing annunciati anche da questo router per la stessa coppia subnet/subnet mask, queste etichette non verranno utilizzate dai router adiacenti upstream e l'LSP (Label Switched Path) tra questi dispositivi avrà esito negativo.

In questo documento viene illustrato un esempio di questo tipo di errore dei provider di servizi di traduzione e vengono illustrate diverse possibili soluzioni. Il documento descrive uno scenario in cui i binding di etichette ricevuti da un router non vengono utilizzati per inoltrare pacchetti con commutazione MPLS. Tuttavia, la procedura utilizzata per diagnosticare e correggere questo problema è applicabile a qualsiasi problema relativo alle associazioni di etichette e all'LFIB sui router configurati per MPLS.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Le informazioni di questo documento si basano sulla seguente versione del software:

- Software Cisco IOS® versione 12.0(21)ST2

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Esempio di rete

Configurazioni router

Configurazione router PE1

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 Configurazione router

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.

Configurazione router PE2

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

Configurazione router CE2

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

Nota: la configurazione CE1 è stata omessa. La configurazione è costituita esclusivamente da indirizzi IP sull'interfaccia Ethernet e da un percorso statico predefinito pari a 10.2.2.2.

Problema

La connettività tra CE1 e l'interfaccia di loopback di CE2 è andata persa, come illustrato nell'esempio seguente.

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)

Tuttavia, CE1 ha una voce di routing valida per questa destinazione, come mostrato nell'esempio seguente.

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 (il router PE collegato a CE1), è possibile controllare le informazioni specifiche della VPN MPLS. Gli esempi seguenti mostrano la presenza di una route valida alla destinazione nella tabella VRF per questa VPN.

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

Come mostrato nell'esempio, PE1 non dispone di una route per l'hop successivo BGP con la maschera corretta.

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

Le informazioni di routing IGP utilizzate da PE1 per raggiungere l'hop BGP successivo vengono ricevute dal router IP. Come mostrato nell'esempio seguente, questo router mostra anche una maschera non corretta per il loopback PE2 e non dispone di una route per questo prefisso con la maschera corretta.

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

Causa dell'errore LSP

I binding LFIB e tag sul router IP mostrano la causa del problema dell'LSP tra il router e PE2. Non esiste etichetta in uscita per 10.5.5.5. Quando il pacchetto esce da PE1 ha due etichette, l'etichetta dell'hop successivo BGP generata dal router IP (16) e l'etichetta VPN generata da PE2 (32). Poiché questa voce sul router IP mostra pacchetti senza etichetta a commutazione di etichetta per questa destinazione, verrà inviata senza etichette. Poiché l'etichetta VPN 32 è stata persa, non verrà mai ricevuta da PE2 e PE2 non disporrà delle informazioni corrette per inoltrare il pacchetto alla destinazione VPN corretta.

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

Come illustrato nell'esempio seguente, la tabella di associazione delle etichette del router IP mostra che PE2 (tsr: 10.8.8.5:0) annuncia solo un binding per 10.5.5.5 con una maschera /24. Un'etichetta per la route /32 viene annunciata dal router IP e da PE1 (tsr: 10.2.2.2:0), ma non PE2. Poiché il binding annunciato da PE2 non corrisponde al percorso annunciato, non è presente alcuna etichetta nell'LFIB del router IP per l'inoltro dei pacchetti a questa destinazione.

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

La causa della discrepanza tra gli aggiornamenti di routing e le associazioni di etichette annunciate da PE2 è indicata nella tabella di routing e nella tabella di associazione di tag di questo router. Il loopback connesso direttamente visualizza la maschera /24 corretta, utilizzata dal router per generare il binding dell'etichetta. Poiché la rete utilizza OSPF (Open Shortest Path First), il router annuncia l'interfaccia con una maschera /32, come mostrato nell'esempio che segue.

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).

Soluzioni

Poiché il guasto dell'LSP tra il router IP e PE1 è stato causato da una mancata corrispondenza tra la route annunciata per il loopback e l'associazione di etichette generata da PE1, la soluzione più semplice consiste nel modificare la maschera del loopback in modo che sia conforme alla maschera annunciata da OSPF per tutte le reti del tipo LOOPBACK.

Soluzione 1: Modifica della subnet mask in 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#

Le informazioni in PE1 sono identiche a quelle dello scenario in cui si verifica un errore LSP, come illustrato nell'esempio seguente.

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

Il router IP mostra che le condizioni che hanno causato il guasto dell'LSP non sono più presenti. L'etichetta in uscita è ora un tag pop. Ciò significa che l'etichetta superiore per l'hop successivo BGP viene visualizzata mentre i pacchetti attraversano il router, ma i pacchetti avranno ancora la seconda etichetta VPN (i pacchetti non vengono più inviati senza tag).

Nella tabella di associazione tag è indicata un'etichetta (imp-null) annunciata da PE2 (tsr: 10.8.8.5:0) per la route /32.

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

Soluzione 2: Modifica tipo di rete OSPF

La seconda soluzione consiste nel modificare il tipo di rete OSPF dell'interfaccia di loopback. Quando il tipo di rete OSPF dell'interfaccia di loopback di PE2 viene modificato in point-to-point, il prefisso di loopback non viene più automaticamente annunciato con una maschera /32. Ciò significa che il binding di etichetta generato da PE2, quando fa riferimento alla subnet connessa direttamente nella relativa tabella di routing (contenente una subnet mask /24), corrisponderà alla route OSPF sul router IP ricevuto da PE2 (contenente una subnet mask /24 per questo prefisso).

Il comando ip ospf network point-to-point può essere utilizzato per modificare il tipo di rete nell'interfaccia di loopback PE2, come illustrato nell'esempio seguente.

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)#

Come mostrato di seguito, la tabella di inoltro tag in PE1 contiene una voce per l'hop successivo BGP, che è coerente con la maschera effettiva dell'interfaccia di loopback in PE2. La tabella di routing mostra anche che la route OSPF associata a questa voce di inoltro è corretta.

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

Nell'esempio seguente, la voce di inoltro dei tag del router IP mostra il tag in uscita come tag pop, come nella soluzione 1, come mostrato nell'esempio che segue. Ancora una volta, l'etichetta superiore per l'hop successivo BGP viene bucata quando il pacchetto attraversa il router, ma la seconda etichetta VPN viene mantenuta e l'LSP non ha esito negativo. È inoltre presente l'associazione che mostra la subnet mask corretta.

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

Come mostrato di seguito, l'output di questo comando conferma che il tipo di rete è stato modificato in point-to-point. La connettività completa è presente da CE1 all'interfaccia di loopback di CE2.

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.

Informazioni correlate

- Supporto della tecnologia di routing IP

- Come risolvere i problemi della VPN MPLS

- Supporto della tecnologia MPLS

- Documentazione e supporto tecnico – Cisco Systems