Отказ на WAN при DMVPN: политика за маршрутизация или затваряне на тунела?

Хъб на DMVPN с два WAN преминава към резервен път по един от два начина и разликата е по-голяма, отколкото изглежда. Единият променя кой следващ хоп избира политиката за маршрутизация, така че пакетите продължават да текат и се променя само изходът им. Другият затваря тунела административно, което сваля заедно с него всяка услуга на този интерфейс. И двата могат да са правилни, защото отговарят на различни въпроси.

Решението идва преди конфигурацията

Три условия решават това вместо вас. Зависи ли нещо друго от това интерфейсът на тунела да е активен, например втори профил на DMVPN или монитор, който чете състоянието му? Носи ли трафикът, който трябва да премине към резерва, собствена политика или разчита на глобалната таблица за маршрутизация? И има ли операторът нужда от недвусмислена промяна на състоянието, или е приемливо тихо превключване на пътя? Отговорете на тези три и изборът обикновено се прави сам.

Ако затварянето би свалило работещи услуги, политиката за маршрутизация е по-малкото действие. Ако изискването е тунелът да не съществува, докато основният WAN не работи, нито един запис в политиката не може да изрази това.

Запишете отговора, защото конфигурацията е лесната част.

Какво всъщност променя политиката за маршрутизация

При маршрутизация, базирана на политика, проследяван обект може да управлява следващ хоп. Записът в маршрутната карта посочва кандидат за следващ хоп и проследявания обект, който трябва да е активен, за да се използва, а това състояние на проследяване идва от сонда на IP SLA. Когато обектът падне, записът спира да съвпада и пакетът се оценява от следващия запис или от обикновената таблица за маршрутизация.

Тази последна подробност изненадва хората: политика, която спира да избира следващ хоп, обикновено разрешава нормална маршрутизация, вместо да блокира трафика. Ако ви трябва черна дупка при отказ, трябва да я напишете.

Синтаксисът се различава между платформите и изданията, затова проверете ръководството за версията, която действително използвате.

Какво променя затварянето на тунела

Затварянето на интерфейс променя административното състояние. Всеки тунел, маршрут и сесия, които зависят от него, падат наведнъж, което е точно това, което искате, ако тунелът е нещото, което трябва да изчезне. Така също аплет на EEM превръща проблем с WAN в прекъсване, което включва и несвързани услуги.

Ако поемете по този път, ограничете аплета до един интерфейс и един тригер, запазете предишното административно състояние, дефинирайте действието за възстановяване и се уверете, че повторните флапове не могат да го задвижат в цикъл.

Твърдо кодирана команда за възстановяване може също да отмени затваряне за поддръжка, извършено от някой друг.

Накарайте сондата да минава по пътя, който мислите

Сонда, която следва текущия най-добър маршрут, се премества към резервния WAN заедно с всичко останало и след това съобщава основния като здрав, защото вече не го използва.

Закрепете сондата към интерфейса или адреса на източника на пътя, който тествате. Проверете също какво атакува, тъй като достигането до следващия хоп на доставчика доказва по-малко от достигането до услугата, за която съществува тунелът. Задайте закъсненията за вдигане и падане умишлено: краткото закъснение за падане реагира бързо и флапа, докато дългото понася смущенията и скрива истински откази. Ръководството на Cisco за проследяване и маршрутизация по политики в IOS XE документира поддържаните комбинации и наборът от функции на вашата платформа решава кои от тях можете да използвате.

Запишете двете стойности на закъснението до проследявания обект, иначе никой няма да знае защо се е държал така.

Решете възстановяването, после проверете

Възстановяването заслужава собствено решение. Връзка, която постоянно пресича прага, може да мести сесии по-често от такава, която явно е отказала, и всяко преместване струва преподмяна на ключове и повторни опити на приложението. Изберете изискване за стабилност и нека закъснението го изрази. След това проверете в прозорец за промени с видим път на сондата: избран маршрут, път на външния партньор и какво всъщност е направило приложението.

Ако отказът работи, но приложението все още се чупи, проблемът е над слоя за маршрутизация и никакво проследяване няма да го поправи.

Пазете доказателствата от този прозорец, защото следващата промяна ще се сравнява с тях.