DMVPN WAN префрлање: рутирачка политика или затворање на тунелот?

DMVPN центар со два WAN преминува на резервен пат на еден од два начина, а разликата е поголема отколку што изгледа. Едниот го менува следниот скок што го избира рутирачката политика, така што пакетите продолжуваат да течат и се менува само нивниот излез. Другиот административно го затвора тунелот, што ги спушта со него сите услуги на тој интерфејс. И двата можат да бидат точни, бидејќи одговараат на различни прашања.

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

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

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

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

Што всушност менува рутирачката политика

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

Овој последен детаљ ги изненадува луѓето: политиката што престанува да избира следен скок обично дозволува нормално рутирање наместо да го блокира сообраќајот. Ако ви треба црна дупка при отказ, мора сами да ја напишете.

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

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

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

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

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

Направете сондата да патува по патот што го мислите

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

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

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

Одлучете за обновувањето, потоа проверете

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

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

Зачувајте ги доказите од тој прозорец, бидејќи следната промена ќе се споредува со нив.