Пребацивање WAN-а у DMVPN-у: политика руте или затварање тунела?

DMVPN чвориште са два WAN-а прелази на резервни пут на један од два начина, а разлика је већа него што изгледа. Један мења који следећи хоп бира политика руте, тако да пакети настављају да теку и мења се само њихов излаз. Други административно затвара тунел, што са собом обара сваку услугу на том интерфејсу. Оба могу бити тачна, јер одговарају на различита питања.

Одлука долази пре конфигурације

Три услова одлучују ово за вас. Да ли још нешто зависи од тога да је интерфејс тунела активан, као други DMVPN профил или монитор који чита његово стање? Да ли саобраћај који мора да се пребаци носи сопствену политику или се ослања на глобалну табелу рутирања? И да ли је оператеру потребна недвосмислена промена стања, или је прихватљиво тихо пребацивање пута? Одговорите на та три и избор се обично сам наметне.

Ако би затварање оборило услуге које су радиле, политика руте је мања акција. Ако је захтев да тунел не постоји док је примарни WAN доле, ниједан унос политике то не може изразити.

Запишите одговор, јер конфигурација је лакши део.

Шта политика руте заиста мења

У рутирању заснованом на политици, праћени објекат може да контролише следећи хоп. Унос у мапи рута именује кандидата за следећи хоп и праћени објекат који мора бити активан да би се користио, а то стање праћења долази из IP SLA сонде. Када објекат падне, унос престаје да се поклапа и пакет процењује следећи унос или обична табела рутирања.

Тај последњи детаљ изненађује људе: политика која престаје да бира следећи хоп обично дозвољава нормално рутирање уместо да блокира саобраћај. Ако вам је потребна црна рупа при отказу, морате сами да је напишете.

Синтакса се разликује међу платформама и издањима, зато проверите водич за верзију коју заиста покрећете.

Шта мења затварање тунела

Затварање интерфејса мења административно стање. Сваки тунел, рута и сесија које од њега зависе падају одједном, што је тачно оно што желите ако је тунел оно што треба да нестане. Тако и EEM аплет претвара проблем са WAN-ом у прекид који укључује и неповезане услуге.

Ако кренете тим путем, ограничите аплет на један интерфејс и један тригер, сачувајте претходно административно стање, дефинишите радњу опоравка и уверите се да поновљени флапови не могу да га уведу у петљу.

Чврсто кодирана команда за опоравак може такође да поништи затварање због одржавања које је извео неко други.

Нека сонда путује путем који мислите

Сонда која прати тренутну најбољу руту прелази на резервни WAN заједно са свим осталим, а затим пријављује примарни као здрав јер га више не користи.

Причврстите сонду на интерфејс или изворну адресу пута који тестирате. Проверите и шта циља, јер достизање следећег хопа провајдера доказује мање од достизања услуге због које тунел постоји. Подесите кашњења подизања и пада намерно: кратко кашњење пада реагује брзо и флапује, док дуго подноси кратке сметње и скрива стварне отказе. Cisco водич за праћење и рутирање по политици у IOS XE документује подржане комбинације, а скуп функција на вашој платформи одлучује које од њих можете да користите.

Запишите обе вредности кашњења поред праћеног објекта, иначе нико неће знати зашто се понашао тако.

Одлучите о опоравку, затим проверите

Опоравак заслужује сопствену одлуку. Веза која стално прелази праг може да премешта сесије чешће од оне која је јасно отказала, а свако премештање кошта поновно уговарање кључева и поновљене покушаје апликације. Изаберите захтев за стабилношћу и пустите кашњење да га изрази. Затим проверите у прозору за промене са видљивим путем сонде: изабрана рута, пут спољног партнера и шта је апликација заиста урадила.

Ако пребацивање ради, али апликација се и даље квари, проблем је изнад слоја рутирања и никакво праћење га неће поправити.

Сачувајте доказе из тог прозора, јер ће се следећа промена поредити са њима.