En DMVPN-hub med to WAN'er skifter til backup på en af to måder, og forskellen er større, end den ser ud. Den ene ændrer, hvilket næste hop en rute-politik vælger, så pakkerne fortsætter med at flyde, og kun deres udgang ændres. Den anden lukker tunnelen administrativt, hvilket tager enhver tjeneste på det interface ned med sig. Begge kan være rigtige, fordi de svarer på forskellige spørgsmål.

Beslutningen kommer før konfigurationen

Tre betingelser afgør dette for dig. Afhænger noget andet af, at tunnel-interfacet er oppe, såsom en anden DMVPN-profil eller en monitor, der læser dets tilstand? Bærer trafikken, der skal skifte over, sin egen politik, eller stoler den på den globale routingtabel? Og har operatøren brug for en umiskendelig tilstandændring, eller er et stille ruteskift acceptabelt? Svar på de tre, og valget træffer normalt sig selv.

Hvis en nedlukning ville tage tjenester ned, der virkede, er rute-politikken den mindre handling. Hvis kravet er, at tunnelen ikke må eksistere, mens den primære WAN er nede, kan ingen politikpost udtrykke det.

Skriv svaret ned, for konfigurationen er den nemme del.

Hvad rute-politikken faktisk ændrer

Med politikbaseret routing kan et sporet objekt styre et næste hop. Rute-map-posten navngiver et kandidat-næste-hop og det sporede objekt, der skal være oppe, for at det bruges, og den sporingstilstand kommer fra en IP SLA-probe. Når objektet går ned, holder posten op med at matche, og pakken vurderes af den næste post eller af den almindelige routingtabel.

Den sidste detalje overrasker folk: en politik, der holder op med at vælge et næste hop, tillader normalt normal routing i stedet for at blokere trafik. Hvis du har brug for et sort hul ved fejl, må du skrive et.

Syntaksen er forskellig på tværs af platforme og versioner, så tjek guiden for den version, du faktisk kører.

Hvad det ændrer at lukke tunnelen

At lukke et interface ændrer den administrative tilstand. Hver tunnel, rute og session, der afhænger af det, går ned på én gang, hvilket er præcis, hvad du vil, hvis tunnelen er det, der skal forsvinde. Det er også sådan en EEM-applet gør et WAN-problem til et udfald, der omfatter urelaterede tjenester.

Hvis du går den vej, skal du begrænse appletten til ét interface og én trigger, gemme den forrige administrative tilstand, definere gendannelseshandlingen og sikre, at gentagne flips ikke kan drive den i loop.

En hårdkodet gendannelseskommando kan også tilsidesætte en vedligeholdelsesnedlukning, som en anden har udført.

Få proben til at rejse ad den vej, du tror

En probe, der følger den aktuelle bedste rute, flytter til backup-WAN'en sammen med alt andet og rapporterer derefter den primære som sund, fordi den ikke længere bruger den.

Fastgør proben til interfacet eller kildeadressen på den vej, du tester. Tjek også, hvad den sigter mod, da det at nå udbyderens næste hop beviser mindre end at nå den tjeneste, som tunnelen findes for. Sæt op- og ned-forsinkelserne med vilje: en kort ned-forsinkelse reagerer hurtigt og flapper, mens en lang rider af på udsving og skjuler reelle fejl. Ciscos guide til sporing og politik-routing i IOS XE dokumenterer de understøttede kombinationer, og funktionssættet på din platform afgør, hvilke af dem du kan bruge.

Notér begge forsinkelsesværdier ved siden af det sporede objekt, ellers vil ingen vide, hvorfor det opførte sig sådan.

Beslut gendannelse, og verificér derefter

Gendannelse fortjener sin egen beslutning. Et link, der hele tiden krydser tærsklen, kan flytte sessioner oftere end et, der tydeligt er fejlet, og hver flytning koster ny nøgleudveksling og gentagne applikationsforsøg. Vælg et stabilitetskrav, og lad forsinkelsen udtrykke det. Verificér derefter i et ændringsvindue med probens vej synlig: valgt rute, ydre peer-vej og hvad applikationen faktisk gjorde.

Hvis failover virker, men applikationen stadig brækker, sidder problemet over routinglaget, og ingen mængde sporing vil rette det.

Gem beviserne fra det vindue, fordi den næste ændring vil blive sammenlignet med dem.

Relaterede artikler