Präfixe mit Aggregatbezeichnungen, die nicht vollständig über den MPLS-Kern verfolgt werden

Ich habe zwei Router, A (Cat6500 mit SUP720-3BXL, IOS 12.2 (33) SXH4) und B (Nexus 7K mit SUP1, NX-OS 5.2 (4)), die durch mehrere Hops über einen MPLS-Kern getrennt sind VRF ABC. Router A verfügt über zwei direkt verbundene Routen und vier statische Routen innerhalb dieser 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

Für diese VRF wird auf beiden Routern eine Präfixkennzeichnung verwendet. Beachten Sie, dass die beiden direkt verbundenen Routen eine gemeinsame Gesamtbezeichnung erhalten (95), während die vier statischen Routen jeweils eine eindeutige Bezeichnung erhalten.

Router B stimmt den zu verwendenden VPN-Labels zu:

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)

Von Router B aus kann ich problemlos zu beiden direkt verbundenen Netzwerken auf Router A zurückverfolgen:

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

Traceroutes zu allen statisch erlernten Routen laufen jedoch über den MPLS-Pfad ab und werden erst bei ihren letzten Sprüngen wieder aufgenommen:

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

Beide Traceroutes oben sollten genau dem gleichen Pfad folgen, und es sind keine Filtermechanismen vorhanden. Das gleiche passiert auch in umgekehrter Richtung. Was vermisse ich? Was ist der Unterschied zwischen BGP-Routen, die durch direkte Verbindung gelernt wurden, und statischer Konfiguration in Bezug auf MPLS / Label-Weiterleitung?

Der Unterschied zwischen aggregierten Beschriftungen und normalen Beschriftungen besteht darin, dass normale Beschriftungen direkt auf L2-Umschreibedetails verweisen (eine Schnittstelle und eine L2-Adresse). Dies bedeutet, dass ein normales Etikett vom Ausgangs-PE-Knoten direkt ausgeschaltet wird, ohne dass eine IP-Suche durchgeführt wird.

Umgekehrt können aggregierte Beschriftungen möglicherweise viele verschiedene Ausgangsoptionen darstellen, sodass L2-Umschreibinformationen nicht mit der Beschriftung selbst verknüpft sind. Dies bedeutet, dass ein Ausgangs-PE-Knoten eine IP-Suche für das Paket durchführen muss, um die entsprechenden L2-Umschreibinformationen zu ermitteln.

Typische Gründe, warum Sie möglicherweise ein aggregiertes Etikett anstelle eines normalen Etiketts haben, sind:

1. Nachbarerkennung muss durchgeführt werden (IPv4 ARP, IPv6 ND)
2. ACL-Suche muss durchgeführt werden (Ausgangs-ACL in der Kundenschnittstelle)
3. Ausführen der gesamten VRF unter einem einzigen Label (Tabellen-Label)

Einige dieser Einschränkungen (insbesondere 2) gelten nicht für alle Plattformen.

Wie Traceroute in der MPLS-VPN-Umgebung beeinflusst wird, hängt vom Transit P ab. Wenn die Nachricht generiert wird, dass die TTL überschritten wurde, weiß sie nicht, wie sie zurückgegeben werden soll (es gibt keinen Routing-Tabelleneintrag an den Absender). Ein Transit-P-Knoten sendet also die Nachricht mit der TTL-Überschreitung mit dem ursprünglichen Etikettenstapel bis zum Ausgangs-PE-Knoten, in der Hoffnung, dass die Ausgangs-PE-Notiz eine Idee hat, wie die TTL-Überschreitungsnachricht an den Absender zurückgegeben werden kann.
Diese Funktion ist in Cisco IOS automatisch aktiviert, erfordert jedoch das in Juniper JunOS konfigurierte "icmp-tunneling".

Aufgrund dessen würde ich vermuten, dass Ihre CE-Geräte möglicherweise keine Pakete akzeptieren, wenn die Quelladresse ein P-Node-Link-Netzwerk ist, und da sie die ICMP-Nachricht nicht akzeptieren, können sie sie nicht an den Absender zurückgeben.
Ein möglicher Test für diese Theorie wäre die Aktivierung des Per-VRF-Labels:

• IOS: MPLS-Label-Modus All-VRFS-Protokoll bgp-vpnv4 per-vrf
• JunOS: Routing-Instanzen FOO vrf-table-label setzen

Generell empfehle ich nicht, TTL zu verbreiten, insbesondere in VPN-Umgebungen, zumindest in unserem Fall sind Kunden verwirrt und besorgt darüber. Sie machen sich Sorgen, warum in ihrem VPN fremde Adressen angezeigt werden.

Eine andere Sache, die Leute verwirrt, die sie veranlassen, ein Support-Ticket zu öffnen, ist, wenn sie eine Traceroute von beispielsweise Großbritannien in die USA durchführen, weil sie eine Latenz von> 100 ms zwischen zwei Core-Routern in Großbritannien sehen, ohne zu bemerken, dass der gesamte Pfad dieselbe Latenz hat den ganzen Weg bis zur Westküste der USA, weil alle Pakete von dort einen Umweg machen.

Dieses Problem kann vom Design her größtenteils nicht behoben werden. In IOS können Sie jedoch festlegen, wie viele Labels höchstens angezeigt werden sollen (mpls ip ttl-expiration pop N), wenn Sie TTL generieren. Dies gibt Ihnen eine recht anständige Annäherung an INET == 1-Label, VPN ==> 1-Label, sodass Sie es so konfigurieren können, dass der VPN-Verkehr getunnelt wird und der INET-Verkehr ohne Umweg des PE-Knotens direkt zurückgegeben wird. Wie ich bereits sagte, ist dies nur eine Annäherung an die gewünschte Funktionalität, da Funktionen wie Reparaturen während des Transports dazu führen können, dass Ihr Etikettenstapel für denselben Service nicht immer dieselbe Größe hat.