Prefixos com rótulos agregados que não rastreiam totalmente o núcleo MPLS

Eu tenho dois roteadores, A (Cat6500 com SUP720-3BXL, IOS 12.2 (33) SXH4) e B (Nexus 7K com SUP1, NX-OS 5.2 (4)), separados por vários saltos em um núcleo MPLS, cada um com VRF ABC. O roteador A possui duas rotas conectadas diretamente e quatro rotas estáticas dentro deste VRF.

RouterA# show ip bgp vpnv4 vrf ABC labels
   Network          Next Hop      In label/Out label
Route Distinguisher: 65000:123 (ABC)
   10.30.10.0/24    10.30.200.1     154/nolabel
   10.30.20.0/24    10.30.200.1     88/nolabel
   10.30.30.0/24    10.30.200.1     38/nolabel
   10.30.40.0/24    10.30.200.1     147/nolabel
   10.30.200.0/24   0.0.0.0         IPv4 VRF Aggr:95/nolabel(ABC)
   10.90.90.0/24    0.0.0.0         IPv4 VRF Aggr:95/nolabel(ABC)
   10.133.242.0/25  192.168.255.3   nolabel/17
   10.133.242.128/26
                    192.168.255.3   nolabel/18
   10.255.255.224/29
                    192.168.255.3   nolabel/492474

A etiquetagem por prefixo é usada para este VRF nos dois roteadores. Observe que as duas rotas conectadas diretamente recebem um rótulo agregado compartilhado (95), enquanto as quatro rotas estáticas recebem um rótulo exclusivo.

O roteador B concorda com os rótulos da VPN para usar:

RouterB# show bgp vpnv4 unicast labels vrf ABC
BGP routing table information for VRF default, address family VPNv4 Unicast
BGP table version is 17042469, local router ID is 192.168.255.3
Status: s-suppressed, x-deleted, S-stale, d-dampened, h-history, *-valid, >-best
Path type: i-internal, e-external, c-confed, l-local, a-aggregate, r-redist
Origin codes: i - IGP, e - EGP, ? - incomplete, | - multipath

   Network            Next Hop            In label/Out label
Route Distinguisher: 65000:123     (VRF ABC)
*>i10.30.10.0/24      172.26.64.1         nolabel/154
*>i10.30.20.0/24      172.26.64.1         nolabel/88
*>i10.30.30.0/24      172.26.64.1         nolabel/38
*>i10.30.40.0/24      172.26.64.1         nolabel/147
*>i10.30.200.0/24     172.26.64.1         nolabel/95
*>i10.90.90.0/24      172.26.64.1         nolabel/95
*>l10.255.255.224/29  0.0.0.0             492474/nolabel (ABC)

Do roteador B, eu posso rastrear para as duas redes diretamente conectadas no roteador A sem nenhum problema:

RouterB# traceroute 10.30.200.10 vrf ABC
traceroute to 10.30.200.10 (10.30.200.10), 30 hops max, 40 byte packets
 1  192.168.254.97 (192.168.254.97) (AS 65000)  19.226 ms  19.369 ms  19.079 ms
      [Label=63 E=0 TTL=1 S=0, Label=95 E=0 TTL=1 S=1]
 2  192.0.2.151 (192.0.2.151) (AS 65000)  23.309 ms  28.027 ms  18.977 ms
      [Label=39 E=0 TTL=1 S=0, Label=95 E=0 TTL=2 S=1]
 3  192.168.251.62 (192.168.251.62) (AS 65000)  21.576 ms  24.265 ms  21.503 ms
      [Label=59 E=0 TTL=1 S=0, Label=95 E=0 TTL=1 S=1]
 4  10.30.200.10 (10.30.200.10) (AS 65000)  19.155 ms *  19.414 ms

No entanto, os rastreamentos para todas as rotas aprendidas estaticamente atingem o tempo limite no caminho do MPLS e recuperam apenas nos seus últimos saltos:

RouterB# traceroute 10.30.10.10 vrf ABC
traceroute to 10.30.10.10 (10.30.10.10), 30 hops max, 40 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  10.30.200.10 (10.30.200.10) (AS 65000)  19.065 ms  19.281 ms  18.68 ms
      [Label=154 E=0 TTL=1 S=1]
 5  10.30.10.10 (10.30.10.10) (AS 65000)  19.420 ms  19.377 ms  19.73 ms

Os dois rastreadores acima devem seguir exatamente o mesmo caminho e não há mecanismos de filtragem implementados ao longo dele. O mesmo acontece na direção inversa também. o que estou perdendo? Qual é a diferença entre as rotas BGP aprendidas pela conexão direta versus a configuração estática em relação ao encaminhamento de MPLS / etiqueta?

A diferença entre etiquetas agregadas e etiquetas normais é tal que as etiquetas normais apontam diretamente para L2 reescrever detalhes (uma interface e endereço L2). Isso significa que um rótulo normal será comutado pelo nó PE de saída diretamente, sem fazer uma pesquisa de IP.

Por outro lado, os rótulos agregados podem representar potencialmente muitas opções de saída diferentes; portanto, as informações de reescrita L2 não estão associadas ao próprio rótulo. Isso significa que um nó PE de saída deve executar uma pesquisa de IP para o pacote, para determinar as informações apropriadas de reescrita L2.

Os motivos típicos pelos quais você pode ter um rótulo agregado em vez do rótulo normal são:

1. Necessidade de realizar a descoberta de vizinhos (IPv4 ARP, IPv6 ND)
2. Necessidade de realizar pesquisa de ACL (saída de ACL na interface do cliente)
3. Executando VRF inteiro sob rótulo único (rótulo de tabela)

Algumas dessas restrições (principalmente 2) não são válidas para todas as plataformas.

Como o traceroute é afetado no ambiente VPN MPLS é o trânsito P, ao gerar a mensagem excedida TTL, não saberá devolvê-lo (ele não possui entrada da tabela de roteamento para o remetente). Portanto, um nó P de trânsito enviará a mensagem excedida TTL com a pilha de etiquetas original até o nó PE de saída, na esperança de que a nota de saída de PE tenha uma idéia de como retornar a mensagem excedida de TTL ao remetente.
Esse recurso é ativado automaticamente no Cisco IOS, mas precisa do 'icmp-tunneling' configurado no Juniper JunOS.

Com base nisso, eu suspeitaria que talvez seus dispositivos CE não estejam aceitando pacotes quando o endereço de origem for uma rede de link de nó P e, como não estão aceitando a mensagem ICMP, não poderão devolvê-lo ao remetente.
Uma possível maneira de testar essa teoria seria habilitar o rótulo per-vrf:

• IOS: protocolo all-vrfs do modo de etiqueta mpls bgp-vpnv4 por vrf
• JunOS: definir instâncias de roteamento FOO vrf-table-label

De um modo geral, não recomendo propagar TTL, especialmente no ambiente VPN, pelo menos em nosso caso, os clientes ficam confusos e ansiosos com isso. Eles se preocupam com o motivo de sua VPN exibir endereços estrangeiros.

Outra coisa que confunde as pessoas que fazem com que elas abram um tíquete de suporte é quando estão executando um traceroute do Reino Unido para os EUA, porque veem> 100ms de latência entre dois roteadores principais no Reino Unido, sem perceber que todo o caminho tem a mesma latência todo o caminho até a costa oeste dos EUA, porque todos os pacotes fazem um desvio a partir daí.

Esse problema geralmente não pode ser corrigido por design; no entanto, no IOS, é possível determinar quantas etiquetas devem ser exibidas no máximo (mpls ip ttl-expiration pop N) ao gerar TTL excedido. Isso fornece uma aproximação um tanto decente se INET == 1 rótulo, VPN ==> 1 rótulo, para que você possa configurá-lo para que o tráfego da VPN seja encapsulado e o tráfego INET seja retornado diretamente sem desvio do nó PE de saída. Mas, como eu disse, isso é apenas uma aproximação da funcionalidade desejada, pois recursos como reparos em trânsito podem fazer com que sua pilha de etiquetas nem sempre tenha o mesmo tamanho para o mesmo serviço.