Laboratorium MPLS L3VPN nie pinguje? Sprawdź tych pięć punktów

Dwa routery klienta, para skrzynek brzegowych dostawcy i ping, który umiera bez komunikatu o błędzie. W małym laboratorium MPLS L3VPN usterka prawie zawsze siedzi w jednym z pięciu punktów kontrolnych, a każdy z nich ma polecenie, które pokazuje, czy zależność działa, czy jej brakuje. Błędem jest restartować BGP za każdym razem, gdy ping zawodzi, zamiast testować zależności po kolei. Wskoczenie prosto do konfiguracji VRF potrafi kosztować godzinę przy problemie, który zaczął się od nierozwiązanego next hopu dwa urządzenia dalej.

Listę przechodź od dołu do góry. Punkt kontrolny, który przejdzie, pozostaje zaliczony, a pierwsza awaria to ta, którą warto debugować.

Pierwszy punkt kontrolny: PE sięgają się nawzajem

Każdy PE potrzebuje trasy do loopbacku drugiego PE, a ta trasa musi się rozwiązać przez coś rzeczywistego. Protokół bramy wewnętrznej to zwykły sposób, ale trasa statyczna też działa, o ile rekurencyjne wyszukanie trafia na żywe sąsiedztwo. Na urządzeniach w stylu IOS show ip route 10.0.0.2, a po nim show ip cef 10.0.0.2, powie ci, czy prefiks istnieje i czy ma rozwiązaną sąsiedztwo. Trasa w tabeli bez sąsiedztwa za sobą nie jest osiągalnością.

Sprawdź oba kierunki. Asymetryczne koszty IGP, pasywny interfejs po złej stronie albo lista dystrybucyjna filtrująca loopback każdy z nich psuje tylko jeden kierunek, a jeden kierunek wystarczy, by zabić sesję. Jeśli loopbacki odpowiadają na ping, ale sesja BGP tkwi w Active, zanim cokolwiek dotkniesz, sprawdź źródło aktualizacji.

Drugi punkt kontrolny: istnieje ścieżka etykiet

Trasa IP do zdalnego loopbacku nie dowodzi, że transport wciśnie etykietę. W projekcie z LDP sprawdź, czy zdalny loopback ma powiązanie lokalne i zdalne oraz czy etykieta wychodząca pojawia się w tabeli przekazywania. show mpls ldp bindings 10.0.0.2 32 pokazuje pary etykiet, a show mpls forwarding-table 10.0.0.2 pokazuje, co karta liniowa faktycznie wstawi. Gdy drugie polecenie pokazuje „no label“ albo przekazuje do IP, transport nie niesie ruchu VPN tak, jak zakłada projekt.

Różnica wynika z tego, jak MPLS oddziela stan przekazywania od prefiksów docelowych, i to jest model opisany w RFC 3031. Jeśli twoje laboratorium używa RSVP-TE albo etykiet sąsiadujących z BGP zamiast LDP, sprawdź stan tego mechanizmu; założenie, że LDP rozdziela każdą etykietę underlay, to częsty sposób gonienia widmowego błędu. Zepsuta ścieżka etykiet zwykle pokazuje się później jako trasa VPN, która istnieje, ale jest bezużyteczna.

Trzeci punkt kontrolny: trasa VPN dotarła nietknięta

Patrz na trasę VPNv4 albo VPNv6 dla dokładnego prefiksu klienta, a nie na podsumowanie sesji. show bgp vpnv4 unicast all 10.10.1.0/24 powinno pokazać wyróżnik trasy, next hop ustawiony na zdalny loopback PE oraz etykietę. Jeśli prefiksu brakuje, pierwszym podejrzanym jest polityka eksportu na PE źródłowym albo polityka importu na PE odbierającym, a route target bywa zwykłym winowajcą.

Kontrolę route target czytaj osobno od odbioru w BGP. Trasa może dotrzeć z właściwym next hopem i nadal nie trafić do VRF, bo import target się nie zgadza. Na PE odbierającym show ip route vrf CUSTOMER 10.10.1.0 jest testem, który ma znaczenie; tabela BGP dowodzi tylko, że trasa przeszła przez płaszczyznę sterowania.

Czwarty punkt kontrolny: interfejs jest w VRF

Definicja VRF z wyróżnikiem trasy i route targetami nie przenosi do niej żadnego interfejsu. Interfejs zwrócony do CE potrzebuje przypisania VRF, a show ip vrf interfaces albo show ip interface brief powinno wymienić go pod właściwą instancją. To punkt kontrolny, w którym skopiowana konfiguracja najczęściej się psuje, bo blok VRF wygląda na kompletny, podczas gdy interfejs wciąż siedzi w tabeli globalnej.

Potem potwierdź, że PE nauczył się lokalnego prefiksu klienta do tej VRF i że CE ma trasę powrotną przez przyłącze. Statyczna trasa domyślna na CE wskazująca na PE wystarczy do laboratorium, o ile VRF na PE ma trasę do sieci LAN klienta. Jeśli brakuje którejkolwiek połowy, ping zawodzi, zanim zostanie wciśnięta jakakolwiek etykieta.

Piąty punkt kontrolny: odpowiedź znajduje drogę do domu

Prześledź pakiet w przód, a potem prześledź pakiet powrotny, bo używają różnych tabel. Na PE wejściowym źródło klienta powinno się rozwiązać wewnątrz VRF do zdalnego prefiksu ze zdalną etykietą. Na PE wyjściowym cel powinien się rozwiązać w tej samej VRF do interfejsu zwróconego do CE. Ping wysłany z samego PE nie jest dowodem: może wyjść przez tabelę globalną albo inny adres źródłowy, dlatego ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 jest testem do wykonania.

Zapory hosta, filtrowanie odwrotnej ścieżki i listy dostępu na CE nadal obowiązują. Jeśli ścieżka w przód działa, a odpowiedź ginie, problem jest w trasie albo filtrze po stronie powrotu, nie w transporcie MPLS.

Prowadź jednolinijkowy zapis dla każdego punktu kontrolnego, nazywając pierwszą zależność, która zawiodła. Ten zapis zamienia „klient nie może pingować“ w konkretne pytanie o osiągalność, stan etykiet, import tras, przynależność interfejsu albo ścieżkę powrotną i nie pozwala następnej sesji debugowania powtarzać tych samych pięciu poleceń w tej samej kolejności.