DMVPN WAN prebacivanje: politika rute ili zatvaranje tunela?

DMVPN čvorište s dva WAN-a prebacuje se na rezervni put na jedan od dva načina, a razlika je veća nego što izgleda. Jedan mijenja to koji sljedeći hop bira politika rute, pa paketi nastavljaju teći i mijenja se samo njihov izlaz. Drugi administrativno gasi tunel, što sa sobom obara svaku uslugu na tom interfejsu. Oba mogu biti ispravna, jer odgovaraju na različita pitanja.

Odluka dolazi prije konfiguracije

Tri uslova odlučuju ovo za vas. Zavisi li još nešto od toga da je interfejs tunela aktivan, poput drugog DMVPN profila ili monitora koji čita njegovo stanje? Nosi li saobraćaj koji se mora prebaciti vlastitu politiku ili se oslanja na globalnu tabelu rutiranja? I treba li operateru nepogrešiva promjena stanja, ili je tiho prebacivanje puta prihvatljivo? Odgovorite na ta tri i izbor se obično sam nametne.

Ako bi gašenje oborilo usluge koje su radile, politika rute je manja akcija. Ako je zahtjev da tunel ne smije postojati dok je primarni WAN pao, nijedan unos politike to ne može izraziti.

Zapišite odgovor, jer konfiguracija je lakši dio.

Šta politika rute zapravo mijenja

U rutiranju zasnovanom na politici, praćeni objekat može kontrolisati sljedeći hop. Unos u mapi ruta navodi kandidata za sljedeći hop i praćeni objekat koji mora biti aktivan da bi se koristio, a to stanje praćenja dolazi iz IP SLA sonde. Kada objekat padne, unos prestaje da se poklapa i paket se procjenjuje sljedećim unosom ili običnom tabelom rutiranja.

Ta posljednja pojedinost iznenađuje ljude: politika koja prestaje birati sljedeći hop obično dopušta normalno rutiranje umjesto da blokira saobraćaj. Ako vam treba crna rupa pri kvaru, morate je napisati.

Sintaksa se razlikuje među platformama i izdanjima, pa provjerite vodič za verziju koju zaista pokrećete.

Šta mijenja gašenje tunela

Gašenje interfejsa mijenja administrativno stanje. Svaki tunel, ruta i sesija koji od njega zavise padaju odjednom, što je tačno ono što želite ako tunel treba da nestane. Tako i EEM aplet pretvara problem WAN-a u ispad koji uključuje i nepovezane usluge.

Ako krenete tim putem, ograničite aplet na jedan interfejs i jedan okidač, sačuvajte prethodno administrativno stanje, definišite radnju oporavka i pobrinite se da ponovljeni flapping ne može da ga dovede u petlju.

Tvrdo kodirana komanda za oporavak također može nadjačati zatvaranje zbog održavanja koje je izveo neko drugi.

Neka sonda putuje putem koji mislite

Sonda koja prati trenutnu najbolju rutu prelazi na rezervni WAN zajedno sa svim ostalim, a zatim prijavljuje primarni kao zdrav jer ga više ne koristi.

Prikačite sondu na interfejs ili izvornu adresu puta koji testirate. Provjerite i šta cilja, jer dostizanje sljedećeg hopa provajdera dokazuje manje od dostizanja usluge zbog koje tunel postoji. Podesite kašnjenja podizanja i pada namjerno: kratko kašnjenje pada reaguje brzo i treperi, dok dugo podnosi kratke smetnje i skriva stvarne kvarove. Cisco vodič za praćenje i rutiranje po politici u IOS XE dokumentuje podržane kombinacije, a skup funkcija na vašoj platformi odlučuje koje od njih možete koristiti.

Zapišite obje vrijednosti kašnjenja pored praćenog objekta, inače niko neće znati zašto se ponašao tako.

Odlučite o oporavku, zatim provjerite

Oporavak zaslužuje vlastitu odluku. Veza koja stalno prelazi prag može premještati sesije češće od one koja je jasno otkazala, a svako premještanje košta ponovnu razmjenu ključeva i ponovne pokušaje aplikacije. Odaberite zahtjev za stabilnost i pustite kašnjenje da ga izrazi. Zatim provjerite u prozoru za promjene s vidljivim putem sonde: odabrana ruta, put vanjskog partnera i šta je aplikacija zaista uradila.

Ako prebacivanje radi, ali aplikacija se i dalje kvari, problem je iznad sloja rutiranja i nikakvo praćenje ga neće popraviti.

Sačuvajte dokaze iz tog prozora, jer će se sljedeća promjena porediti s njima.