OSPF съседите не се формират през VPN? Проверете тези неща по ред

Тунелът е активен, интерфейсите са в една и съща подмрежа, а OSPF все още не показва нищо. В повечето случаи тунелът е наред и едно изискване на OSPF не е изпълнено. Изпълнете петте проверки по-долу по ред и спрете на първата, която се провали.

Всяка проверка има отделен симптом, затова редът е по-важен от списъка.

Проверка 1: правилен ли е моделът на връзката

Интерфейс точка-точка и споделена мрежа с множествен достъп са различни OSPF среди. Копирането на конфигурация за broadcast LAN върху тунел е най-честата грешка тук. Задайте типа мрежа, който реализацията на VPN поддържа, обикновено точка-точка за маршрутизиран тунел. След това потвърдете, че платформата е съгласна, защото някои реализации игнорират или преназначават настройката.

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

Проверка 2: пропускат ли се пакетите

OSPFv2 е IP протокол 89, а не TCP или UDP порт, затова правило в защитната стена, написано за портове, го отхвърля тихо. Hello съобщенията също отиват до multicast адреси, което дадена политика може да не разрешава. Разрешете протокол 89 между краищата на тунела, после проверете дали платформата изисква явни декларации за съсед.

Тунел, който пропуска само ping, е проблем на политика, а не на маршрутизация.

Проверка 3: съвпадат ли параметрите на съседа

Area ID, hello и dead интервалите, удостоверяването и флаговете stub трябва да съвпадат. Несъответствието обикновено оставя съседа във видимо състояние, вместо да се провали тихо, което е полезно. Сравнете работещата конфигурация от двете страни, а не предвидената.

Несъответствието в MTU е финият случай. То блокира обмена на базата данни при ExStart, така че съседът никога не достига Full.

Проверка 4: какво казва състоянието

Състоянието назовава отказа. Init означава, че hello съобщения пристигат, но този рутер не е изброен в тях, което сочи към еднопосочен път или проблем с multicast. Two-Way е нормално за broadcast сегмент със съсед, който не е DR, и ненормално за връзка точка-точка. Заседнали ExStart или Exchange означават проблем с MTU или с описанието на базата данни. Loading означава, че на link-state заявките не се отговаря.

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

show ip ospf neighbor показва състоянието, адреса на съседа и dead таймера. Сравнете този таймер с hello интервала от двете страни: dead интервал, четири пъти по-голям от hello, е нормален, всичко друго е несъответствие. Колоната за състояние е най-бързото четене на цялата страница.

Проверка 5: какво реално се анонсира

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

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

При IPv6 OSPFv3 има свои изисквания и не е превключвател на адресно семейство върху всяка настройка на OSPFv2. Използвайте съответния протокол и документацията на платформата. И ако връзката е едно фиксирано звено, сравнете статичните маршрути, преди да добавите контролен слой, който ще трябва да управлявате.