Préfixes avec des étiquettes d'agrégat ne tracant pas entièrement le cœur MPLS

J'ai deux routeurs, A (Cat6500 avec SUP720-3BXL, IOS 12.2 (33) SXH4) et B (Nexus 7K avec SUP1, NX-OS 5.2 (4)), séparés par plusieurs sauts à travers un noyau MPLS, chacun avec VRF ABC. Le routeur A a deux routes directement connectées et quatre routes statiques dans ce 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

L'étiquetage par préfixe est utilisé pour ce VRF sur les deux routeurs. Notez que les deux routes directement connectées reçoivent une étiquette agrégée partagée (95) tandis que les quatre routes statiques reçoivent chacune une étiquette unique.

Le routeur B accepte les étiquettes VPN à utiliser:

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)

Du routeur B, je peux traceroute vers les deux réseaux directement connectés sur le routeur A sans problème:

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

Cependant, les traceroutes vers toutes les routes apprises statiquement dépassent le délai sur le chemin MPLS et ne sont récupérées qu'à leurs derniers sauts:

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

Les deux traceroutes ci-dessus devraient suivre exactement le même chemin, et aucun mécanisme de filtrage n'est en place le long de celui-ci. La même chose se produit également dans le sens inverse. Qu'est-ce que je rate? Quelle est la différence entre les routes BGP apprises par connexion directe et la configuration statique en ce qui concerne le transfert MPLS / étiquette?

La différence entre les étiquettes agrégées et les étiquettes normales est telle que les étiquettes normales pointent directement vers les détails de réécriture L2 (une interface et une adresse L2). Cela signifie qu'une étiquette normale sera commutée par le nœud PE de sortie directement, sans faire de recherche IP.

À l'inverse, les étiquettes agrégées peuvent potentiellement représenter de nombreuses options de sortie différentes, de sorte que les informations de réécriture L2 ne sont pas associées à l'étiquette elle-même. Cela signifie qu'un nœud PE de sortie doit effectuer une recherche IP pour le paquet, afin de déterminer les informations de réécriture L2 appropriées.

Les raisons typiques pour lesquelles vous pourriez avoir une étiquette agrégée au lieu d'une étiquette normale sont:

1. Besoin d'effectuer la découverte des voisins (IPv4 ARP, IPv6 ND)
2. Besoin d'effectuer une recherche ACL (sortie ACL dans l'interface client)
3. Exécution de VRF entier sous une seule étiquette (étiquette de table)

Certaines de ces restrictions (en particulier 2) ne sont pas valables pour toutes les plateformes.

Comment traceroute est affecté dans l'environnement MPLS VPN par le transit P, lors de la génération du message TTL dépassé, ne saura pas comment le renvoyer (il n'a pas d'entrée de table de routage à l'expéditeur). Ainsi, un nœud P de transit enverra le message dépassé TTL avec la pile d'étiquettes d'origine jusqu'au nœud PE de sortie, dans l'espoir que la note PE de sortie ait une idée de la façon de renvoyer le message dépassé TTL à l'expéditeur.
Cette fonctionnalité est automatiquement activée dans Cisco IOS mais nécessite un «tunnelage icmp» configuré dans Juniper JunOS.

Sur cette base, je soupçonne que vos appareils CE n'acceptent peut-être pas les paquets lorsque l'adresse source est un réseau de liaison de nœud P et qu'ils n'acceptent pas le message ICMP, ils ne sont pas en mesure de le renvoyer à l'expéditeur.
Un test possible de cette théorie serait d'activer l'étiquette per-vrf:

• IOS: protocole d'étiquette mpls tout-vrfs bgp-vpnv4 per-vrf
• JunOS: définir les instances de routage FOO vrf-table-label

D'une manière générale, je ne recommande pas de propager TTL, en particulier sur l'environnement VPN, du moins dans notre cas, les clients sont confus et anxieux à ce sujet. Ils se demandent pourquoi leur VPN affiche des adresses étrangères.

Une autre chose qui déroute les gens qui les obligent à ouvrir un ticket de support, c'est lorsqu'ils exécutent une traceroute du Royaume-Uni vers les États-Unis, car ils voient une latence> 100 ms entre deux routeurs principaux au Royaume-Uni, sans se rendre compte que tout le chemin a la même latence jusqu'à la côte ouest des États-Unis, car tous les paquets partent de là.

Ce problème est généralement impossible à résoudre de par sa conception, mais dans IOS, vous pouvez déterminer le nombre maximal d'étiquettes à afficher (mpls ip ttl-expiration pop N) lorsque vous générez un TTL dépassé. Cela vous donne une approximation quelque peu décente si l'étiquette INET == 1, VPN ==> 1, vous pouvez donc la configurer de sorte que le trafic VPN soit tunnellisé et que le trafic INET soit directement renvoyé sans détour du nœud PE de sortie. Mais comme je l'ai dit, ce n'est qu'une approximation des fonctionnalités souhaitées, car des fonctionnalités telles que les réparations en transit peuvent empêcher votre pile d'étiquettes d'être toujours de la même taille pour le même service.