Sesja BGP działa, ścieżka klienta zepsuta: MPLS nad DMVPN

Peering działa od tygodni, liczba prefiksów wygląda poprawnie, a ruch jednego klienta wciąż idzie długą drogą albo nigdy nie dociera. Ten sam wskaźnik ocenia dwie różne rzeczy. Sesja BGP mówi, że dwa peery mogą wymieniać komunikaty przez połączenie TCP; nic nie mówi o tym, czy overlay zdoła przenieść oznaczony pakiet właśnie dla tego klienta.

Tę lukę najłatwiej dostrzec w projekcie MPLS nad DMVPN, gdzie ścieżka przez hub i bezpośrednia ścieżka przez spoke mogą zachowywać się różnie z powodów niemających nic wspólnego z peeringiem.

Co sesja naprawdę dowodzi

BGP działa po TCP, więc każdy peer potrzebuje trasy do adresu drugiego końca, zanim cokolwiek innego się stanie. Jeśli jako ten koniec wybierzesz loopback, stworzyłeś wymóg osiągalności, a nie gwarancję przekazywania. Sesja może potem pozostać w górze przez interfejs, którego ruch klienta nigdy by nie użył.

Przed wyciągnięciem wniosków zapisz cztery fakty na obu końcach: adres źródłowy sesji, adres docelowy, kontekst routingu, w którym ona siedzi, i to, który interfejs jądro lub router wybrałoby dla tej pary. Te fakty opisują płaszczyznę sterowania. Pakiety klienta dokładają do nich VRF, stos etykiet i mapowanie overlaya.

Cztery mechanizmy, nie jeden

Dokumentacja Cisco dotycząca MPLS nad DMVPN wyraźnie rozdziela części. MP-BGP rozprowadza etykiety overlaya klienta między urządzeniami na krawędzi dostawcy. MPLS używa tych etykiet do wyboru kontekstu przekazywania pakietu. NHRP mapuje adres overlaya na punkt końcowy transportu, którego potrzebuje tunel dynamiczny. IPsec chroni ścieżkę peera tam, gdzie ma zastosowanie.

Każdy z czterech może być poprawny, podczas gdy inny jest błędny, i to kombinacja przenosi ruch. Wymiana tras może się zakończyć, gdy brakuje powiązania etykiety dla jednego VRF, gdy mapowanie NHRP wskazuje nieaktualny adres transportu albo gdy tunel istnieje, ale żadna polityka nie pozwala na pakiet wewnętrzny. Żaden z tych warunków nie zrywa sesji.

Porównaj ścieżkę przez hub ze skrótem, jedna zmienna naraz

Ustal host źródłowy, host docelowy i VRF, a następnie dwa razy prześledź ten sam przepływ. Na ścieżce przez hub zanotuj następny hop, etykietę usługi identyfikującą zdalny kontekst klienta i używane mapowanie overlaya na transport. Na zamierzonej ścieżce bezpośredniej zanotuj te same trzy rzeczy. Różnica między obiema listami jest usterką albo jej brakiem.

Utrzymuj przepływ stały podczas porównania. Zmiana hosta źródłowego, VRF lub celu między obserwacjami daje dwie niepowiązane historie, i to najczęstszy sposób, w jaki to ćwiczenie się nie udaje.

Trzymaj testy loopback w osobnym przedziale

Ping wysłany z loopbacka routera to użyteczny test i ćwiczy inny przypadek niż przepływ z hosta. Adres źródłowy należy do routera, jego kontekst routingu może być globalny, a nie VRF, a ścieżka odpowiedzi może się różnić od tej, którą obrałby prefiks klienta. Dlatego odpowiadający loopback i aplikacja działająca skrótem to osobne wyniki, i tylko drugi opisuje klienta.

Przetestuj oba, a potem oznacz je osobno w notatkach. Gdy się nie zgadzają, nauczyłeś się czegoś konkretnego o tym, gdzie projekt się rozjeżdża, a to więcej, niż kiedykolwiek powie jeden zielony znacznik.

Twierdzenia o wersji i o defekcie potrzebują własnych dowodów

Raporty terenowe czasem zalecają zmianę maski hosta albo adresu źródłowego BGP, i takie raporty warto czytać tylko razem z defektem, o którym je napisano, i wydaniami, których dotyczył. Obejście z jednego wydania nie jest stwierdzeniem, że architektura nie obsługuje żadnego prefiksu /32.

Używaj dokumentacji zgodnej z twoją fazą DMVPN, platformą i wydaniem, i pamiętaj, że jeden rozdział może obejmować kilka układów, w tym FlexVPN. Przykład z jednego układu nie przenosi się po cichu na inny. Wybierz końce sesji pod projekt płaszczyzny sterowania, którego naprawdę potrzebujesz, a potem osobno zweryfikuj ścieżkę przekazywania klienta, bo przepisywanie każdej maski loopback nie zastępuje ustalenia, które zadanie zawiodło.