Los prefijos con etiquetas agregadas no trazan completamente el trazado en el núcleo MPLS

Tengo dos enrutadores, A (Cat6500 w / SUP720-3BXL, IOS 12.2 (33) SXH4) y B (Nexus 7K w / SUP1, NX-OS 5.2 (4)), separados por varios saltos a través de un núcleo MPLS, cada uno con VRF ABC. El enrutador A tiene dos rutas conectadas directamente y cuatro rutas estáticas dentro de este 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

El etiquetado por prefijo se utiliza para este VRF en ambos enrutadores. Observe que las dos rutas conectadas directamente reciben una etiqueta agregada compartida (95) mientras que las cuatro rutas estáticas reciben cada una una etiqueta única.

El enrutador B acepta las etiquetas de 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)

Desde el enrutador B, puedo rastrear a las dos redes conectadas directamente en el enrutador A sin ningún 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

Sin embargo, las rutas de seguimiento de todas las rutas aprendidas estáticamente caducan a través de la ruta MPLS y vuelven a subir solo en sus ú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

Ambos traceroutes anteriores deben seguir exactamente el mismo camino, y no hay mecanismos de filtrado en su lugar. Lo mismo sucede en la dirección inversa también. ¿Qué me estoy perdiendo? ¿Cuál es la diferencia entre las rutas BGP aprendidas por conexión directa versus la configuración estática con respecto al reenvío de etiquetas / MPLS?

La diferencia entre las etiquetas agregadas y las etiquetas normales es tal que las etiquetas normales apuntan directamente a los detalles de reescritura L2 (una interfaz y una dirección L2). Esto significa que una etiqueta normal será cambiada por el nodo PE de salida directamente, sin hacer una búsqueda de IP.

Adversamente, las etiquetas agregadas pueden representar muchas opciones de salida diferentes, por lo que la información de reescritura de L2 no está asociada con la etiqueta en sí. Esto significa que un nodo PE de salida debe realizar una búsqueda de IP para el paquete, para determinar la información de reescritura de L2 adecuada.

Las razones típicas por las que podría tener una etiqueta agregada en lugar de una etiqueta normal son:

1. Necesidad de realizar descubrimiento vecino (IPv4 ARP, IPv6 ND)
2. Necesita realizar una búsqueda de ACL (salida de ACL en la interfaz del cliente)
3. Ejecutar VRF completo bajo una sola etiqueta (etiqueta de tabla)

Algunas de estas restricciones (particularmente 2) no son válidas para todas las plataformas.

La forma en que el tránsito P afecta al traceroute en el entorno MPLS VPN es que, al generar el mensaje de TTL excedido, no sabrá cómo devolverlo (no tiene una entrada en la tabla de enrutamiento al remitente). Por lo tanto, un nodo P de tránsito enviará el mensaje TTL excedido con la pila de etiquetas original hasta el nodo PE de salida, con la esperanza de que la nota PE de salida tenga una idea de cómo devolver el mensaje excedido TTL al remitente.
Esta característica se activa automáticamente en Cisco IOS pero necesita un 'túnel de icmp' configurado en Juniper JunOS.

Basado en esto, sospecharía que quizás sus dispositivos CE no están aceptando paquetes cuando la dirección de origen es una red de enlace de nodo P, y como no están aceptando el mensaje ICMP, no pueden devolverlo al remitente.
Una posible prueba de esta teoría sería habilitar la etiqueta por vrf:

• IOS: mpls label mode all-vrfs protocol bgp-vpnv4 per-vrf
• JunOS: establecer enrutamiento-instancias FOO vrf-table-label

En términos generales, no recomiendo propagar TTL, especialmente en un entorno VPN, al menos en nuestro caso los clientes se confunden y se preocupan por ello. Les preocupa por qué su VPN tiene direcciones extranjeras que se muestran.

Otra cosa que confunde a las personas al hacer que abran un ticket de soporte es cuando están ejecutando un traceroute desde, por ejemplo, el Reino Unido a los EE. UU., Porque ven una latencia> 100 ms entre dos enrutadores centrales en el Reino Unido, sin darse cuenta de que todo el camino tiene la misma latencia todo el camino hasta la costa oeste de los EE. UU., porque todos los paquetes se desvían de allí.

Este problema es principalmente insoluble por diseño, sin embargo, en IOS puede determinar cuántas etiquetas como máximo aparecer (mpls ip ttl-expiration pop N) cuando genera TTL excedido. Esto le da una aproximación bastante decente si INET == 1 etiqueta, VPN ==> 1 etiqueta, por lo que puede configurarlo para que el tráfico VPN se canalice y el tráfico INET se devuelva directamente sin desvío del nodo PE de salida. Pero como dije, esto es solo una aproximación de la funcionalidad deseada, ya que características como las reparaciones en tránsito pueden hacer que su pila de etiquetas no sea siempre del mismo tamaño para el mismo servicio.