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ódło
Odpowiedzi:
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:
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:
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.
źródło