Сосед EIGRP или транзит DMVPN? Сначала проверьте роль

Соседства нет, и маршрутизатор посередине выглядит очевидным подозреваемым. Возможно, он невиновен. Пересылка внешних пакетов туннеля и участие в протоколе маршрутизации overlay — две разные задачи, и устройство может выполнять первую, не выполняя вторую. Пройдите пять проверок ниже по порядку и остановитесь на первой неудачной.

Шаг 1: нарисуйте две роли

Нарисуйте предполагаемое соседство EIGRP как логическое соединение между двумя маршрутизаторами, затем нарисуйте маршрутизаторы underlay, которые переносят его пакеты туннеля. Одно и то же устройство не обязано быть в обоих списках, и путаница в списках — самая частая причина, по которой исправный транзитный маршрутизатор обвиняют в поломке соседства.

Транзитный маршрутизатор пересылает внешние пакеты своей обычной маршрутизацией IP и политикой. Ему не нужно запускать протокол, переносимый внутри защищённого туннеля, и не нужен процесс EIGRP, чтобы передавать эти пакеты дальше.

Шаг 2: проверьте, что завершает среднее устройство

Если средний маршрутизатор завершает туннель и должен формировать соседства EIGRP со spoke, ответ меняется полностью. Этому устройству нужно поддерживаемое поведение маршрутизации overlay, и название «транзит» не снимает требование соседства. Прочитайте конфигурацию туннеля раньше конфигурации маршрутизации. Этот ответ определяет каждую следующую проверку.

Итак, первый настоящий вопрос — не какой протокол настраивать. Вопрос в том, является ли коробка hub, spoke, чистым переходом underlay или службой Layer 2, которая переносит кадры между оконечными точками.

Шаг 3: проверьте плоскость управления соседа

На каждом устройстве, которое должно быть соседом, подтвердите четыре вещи: экземпляр EIGRP и номер автономной системы, параметры аутентификации, интерфейс, участвующий в процессе, и сетевую команду, покрывающую этот интерфейс. Несовпадение любого из них удерживает соседство внизу, пока интерфейс остаётся поднятым и ping продолжает работать.

RFC 7868 описывает EIGRP как протокол IP с многоадресным обменом управления, поэтому соседские отношения — не то, что промежуточный маршрутизатор может подменить, маршрутизируя пакеты к месту назначения. Либо обмен управления доходит до партнёра, либо соседство не формируется.

Шаг 4: проверьте, что транспорт доставляет обмен управления

Далее проверьте, действительно ли overlay переносит управляющий трафик между предполагаемыми оконечными точками. Изучите отображение NHRP для партнёра и внешний маршрут, который к нему ведёт, затем подтвердите, что интерфейс туннеля поднят и пропускает трафик. Успешный ping underlay доказывает, что внешний путь существует; он не доказывает, что обмен управления overlay был доставлен.

Прозрачная служба Layer 2, туннель «точка — точка» и многоточечное облако DMVPN доставляют многоадресный трафик по-разному. Следуйте поддерживаемой модели интерфейса, NHRP и многоадресной рассылки для того, что действительно развёрнуто, вместо предположения, что все три ведут себя одинаково.

Шаг 5: перепроектируйте границу, если она не может участвовать

Если требуемое устройство overlay не может запускать протокол, измените проект явно. Используйте на этой границе поддерживаемый протокол или модель обмена либо организуйте подходящий сквозной туннель, чтобы соседями были оконечные точки, которые действительно общаются друг с другом. Не предполагайте, что статический маршрут превращает неучастника в ретранслятор каждого управляющего пакета.

Запишите роль каждого устройства на схеме и храните её вместе с конфигурацией. RFC 7868 определяет обмен протокола, и это определение служит ориентиром для понимания того, почему соседские отношения нельзя имитировать транзитной пересылкой.

Если соседство не поднимается и после всех пяти проверок, оставшиеся подозреваемые — функции платформы, такие как обработка многоадресного трафика на интерфейсе туннеля и политика, фильтрующая протокол 88. Это конкретные, проверяемые причины, и они ценнее очередного круга обвинений в адрес маршрутизатора посередине.