OSPF или EIGRP през VTI на ASA: кое поддържа вашата версия

Повечето спорове OSPF срещу EIGRP приемат, че тунелът вече може да пренася протокола, а на ASA точно това допускане е частта, която си струва да се провери първа. Сравнението става интересно едва след като бъдат потвърдени образът, типът VTI и multicast пътят. Сгрешете ли този ред, ще прекарате следобеда в настройка на таймери по тунел, който никога няма да образува съседство. Започвам всеки от тези проекти с бележките за версията и текущата конфигурация, а не с предпочитанието за протокол.

Версията решава преди протокола

Ръководството на Cisco за VTI на ASA 9.24 е използваема документална база: описва статични и динамични VTI и изброява статично маршрутизиране, BGP, OSPF и EIGRP. Историята на функциите поставя поддръжката на OSPFv2 и EIGRP върху VTI при 9.19(1). Всичко по-старо от това е друг разговор.

И така, първите два въпроса са скучни и решаващи:

Твърдението, че ASA не може да използва VTI или не може да пренася IGP, е било вярно за някои по-стари образи и не е актуална матрица за поддръжка. По същия начин ръководството за 9.24 не е указание да се обновява всяко устройство. То ви казва какво поддържа тази версия, а внедрената ви версия трябва да отговаря сама за себе си.

Преминаването на unicast не означава, че IGP ще се образува

Същото ръководство отбелязва, че unicast преминава по подразбиране и че multicast трябва да бъде включен за OSPFv2 или EIGRP върху VTI, с документирани ограничения за multicast групи. Това едно изречение обяснява повечето неуспешни съседства, които съм виждал при този дизайн. Работещ ping през тунела или зелен статус на IPsec доказва само unicast пътя. Откриването на протокола се нуждае от multicast пътя и двете се конфигурират отделно.

Проверете конфигурацията на тунелния интерфейс за тази multicast настройка, преди да пипате hello или hold таймерите. Ако настройката липсва, съседството не е бавно, то е невъзможно.

OSPF и EIGRP един до друг върху един и същ тунел

Върху самия тунел двата протокола изглеждат както навсякъде другаде. OSPF се нуждае от подходящ тип мрежа, зона, удостоверяване и параметри за съседи; EIGRP се нуждае от своя AS номер и настройките на интерфейсно ниво, които вървят с него.

Капанът е копирането на neighbor оператори от друг модел тунел. Съветите за статични съседи при дизайн без VTI са съществували, за да се избегне multicast, и не се пренасят към VTI, от който се очаква да пренася протокола естествено. Конфигурирайте поддържаното поведение на интерфейса и след това оставете протокола да образува съседството си сам.

После сравнете по осите, които наистина се различават за вашата топология: съвместимост с другата страна, поведение на сходимост, което можете да тествате, и оперативните знания в екипа ви. Исторически анекдот за това, че един протокол е по-бърз или по-лек, не е измерване на вашата мрежа.

Съседите не са равни на инсталираните маршрути

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

show ospf neighbor и show eigrp neighbors ви казва, че сесията е жива. show route ви казва дали префиксът на клона е пристигнал, и това са различни въпроси.

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

Какво трябва да запише завършеното сравнение

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

Ако липсва някое от тези четири, имате предпочитание, а не дизайн. Първо поправете липсващия факт; изборът на протокол е лесната част.