Brakująca trasa w VRF: lokalna, VPNv4 czy tablica przekazywania?

Klient mówi, że prefiks zniknął po zmianie celu trasy, a pierwszy zrzut ekranu, który przysyła, to zwykle niewłaściwa tablica. Trzy różne tablice odpowiadają na trzy różne pytania: czy prefiks istnieje wewnątrz VRF, czy został ogłoszony i zaimportowany jako trasa VPNv4 oraz czy wpis przekazywania został faktycznie zainstalowany. Czytanie ich poza kolejnością daje pewne i błędne wnioski. Ten runbook prowadzi jeden prefiks lokalny i jeden zdalny przez wszystkie trzy tablice po kolei i kończy się planem wycofania zmiany RT, która to zaczęła.

Nazwij prefiks i tablicę, do której należy

Zapisz dwa prefiksy, zanim cokolwiek wpiszesz. Jeden jest lokalny w lokalizacji klienta, nauczony z podłączonego interfejsu lub ogłoszenia CE. Drugi jest zdalny i ma przyjść przez sieć szkieletową dostawcy. Wchodzą do tej samej VRF różnymi drogami, a awaria w jednym nic nie mówi o drugim.

Utrzymuj wyraźne rozróżnienie obu identyfikatorów, bo stąd bierze się większość zamieszania w tych zgłoszeniach. Rozróżniacz trasy jest częścią NLRI VPNv4 i istnieje po to, by skądinąd identyczne prefiksy klientów były unikalne w sieci szkieletowej. Cel trasy to rozszerzona społeczność przenoszona jako atrybut, i to z nim dopasowuje się polityka importu i eksportu. To nie jest druga nazwa rozróżniacza i nie jest przenoszone w pakietach klienta.

Krok 1: udowodnij, że prefiks jest w VRF

Zacznij od widoku lokalnego, potem od RT, które rządzą importem. Jeśli lokalnego prefiksu tu nie ma, nic powyżej nie może być winne:

show ip route vrf CUST-A 172.21.4.0 255.255.255.0
show ip route vrf CUST-A | include 172.21.4.0
show ip vrf CUST-A

Prefiks widoczny jako podłączony lub statyczny jest nauczony lokalnie, a jego obecność nic nie mówi o tym, czy został wyeksportowany. To najczęstsze błędne odczytanie w tym procesie: zdrowa tablica VRF jest dowodem tylko na uczenie lokalne. Strona eksportu to osobne pytanie, na które odpowiadają widok sąsiada i dołączony cel eksportu.

Sprawdź listy RT na VRF, póki tu jesteś. Jeśli zamierzony cel importu nie jest na liście, wszystko poniżej jest nieistotne. Jeśli jest, ale różni się od tego, co eksportuje zdalny PE, znalazłeś awarię bez otwierania jednego przechwycenia pakietów.

Krok 2: przeczytaj tablicę VPNv4 i jej cele

Tablica VPNv4 pokazuje, co płaszczyzna sterowania rzeczywiście wymieniła. Szukaj zdalnego prefiksu pod właściwym rozróżniaczem, a potem spójrz na społeczności do niego dołączone:

show ip bgp vpnv4 all 10.60.9.0/24
show ip bgp vpnv4 all | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A neighbors 192.0.2.17 advertised-routes

Wpis z właściwym celem trasy, ale bez instalacji lokalnej, wskazuje na politykę importu lub na wybór trasy, a nie na osiągalność. Wpis, który w ogóle nie pojawia się w tablicy VPNv4, wskazuje w górę: źródłowy PE może go nie wyeksportował albo sesja nie przenosi rodziny adresów.

Jest trzeci przypadek, który myli ludzi podczas zmian. Niektóre platformy ograniczają, których tras VPN żądają lub które utrzymują, korzystając z informacji o członkostwie w celach trasy, więc brak zdalnego NLRI w jednym filtrowanym widoku nie jest dowodem, że ogłoszenia nie ma nigdzie. Sprawdź tablicę bez filtra i ogłoszone trasy sąsiada, zanim uznasz, że trasa została wycofana globalnie.

Krok 3: potwierdź, że coś zostało zainstalowane i oznaczone

Wpis BGP to decyzja, nie ścieżka. Tablice przekazywania mówią, czy pakiety mają gdzie iść:

show ip cef vrf CUST-A 10.60.9.0/24
show mpls forwarding-table vrf CUST-A | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A

Wpis CEF z rozwiązanym sąsiedztwem i etykietą wychodzącą oznacza, że ruch płaszczyzny danych powinien działać, a każdy pozostały objaw należy do aplikacji lub do filtrowania wewnątrz VRF. Wpis CEF pokazujący nierozwiązany następny skok oznacza, że ścieżka etykiety jest niekompletna, mimo że BGP wygląda zdrowo, i właśnie w tym przypadku zrzut tablicy BGP wprowadził w błąd przegląd zmiany.

Porównaj etykietę, którą narzuca lokalny PE, z tą, którą zdalny PE oczekuje otrzymać. Rozbieżność między oboma widokami to problem przydziału etykiet albo sesji, i nie naprawi jej edycja celów trasy, ile razy byś jej nie powtarzał.

Wycofaj zmianę RT z zadeklarowanym zakresem

Jeśli awaria zaczęła się od edycji celu trasy, cofnij ją jako jeden świadomy krok i powiedz, jaki zakres zmieniasz. Usunięcie celu importu wycofuje uprawnienie wewnątrz tej VRF. Nie usuwa ogłoszenia VPNv4 z sieci szkieletowej, a na niektórych platformach trasa pozostaje utrzymana w tablicy. To różne wyniki i efekt widoczny dla użytkownika zależy od tego, który z nich masz na myśli.

configure terminal
vrf definition CUST-A
 address-family ipv4
  no route-target import 65000:410
 end
clear ip bgp vpnv4 vrf CUST-A soft in

Miękka rekonfiguracja wejściowa wystarcza, gdy sesja już przechowuje prefiksy; twardy reset sesji skierowanej do dostawcy w godzinach pracy to decyzja, którą powinien podjąć ktoś inny. W Junos odpowiednie kontrole czytają tablicę na VRF i tablicę VPN bezpośrednio, a wycofanie jest powrotem przy commit, a nie cofnięciem na polecenie, więc zapisz różnicę konfiguracji przed rozpoczęciem.

Zakończ tymi samymi trzema poleceniami, od których zacząłeś, w tej samej kolejności, i zapisz ich wynik ze znacznikiem czasu. Zgłoszenie, które mówi, że RT był zły i teraz jest dobry, nie nadaje się do ponownego użycia; to, które pokazuje prefiks w VRF, w VPNv4 i zainstalowany w CEF, jest dowodem, z którym następna osoba może porównać. Jeśli zmieniły się tylko dwa pierwsze, nie skończyłeś zmiany.