Multiprotocol Label Switching (MPLS) : MPLS

Troubleshooting de Falha de LSP em MPLS VPN

15 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Este documento pressupõe que você já tem algum conhecimento sobre os conceitos básicos de MPLS (Multiprotocol Label Switching). Pacotes comutados por MPLS são encaminhados com base nas informações contidas na LFIB (Base de informações de encaminhamento de rótulo). Um pacote que sae de um roteador sobre uma interface comutada por rótulo receberá etiquetas com os valores especificados pelo LFIB. As etiquetas são associadas com os destinos no LFIB de acordo com as classes de equivalência da transmissão (FEC). Um FEC é um agrupamento dos pacotes IP que viajam sobre o mesmo trajeto e recebem o mesmo tratamento da transmissão. O exemplo mais simples de um FEC apresenta todos os pacotes sendo transmitidos para uma determinada sub-rede. Um outro exemplo podia ser todos os pacotes com uma Precedência IP dada que vai a um salto seguinte do Interior Gateway Protocol (IGP) associado com um grupo de rotas (BGP) de protocolo de gateway de borda.

A LIB (Base de informações de rótulo) é uma estrutura que armazena os rótulos recebidos de todos os vizinhos do LDP (Protocolo de distribuição de rótulos) ou do TDP (Protocolo de distribuição de etiquetas). Para a implementação Cisco, as etiquetas são enviadas para todas as rotas na tabela de roteamento de um roteador dado (à excecpção das rotas de BGP), a todo o LDP ou vizinhos de TDP. Todos os rótulos recebidos de vizinhos são mantidos no LIB, independente de serem usados. Caso os rótulos sejam recebidos de um downstream vizinho para suas FECs, os rótulo armazenados na LIB serão utilizados para encaminhamento de pacotes pela LFIB. Isso significa que os rótulos usados para encaminhamento são aqueles recebidos do próximo salto de um roteador a um destino, de acordo com o Cisco Express Forwarding (CEF) do roteador e com as tabelas de roteamento.

Se associações de rótulos são recebidas de um vizinho de downstream para prefixos (incluindo a máscara de sub-rede) que não aparecem no encaminhamento e nas tabelas CEF de um roteador, essas associações não serão utilizadas. De forma semelhante, se um roteador anuncia etiquetas para um par da sub-rede/máscara de sub-rede, que não correspondam às atualizações de roteamento igualmente anunciem por este roteador para os pares da mesma sub-rede/máscara de sub-rede, estas etiquetas não serão usadas por vizinhos rio acima e o caminho comutado por rótulo (LSP) entre estes dispositivos falhará.

Este documento dá um exemplo desse tipo de falha de LSP e fornece várias soluções possíveis. O documento abrange um cenário em que as conexões por ponte de rótulo recebidas por um roteador não são usadas para encaminhar os pacotes comutados por MLPS. Entretanto, os passos seguidos para diagnosticar e corrigir esse problema são aplicáveis a todo os problemas que envolvam associações de rótulo e LFIB em roteadores configurados para o MPLS.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

As informações aqui são baseadas nesta versão de software:

  • Software Release Version 12.0(21)ST2 do ½ do ¿  de Cisco IOSïÂ

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Diagrama de Rede

troubleshoot_mpls_vpn-1.gif

Configurações do Roteador

Configuração do Roteador 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

Configuração de roteador P
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.

Configuração do roteador 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

Configuração do roteador 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: A configuração de CE1 foi omitida. A configuração consiste somente no endereçamento de IP na interface Ethernet e em uma rota padrão estática a 10.2.2.2.

Problema

A conectividade entre CE1 e a interface de loopback do CE2 foi perdida, conforme mostra o exemplo a seguir.

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)

Contudo, o CE1 tem uma entrada de roteamento válida para este destino, segundo as indicações do exemplo seguinte.

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

Em PE1 (o roteador de PE anexado ao CE1), você pode verificar a informação do específico do MPLS VPN. Os exemplos seguintes mostram que uma rota válida ao destino esta presente na tabela VRF para este 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

Como mostrado neste exemplo, o PE1 não possui uma rota para o próximo salto de BGP com a máscara correta.

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

As informações de IGP Routing utilizadas pelo PE1 para alcançar este próximo salto de BGP são recebidas do roteador P. Conforme mostrado no exemplo a seguir, esse roteador também mostra uma máscara incorreta para o circuito de retorno PE2 e não tem uma rota para esse prefixo com a máscara correta.

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 da falha de LSP

O LFIB e as ligações de caracteres especiais no roteador P mostram a causa da falha do LSP entre este roteador e o PE2. Não a rótulo de saída para o 10.5.5.5. Ao sair do PE1, o pacote leva dois rótulos, o rótulo BGP de próximo salto gerado pelo roteador P (16) e o rótulo VPN gerado pelo PE2 (32). Porque esta entrada no roteador P mostra o sem etiqueta, pacotes etiqueta-comutados para este destino, será mandada sem nenhumas etiquetas. Como o rótulo 32 do VPN foi perdido, ele nunca será recebido por PE2, e PE2 não terá as informações corretas para encaminhar o pacote para o destino de VPN apropriado.

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

Segundo as indicações do exemplo seguinte, a tabela de ligação de rótulo do roteador P mostra esse PE2 (tsr: 10.8.8.5:0) anunciam somente um emperramento para 10.5.5.5 com uma máscara de /24. Uma etiqueta para a rota de /32 é anunciada pelo roteador P e pelo PE1 (tsr: 10.2.2.2:0), mas não PE2. Porque o emperramento anunciado pelo PE2 não combina a rota que igualmente anuncia, nenhuma etiqueta esta presente no LFIB do roteador P para enviar pacotes a este destino.

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

O motivo para a discrepância entre as atualizações de roteamento e os Label Bindings anunciadas por PE2 pode ser visto na tabela de roteamento e na tabela de Tag Binding deste roteador. O laço de retorno diretamente conectado mostra a máscara correta de /24, isto é usado pelo roteador em gerar as ligações de rótulo. Porque este Open Shortest Path First (OSPF) dos usos da rede, o roteador anuncia esta relação com uma máscara de /32, segundo as indicações do exemplo seguinte.

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

Soluções

Como a falha do LSP entre o roteador P e o PE1 foi causada por uma incompatibilidade entre a rota anunciada para o loopback e o vínculo de rótulo gerado pelo PE1, a solução mais simples é alterar a máscara do loopback para que ela fique de acordo com a máscara anunciada pelo OSPF para todas as redes do tipo LOOPBACK.

Solução 1: Mudança da máscara de sub-rede no 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#

A informação no PE1 aparece o mesmos que na encenação onde a falha LSP ocorre, segundo as indicações do exemplo seguinte.

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

O roteador P mostra que as condições que causaram a falha do LSP não estão mais presentes. O rótulo de saída [e uma tag pop. Isto significa que a etiqueta superior para o salto seguinte BGP estará estalada como os pacotes atravessa o roteador, mas os pacotes ainda terão a segunda etiqueta VPN (os pacotes são já não sem etiqueta mandado).

A tabela de ligação da etiqueta mostra que uma etiqueta (IMP-nula) está anunciada por PE2 (tsr: 10.8.8.5:0) para a rota de /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

Solução 2: Alteração de tipo de rede OSPF

A segunda solução é mudar o tipo de rede OSPF da interface de loopback. Quando o tipo de rede OSPF da interface de loopback do PE2 é mudado a ponto a ponto, o prefixo do laço de retorno está anunciado já não automaticamente com uma máscara de /32. Isso significa que a ligação de rótulo gerada pelo PE2 ao fazer referência à sub-rede de conexão direta em sua tabela de roteamento (que contém uma máscara de sub-rede /24), corresponderá à rota de OSPF no roteador P recebido do PE2 (que contém uma máscara de sub-rede /24 para esse prefixo).

O comando ip ospf network point-to-point pode ser utilizado para alterar o tipo de rede na interface de loopback PE2, conforme mostrado no exemplo a seguir:

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

Como mostrado abaixo, a tabela do forwarding da etiqueta no PE1 contém uma entrada para o salto seguinte BGP, que é consistente com a máscara real da interface de loopback no PE2. A tabela de roteamento mostra que a rota de OSPF associada a esta entrada de encaminhamento também está correta.

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

No exemplo abaixo, a entrada de encaminhamento da etiqueta do roteador P mostra a etiqueta que parte como uma etiqueta do PNF, como na solução 1, segundo as indicações do exemplo abaixo. Mais uma vez, a etiqueta superior para o salto seguinte BGP será estalada como o pacote atravessa este roteador, mas a segunda etiqueta VPN será retida e o LSP não falhará. O emperramento que mostra a máscara de sub-rede correta está igualmente atual.

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

Conforme mostrado a seguir, a saída deste comando confirma se o tipo de rede foi alterado para ponto-a-ponto. A conectividade direta esta presente do CE1 à interface de loopback do 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.

Informações Relacionadas


Document ID: 23565