EIGRP-соседи не поднимаются на оверлее DMVPN

Unicast через оверлей работает, а смежность всё равно не устанавливается, поэтому проверяйте репликацию multicast в NHRP, политику EIGRP на туннеле и IPsec как три отдельных уровня.

Туннель поднят, один spoke может пинговать другой, а EIGRP по-прежнему не показывает ни одного соседа на hub. Такое сочетание нормально, а не загадочно: ping доказывает доступность unicast через NHRP, а hello-сообщения EIGRP передаются multicast. На оверлее DMVPN модель доставки протокола маршрутизации — это вторая плоскость конфигурации, и именно её люди пропускают, потому что первая плоскость уже выглядит здоровой. Каждый уровень ниже проверяется своей командой, поэтому сбой на одном не отправляет вас в начало списка.

Запишите смежности, которые ожидаете

Перед любой командой show составьте короткий список: какой spoke с каким hub должен установить peer, через какой туннельный интерфейс и в какой автономной системе EIGRP. Схемы с несколькими hub ломаются в промежутках между hub, и список превращает «EIGRP сломан» в «spoke 3 не регистрируется на hub 2». Включите туннельные подсети, которые ожидаете на каждом звене, потому что несовпадение адресов на двух концах выглядит в точности как сбой протокола. Запишите список в тикет, чтобы следующая смена сравнивала с проектом, а не с последним скриншотом.

Проверьте NHRP, затем путь multicast

Начните с состояния регистрации и привязок, которые hub действительно держит. Spoke без динамической записи на hub не зарегистрирован, и никакой протокол маршрутизации это не исправит. Затем подтвердите, что spoke принимает multicast с адреса NBMA хаба, а это отдельная строка от записи NHS.

show dmvpn
show ip nhrp
show ip nhrp nhs detail
interface Tunnel0
 ip nhrp network-id 1
 ip nhrp nhs 203.0.113.1 nbma 198.51.100.1
 ip nhrp map multicast 198.51.100.1
 tunnel mode gre multipoint
 tunnel key 100

Именно строка ip nhrp map multicast позволяет spoke отправлять свои hello на hub как реплицированный multicast через оверлей и позволяет multicast хаба доходить до зарегистрированных spoke. Без неё unicast через NHRP работает, а multicast нет, и именно это разделение заставляет ping выглядеть доказательством. Руководство Cisco IOS XE DMVPN описывает поведение multicast на hub и spoke для каждой фазы, поэтому согласуйте конфигурацию с той фазой, которую вы действительно развернули, а не копируйте фрагмент из другой топологии.

Проверьте собственную политику интерфейса EIGRP

Туннель, которого нет в процессе EIGRP или который пассивен, никогда не образует смежность, как бы здорово ни выглядел оверлей. Читайте участие интерфейса и таблицу соседей вместе, потому что первое объясняет второе.

show ip eigrp interfaces detail Tunnel0
show ip eigrp neighbors detail
show run | section router eigrp
router eigrp 100
 network 10.10.0.0 0.0.0.255
 passive-interface default
 no passive-interface Tunnel0

Аутентификация и веса метрики должны совпадать на обоих концах. Цепочка ключей с неверным режимом или несовпадение значения K отбрасывает hello без очевидной строки syslog у получателя. Если схема использует явно настроенных unicast-соседей, следуйте этой модели полностью, а не наслаивайте её поверх настроек multicast, пока что-нибудь не поднимется.

Держите транспорт GRE и защиту IPsec раздельно

DMVPN переносит multicast внутри GRE, а IPsec защищает пакеты GRE, а не внутренний multicast напрямую. Поэтому общее утверждение, что IPsec не может переносить multicast, для этой схемы неверно и бесполезно как диагностика. Проверьте профиль IPsec на туннеле, ассоциации безопасности для каждого peer и состояние туннельного интерфейса как три отдельных факта.

show crypto ipsec sa peer 198.51.100.1
show interfaces Tunnel0 | include line protocol
show ip nhrp multicast

SA, которая поднята и счётчики которой растут, пока EIGRP остаётся внизу, возвращает расследование выше по стеку: пакеты защищаются и доставляются, значит проблема в том, какие пакеты протокол выбирает для отправки.

Проверяйте маршруты, а не только число соседей

Как только смежность сформирована, прочитайте, что она анонсирует и устанавливает. На многоточечном туннеле split horizon и поведение next-hop решают, сможет ли spoke добраться до другого spoke через hub, а суммаризация может скрыть префикс даже при идеальных соседских отношениях.

Завершите разрешённым приложением между двумя площадками и подтвердите путь, который оно проходит. Прямые сокращения spoke-to-spoke — это требование пересылки с собственным состоянием NHRP и безопасности, и их добавление ради лучшего вида числа соседей обычно создаёт вторую проблему.

Запишите поэтапную схему, привязку multicast и политику EIGRP в одном месте. Следующему инженеру понадобится схема, а не стенограмма.

Похожие статьи