IPv6 w MPLS VPN: trzy decyzje, nie jedna rodzina adresów
Trasy VPN klienta, sesja BGP między PE i transport w rdzeniu to osobne decyzje. Sesja może działać w jednej rodzinie i nieść inną.
Powiedz na przeglądzie projektu „uruchom IPv6 L3VPN po IPv6 BGP”, a w tym jednym zdaniu kryją się trzy osobne decyzje. Które prefiksy należą do VPN klienta, które adresy niosą sesję routingu między krawędziami dostawcy i który rdzeń przenosi oznaczony pakiet, to niezależne wybory. Wszystkie mogą być IPv6, mogą być mieszane, a mieszanie jest celowo dozwolone. Dopiero rozdzielenie tych trzech zamienia niejasne wymaganie w coś, przeciw czemu można testować platformę.
Rozdziel trzy zadania
Pierwsze zadanie to trasa klienta: prefiksy IPv6 należące do jednego kontekstu routingu VPN i muszące pozostać poza każdym innym kontekstem. Drugie to połączenie routingu między routerami krawędzi dostawcy, które wymieniają te prefiksy. Trzecie to transport, który niesie oznaczony pakiet klienta przez rdzeń do odległej krawędzi. Wymienienie tylko jednego z nich to jeszcze nie projekt.
| Job | The question it answers | What confusion looks like |
|---|---|---|
| Customer VPN routes | Which IPv6 prefixes belong to each VPN context, and how are they kept apart? | Prefixes leak into the global table and between customers |
| PE-to-PE BGP session | Which addresses carry the routing connection between the two edges? | A session-family mismatch gets chased as a core transport fault |
| Transport to the remote PE | How does the chosen core move the labelled packet to the far edge? | A route is present and unforwardable in the same moment |
Każde zadanie ma własną rodzinę adresów, własne tryby awarii i często własny zespół. Tabela jest użyteczna właśnie dlatego, że jedno zdanie w dokumencie projektu ma zwyczaj zgniatać wszystkie trzy wiersze w jeden.
Rodziną trasy jest VPN-IPv6, a nie IPv6 unicast
RFC 4659 definiuje rodzinę BGP/MPLS IPv6 VPN, a przynależność do niej jest bardziej szczegółowa, niż sugeruje słowo IPv6. Trasa jest tam wyróżnikiem trasy połączonym z prefiksem IPv6, zakodowanym w AFI 2 i SAFI 128. Zwykły IPv6 unicast to inna rodzina, więc ogłoszenie, które w looking glass wygląda jak prefiks, może wcale nie być tym samym obiektem. Błędne odczytanie rodziny to pierwszy sposób, w jaki ten projekt idzie źle.
Różnica gryzie na krawędzi, gdzie trasa musi najpierw trafić do właściwego kontekstu VPN, zanim cokolwiek zrobi. Odebranie prefiksu dowodzi, że wymiana nastąpiła, i nic nie mówi o instalacji. Ta luka daje klasyczny raport, w którym sesja jest podniesiona, a klient wciąż jest w ciemności.
Sesja może działać w innej rodzinie niż VPN
Nic nie zmusza połączenia BGP między dwiema krawędziami do używania własnej rodziny VPN. Specyfikacja dopuszcza sesję IPv4 lub IPv6, a transport IPv6 VPN sam jest zdefiniowany nad oboma typami rdzenia. Sesja IPv6 nie mówi więc nic o rodzinie tego, co niesie, i nie wybiera też płaszczyzny danych. Trzy niezależne bity, a projekt powinien nieść wszystkie trzy osobno.
To wyzwala i jednocześnie łatwo się czyta źle. Trasy klienta IPv6 mogą jechać po sesji z adresem IPv4, a trasy IPv4 po sesji IPv6, pod warunkiem że platforma wspiera tę kombinację, a następny skok się rozwiązuje. Nie może się zdarzyć, żeby sesja sugerowała ładunek, ani w dokumencie projektu, ani w monitoringu, który później dowodzi usługi.
Następny skok w rdzeniu IPv4 ma własne kodowanie
Gdy rdzeń pod VPN jest IPv4, trasa nie pojawia się z następnym skokiem, którego krawędź wejściowa mogłaby użyć bezpośrednio. Przychodzi w postaci IPv6 odwzorowanego w IPv4, i tak specyfikacja wyraża krawędź wyjściową, gdy transport pod spodem jest IPv4. Router wejściowy musi wtedy zamienić ten odwzorowany adres w coś, do czego naprawdę dotrze przez rdzeń, a rozwiązywanie to krok, który po cichu zawodzi.
Czytaj to jako zależność przekazywania, a nie jako ciąg do kopiowania między urządzeniami. Potwierdź trzy rzeczy na platformie, którą naprawdę utrzymujesz: ogłoszony następny skok rozwiązuje się do użytecznej ścieżki, stos etykiet jest akceptowany, a cel trafia do zamierzonego kontekstu VPN. Jeśli którakolwiek zawiedzie, zostaje sesja, która wygląda zdrowo i nic nie przekazuje, dlatego kontrola należy do przebiegu odbiorczego, a nie do późniejszego incydentu.
Napisz wymaganie w czterech wierszach
Wymaganie warte testowania nazywa cztery rzeczy: rodzinę VPN, transport sesji, kodowanie następnego skoku i układ rdzenia. Potem nazywa jeden prefiks klienta do śledzenia od początku do końca: przez wymianę, instalację, rozwiązywanie etykiet i drogę powrotną. „Obsługuje IPv6 BGP” nie pokrywa żadnej z czterech i ukrywa, gdzie naprawdę mieszka niezgodność.
Zdrowa sesja bez wymiany VPN-IPv6 jest niekompletna, a odebrana trasa VPN bez działającego przekazywania jest równie niekompletna. Trzymanie ich jako osobnych wierszy odbiorczych skraca następną rozmowę o rozwiązywaniu problemów, bo wiersz, który zawodzi, jest już zapisany.