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

9

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?

mpls troubleshooting Jeremy Stretch
quelle
Ist das Thema falsch? Sieht aus wie Aggregatetiketten Traceroute in Ordnung, normale Etiketten nicht? Welche Plattform ist das? Gibt es etwas, das in Bezug auf das Ausblenden von TTL oder andere spezifische Befehle konfiguriert ist? In VPN wird die Traceroute immer zum Ausgangs-PE geleitet, bevor eine TTL-Überschreitung generiert wird. Aus irgendeinem Grund generieren Sie für nicht aggregierte Labels keine TTL-Überschreitung.
Ytti
Die Frage wurde aktualisiert, um Plattformen (IOS und NX-OS) widerzuspiegeln.
Jeremy Stretch
HW wäre auch dankbar, sup720-3bxl hat HW-Einschränkungen, wenn es um die TTL-Dekrementierung in einer MPLS-Umgebung geht. Tritt das Problem in beide Richtungen oder nur in eine Richtung auf?
Ytti
Das gleiche passiert mit statisch gelernten Routen auch in umgekehrter Richtung. Auf Router A wird ein SUP720-3BXL ausgeführt. könnten die von Ihnen erwähnten Einschränkungen näher erläutern?
Jeremy Stretch
Leider erklärt das Problem sup720-3blx (oder PFC3B, um genau zu sein, PFC3C ist behoben) dies nicht. Seitdem würden Sie Egress PE in Traceroute nur noch komplett verpassen (keine Sterne). Und es hätte nicht das gleiche Problem in beide Richtungen. Das ist für mich sehr merkwürdig, wie das Problem von nexus7k auf 7600 und 7600 auf nexus7k auftritt.
Ytti

Antworten:

9

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.

ytti
quelle