OSPF или EIGRP поверх VTI на ASA: какую поддерживает ваша версия
OSPFv2 и EIGRP ходят поверх VTI на ASA только начиная с 9.19(1) и только с включённым multicast. Сравните оба на своей версии, а затем проверьте соседей.
Большинство споров OSPF против EIGRP исходят из того, что туннель уже умеет нести протокол, а на ASA именно это допущение и стоит проверить первым. Сравнение становится интересным только после того, как подтверждены образ, тип VTI и путь multicast. Ошибётесь с этим порядком — потратите полдня на настройку таймеров в туннеле, который никогда не сформирует соседство. Я начинаю каждый такой проект с примечаний к версии и текущей конфигурации, а не с предпочтения протокола.
Версия решает раньше протокола
Руководство Cisco по VTI для ASA 9.24 — годная документальная основа: в нём описаны статические и динамические VTI и перечислены статическая маршрутизация, BGP, OSPF и EIGRP. История функций относит поддержку OSPFv2 и EIGRP на VTI к версии 9.19(1). Всё, что старше, — другой разговор.
Итак, первые два вопроса скучны и решающи:
| Check | What decides it |
|---|---|
| Image and release | Whether the feature history lists OSPFv2 or EIGRP on VTI for the version you run |
| VTI type | Static or dynamic, and which routing context the platform permits |
| Multicast on the tunnel | Whether it is enabled, and whether the group limits are respected |
Утверждение, что 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, потому что именно эта деталь тихо решает, работает ли всё остальное. Держите эту запись рядом с развёрнутой версией, чтобы более позднее изменение функций можно было рассмотреть, не начиная заново с допущения, которое с тех пор истекло.
Если чего-то из этих четырёх не хватает, у вас есть предпочтение, а не проект. Сначала исправьте недостающий факт; выбор протокола — лёгкая часть.