Przełączanie awaryjne WAN w DMVPN: polityka tras czy zamknięcie tunelu?
Failover oznacza dwie różne rzeczy: politykę, która przestaje wybierać następny skok, albo tunel, który schodzi administracyjnie. Wybierz według tego, co od niego zależy.
Koncentrator DMVPN z dwoma WAN przełącza się na zapasowy na jeden z dwóch sposobów, a różnica jest większa, niż się wydaje. Jeden zmienia, który następny skok wybiera polityka tras, więc pakiety płyną dalej i zmienia się tylko ich wyjście. Drugi administracyjnie zamyka tunel, co zabiera ze sobą każdą usługę na tym interfejsie. Oba mogą być właściwe, bo odpowiadają na różne pytania.
Decyzja zapada przed konfiguracją
Trzy warunki rozstrzygają to za ciebie. Czy coś jeszcze zależy od tego, że interfejs tunelu jest aktywny, na przykład drugi profil DMVPN albo monitor czytający jego stan? Czy ruch, który musi się przełączyć, niesie własną politykę, czy opiera się na globalnej tabeli routingu? I czy operator potrzebuje jednoznacznej zmiany stanu, czy wystarczy ciche przełączenie ścieżki? Odpowiedz na te trzy, a wybór zwykle dokonuje się sam.
Gdyby zamknięcie zabrało działające usługi, polityka tras jest mniejszym działaniem. Jeśli wymaganiem jest, aby tunel nie istniał, dopóki główny WAN jest wyłączony, żaden wpis polityki tego nie wyrazi.
Zapisz odpowiedź, bo konfiguracja to łatwa część.
Co polityka tras naprawdę zmienia
W routingu opartym na politykach śledzony obiekt może bramkować następny skok. Wpis mapy tras wskazuje kandydata na następny skok i śledzony obiekt, który musi być aktywny, aby go użyto, a ten stan śledzenia pochodzi z sondy IP SLA. Gdy obiekt spadnie, wpis przestaje pasować, a pakiet jest oceniany przez następny wpis albo zwykłą tabelę routingu.
Ten ostatni szczegół zaskakuje ludzi: polityka, która przestaje wybierać następny skok, zwykle pozwala na normalny routing, zamiast blokować ruch. Jeśli potrzebujesz czarnej dziury przy awarii, musisz ją napisać sam.
Składnia różni się między platformami i wydaniami, więc sprawdź przewodnik dla wersji, którą naprawdę uruchamiasz.
Co zmienia zamknięcie tunelu
Zamknięcie interfejsu zmienia stan administracyjny. Każdy tunel, trasa i sesja, które od niego zależą, schodzą naraz, co jest dokładnie tym, czego chcesz, jeśli tunel jest tym, co ma zniknąć. Tak też aplet EEM zamienia problem z WAN w awarię obejmującą niepowiązane usługi.
Jeśli wybierzesz tę drogę, ogranicz aplet do jednego interfejsu i jednego wyzwalacza, zapisz poprzedni stan administracyjny, zdefiniuj akcję przywracania i upewnij się, że powtarzające się flappy nie mogą wpędzić go w pętlę.
Zakodowana na stałe komenda przywracania może też nadpisać zamknięcie serwisowe wykonane przez kogoś innego.
Niech sonda podróżuje ścieżką, którą myślisz
Sonda, która podąża za aktualnie najlepszą trasą, przenosi się na zapasowy WAN razem ze wszystkim innym, a potem zgłasza główny jako zdrowy, bo już go nie używa.
Przypnij sondę do interfejsu lub adresu źródłowego ścieżki, którą testujesz. Sprawdź też, na co celuje, bo dotarcie do następnego skoku dostawcy dowodzi mniej niż dotarcie do usługi, dla której istnieje tunel. Ustaw opóźnienia wznoszenia i opadania świadomie: krótkie opóźnienie opadania reaguje szybko i flappuje, a długie wytrzymuje krótkie zakłócenia i ukrywa prawdziwe awarie. Przewodnik Cisco dotyczący śledzenia i routingu opartego na politykach w IOS XE dokumentuje obsługiwane kombinacje, a zestaw funkcji na twojej platformie decyduje, których z nich możesz użyć.
Zapisz obie wartości opóźnienia obok śledzonego obiektu, inaczej nikt nie będzie wiedział, dlaczego zachowywał się właśnie tak.
Zdecyduj o przywracaniu, a potem zweryfikuj
Przywracanie zasługuje na własną decyzję. Łącze, które stale przekracza próg, może przenosić sesje częściej niż takie, które wyraźnie zawiodło, a każde przeniesienie kosztuje ponowne uzgadnianie kluczy i ponowienia aplikacji. Wybierz wymóg stabilności i pozwól opóźnieniu go wyrazić. Potem zweryfikuj w oknie zmian, widząc ścieżkę sondy: wybrana trasa, ścieżka zewnętrznego peera i to, co naprawdę zrobiła aplikacja.
Jeśli przełączanie działa, ale aplikacja nadal się psuje, problem leży powyżej warstwy routingu i żadna ilość śledzenia go nie naprawi.
Zachowaj dowody z tego okna, bo następna zmiana będzie porównywana właśnie z nimi.