Tunel RSVP-TE działa, ale L3VPN klienta nie ma ścieżki
Transport i usługa to osobne decyzje. Przeczytaj stos etykiet, sprawdź osobno rozwiązywanie następnego skoku i podłączenie VRF, a następnie przetestuj jeden rzeczywisty przepływ klienta.
Dwa zespoły mogą mieć jednocześnie rację, gdy klient zgłasza, że VPN nie działa, a zespół transportu zgłasza, że tunel jest w porządku. LSP z inżynierią ruchu i MPLS L3VPN odpowiadają na różne pytania: jeden przenosi oznaczone pakiety przez rdzeń, drugi decyduje, do jakiego kontekstu routingu należy pakiet. Kiedy się je pomiesza, spór kręci się w kółko, ponieważ każda strona mierzy inny obiekt i oba pomiary są prawidłowe.
Transport działa, a usługa nie — to normalny stan
LSP może być ustanowiony, przenosić ruch i być widoczny w każdym systemie monitorowania, podczas gdy usługa klienta pozostaje bezużyteczna. Nic w tej kombinacji nie jest sprzeczne, ponieważ tunel nie ma zdania na temat tego, czy istnieje zdalny prefiks, czy polityka importu go zaakceptowała albo czy dołączony obwód przepuszcza ramki.
Objaw, który zwykle ujawnia zamieszanie, jest asymetryczny: pingi z loopbacku PE przechodzą, a host w sieci LAN klienta nie otrzymuje nic, lub odwrotnie. Zapisz, które adresy działały, zanim stworzysz teorię. Gdy zauważysz, że testujesz dwa różne obiekty, następnym krokiem jest przeczytanie stosu etykiet, a nie spieranie się, czyj graf jest poprawny. Dwa adresy, dwóch właścicieli i zwykle dwie różne osoby, z których każda wierzy, że druga coś zepsuła.
Czytaj stos jako dwie odpowiedzialności
Dolna etykieta należy do usługi, a górna etykieta należy do ścieżki. RFC 4364 opisuje sekwencję prosto: najpierw nakładana jest etykieta trasy VPN, potem ten oznaczony pakiet jest tunelowany w kierunku następnego skoku BGP, gdzie tunel inżynierii ruchu dokłada swoją własną etykietę na wierzch.
| Object | Decision it encodes | Who owns it |
|---|---|---|
| Attachment and VRF | Which customer context receives the arriving packet | Edge configuration |
| VPN route and service label | Which remote forwarding context handles the destination | BGP VPN signalling |
| Transport LSP and tunnel label | How the core carries the packet to the BGP next hop | RSVP-TE or another tunnel mechanism |
Na zdalnym PE etykieta usługi wybiera traktowanie, które może być wyszukaniem w VRF lub decyzją o podłączeniu. Tej etykiety nie można zastąpić etykietą, która jedynie przecina rdzeń, i obie nie są wymienne, nawet gdy obie pojawiają się w tym samym stosie na tym samym interfejsie.
Co dowodzi sukces RSVP, a czego nie
RSVP-TE ustanawia jawnie trasowane LSP, z rezerwacjami zasobów lub bez nich, co jest konkretną i użyteczną gwarancją dotyczącą ścieżki, jaką pakiet pokonuje przez rdzeń. To nie jest stwierdzenie o trasach klienta, a skonfigurowana nazwa tunelu wcale nie jest trasą.
Obecność RSVP również nie daje obietnicy wydajności end-to-end. Rezerwacja przepustowości na jednym LSP nie mówi nic o dołączonym obwodzie, własnej linii dostępowej klienta ani zachowaniu kolejek na zdalnej krawędzi. Traktowanie tego jako gwarancji daje pewne siebie odpowiedzi na pytania, których nikt nie zadał. Jeśli wymaganie naprawdę jest zobowiązaniem dotyczącym przepustowości, musi zostać złożone z elementów, które faktycznie je egzekwują, a LSP jest tylko środkiem tego łańcucha.
Sprawdzaj po kolei, potem się zatrzymaj
Pracuj od transportu na zewnątrz i zatrzymaj się na pierwszym kroku, który zawiedzie, ponieważ każdy późniejszy krok zakłada, że wcześniejsze się utrzymały. Najpierw potwierdź, że LSP jest ustanowiony i że wpis przekazywania dla prefiksu usługi faktycznie na niego wskazuje. Następnie potwierdź, że trasa VPN istnieje we właściwej tabeli, że jej powiązanie z etykietą jest obecne i że polityka importu ją zaakceptowała. Potem potwierdź podłączenie: interfejs, enkapsulację i, jeśli ma to zastosowanie, identyfikator VLAN należący do tej umowy.
show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMERSkładnia poleceń różni się w zależności od platformy, więc traktuj te cztery wiersze jako cztery pytania, a nie jako skrypt. Najważniejsze jest to, że każde z nich odpytywa inny obiekt, i właśnie dlatego awaria wskazuje konkretnego właściciela.
Prześledź jedno dozwolone żądanie i zachowaj dobre dowody
Zakończ jednym rzeczywistym żądaniem klienta, dozwolonym przez politykę, i jego odpowiedzią. Jeden działający przepływ end-to-end rozstrzyga więcej niż strona odczytów liczników i ćwiczy kombinację, a nie każdy element osobno.
Gdy późniejszy etap zawiedzie, zachowaj udaną obserwację LSP zamiast odbudowywać transport. Odbudowa działającego tunelu nie może naprawić brakującego zdalnego prefiksu, błędnego podłączenia VRF ani reguły dostępu do miejsca docelowego, i niszczy dowód, który początkowo mówił, że transport jest zdrowy.