Почему EIGRP не работает. Соседи, пропавшие маршруты и зависший пересчёт

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

Диагностику удобнее строить вокруг конкретного симптома и одного проблемного префикса. Сначала проверьте соседство, затем распространение маршрута, выбор пути и пересылку пакетов. При долгом восстановлении после обрыва отдельно измерьте время обнаружения отказа и время пересчёта.

Примеры ниже относятся к IPv4 EIGRP на Cisco IOS и IOS XE. Конфигурационные фрагменты используют классический режим с номером автономной системы 100. В named mode параметры находятся внутри address-family, af-interface и topology. Названия интерфейсов, доступные команды и отдельные поля вывода зависят от платформы и версии ПО. Если сеть работает в VRF, все проверки нужно выполнять в соответствующем экземпляре маршрутизации.

Как быстро определить направление поиска

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

Что наблюдается	Что проверять первым
Соседа нет	Связность интерфейсов, включение EIGRP, AS, K-коэффициенты, аутентификацию и доставку пакетов
Сосед постоянно исчезает	Причину разрыва в журнале, потери, очереди и подтверждения пакетов
Сосед стабилен, префикс отсутствует в топологии	Объявление сети, фильтры, суммаризацию и ограничения распространения
Префикс есть в топологии, но выбран другой маршрут	Состояние EIGRP-маршрута и конкурирующий источник того же префикса
Трафик идёт неожиданным путём	Длину префикса, тип маршрута, метрику, распределение нагрузки и политики
После отказа маршрут долго остаётся в Active	Готовый резерв и соседей, от которых ожидаются ответы

Перед изменениями сохраните исходную картину. На крупном маршрутизаторе запрашивайте конкретный префикс вместо полного вывода всех маршрутов.

show ip eigrp neighbors
 show ip protocols
 show ip eigrp topology 10.20.30.0 255.255.255.0
 show ip route 10.20.30.0 255.255.255.0
 show logging

Соседство не устанавливается

Шаг 1. Проверьте соединение и участие интерфейса в EIGRP

show ip interface brief
 show interfaces GigabitEthernet0/0
 show ip interface GigabitEthernet0/0
 show ip eigrp interfaces
 show running-config interface GigabitEthernet0/0
 show running-config | section router eigrp

Для обычного Ethernet-соединения проверьте состояние up/up, общий VLAN и согласованную адресацию в одной подсети. Убедитесь, что смотрите правильную VRF. Выполните ping до адреса соседа с исходным адресом проверяемого интерфейса, чтобы случайно не проверить другой путь.

Затем установите, включён ли EIGRP на интерфейсе. Команда network выбирает локальные интерфейсы по IP-адресам. Запись удалённой сети в network не заставляет маршрутизатор объявлять маршрут, которого у маршрутизатора нет.

Например, следующий фрагмент выбирает интерфейс с локальным адресом 192.0.2.1 и разрешает соседство на GigabitEthernet0/0.

router eigrp 100
  network 192.0.2.1 0.0.0.0
  no passive-interface GigabitEthernet0/0

Нулевая wildcard-маска здесь выбирает точный адрес интерфейса. Подключённая сеть объявляется с маской самого интерфейса, а не автоматически превращается в маршрут /32.

Шаг 2. Сопоставьте настройки соседства

На обоих устройствах должны совпадать номер AS и совместимые параметры расчёта метрики, прежде всего K-коэффициенты. Если включена аутентификация, сопоставьте способ аутентификации и действующие ключи. Для key chain проверьте сроки отправки и приёма ключей, а также время на устройствах.

В named mode сравнивайте номер autonomous-system внутри нужного address-family. Локальные названия процессов могут различаться. Само сочетание classic mode на одном устройстве и named mode на другом не означает несовместимость.

Проверьте passive-interface и административное отключение EIGRP в соответствующем режиме конфигурации. Пассивный интерфейс не формирует соседство, но подключённая сеть может объявляться через другие интерфейсы. Поэтому passive-interface на пользовательской LAN часто настроен намеренно.

Как исправить. Восстановите предусмотренные проектом AS, K-коэффициенты и параметры аутентификации. Снимайте passive-interface только с транзитного соединения, где должен работать сосед. Не меняйте K-коэффициенты всей сети ради попытки поднять одну связь.

Шаг 3. Проверьте прохождение EIGRP

EIGRP работает непосредственно поверх IP с номером протокола 88. Правило для TCP или UDP с портом 88 не разрешает такой обмен. Для обычного динамического соседства IPv4 нужны multicast-пакеты на 224.0.0.10, а также unicast между соседями, который используется в служебном обмене.

Проверьте ACL на интерфейсах, промежуточную фильтрацию и ограничения трафика к управляющему процессору. Разрешённый ICMP не доказывает, что EIGRP проходит. В захвате пакетов удобно использовать фильтр отображения Wireshark eigrp или ip.proto == 88.

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

Есть менее очевидная причина. Команда neighbor для статического соседа меняет обмен на соответствующем интерфейсе и в типичных реализациях IOS отключает там динамический multicast-обмен EIGRP. После добавления одного статического соседа могут исчезнуть остальные динамические соседи этого сегмента. Проверьте, не смешали ли два способа построения соседства.

Сосед появляется и снова исчезает

Сначала найдите причину разрыва в журнале. Истечение Hold, превышение числа повторных передач и административное отключение требуют разных действий.

show ip eigrp neighbors detail
 show ip eigrp traffic
 show interfaces GigabitEthernet0/0
 show logging

Следите за Uptime и Q Cnt. Постоянно сбрасывающийся Uptime подтверждает нестабильность. Q Cnt показывает очередь пакетов EIGRP, ожидающих отправки или подтверждения. Краткий всплеск во время обмена допустим, устойчивая очередь вместе с повторными передачами указывает на проблему.

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

Интервалы Hello и Hold не обязаны совпадать между соседями. Каждый маршрутизатор сообщает соседу Hold Time, в течение которого следует считать отправителя доступным. Изменять таймеры имеет смысл после проверки потерь, иначе агрессивные интервалы могут усилить нестабильность.

Как исправить. Устраните конкретные потери, неверную фильтрацию или перегрузку, затем убедитесь, что очередь освобождается, а Uptime растёт без сбросов. Однократное появление строки в таблице соседей недостаточно.

Сосед есть, но нужного маршрута нет

Шаг 1. Найдите источник префикса

Выберите точную сеть, например 10.20.30.0/24, и начните с маршрутизатора, который должен её объявлять.

show ip route 10.20.30.0 255.255.255.0
 show ip eigrp topology 10.20.30.0 255.255.255.0
 show ip protocols

Если сеть подключена напрямую, проверьте состояние интерфейса и включение в EIGRP. Если маршрут должен поступать из OSPF, статической конфигурации или другого источника, проверьте redistribution, условия route-map и начальную метрику. Не для всех источников действуют одинаковые правила назначения метрики, поэтому универсальная команда default-metric наугад здесь не подходит.

Как исправить. Восстановите исходный маршрут, включите нужный локальный интерфейс в EIGRP либо исправьте правила перераспределения и требуемую метрику. Затем убедитесь, что префикс появился в топологии самого отправителя.

Шаг 2. Найдите участок, где объявление исчезает

Проверяйте префикс последовательно на соседних маршрутизаторах. На границе между последним устройством, где маршрут есть, и первым, где отсутствует, изучите исходящий и входящий distribute-list, используемые prefix-list и route-map.

show ip protocols
 show ip prefix-list
 show route-map
 show access-lists

Не путайте фильтрацию пакетов с фильтрацией маршрутов. Интерфейсный ACL может мешать самому обмену EIGRP. Prefix-list, подключённый через distribute-list, может запрещать отдельный префикс при полностью исправном соседстве.

Например, правило permit 10.20.0.0/16 в prefix-list разрешает точный /16, но не все входящие подсети. Если требуется разрешить только 10.20.30.0/24, добавьте точное разрешение перед подходящим запрещающим правилом. Используйте ge и le только для действительно нужного диапазона длин масок.

Шаг 3. Проверьте суммаризацию, split horizon и stub

Отсутствие /24 не всегда означает потерю связности. Сосед может получать агрегат /16, через который адрес назначения остаётся доступным. Сначала проверьте маршрут до конкретного IP-адреса.

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

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

Stub ограничивает категории объявляемых маршрутов и сообщает соседям, что устройство не следует использовать для поиска транзитных путей. Если филиал должен передавать трафик между другими сегментами, проверьте, соответствует ли настройка stub фактической роли маршрутизатора.

Шаг 4. Если префикс получен, проверьте его состояние и конкурентов

Убедитесь, что маршрут находится в Passive и имеет пригодный следующий переход. Для просмотра дополнительных путей используйте show ip eigrp topology all-links. Затем сравните источники одного и того же префикса в общей таблице маршрутизации.

По умолчанию внутренняя EIGRP имеет административную дистанцию 90, внешняя 170, OSPF 110, обычный статический маршрут 1. Поэтому внешний EIGRP-маршрут может уступить OSPF, хотя соседство и распространение работают правильно. Метрики разных протоколов напрямую не сравниваются.

Как исправить. Удалите ошибочный статический маршрут или скорректируйте предусмотренную политику выбора. Изменение административной дистанции требует проверки всех затронутых направлений.

Трафик выбирает неожиданный путь

Шаг 1. Проверьте конкретное назначение и источник трафика

show ip route 10.20.30.10
 show ip cef 10.20.30.10 detail
 show ip policy

При обычной маршрутизации пакет использует наиболее специфичный подходящий префикс. Маршрут /24 выигрывает у /16 независимо от административной дистанции этих двух записей. Дистанция помогает выбирать источники одинакового префикса.

Если запись выглядит правильно, проверьте policy-based routing на входящем интерфейсе, соответствующую VRF и обратный путь. Ping, запущенный с маршрутизатора, может использовать другой исходный адрес и проходить иначе, чем трафик пользовательского компьютера.

Шаг 2. Сравните тип и метрику EIGRP-маршрутов

Внутри одного EIGRP-процесса внутренний маршрут к префиксу предпочтительнее внешнего независимо от их метрик. При нескольких точках перераспределения сначала выясните происхождение путей и лишь затем сравнивайте численные значения.

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

show ip eigrp topology 10.20.30.0 255.255.255.0
 show interfaces GigabitEthernet0/0
 show interfaces GigabitEthernet0/1
 show ip protocols

Проверьте настроенные bandwidth и delay, особенно на туннелях, а также offset-list. Значение bandwidth не меняет физическую скорость порта, но влияет на расчёты. Исправляйте ошибочные параметры с учётом остальных протоколов и механизмов, которые используют те же значения.

При wide metrics численные значения отличаются от классических метрик, а метрика в таблице маршрутизации может отображаться после масштабирования. Сравнивайте пути в одном контексте и смотрите составляющие метрики, прежде чем объявлять расхождение ошибкой.

Шаг 3. Проверьте распределение нагрузки

Несколько следующих переходов могут появиться из-за равных метрик или настройки variance. Проверьте также maximum-paths. Для неравноценной балансировки недостаточно увеличить variance, дополнительный путь должен удовлетворять условию допустимости EIGRP.

Один traceroute показывает лишь отдельную последовательность проб. Чтобы оценить фактическое распределение, сопоставьте таблицу пересылки и счётчики интерфейсов при нескольких потоках.

После обрыва связь долго не восстанавливается

Разделите время простоя на обнаружение отказа и выбор нового пути. Если физический интерфейс сразу переходит в down, маршрутизатор получает прямой сигнал. Если удалённый участок отказал, а локальный порт остался up, обнаружение может занять время до истечения Hold или срабатывания другого механизма контроля.

Сопоставьте отметки времени в журнале с моментом обрыва. Если задержка возникает до исчезновения соседа, изучайте обнаружение отказа. BFD может ускорить реакцию там, где поддерживается и настроен для соответствующего соединения, но не устраняет проблемы последующего пересчёта.

Если сосед исчез быстро, проверьте резервный путь. Feasible successor позволяет выбрать допустимый запасной путь без распределённого поиска. Для этого объявленная соседом дистанция RD должна быть строго меньше локальной FD.

FD хранит минимальную дистанцию с момента последнего перехода маршрута из Active в Passive и не обязана совпадать с текущей метрикой лучшего пути. Например, при FD 10000 сосед с RD 9000 проходит проверку, а с RD 10000 уже нет. Полная локальная метрика пути через соседа при этом может быть выше FD.

Невыполнение условия не доказывает наличие петли. У маршрутизатора просто нет достаточной гарантии, чтобы выбрать путь без согласованного пересчёта. Поэтому второй канал и даже второй путь в all-links ещё не гарантируют немедленного переключения.

Маршрут завис в Stuck in Active

Passive означает, что маршрут не требует распределённого пересчёта. Active означает, что DUAL ищет согласованный путь и ожидает ответы на запросы Query. Кратковременное состояние Active допустимо. Stuck in Active возникает, когда обязательный обмен не завершается в предусмотренные механизмом сроки.

show ip eigrp topology active
 show ip eigrp neighbors detail
 show ip eigrp traffic
 show logging
 show processes cpu sorted
 show interfaces GigabitEthernet0/0

1. Найдите префикс и ожидаемые ответы. В выводе topology active посмотрите длительность Active и соседей с незавершённым Reply. Сохраните вывод до сброса соседства.
2. Проследите цепочку ожидания. На соответствующем соседе проверьте тот же префикс. Маршрутизатор может ждать ответа от следующего устройства, поэтому первый адрес в сообщении об ошибке не обязательно указывает на первопричину.
3. Проверьте доставку. Сопоставьте захваты на обоих концах подозрительного участка. Установите, приходит ли Query, отправляется ли Reply и получает ли отправитель подтверждения.
4. Проверьте ресурсы. Изучите ошибки и отбрасывания, загрузку CPU, доступную память и устойчивые очереди. Исправное соседство не исключает потери отдельных служебных пакетов.
5. Оцените распространение запросов. Если пересчёт регулярно вовлекает большую часть сети, пересмотрите границы суммаризации и применение stub на нетранзитных узлах.

SIA-Query и SIA-Reply помогают отличить молчащего соседа от маршрутизатора, который продолжает пересчёт. SIA-Reply не заменяет окончательный ответ на исходный Query. Поэтому утверждение «ровно через три минуты EIGRP всегда сбрасывает соседа» чрезмерно упрощает поведение протокола.

Как исправить. Устраните найденные потери, ограничения обработки или перегрузку. Если причина связана с архитектурой, ограничьте ненужное распространение запросов. Увеличение active-time не исправляет потерянные ответы и может лишь продлить простой.

Как убедиться, что причина устранена

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

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