DMVPN WAN-failover: Itinera politiko aŭ fermi la tunelon?

DMVPN-habo kun du WAN-oj plusekvas unu el du manieroj, kaj la diferenco estas pli granda ol ĝi ŝajnas. Unu ŝanĝas, kiun sekvan halton itinera politiko elektas, do pakaĵoj daŭre fluas kaj nur ilia eliro ŝanĝiĝas. La alia administre fermas la tunelon, kio faligas kune kun ĝi ĉiun servon sur tiu interfaco. Ambaŭ povas esti ĝustaj, ĉar ili respondas al malsamaj demandoj.

La decido venas antaŭ la agordo

Tri kondiĉoj decidas tion por vi. Ĉu io alia dependas de tio, ke la tunela interfaco estu aktiva, ekzemple dua DMVPN-profilo aŭ monitoro, kiu legas ĝian staton? Ĉu la trafiko, kiu devas plusekvi, portas sian propran politikon, aŭ ĝi fidas la ĝeneralan itineran tabelon? Kaj ĉu la operatoro bezonas nekonfuzeblan statŝanĝon, aŭ ĉu kvieta vojŝanĝo estas akceptebla? Respondu tiujn tri kaj la elekto kutime faras sin mem.

Se fermo faligus servojn, kiuj funkciis, la itinera politiko estas la pli malgranda ago. Se la postulo estas, ke la tunelo ne ekzistu dum la ĉefa WAN estas neaktiva, neniu politika ero povas esprimi tion.

Skribu la respondon, ĉar la agordo estas la facila parto.

Kion la itinera politiko fakte ŝanĝas

Ĉe politik-bazita itinero, spurada objekto povas regi sekvan halton. La itiner-mapa ero nomas kandidatan sekvan halton kaj la spuratan objekton, kiu devas esti aktiva por ke ĝi uziĝu, kaj tiu spurstato venas de IP SLA-sondilo. Kiam la objekto falas, la ero ĉesas kongrui kaj la pakaĵo estas taksata de la sekva ero aŭ de la ordinara itinera tabelo.

Tiu lasta detalo surprizas homojn: politiko, kiu ĉesas elekti sekvan halton, kutime permesas normalan itineradon anstataŭ bloki trafikon. Se vi bezonas nigran truon ĉe fiasko, vi devas skribi ĝin.

La sintakso diferencas inter platformoj kaj eldonoj, do kontrolu la gvidilon por la versio, kiun vi efektive rulas.

Kion ŝanĝas fermo de la tunelo

Fermi interfacon ŝanĝas la administran staton. Ĉiu tunelo, itinero kaj sesio, kiuj dependas de ĝi, falas samtempe, kio estas ĝuste tio, kion vi volas se la tunelo estas la afero, kiu devas malaperi. Tiel ankaŭ EEM-aplikaĵeto transformas WAN-problemon en paneon, kiu inkluzivaserilatajn servojn.

Se vi iras tiun vojon, limigu la aplikaĵeton al unu interfaco kaj unu ellasilo, konservu la antaŭan administran staton, difinu la reakiran agon kaj certigu, ke ripetaj fluktuoj ne povas puŝi ĝin en buklon.

Malmole programita reakra komando povas ankaŭ superi bontenadan fermon, kiun faris iu alia.

Igu la sondilon vojaĝi laŭ la vojo, kiun vi pensas

Sondilo, kiu sekvas la nunan plej bonan itineron, moviĝas al la rezerva WAN kune kun ĉio alia, kaj poste raportas la ĉefan kiel sanan, ĉar ĝi ne plu uzas ĝin.

Fiksu la sondilon al la interfaco aŭ fontadreso de la vojo, kiun vi testas. Kontrolu ankaŭ, kion ĝi celas, ĉar atingi la sekvan halton de la provizanto pruvas malpli ol atingi la servon, por kiu la tunelo ekzistas. Agordu la supren- kaj malsupren-prokrastojn konscie: mallonga malsupren-prokrasto reagas rapide kaj fluktuas, dum longa eltenas etajn batetojn kaj kaŝas verajn fiaskojn. La gvidilo de Cisco pri spurado kaj politik-bazita itinerado en IOS XE dokumentas la subtenatajn kombinojn, kaj la funkciaro sur via platformo decidas, kiujn el ili vi povas uzi.

Notu ambaŭ prokrastajn valorojn apud la spurata objekto, alie neniu scios, kial ĝi kondutis tiel.

Decidu pri restarigo, poste kontrolu

Restarigo meritas propran decidon. Ligo, kiu senĉese transiras la sojlon, povas movi sesiojn pli ofte ol unu, kiu klare fiaskis, kaj ĉiu movo kostas reŝlosiladon kaj ripetojn de la aplikaĵo. Elektu stabilec-postulon kaj lasu la prokraston esprimi ĝin. Poste kontrolu dum ŝanĝa fenestro kun videbla sondila vojo: elektita itinero, vojo de la ekstera kunulo kaj kion la aplikaĵo efektive faris.

Se la plusekvo funkcias sed la aplikaĵo ankoraŭ rompiĝas, la problemo sidas super la itinera tavolo kaj neniu kvanto da spurado riparos ĝin.

Konservu la pruvojn el tiu fenestro, ĉar la sekva ŝanĝo estos komparata kun ili.