Тунелът стои, маршрутът изчезна: как да разделим два отказа на VPN
Един префикс може да бъде получен, избран и инсталиран на три различни етапа. Прочетете първо таблицата за препращане, после таблицата на протокола, после часовниците.
Един хост става недостъпен, докато интерфейсът на тунела все още се отчита като установен, и двете наблюдения не си противоречат. Нещо премахна пътя, който трафикът използваше: съсед оттегли своя префикс, проследяван статичен маршрут беше премахнат или друг маршрут стана предпочитан. Асоциацията за сигурност може да остане напълно здрава през трите случая. Разделянето на събитията означава да попитаме кой слой се промени пръв, а не дали VPN е отказал.
Три етапа, които изглеждат като едно събитие
Маршрутното решение има три етапа. Префиксът се получава, избира се като най-добър и се инсталира в таблицата за препращане. Всеки етап може да се провали сам, а отказът изглежда еднакво от страна на приложението. Префикс, който е бил научен, но е загубил избора, е неразличим от такъв, който никога не е пристигнал, когато единственото доказателство, което гледате, е таблицата за препращане.
Затова първият въпрос е кой етап се е счупил, а не кой протокол е виновен. Отговорът решава кой притежава инцидента и кой инструмент използва следващата проверка.
Прочетете първо инсталирания маршрут
Попитайте ядрото накъде всъщност отива трафикът към отказалата дестинация. ip route get отпечатва следващия хоп, интерфейса и адреса на източника, който ядрото би използвало, и отговаря за една дестинация, а не за цялата таблица. Ако отговорът посочва тунела, таблицата за препращане все още вярва, че пътят съществува, и проблемът е над нея.
ip route get 10.20.5.10
ip route show 10.20.0.0/16
Отговор „unreachable“ означава, че няма никакъв инсталиран маршрут, което сочи към оттегляне или липсваща инсталация. Отговор, който посочва физически интерфейс, означава, че трафикът е напуснал тунела, без някой да е решил това, и следващата проверка е предпочитанието, което е спечелило. Отговор, който посочва тунела, докато пакетите продължават да изчезват, сочи по-нататък по пътя, към филтриране или към отсрещната страна.
После погледнете собствения изглед на протокола
Маршрутният демон поддържа повече от една таблица и интересното сравнение е между тях. За BGP състоянието на съседната сесия, полученото обявление и инсталираният маршрут са три отделни доказателства. Един префикс може да стои в получената таблица и никога да не стигне до ядрото, защото маршрут с по-малко административно разстояние печели. Проверете и трите, преди да заключите, че другата страна е спряла да обявява.
vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"
Обобщението ви казва дали сесията е установена, изгледът по префикс — дали префиксът е приет, а търсенето в ядрото — дали е инсталиран. Четенето им в този ред не позволява трептенето на сесията да се сбърка с оттегляне, а оттеглянето — с отказ по политика.
Когато часовниците не съвпадат
Поставете лога на тунела, маршрутния лог и първия отказ на приложението на една времева линия, използвайки реалните им часови зони. Ако загубата на съсед е първа, тунелът е свалил маршрута заедно със себе си. Ако оттеглянето е първо, маршрутизацията се е променила, а тунелът е реагирал след това. Това са различни инциденти с различни собственици и редът е цялата находка.
Една минута разминаване на часовниците е достатъчна, за да обърне това заключение, затова потвърдете часовата зона и отместването, преди да се доверите на последователността. Устройствата, които водят лог в местно време без отместване, са обичайният източник на уверена, но грешна времева линия.
Възстановяване без цикъл
След оттегляне два пътя могат да бъдат допустими: този, който протоколът избира, и този, който закрепвате на ръка. Само първият е решение, което мрежата продължава да взема вместо вас, затова ръчният маршрут е временно решение, а не план за възстановяване. Алтернативното обявление също не запазва състоянието на защитната стена или NAT за вече установена сесия, така че новите потоци може да работят, докато първоначалният остава счупен. Потвърдете кой резервен път трябва да стане активен и дали отдалеченият сайт ще приеме обратен път през него.
Не инсталирайте постоянно статично заместване, преди да разберете защо се е случило оттеглянето. Този пряк път може да прикове трафика към отказал път или тихо да заобиколи умишлена маршрутна политика и погребва първоначалната причина под нова конфигурация. Тествайте отново приложението, след като маршрутът е възстановен, и потвърдете, че избраният префикс има работещ път за данни, а не само запис в таблица.