Přepnutí WAN u DMVPN: směrovací politika, nebo vypnutí tunelu?

Rozbočovač DMVPN se dvěma WAN se přepíná na záložní cestu jedním ze dvou způsobů a rozdíl je větší, než se zdá. Jeden mění, který další skok směrovací politika vybere, takže pakety dál tečou a mění se jen jejich výstup. Druhý administrativně vypíná tunel, což s sebou shodí každou službu na tomto rozhraní. Oba mohou být správné, protože odpovídají na různé otázky.

Rozhodnutí přichází před konfigurací

Rozhodují to za vás tři podmínky. Závisí na tom, že rozhraní tunelu je aktivní, ještě něco jiného, například druhý profil DMVPN nebo monitor, který čte jeho stav? Nese provoz, který se musí přepnout, vlastní politiku, nebo se spoléhá na globální směrovací tabulku? A potřebuje operátor jednoznačnou změnu stavu, nebo je tiché přepnutí cesty přijatelné? Odpovězte na ty tři a volba se obvykle udělá sama.

Pokud by vypnutí shodilo služby, které fungovaly, je směrovací politika menší zásah. Pokud je požadavkem, aby tunel neexistoval, dokud je primární WAN dole, žádný záznam politiky to nevyjádří.

Zapište odpověď, protože konfigurace je ta snadná část.

Co směrovací politika skutečně mění

U směrování založeného na politice může sledovaný objekt řídit další skok. Záznam v mapě tras pojmenovává kandidáta na další skok a sledovaný objekt, který musí být aktivní, aby se použil, a tento stav sledování pochází ze sondy IP SLA. Když objekt spadne, záznam přestane odpovídat a paket se vyhodnotí dalším záznamem nebo běžnou směrovací tabulkou.

Tento poslední detail lidi překvapuje: politika, která přestane vybírat další skok, obvykle povolí normální směrování, místo aby provoz blokovala. Pokud potřebujete černou díru při výpadku, musíte si ji napsat.

Syntaxe se liší mezi platformami a verzemi, proto si prohlédněte příručku pro verzi, kterou skutečně používáte.

Co mění vypnutí tunelu

Vypnutí rozhraní mění administrativní stav. Každý tunel, trasa a relace, které na něm závisí, spadnou najednou, což je přesně to, co chcete, pokud má tunel zmizet. Také tak applet EEM promění problém s WAN ve výpadek, který zahrne i nesouvisející služby.

Pokud se vydáte touto cestou, omezíte applet na jedno rozhraní a jeden spouštěč, uložte předchozí administrativní stav, definujte akci obnovy a zajistěte, aby ho opakované flappy nemohly uvést do smyčky.

Natvrdo zapsaný příkaz obnovy může také přepsat odstávku kvůli údržbě, kterou provedl někdo jiný.

Nechte sondu cestovat po cestě, kterou si myslíte

Sonda, která sleduje aktuální nejlepší trasu, se přesune na záložní WAN spolu se vším ostatním a potom ohlásí primární jako zdravou, protože ji už nepoužívá.

Připněte sondu k rozhraní nebo zdrojové adrese cesty, kterou testujete. Zkontrolujte také, na co cílí, protože dosažení dalšího skoku poskytovatele dokazuje méně než dosažení služby, kvůli které tunel existuje. Nastavte zpoždění náběhu a poklesu záměrně: krátké zpoždění poklesu reaguje rychle a flappuje, zatímco dlouhé vydrží krátké výkyvy a skryje skutečné poruchy. Příručka Cisco pro sledování a směrování podle politik v IOS XE dokumentuje podporované kombinace a sada funkcí na vaší platformě rozhoduje, které z nich můžete použít.

Zapište obě hodnoty zpoždění vedle sledovaného objektu, jinak nikdo nebude vědět, proč se choval právě tak.

Rozhodněte o obnově a potom ověřte

Obnova si zaslouží vlastní rozhodnutí. Spoj, který neustále překračuje práh, může přesouvat relace častěji než ten, který jasně selhal, a každý přesun stojí obnovu klíčů a opakované pokusy aplikace. Zvolte požadavek na stabilitu a nechte zpoždění, aby ho vyjádřilo. Potom ověřte v okně změn s viditelnou cestou sondy: zvolená trasa, cesta vnějšího protějšku a co aplikace skutečně udělala.

Pokud přepnutí funguje, ale aplikace se stále láme, problém je nad směrovací vrstvou a žádné množství sledování ho neopraví.

Uchovejte důkazy z toho okna, protože další změna se s nimi bude porovnávat.