Ten sam /24 dla dwóch klientów? VPNv4 wymaga RD i etykiety

Dwaj najemcy numerują swoją filię tą samą 10.50.0.0/24, a po zmianie trasa jednego z nich znika z krawędzi dostawcy, podczas gdy druga nadal działa. Uproszczenie stojące za tym zgłoszeniem to zwykle rezygnacja z rozróżniacza trasy (RD), bo „etykieta już identyfikuje klienta“. Nie identyfikuje. RD i etykieta odpowiadają na dwa różne pytania, a różnica staje się widoczna dopiero wtedy, gdy wymuszą ją nakładające się adresy.

Jedna trasa tam, gdzie powinny być dwie

Zwykły IPv4 unicast porównuje dwie ścieżki do tego samego prefiksu i instaluje lepszą. 10.50.0.0/24 od najemcy A i 10.50.0.0/24 od najemcy B to jeden klucz, więc jeden wygrywa, a drugi przetrwa tylko jako ścieżka zapasowa. Protokół zrobił to, co mu kazano; płaszczyznę sterowania poproszono o przechowanie dwóch różnych tras pod jednym identyfikatorem.

Wynik wygląda jak brakująca trasa, a nie błąd: PE, który przegrał rywalizację, nadal przekazuje swojego najemcę lokalnie, więc ping w obrębie lokalizacji się udaje, a test między lokalizacjami zawodzi. Zanim dotkniesz jakiejkolwiek polityki, policz wpisy dla tego prefiksu w tabeli VPNv4.

RD zamienia jeden klucz w dwa

Ośmiobajtowy rozróżniacz trasy jest dodawany przed prefiksem IPv4, a obiekt przenoszony przez BGP staje się adresem VPN-IPv4 zamiast prefiksu IPv4. Dwaj najemcy mogą trzymać te same 32 bity, ponieważ 64 bity z przodu się różnią. Istnieją typy formatu dla RD opartego na AS i dla RD opartego na adresie, a wybór należy do źródłowego PE. RD oparty na AS jest typowy, gdy PE dzielą AS, a oparty na adresie, gdy nie dzielą.

Nie czytaj RD jako znacznika członkostwa. Cele trasy sterują importem i eksportem i decydują, które VRF mogą zainstalować trasę; RD gwarantuje tylko, że trasa ma własną tożsamość. Dawanie każdemu VRF własnego RD to powszechna praktyka, ponieważ utrzymuje to mapowanie czytelnym w przeglądzie tras.

Etykieta jest lokalną instrukcją przekazywania

Każde ogłoszenie niesie też etykietę MPLS, a jej znaczenie ogranicza się do routera, który ją przydzielił. Inny PE może wydać ten sam numer dla niepowiązanego celu. Właśnie dlatego etykieta nie może zastąpić tożsamości klienta: numer jest poprawny tylko obok następnego skoku i stanu przekazywania, który go zainstalował.

Granularność przydziału różni się w zależności od implementacji i projektu: niektóre platformy przydzielają jedną etykietę na VRF, inne na prefiks, a etykieta może wskazywać akcję przekazywania, a nie klienta. Dwie różne etykiety docierające do tego samego celu nie są sprzecznością, a ten sam numer etykiety na dwóch PE też nie.

Dlaczego jedno nie może zastąpić drugiego

Czytanie ogłoszenia oznacza patrzenie na cztery rzeczy naraz: prefiks kwalifikowany przez RD, cele trasy, następny skok i etykietę. Czytanie pakietu użytkownika oznacza patrzenie na stos zainstalowany na podstawie tych informacji. Zdrowy projekt pokazuje zgodność obu stron, a zepsuty ma zwykle jedną stronę poprawną, a drugą nieaktualną. To porównanie oddziela problem tożsamości od problemu przekazywania.

Schludny kontrast między płaszczyzną sterowania a płaszczyzną danych jest zabiegiem dydaktycznym, nie opisem kodowania. RFC 8277 umieszcza etykietę wewnątrz oznaczonego NLRI, więc samo ogłoszenie niesie powiązanie; użycie jej do przekazywania to późniejszy, osobny krok.

Gdy brakuje trasy najemcy, sprawdzaj w tej kolejności: dwa wpisy VPNv4 dla prefiksu, właściwy cel trasy na każdym, rozwiązywalny następny skok i etykietę, dla której odbierający PE ma stan. Naprawianie tożsamości wartością przekazywania, lub odwrotnie, przejdzie jedną kontrolę i zawiedzie na następnej.