DMVPN faza 3: czytanie skrótu w obu kierunkach

Widzisz, jak jeden ping idzie od spoke do spoke długą drogą przez hub, a drugi idzie bezpośrednio. W tym momencie kusi, by ogłosić skrót działającym. Ten wniosek jest w połowie słuszny. Droga tam może być skrótem, podczas gdy droga powrotna nadal idzie przez hub, a stan, który dowodzi każdego kierunku, to inny stan. Przejdź oba kierunki i przeczytaj trzy tabele, zanim uznasz projekt za zdrowy.

Zacznij od ścieżki pakietu, którą naprawdę widzisz

Zacznij na spoke z celem, który powinien być bezpośredni. Prześledź pierwszy pakiet: idzie trasą spoke w stronę hub, bo skrót jeszcze nie istnieje. Hub przekazuje go dalej i w projekcie fazy 3 wysyła też przekierowanie do źródła, że istnieje lepsza droga.

To przekierowanie jest wyzwalaczem, nie dowodem. Mówi, że hub widział ruch, który można zoptymalizować. Nie mówi, że źródło zbudowało skrót, że cel odpowiedział na rozwiązanie ani że droga powrotna go używa.

Pierwszą użyteczną obserwacją jest więc stan przed i po: pierwszy przepływ przez hub, późniejszy przepływ bezpośrednio.

Trzy stany, które wyglądają jak jeden tunel

Skrót zależy od trzech części stanu, a każda ma własny czas życia i własne polecenie.

Wpis w pamięci podręcznej NHRP mapuje adres overlay na adres transportowy NBMA. Trasa lub skrót decyduje, dokąd przekazywany jest jeden cel wewnętrzny. Asocjacja IPsec chroni ruch, który z tego wynika. Brakująca odpowiedź może pochodzić z każdego z trzech miejsc, a polecenia mówią, którego brakuje.

Czytaj je w tej kolejności, bo brakujące mapowanie czyni pozostałe dwa nieciekawymi.

Przejdź osobno żądanie i odpowiedź

Ze spoke A poproś o rozwiązanie i obserwuj, co wraca. Żądanie idzie obsługiwaną ścieżką przekazywania NHRP, a cel może odpowiedzieć bezpośrednio, a nie przez hub. Ta asymetria jest normalna, i dlatego odpowiedź jest ciekawszą połową wymiany.

Teraz zamień role. Wyślij z B do A i powtórz te same trzy odczyty. Projekt, który robi skrót w jednym kierunku, a w drugim nie, nie jest symetryczny, a asymetria zwykle wynika z brakującego prefiksu po jednej stronie lub z rozwiązania, które nigdy nie dostało odpowiedzi.

Odpowiedź partnera nie musi przechodzić przez hub tylko dlatego, że żądanie to zrobiło. Nie czytaj tego jako błędu i nie zaczynaj gonić usterki routingu, której nie ma.

Czytaj przekierowanie hub, nie tylko jego trasę

Tablica tras hub mówi, dokąd hub wysłałby pakiet. Przekierowanie mówi, co hub poprosił źródło, żeby z tym zrobiło. To różne fakty, a hub z poprawną trasą i bez przekierowań utrzyma każdy przepływ na długiej drodze bez końca. Sprawdź zdarzenia NHRP hub i potwierdź, że przekierowania są generowane dla ruchu, na którym ci zależy.

Faza 3 zmienia też znaczenie podsumowania. Przy zachowaniu skrótu spoke nie potrzebują całego zestawu konkretnych tras zdalnych, którego oczekiwał projekt fazy 2, więc podsumowana trasa na spoke nie jest automatycznie brakującą siecią. Potwierdź fazę i politykę routingu, zanim odczytasz podsumowanie jako usterkę.

To jedno nieporozumienie powoduje więcej zgłoszeń DMVPN niż cokolwiek innego.

Zapisz wniosek jako brakujący obiekt

Zakończ autoryzowanym przepływem aplikacji i jego odpowiedzią, i zanotuj dla każdego kierunku, czy użył drogi bezpośredniej. Następnie zapisz wniosek jako obiekt, którego brakowało: mapowanie, skrót przekazywania, asocjacja ochrony lub odpowiedź aplikacji.

Sąsiedztwo routingu i współdzielona asocjacja bezpieczeństwa są dowodem zdrowia, a nie dowodem drogi. Oba mogą być doskonałe, podczas gdy każdy pakiet nadal jedzie długą drogą. Sprawdź najpierw decyzję przekazywania, potem asocjację, która ją niesie. Kolejność ma znaczenie, bo asocjacja powstaje tak czy inaczej.

Ten nawyk się opłaca przy następnym zgłoszeniu. „Tunel jest podniesiony, ale wolny“ zmienia się w „B nie ma skrótu do hosta A“, a drugie stwierdzenie to poprawka na pięć minut. Trzymaj wyjście poleceń razem z wnioskiem i miej obok przewodnik po fazie 3 od dostawcy.