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

En DMVPN-hub med to WAN-er svitsjer til backup på en av to måter, og forskjellen er større enn den ser ut. Den ene endrer hvilket neste hopp en rute-policy velger, slik at pakkene fortsetter å flyte og bare utgangen deres endres. Den andre stenger tunnelen administrativt, noe som tar ned hver tjeneste på det grensesnittet. Begge kan være riktige, fordi de svarer på forskjellige spørsmål.

Beslutningen kommer før konfigurasjonen

Tre betingelser avgjør dette for deg. Avhenger noe annet av at tunnelgrensesnittet er oppe, som en annen DMVPN-profil eller en monitor som leser tilstanden? Bærer trafikken som må svitsje over sin egen policy, eller stoler den på den globale rutetabellen? Og trenger operatøren en umiskjennelig tilstandsendring, eller er et stille banebytte akseptabelt? Svar på de tre, og valget tar seg vanligvis selv.

Hvis en stenging ville ta ned tjenester som fungerte, er rute-policyen den mindre handlingen. Hvis kravet er at tunnelen ikke skal finnes mens den primære WAN-en er nede, kan ingen policyoppføring uttrykke det.

Skriv ned svaret, for konfigurasjonen er den enkle delen.

Hva rute-policyen faktisk endrer

Med policybasert ruting kan et sporet objekt styre et neste hopp. Rute-kart-oppføringen navngir et kandidat-neste-hopp og det sporede objektet som må være oppe for at det skal brukes, og den sporingstilstanden kommer fra en IP SLA-probe. Når objektet går ned, slutter oppføringen å matche, og pakken vurderes av neste oppføring eller av den vanlige rutetabellen.

Den siste detaljen overrasker folk: en policy som slutter å velge neste hopp, tillater vanligvis normal ruting i stedet for å blokkere trafikk. Hvis du trenger et svart hull ved feil, må du skrive et.

Syntaksen er forskjellig på tvers av plattformer og versjoner, så sjekk veiledningen for versjonen du faktisk kjører.

Hva det endrer å stenge tunnelen

Å stenge et grensesnitt endrer administrativ tilstand. Hver tunnel, rute og sesjon som avhenger av det, går ned på en gang, som er nøyaktig det du vil hvis tunnelen er det som skal forsvinne. Det er også slik en EEM-applet gjør et WAN-problem til et avbrudd som omfatter urelaterte tjenester.

Hvis du går denne veien, begrens appletten til ett grensesnitt og én utløser, lagre forrige administrative tilstand, definer gjenopprettingshandlingen og sørg for at gjentatte flapper ikke kan drive den i loop.

En hardkodet gjenopprettingskommando kan også overstyre en vedlikeholdsstenging som noen andre har utført.

Få proben til å reise den veien du tror

En probe som følger den gjeldende beste ruten, flytter til backup-WAN-en sammen med alt annet og rapporterer deretter den primære som frisk fordi den ikke lenger bruker den.

Fest proben til grensesnittet eller kildeadressen til banen du tester. Sjekk også hva den sikter mot, siden det å nå leverandørens neste hopp beviser mindre enn å nå tjenesten tunnelen finnes for. Sett opp- og ned-forsinkelsene med vilje: en kort ned-forsinkelse reagerer raskt og flapper, mens en lang rider av på utsving og skjuler reelle feil. Ciscos veiledning for sporing og policy-ruting i IOS XE dokumenterer de støttede kombinasjonene, og funksjonssettet på plattformen din avgjør hvilke av dem du kan bruke.

Noter begge forsinkelsesverdiene ved siden av det sporede objektet, ellers vil ingen vite hvorfor det oppførte seg slik.

Bestem gjenoppretting, og verifiser deretter

Gjenoppretting fortjener sin egen beslutning. En lenke som stadig krysser terskelen, kan flytte sesjoner oftere enn en som tydelig har feilet, og hver flytting koster ny nøkkelutveksling og nye applikasjonsforsøk. Velg et stabilitetskrav og la forsinkelsen uttrykke det. Verifiser deretter i et endringsvindu med probens bane synlig: valgt rute, ytre peer-bane og hva applikasjonen faktisk gjorde.

Hvis failover fungerer, men applikasjonen fortsatt knekker, sitter problemet over rutelaget, og ingen mengde sporing vil rette det.

Ta vare på bevisene fra det vinduet, fordi den neste endringen vil bli sammenlignet med dem.