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 і пов'язані з ним налаштування рівня інтерфейсу.

Пастка — копіювати команди сусідів з іншої моделі тунелю. Поради про статичних сусідів у схемі без VTI існували, щоб уникнути multicast, і вони не переносяться на VTI, який має нести протокол нативно. Налаштуйте підтримувану поведінку інтерфейсу, а потім дайте протоколу самому сформувати сусідство.

Потім порівняйте за осями, які справді різняться у вашій топології: сумісність з іншою стороною, поведінка збіжності, яку можна перевірити, і операційні знання вашої команди. Історична байка про те, що один протокол швидший або легший, не є вимірюванням вашої мережі.

Сусіди не дорівнюють встановленим маршрутам

Коли сусідство піднято, відділіть те, що анонсується, від того, що приймається. Подивіться, які префікси філій оголошує кожна сторона, які приймаються, які обираються і які справді потрапляють до таблиці маршрутизації. Обсяг імпорту, експорту та перерозподілу має бути усвідомленим, а не суцільним анонсом усього, що знає пристрій.

show ospf neighbor і show eigrp neighbors кажуть вам, що сесія жива. show route каже, чи надійшов префікс філії, і це різні питання.

Шлях застосунку — знову третє питання. Відносини сусідства розподіляють доступність; вони не дають дозволу крізь міжмережевий екран і не доводять, що селектори трафіку та правила фільтрації узгоджені. Перевірте дозволений потік і зворотний шлях до нього схваленим тестом, замість того щоб припускати, що маршрут означає політику.

Що має зафіксувати завершене порівняння

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

Якщо чогось із цих чотирьох бракує, у вас є уподобання, а не проєкт. Спершу виправте відсутній факт; вибір протоколу — легка частина.