Prepolovanie WAN v DMVPN: smerovacia politika alebo vypnutie tunela?

Koncentrátor DMVPN s dvoma WAN sa prepína na záložnú cestu jedným z dvoch spôsobov a rozdiel je väčší, než sa zdá. Jeden mení, ktorý ďalší skok vyberie smerovacia politika, takže pakety naďalej tečú a mení sa len ich výstup. Druhý administratívne vypína tunel, čo so sebou zhodí každú službu na tomto rozhraní. Oba môžu byť správne, pretože odpovedajú na rôzne otázky.

Rozhodnutie prichádza pred konfiguráciou

Rozhodujú to za vás tri podmienky. Závisí od toho, že rozhranie tunela je aktívne, ešte niečo iné, napríklad druhý profil DMVPN alebo monitor, ktorý číta jeho stav? Nesie prevádzka, ktorá sa musí prepnúť, vlastnú politiku, alebo sa spolieha na globálnu smerovaciu tabuľku? A potrebuje operátor jednoznačnú zmenu stavu, alebo je tiché prepnutie cesty prijateľné? Odpovedzte na tie tri a voľba sa zvyčajne urobí sama.

Ak by vypnutie zhodilo služby, ktoré fungovali, smerovacia politika je menší zásah. Ak je požiadavkou, aby tunel neexistoval, kým je primárny WAN dole, žiadny záznam politiky to nevyjadrí.

Zapíšte odpoveď, pretože konfigurácia je tá ľahká časť.

Čo smerovacia politika skutočne mení

Pri smerovaní založenom na politike môže sledovaný objekt riadiť ďalší skok. Záznam v mape trás pomenúva kandidáta na ďalší skok a sledovaný objekt, ktorý musí byť aktívny, aby sa použil, a tento stav sledovania pochádza zo sondy IP SLA. Keď objekt padne, záznam prestane zodpovedať a paket sa vyhodnotí ďalším záznamom alebo bežnou smerovacou tabuľkou.

Tento posledný detail ľudí prekvapuje: politika, ktorá prestane vyberať ďalší skok, zvyčajne povolí normálne smerovanie namiesto blokovania prevádzky. Ak potrebujete čiernu dieru pri výpadku, musíte si ju napísať.

Syntax sa líši medzi platformami a vydaniami, preto si pozrite príručku pre verziu, ktorú skutočne používate.

Čo mení vypnutie tunela

Vypnutie rozhrania mení administratívny stav. Každý tunel, trasa a relácia, ktoré od neho závisia, padnú naraz, čo je presne to, čo chcete, ak má tunel zmiznúť. Takto aj applet EEM premení problém s WAN na výpadok, ktorý zahŕňa aj nesúvisiace služby.

Ak sa vydáte touto cestou, obmedzte applet na jedno rozhranie a jeden spúšťač, uložte predchádzajúci administratívny stav, definujte akciu obnovy a uistite sa, že ho opakované flappy nemôžu uviesť do slučky.

Natvrdo zapísaný príkaz obnovy môže tiež prepísať odstávku kvôli údržbe, ktorú vykonal niekto iný.

Nechajte sondu cestovať po ceste, ktorú si myslíte

Sonda, ktorá sleduje aktuálnu najlepšiu trasu, sa presunie na záložný WAN spolu so všetkým ostatným a potom ohlási primárny ako zdravý, pretože ho už nepoužíva.

Pripnite sondu k rozhraniu alebo zdrojovej adrese cesty, ktorú testujete. Skontrolujte aj to, na čo cieli, pretože dosiahnutie ďalšieho skoku poskytovateľa dokazuje menej ako dosiahnutie služby, pre ktorú tunel existuje. Nastavte oneskorenia nábehu a poklesu zámerne: krátke oneskorenie poklesu reaguje rýchlo a flappuje, zatiaľ čo dlhé vydrží krátke výkyvy a skryje skutočné poruchy. Príručka Cisco pre sledovanie a smerovanie podľa politík v IOS XE dokumentuje podporované kombinácie a sada funkcií na vašej platforme rozhoduje, ktoré z nich môžete použiť.

Zapíšte obe hodnoty oneskorenia vedľa sledovaného objektu, inak nikto nebude vedieť, prečo sa správal práve tak.

Rozhodnite o obnove a potom overte

Obnova si zaslúži vlastné rozhodnutie. Spoj, ktorý neustále prekračuje prah, môže presúvať relácie častejšie ako ten, ktorý jasne zlyhal, a každý presun stojí obnovu kľúčov a opakované pokusy aplikácie. Zvoľte požiadavku na stabilitu a nechajte oneskorenie, aby ju vyjadrilo. Potom overte v okne zmien s viditeľnou cestou sondy: zvolená trasa, cesta vonkajšieho partnera a čo aplikácia skutočne urobila.

Ak prepnutie funguje, ale aplikácia sa stále láme, problém je nad smerovacou vrstvou a žiadne množstvo sledovania ho neopraví.

Uchovajte dôkazy z toho okna, pretože ďalšia zmena sa s nimi bude porovnávať.