DMVPN WAN-failover: rute-policy eller stengje tunnelen?

Ein DMVPN-hub med to WAN svitsjar til reserve på ein av to måtar, og skilnaden er større enn han ser ut. Den eine endrar kva neste hopp ein rute-policy vel, slik at pakkane held fram med å flyte og berre utgangen deira blir endra. Den andre stengjer tunnelen administrativt, noko som tek ned kvar teneste på det grensesnittet. Begge kan vere riktige, fordi dei svarar på ulike spørsmål.

Avgjerda kjem før konfigurasjonen

Tre vilkår avgjer dette for deg. Er noko anna avhengig av at tunnelgrensesnittet er oppe, som ein annan DMVPN-profil eller ein monitor som les tilstanden? Ber trafikken som må svitsje over sin eigen policy, eller stoler han på den globale rutetabellen? Og treng operatøren ei umiskjenneleg tilstandsendring, eller er eit stille banebytte akseptabelt? Svar på dei tre, og valet tek seg vanlegvis sjølv.

Viss ei stenging ville teke ned tenester som fungerte, er rute-policyen den mindre handlinga. Viss kravet er at tunnelen ikkje skal finnast medan den primære WAN-en er nede, kan ingen policyoppføring uttrykkje det.

Skriv ned svaret, for konfigurasjonen er den enkle delen.

Kva rute-policyen faktisk endrar

Med policybasert ruting kan eit spora objekt styre eit neste hopp. Rute-kart-oppføringa namngjev eit kandidat-neste-hopp og det spora objektet som må vere oppe for at det skal bli brukt, og den sporingstilstanden kjem frå ein IP SLA-probe. Når objektet går ned, sluttar oppføringa å matche, og pakken blir vurdert av neste oppføring eller av den vanlege rutetabellen.

Den siste detaljen overraskar folk: ein policy som sluttar å velje neste hopp, tillèt vanlegvis normal ruting i staden for å blokkere trafikk. Viss du treng eit svart hol ved feil, må du skrive eit.

Syntaksen er ulik på tvers av plattformer og versjonar, så sjekk rettleiinga for versjonen du faktisk køyrer.

Kva det endrar å stengje tunnelen

Å stengje eit grensesnitt endrar administrativ tilstand. Kvar tunnel, rute og sesjon som er avhengig av det, går ned på ein gong, som er nøyaktig det du vil viss tunnelen er det som skal forsvinne. Det er også slik ein EEM-applet gjer eit WAN-problem til eit avbrot som omfattar urelaterte tenester.

Viss du går denne vegen, avgrens appletten til eitt grensesnitt og éin utløysar, lagre førre administrative tilstand, definer gjenopprettingshandlinga og sørg for at gjentekne flapp ikkje kan drive han i loop.

Ein hardkoda gjenopprettingskommando kan også overstyre ei vedlikeholdsstenging som nokon andre har utført.

Få proben til å reise den vegen du trur

Ein probe som følgjer den gjeldande beste ruta, flyttar til reserve-WAN-en saman med alt anna og rapporterer deretter den primære som frisk fordi han ikkje lenger brukar henne.

Fest proben til grensesnittet eller kjeldeadressa til ruta du testar. Sjekk også kva han siktar mot, sidan det å nå neste hopp hos leverandøren beviser mindre enn å nå tenesta tunnelen finst for. Set opp- og ned-forsinkelsane med vilje: ein kort ned-forsinkelse reagerer raskt og flappar, medan ein lang rid av på utsving og skjuler reelle feil. Ciscos rettleiing for sporing og policy-ruting i IOS XE dokumenterer dei støtta kombinasjonane, og funksjonssettet på plattforma di avgjer kva av dei du kan bruke.

Noter begge forsinkingsverdiane ved sida av det spora objektet, elles vil ingen vite kvifor det oppførte seg slik.

Avgjer gjenoppretting, og verifiser deretter

Gjenoppretting fortener si eiga avgjerd. Ei lenke som stadig kryssar terskelen, kan flytte sesjonar oftare enn ei som tydeleg har feila, og kvar flytting kostar ny nøkkelutveksling og nye applikasjonsforsøk. Vel eit stabilitetskrav og la forsinkelsen uttrykkje det. Verifiser deretter i eit endringsvindauge med banen til proben synleg: vald rute, bane til ytre partnar og kva applikasjonen faktisk gjorde.

Viss failover fungerer, men applikasjonen framleis knekk, sit problemet over rutelaget, og inga mengd sporing vil rette det.

Ta vare på prova frå det vindauget, fordi den neste endringa vil bli samanlikna med dei.