Przedrostki z zagregowanymi etykietami nie w pełni śledzą trasy w rdzeniu MPLS

Mam dwa routery A (Cat6500 z SUP720-3BXL, IOS 12.2 (33) SXH4) i B (Nexus 7K z SUP1, NX-OS 5.2 (4)), oddzielone kilkoma przeskokami w rdzeniu MPLS, każdy z VRF ABC. Router A ma dwie bezpośrednio połączone trasy i cztery trasy statyczne w tym 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

Dla tego routera VRF używane jest etykietowanie według prefiksu. Zauważ, że dwie bezpośrednio połączone trasy otrzymują wspólną etykietę zbiorczą (95), podczas gdy każda z czterech tras statycznych otrzymuje unikalną etykietę.

Router B wyraża zgodę na używanie etykiet VPN do używania:

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)

Z routera B bez problemu mogę prześledzić trasę do obu bezpośrednio połączonych sieci na routerze A:

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

Jednak traceroute do wszystkich statycznie wyuczonych tras przekroczą limit czasu na ścieżce MPLS i odbierają tylko przy ostatnich przeskokach:

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

Oba powyższe traceroute powinny podążać dokładnie tą samą ścieżką i wzdłuż niej nie ma żadnych mechanizmów filtrujących. To samo dzieje się również w odwrotnym kierunku. czego mi brakuje? Jaka jest różnica między trasami BGP poznanymi przez bezpośrednie połączenie a konfiguracją statyczną w odniesieniu do przekazywania MPLS / etykiet?

Różnica między etykietami zbiorczymi a normalnymi polega na tym, że normalne etykiety bezpośrednio wskazują szczegóły przepisywania L2 (interfejs i adres L2). Oznacza to, że normalna etykieta zostanie przełączona przez węzeł wyjściowy PE bezpośrednio na zewnątrz, bez wyszukiwania adresu IP.

Przeciwnie, zagregowane etykiety mogą potencjalnie reprezentować wiele różnych opcji wyjścia, więc informacje o przepisywaniu L2 nie są powiązane z samą etykietą. Oznacza to, że wyjściowy węzeł PE musi przeprowadzić wyszukiwanie adresu IP dla pakietu, aby określić odpowiednie informacje o przepisaniu L2.

Typowe powody, dla których możesz mieć etykietę zbiorczą zamiast zwykłej, to:

1. Konieczność wykonania wyszukiwania sąsiadów (IPv4 ARP, IPv6 ND)
2. Konieczność wykonania wyszukiwania listy ACL (wyjście listy ACL w interfejsie klienta)
3. Uruchamianie całego VRF pod jedną etykietą (table-label)

Niektóre z tych ograniczeń (szczególnie 2) nie dotyczą wszystkich platform.

Wpływ na traceroute w środowisku MPLS VPN ma tranzyt P, podczas generowania komunikatu przekroczonego TTL nie będzie wiedział, jak go zwrócić (nie ma wpisu tablicy routingu do nadawcy). Tak więc tranzytowy węzeł P wyśle ​​komunikat przekroczenia TTL z oryginalnym stosem etykiet aż do węzła wyjściowego PE, mając nadzieję, że notatka PE wyjściowego ma pomysł, jak zwrócić komunikat przekroczenia TTL do nadawcy.
Ta funkcja jest automatycznie włączana w Cisco IOS, ale wymaga „tunelowania icmp” skonfigurowanego w Juniper JunOS.

Na tej podstawie podejrzewam, że być może twoje urządzenia CE nie akceptują pakietów, gdy adresem źródłowym jest sieć łącza węzła P, a ponieważ nie akceptują wiadomości ICMP, nie są w stanie zwrócić jej nadawcy.
Możliwym sposobem przetestowania tej teorii byłoby włączenie etykiety per-vrf:

• IOS: tryb etykiety mpls protokół all-vrfs bgp-vpnv4 per-vrf
• JunOS: ustaw instancje routingu FOO vrf-table-label

Ogólnie rzecz biorąc, nie polecam propagowania TTL, szczególnie w środowisku VPN, przynajmniej w naszym przypadku klienci są zdezorientowani i zaniepokojeni. Martwią się, dlaczego ich VPN wyświetla adresy obce.

Kolejną rzeczą, która dezorientuje ludzi, powodując, że otwierają bilet pomocy technicznej, jest to, że korzystają z traceroute z np. Wielkiej Brytanii do USA, ponieważ widzą opóźnienie> 100 ms między dwoma głównymi routerami w Wielkiej Brytanii, nie zdając sobie sprawy, że cała ścieżka ma takie samo opóźnienie aż do zachodniego wybrzeża USA, ponieważ wszystkie pakiety stamtąd się objeżdżają.

Ten problem jest w większości nierozwiązywalny z założenia, jednak w IOS można określić, ile etykiet może najwyżej pop (mpls ip ttl-expiration pop N), gdy generowane jest przekroczenie TTL. Daje to nieco przyzwoite przybliżenie, jeśli etykieta INET == 1, etykieta VPN ==> 1, dzięki czemu można ją skonfigurować tak, aby ruch VPN był tunelowany, a ruch INET był zwracany bezpośrednio bez wychodzenia z węzła PE. Ale jak powiedziałem, jest to tylko przybliżenie pożądanej funkcjonalności, ponieważ funkcje takie jak naprawy w transporcie mogą spowodować, że stos etykiet nie będzie zawsze tego samego rozmiaru dla tej samej usługi.