Czy VPNv4 potrzebuje MPLS w rdzeniu? Niekoniecznie

Włączenie rodziny adresów VPNv4 między dwoma routerami tworzy tylko kontekst dystrybucji tras i nic więcej. Nie instaluje ścieżki przekazywania i nie mówi, która enkapsulacja przeniesie pakiet klienta do zdalnego punktu końcowego. Gdy te dwa fakty zostaną rozdzielone, pytanie „czy to wymaga MPLS w rdzeniu” staje się węższe i możliwe do odpowiedzi pytaniem o płaszczyznę danych obsługiwaną przez platformę.

Co tak naprawdę negocjuje rodzina adresów

Wieloprotokołowy BGP przenosi informacje o osiągalności warstwy sieciowej VPNv4 w ramach AFI 1 i SAFI 128, a każdy wpis łączy rozróżnik trasy z prefiksem i etykietą. Sesja negocjuje, że obie strony potrafią kodować i dekodować te informacje. To, czego nie negocjuje, to płaszczyzna danych. Wszystko po tym akapicie dotyczy przekazywania i nic z tego nie jest rozstrzygane przez podniesienie sesji.

Udana sesja jest więc dowodem zdolności płaszczyzny sterowania, a nie przekazywania. Router może trzymać tysiące wpisów VPNv4 i nadal odrzucać każdy pakiet klienta, i właśnie dlatego te dwie klasy błędów są na początku mylone.

Zwróć uwagę na etykietę w NLRI. To etykieta usługi, powiązana z prefiksem wewnątrz VRF, i ma rolę w przekazywaniu, gdy pakiet dotrze do wyjściowego punktu końcowego. Czy jakiekolwiek urządzenie tranzytowe ją czyta, jest osobną decyzją projektową.

Odbiór, import i przekazywanie to trzy kroki

Odbieranie trasy, prawo do jej używania i możliwość przekazywania nią wykonują różne części urządzenia. BGP przechowuje to, co słyszy; polityka importu i dopasowanie celu trasy decydują, która VRF może ją rozważyć; następnie płaszczyzna przekazywania musi rozwiązać ogłoszony następny skok na coś, co naprawdę może wypchnąć na przewód.

Właśnie w tym środkowym kroku mieszkają najbardziej zaskakujące błędy. Trasa może być obecna w tabeli BGP, ważna, a nawet najlepsza, podczas gdy tabela tras VRF pozostaje pusta, bo żaden cel trasy nie pasował do listy importu. Nic nie rejestruje błędu protokołu, bo nie wystąpił żaden błąd protokołu.

Ostatni krok to miejsce, w którym ujawnia się wsparcie platformy. Następny skok osiągalny w warstwie bazowej nie jest automatycznie rozwiązywany jako transport usługi VPN, a urządzenie może wymagać określonego typu tunelu, określonej operacji na etykiecie albo obu. Czytanie stanu rozwiązania jest bardziej informacyjne niż czytanie liczby tras.

Rdzeń IP może nieść stos, którego nigdy nie komutuje

Rozróżnienie, które warto zachować, to «rdzeń nie uruchamia MPLS» wobec «w usłudze nigdzie nie ma etykiety». To różne twierdzenia i tylko pierwsze dotyczy urządzeń tranzytowych. RFC 4023 definiuje przenoszenie MPLS przez tunele IP lub GRE, i właśnie ten mechanizm czyni drugie twierdzenie możliwym na czysto IP-owym rdzeniu.

customer packet + service label
  encapsulated in GRE, addressed to the egress tunnel endpoint
  forwarded by ordinary IP routers on the outer header
  decapsulated at the endpoint, label still meaningful

Routery tranzytowe przekazują według zewnętrznego celu IP i nie potrzebują ani prefiksów klienta, ani natywnego przełączania etykiet. Na dalekim końcu zewnętrzny tunel jest usuwany, a etykieta usługi wznawia swoją pracę. Rdzeń przeniósł nieprzejrzysty ładunek, i dokładnie do tego sieć IP jest dobra.

Czego ten projekt ci nie daje, to gwarancja uniwersalna. To nie dowód, że każdy router rozwiązuje każdy następny skok VPNv4 przez dowolny interfejs GRE, ani powód, by usunąć działającą natywną konfigurację MPLS. To kontrprzykład dla twierdzenia uniwersalnego, a pytanie praktyczne pozostaje lokalne dla platformy. Zapisz to pytanie jako ograniczenie platformy, a nie jako regułę protokołu.

Przejdź łańcuch na urządzeniu, aż się zerwie

Zacznij od otrzymanej trasy i zatrzymaj się na pierwszym kroku, który zawodzi, bo późniejszych kroków nie da się zdiagnozować, dopóki wcześniejszy jest zepsuty. Cztery polecenia obejmują większość tego w typowej implementacji.

show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_A

Czytaj je jako sekwencję, a nie jako cztery niezależne kontrole. Pierwsze potwierdza, że rodzina jest aktywna i że sąsiad wymienia trasy; drugie pokazuje, czy prefiks dotarł z użytecznym następnym skokiem; trzecie dowodzi kwalifikowalności do importu; czwarte pokazuje, czy płaszczyzna przekazywania związała z nim etykietę lub tunel.

Następnie przetestuj ścieżkę obciążenia w obu kierunkach, z MTU, które przetrwa enkapsulację. GRE dodaje bajty nagłówka, a ścieżka, która przechodzi małe sondy, może zawieść na pakietach pełnego rozmiaru tylko w jednym kierunku, co wygląda jak usterka aplikacji, a nie transportu.

Dwie notatki operacyjne zamykają pętlę. GRE to enkapsulacja, a nie poufność, więc niezaufana sieć tranzytowa potrzebuje obsługiwanego zabezpieczenia na wierzchu, a nie założenia. I zapisz, którą enkapsulację platforma naprawdę obsługuje przed przeglądem projektu, bo ta jedna odpowiedź decyduje, czy rdzeń tylko z IP jest słusznym wyborem, czy planem, który nie potrafi przekazywać.