WAN-failover í DMVPN: stefna leiðar eða loka göngunni?

DMVPN-miðstöð með tvö WAN fer í varabúnað á einn af tveimur vegum, og munurinn er meiri en hann virðist. Önnur breytir því hvaða næsta hopp leiðarstefnan velur, svo pakkarnir halda áfram að streyma og aðeins útgangur þeirra breytist. Hin lokar göngunni stjórnunarlega, sem tekur hverja þjónustu á því viðmóti niður með sér. Báðar geta verið réttar, því þær svara ólíkum spurningum.

Ákvörðunin kemur á undan stillingunni

Þrjú skilyrði ákveða þetta fyrir þig. Er eitthvað annað háð því að gönguviðmótið sé virkt, eins og önnur DMVPN-snið eða vaktari sem les stöðu þess? Ber umferðin sem verður að fara í vara eigin stefnu, eða treystir hún á almenna leiðatöfluna? Og þarf stjórnandinn ótvíræða stöðubreytingu, eða er hljóðlát leiðaskipti ásættanleg? Svaraðu þessum þremur og valið gerir sig venjulega sjálft.

Ef lokun myndi taka niður þjónustu sem virkaði, er leiðarstefnan minni aðgerðin. Ef krafan er að göngin megi ekki vera til á meðan aðal-WAN er niðri, getur engin stefnufærsla lýst því.

Skrifaðu svarið niður, því stillingin er auðveldi hlutinn.

Hvað leiðarstefnan breytir í raun

Við stefnumiðaða leiðsögn getur rakið hlutur stjórnað næsta hoppi. Leiðarkortsfærslan nefnir frambjóðanda í næsta hopp og rakinn hlut sem verður að vera virkur til að hann sé notaður, og sú rakningastaða kemur frá IP SLA-prufu. Þegar hluturinn fer niður hættir færslan að passa og pakkinn er metinn af næstu færslu eða venjulegu leiðatöflunni.

Þessi síðasta smáatriði kemur fólki á óvart: stefna sem hættir að velja næsta hopp leyfir venjulega eðlilega leiðsögn í stað þess að loka umferð. Ef þú þarft svarthol þegar bilun verður, verður þú að skrifa eitt.

Setningafræðin er mismunandi eftir kerfum og útgáfum, svo skoðaðu leiðarvísinn fyrir þá útgáfu sem þú keyrir í raun.

Hvað lokun ganganna breytir

Að loka viðmóti breytir stjórnunarstöðu. Hver göng, leið og lota sem er háð því fer niður í einu, sem er einmitt það sem þú vilt ef göngin eru hluturinn sem á að hverfa. Þannig breytir EEM-forrit WAN-vandamáli í niðurföll sem nær til ótengdra þjónustu.

Ef þú ferð þessa leið skaltu takmarka forritið við eitt viðmót og eitt kveikju, vista fyrri stjórnunarstöðu, skilgreina endurheimtaraðgerð og tryggja að endurtekin flökt geti ekki keyrt það í lykkju.

Harðkóðuð endurheimtarskipun getur líka hnekkt viðhaldslokun sem einhver annar framkvæmdi.

Láttu prufuna ferðast þá leið sem þú heldur

Prufa sem fylgir bestu leiðinni núna flyst yfir á varagöngin með öllu öðru og tilkynnir síðan að aðalleiðin sé heilbrigð því hún notar hana ekki lengur.

Festu prufuna við viðmótið eða upprunaaðsetur leiðarinnar sem þú ert að prófa. Athugaðu líka hvað hún miðar á, því að ná næsta hoppi þjónustuveitunnar sannar minna en að ná þjónustunni sem göngin eru til fyrir. Stilltu upp- og niðurtefðirnar viljandi: stutt niðurtefðin bregst hratt við og flöktir, en löng þolir skammvinnar truflanir og felur raunverulegar bilanir. Leiðarvísir Cisco um rakningu og stefnumiðaða leiðsögn í IOS XE skrásetur studdu samsetningarnar, og eiginleikamengið á þínu kerfi ræður því hverra þú getur notað.

Skráðu bæði tefðigildin við hlið rakna hlutarins, annars mun enginn vita hvers vegna hann hagaði sér þannig.

Ákveddu endurheimt og staðfestu síðan

Endurheimt á skilið eigin ákvörðun. Tengill sem fer stöðugt yfir þröskuldinn getur flutt lotur oftar en sá sem hefur greinilega bilað, og hver flutningur kostar endursamningu lykla og endurteknar tilraunir forritsins. Veldu stöðugleikakröfu og láttu tefðina lýsa henni. Staðfestu síðan í breytingaglugga með leið prufunnar sýnilega: valin leið, leið ytri jafningja og hvað forritið gerði í raun.

Ef failover virkar en forritið brotnar samt, liggur vandamálið ofan við leiðsagnarlagið og engin rakning mun laga það.

Geymdu sönnunargögnin úr þeim glugga, því næsta breyting verður borin saman við þau.