Prefissi con etichette aggregate che non eseguono il tracciamento completo del core MPLS

Ho due router, A (Cat6500 con SUP720-3BXL, IOS 12.2 (33) SXH4) e B (Nexus 7K con SUP1, NX-OS 5.2 (4)), separati da più salti su un core MPLS, ciascuno con VRF ABC. Il router A ha due route collegate direttamente e quattro route statiche all'interno di questo 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'etichettatura per prefisso viene utilizzata per questo VRF su entrambi i router. Si noti che le due route collegate direttamente ricevono un'etichetta aggregata condivisa (95) mentre le quattro route statiche ricevono ciascuna un'etichetta univoca.

Il router B accetta le etichette VPN per utilizzare:

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)

Dal router B, posso eseguire il traceroute su entrambe le reti direttamente connesse sul router A senza alcun 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

Tuttavia, i traceroute su tutti i timeout delle rotte apprese staticamente attraverso il percorso MPLS e riprendono solo agli ultimi salti:

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

Entrambi i traceroute sopra dovrebbero seguire lo stesso identico percorso e non vi sono meccanismi di filtraggio in atto lungo di esso. La stessa cosa accade anche nella direzione opposta. Cosa mi sto perdendo? Qual è la differenza tra le route BGP apprese dalla connessione diretta rispetto alla configurazione statica rispetto all'inoltro MPLS / etichetta?

La differenza tra etichette aggregate ed etichette normali è tale che le etichette normali puntano direttamente ai dettagli di riscrittura di L2 (un'interfaccia e un indirizzo L2). Ciò significa che un'etichetta normale verrà commutata direttamente dal nodo PE di uscita, senza effettuare una ricerca IP.

Le etichette aggregate possono potenzialmente rappresentare molte diverse opzioni di uscita, quindi le informazioni di riscrittura L2 non sono associate all'etichetta stessa. Ciò significa che un nodo PE di uscita deve eseguire una ricerca IP per il pacchetto, per determinare le informazioni di riscrittura L2 appropriate.

I motivi tipici per cui potresti avere un'etichetta aggregata anziché un'etichetta normale sono:

1. È necessario eseguire il rilevamento dei vicini (IPv4 ARP, IPv6 ND)
2. È necessario eseguire la ricerca ACL (uscita ACL in uscita nell'interfaccia del cliente)
3. Esecuzione di VRF intero con etichetta singola (etichetta tabella)

Alcune di queste restrizioni (in particolare 2) non sono valide per tutte le piattaforme.

In che modo traceroute è influenzato dall'ambiente VPN MPLS dal transito P, quando si genera il messaggio TTL superato, non saprà come restituirlo (non ha una voce di tabella di routing al mittente). Quindi un nodo P di transito invierà il messaggio TTL superato con lo stack di etichette originale fino al nodo PE di uscita, nella speranza che la nota PE di uscita abbia un'idea di come restituire il messaggio TTL superato al mittente.
Questa funzione è attiva automaticamente in Cisco IOS ma necessita di "icmp-tunneling" configurato in Juniper JunOS.

Sulla base di ciò, sospetterei che forse i tuoi dispositivi CE non accettano pacchetti quando l'indirizzo di origine è una rete di collegamento del nodo P e poiché non accettano il messaggio ICMP, non sono in grado di restituirlo al mittente.
Un modo possibile per testare questa teoria sarebbe abilitare l'etichetta per-vrf:

• IOS: modalità etichetta mpls protocollo all-vrfs bgp-vpnv4 per-vrf
• JunOS: imposta le istanze di routing FOO vrf-table-label

In generale, non raccomando di propagare il TTL, specialmente in ambiente VPN, almeno nel nostro caso i clienti si confondono e si preoccupano. Si preoccupano perché la loro VPN ha indirizzi stranieri che mostrano.

Un'altra cosa che confonde le persone inducendole ad aprire un ticket di supporto è quando eseguono un traceroute da dire il Regno Unito agli Stati Uniti, perché vedono una latenza> 100ms tra due router principali nel Regno Unito, senza rendersi conto che l'intero percorso ha la stessa latenza fino alla costa occidentale degli Stati Uniti, perché tutti i pacchetti prendono una deviazione da lì.

Questo problema è per lo più non risolvibile in base alla progettazione, tuttavia in IOS è possibile determinare il numero massimo di etichette da visualizzare (mpls ip ttl-expiration pop N) quando si genera TTL superato. Questo ti dà un'approssimazione piuttosto decente se INET == 1 etichetta, VPN ==> 1 etichetta, quindi puoi configurarlo in modo che il traffico VPN sia sintonizzato e il traffico INET venga restituito direttamente senza deviazione del nodo PE in uscita. Ma come ho già detto, questa è solo un'approssimazione della funzionalità desiderata, poiché funzionalità come le riparazioni in transito possono far sì che la pila di etichette non abbia sempre le stesse dimensioni per lo stesso servizio.