Особенности протокола EIGRP

Данную статью написал наш читатель и слушатель Дмитрий Фиголь специально для linkmeup.
==================================

Привет! В этой статье я расскажу про интересные особенности протокола маршрутизации EIGRP.
Основы EIGRP отлично описаны в одной из статей цикла СДСМ: 6. Сети для самых маленьких. Часть шестая. Динамическая маршрутизация
В первой половине статьи кратко описаны некоторые факты об этом протоколе, а во второй — несколько интересных примеров с топологией и командами.

Факты про EIGRP


  • В феврале 2013 года Cisco решила открыть EIGRP. Стоит отметить, что был открыт не исходный код, а лишь информация, необходимая для реализации протокола. В итоге появился драфт RFC. Последнее обновление 10.04.2014. В этом документе не была раскрыта ключевая особенность — Stub, без которой пользоваться протоколом практически бесполезно. Интересна реакция других вендоров: на сегодняшний день никто, кроме Cisco, не внедрил поддержку этого протокола в своём оборудовании.
  • EIGRP для расчёта метрики использует 5 K-values, которые являются лишь модификаторами (коэффициентами), и 4 значения метрики. Надёжность (reliability) и загрузка линка (load) являются динамическими параметрами, поэтому эти значения пересчитываются только при изменении в сети. K5 — это дополнительный коэффициент надёжности, и никакого отношения к MTU он не имеет! Напомню общую формулу расчёта метрики:

    А если K5 = 0, то формула имеет такой вид:



    где min_bandwidth — это пропускная способность наихудшего линка в kbps,
    а total_delay — это сумма задержек всех линков в мкс (микросекундах).
    Для изменения метрики обычно меняют delay, так как bandwidth влияет на QoS, кроме этого, изменение bandwidth не всегда меняет метрику (если наихудший линк не изменился).
    Минимальное значение MTU действительно подсчитывается, но не принимает никакой роли в определении лучшего пути. В своей топологии в GNS3 я тестировал несколько десятков раз с помощью команд redistribute connected metric и maximum-paths 1. Несмотря на различное значение MTU, лучший путь выбирается тот, который был изучен ранее. Также интересно, что в драфте RFC упоминается дополнительный коэффициент K6 и 2 дополнительных значения метрики: джиттер (jitter) и энергия (energy).
  • Feasibility Condition не всегда легко понять в первый раз. Но логика очень простая: если ты говоришь мне, что у тебя метрика больше, чем метрика моего лучшего пути, значит есть шанс, что твой путь проходит через меня, что в свою очередь означает петлю. Из-за этого часто очевидные для инженера «пути-без-петли» могут не рассматриваются протоколом как feasible successors. Помните, EIGRP не видит всей сети — а лишь то, что говорят соседи.
  • EIGRP — Distance Vector протокол, никакой гибридности в нём нет.
  • С помощью show ip eigrp neighbors detail можно посмотреть, является ли сосед тупиковым (stub) роутером.
  • Помните, с помощью команды show ip eigrp topology видны лишь successors и feasible successors. Чтобы посмотреть все возможные пути, необходимо добавить ключевое слово «all-links»: show ip eigrp topology all-links.
  • В IOS 15 наконец-то отключена по умолчанию автоматическая суммаризация, ура! Прощай, команда no auto-summary!
  • Значения таймеров (Hello и Hold) могут быть неодинаковыми. Кстати, значение таймера Hold передаётся соседу и означает: «если в течение X секунд ты от меня не получишь Hello, значит я больше недоступен».
  • EIGRP использует свой транспортный протокол (IP protocol number: 88) — RTP (Reliable Transport Protocol). Не стоит путать его с другим известным протоколом Real-time Transport Protocol (тоже RTP), который используется для передачи потоков реального времени, например, VoIP (в связке с SIP). EIGRP также использует мультикаст адрес: 224.0.0.10. Не забывайте во входящем ACL разрешать EIGRP трафик, например, с помощью записи: permit eigrp any any.
  • Из-за различных значений административной дистанции (AD) для внутренних (90) и внешних (170) маршрутов EIGRP позволяет избежать некоторых проблем при редистрибьюции (redistribution).
  • Помните, что 2 роутера могут быть соседями, и при этом у них может не быть adjacency. С помощью команды show ip eigrp neighbors показываются все соседи, а для того, чтобы узнать, является ли сосед смежным (adjacent), необходимо убедиться, что значение в поле Q Cnt равно 0.
  • EIGRP кроме суммарного маршрута может отправить и конкретный специфический маршрут. Эта особенность называется EIGRP Leak Map. Это полезно, если мы хотим сделать traffic engineering. Идея очень похожая на bgp unsuppress-map. Для этого необходимо применить команду: ip summary-address eigrp as-number summary-address summary-mask leak-map leak-map-route-map.

Ну что, пора заняться практикой?


EIGRP Split Horizon


Про эту проблему в сетях вида Hub-and-Spoke (Frame Relay, DMVPN) + EIGRP написано почти в каждой книге. Так зачем про это рассказывать в очередной раз, да ещё и с примером, спросите вы? А давайте посмотрим внимательно, здесь очень легко можно угодить в ловушку. Рассмотрим следующую топологию Frame-Relay сети:

Скачать топологию со стартовыми файлами конфигурации для GNS3 можно здесь. Используемый образ IOS: c3640-jk9s-mz.124-16.bin

Ничего особенного правда? 2 виртуальных соединения (PVC), одна общая сеть 192.168.123.0/24, работает всё на физических интерфейсах, а не на саб-интерфейсах. На каждом роутере также настроен Loopback адрес. EIGRP включён на всех интерфейсах.
Посмотрим таблицу маршрутизации на хабе R1:



У R1 есть маршруты ко всем сетям. А теперь на споуке R2:



У R2 почему-то нет маршрута к сети 3.3.3.0/24.
Вы наверняка уже мысленно кричите: «Да что тут такого? Очевидно, что необходимо отключить split horizon на интерфейсе s0/0 роутера R1!»
Давайте проверим с помощью команды show ip interface s0/0:



???
И в этот момент можно легко растеряться. Это ведь была отличная догадка!
Но я всё же попробую команду no ip split-horizon eigrp 100:



А теперь проверим таблицу маршрутизации:



О! Появился маршрут.
Проверим пинг:



Пингуется, всё отлично.
Так в чём же дело? Почему команда show ip interface s0/0 показала, что split horizon отключён, если на самом деле он был включён? Ответ прост. Эта строка говорит лишь о том, что split horizon выключен для протокола RIP.
А как тогда посмотреть для EIGRP? Вообще-то никак, кроме наличия строки в текущей конфигурации:



Кстати, в IOS 15 появилась возможность это проверить с помощью команды show ip eigrp interfaces detail s0/0.
Вот такая интересная особенность.

Но, наверное, вся статья задумывалась исключительно ради следующего примера.

EIGRP Router-ID


Рассмотрим внимательно топологию:


Скачать файл топологии с начальной конфигурацией для GNS3 можно здесь. Используемый образ IOS: c3640-jk9s-mz.124-16.bin.


4 роутера, 2 роутинг домена: OSPF area 0 и EIGRP AS 100. Роутер R1 выполняет редистрибьюцию в обе стороны. Loopback0 R1 анонсирован в домен EIGRP, Loopback1 R1 не анонсирован никуда.
Давайте посмотрим на таблицу маршрутизации роутера R2:



Отлично, маршруты к ospf сетям 172.16.x.0/24 видны, как D EX (EIGRP External, AD 170).
А теперь на таблицу маршрутизации R3:



???
А где маршруты к ospf сетям?
Давайте глянем на соседей R1:



Всё нормально, правда? И потом, R3 ведь видит другие EIGRP маршруты: например, 2.2.2.0/24 и 1.1.1.0/24. Следующим шагом было бы логично посмотреть роут-мепы на R1 и R2. Но в данном примере я их не использовал. Если не знать в чём причина, то отдебажить данную проблему трудно. Поэтому давайте посмотрим в чём дело. На R1 и R3 используем команду show ip eigrp topology:




Да, проблема в одинаковых eigrp router-id. Есть одна замечательная, спрятанная в IOS, команда (не видна с помощью "?"), которая поможет понять, что происходит: show ip eigrp events на R3.


[Данная команда может помочь и при других проблемах с EIGRP]

Мы видим, что R3 всё же получает маршруты к сетям 172.16.x.0/24, но отбрасывает их из-за дубликата router-id.
Оказывается, что в общем случае EIGRP всё равно, какие router-id у вас в AS. Ровно до тех пор, пока на одном из роутеров с одинаковым router-id не настроена редистрибьюция. Тогда инжектированные маршруты получают специальную метку с router-id роутера, который сделал редистрибьюцию. Если роутер получает маршрут с такой меткой и видит, что его router-id совпадает, то такой маршрут отбрасывается. Router-id определяется также, как и в OSPF: специальной командой или наивысший Loopback адрес, или наивысший IP адрес, если нет Loopback.
В данном случае на роутере R1 есть Loopback1: 11.11.11.11, а на R3 была использована команда eigrp router-id 11.11.11.11. Отменим её с помощью ключевого слова no и проверим таблицу маршрутизации снова:



Маршруты появились, проблема решена!



В реальной сети гораздо более вероятно, что на двух роутерах могут быть случайно настроены одинаковые Loopback адреса. Никогда не слышав о данной проблеме, траблшутинг может превратиться в увлекательное занятие и потрепать немало нервов.
Если вы чувствуете, что знаете EIGRP достаточно хорошо, то я рекомендую попробовать EIGRP Troubleshoot Lab от GNS3Vault.

Бонус! Key Chain


Это мало относится к EIGRP, но из троицы протоколов маршрутизации EIGRP, OSPF, BGP лишь EIGRP использует key chain для аутентификации. Key chain позволяет использовать разные ключи в разное время. К примеру, можно бесшовно сменить пароль аутентификации EIGRP, не обвалив «adjacency». Но посмотрим мы на немного другое. У этого механизма есть интересная особенность. Наверняка все знают, что команда service password-encryption использует взламываемый алгоритм (Type 7). В интернете можно найти много сайтов, которые восстановят пароль из такого хеша. Но, оказывается, что можно заставить сам роутер восстановить пароль. Давайте, я покажу как. Сначала создаём пользователя с паролем в локальной базе данных и включаем service password-encryption:



Смотрим running config и копируем значение хеша:



Теперь создаём key chain, номер ключа и вводим этот хеш:



А теперь используем команду show key chain:



Клёво, правда? :)

Надеюсь, что вам понравилось. Ведь в таком случае в скором времени появится похожая статья про OSPF!

==================================
Блог автора: dmitryfigol.blogspot.ru
  • 1
  • 0
  • 8422

12 комментариев

avatar
Замечу, зато OSPF как раз можно считать гибридным. Intra-area — Link State, Inter-area — Distance Vector :)
avatar
Тогда уж и IS-IS туда же.
avatar
Ну раз уж вспомнили про IS-IS, то замечу, что он также поддерживает key chain аутентификацию Пруф.

Не поленился собрать лабу в GNS с одинаковыми router-id. Действительно, для EIGRP router-id даже у соседей может быть одинаковый. Очень странное решение со стороны cisco. OSPF не позволяет напрямую установить соседство между роутерами с одинаковыми RId, но про этом внутри одной area совершенно спокойно могут совершенно спокойно сосуществовать одинаковые. Нет, конечно, при этом в консоль оба будут ругаться, но никаких ошибок и разорванных соседств.

Мне кажется, что EIGRP придумывался по принципу — чем меньше конфига для соседства — тем лучше. На минуточку условия соседства OSPF:
1. Subnet mask used on the subnet.
2. Subnet number ( as derived using the subnet mask and each router's interface IP address)
3. Hello Interval
4. Dead Interval
5. OSPF area ID
6. Authentication
7. MTU

В EIGRP только AS-номер и аутентификация. Как будто в пику OSPF писали.
avatar
С одинаковыми Router ID в OSPF тоже можно лиха хлебнуть. К сожалению, не опишу механизм проблемы, но у меня уже была ситуация, когда маршруты флапались сотнями каждую секунду. Причина была именно в этом.

Ну и ISIS, да, несправедливо исключили из списка)
avatar
Не люблю упоминать то, что не знаю (IS-IS). Но доберусь и до него на пути к CCIE ;)
Насколько я помню, в OSPF при дубликате RID в консоль ошибки сыпятся, разве нет?
У EIGRP с этим хуже — он просто молчит.
avatar
Да, вы правы. OSPF действительно ругается в консоль на тех устройствах, если RId совпадает в пределах одной area (кстати, я уже писал об этом). В EIGRP все немного проще. Поле originating router заполняется только в том случае, если у вас есть внешние маршруты (как на примере в статье). Остальные маршруты пойдут без происхождения. Грозит это только тем, что у вас пропадут внешние маршруты на одном роутере (на котором RId совпадает с тем, кто анонсит внешние маршруты). При этом, если у вас 10 роутеров, то вы четко увидите, что на 9-ти из них внешние маршруты есть, а на 10-м нет. Тут-то и должна прийти мысль. В случае, если одинаковые RId на рядовых роутерах (без внешних маршрутов), то никаких проблем с этим у вас возникнуть не должно (по идее). С OSPF немного сложнее (см. пост ниже).
avatar
В OSPF возможны две ситуации. Когда одинаковые RId в пределах одной area — тогда все не так уж и плохо. Два роутера просто не будут видеть сетки друг друга (срабатывает аналог правила split horizon — дропай маршруты, если RId такой же как и у тебя). В случае, когда одинаковые RId в разных area, то тут все будет намного интереснее (сдается мне, что это как раз ваш случай). ABR был несколько удивлен, когда к нему с разных сторон приходили маршруты с одного RId. Вот и приходилось бедняге на каждый hello пакет пересчитывать SPF и рассылать всем Summary LSA 3.
avatar
Я думаю именно так и было. Хотя, конечно встретить сеть с количеством OSPF-зон больше одной довольно сложно). Гораздо чаще деление по процессам.
avatar
EIGRP ведь тоже проверяет network/mask.
Ещё K-values забыли.
avatar
Да, точно, забыл про них. Интересно, есть ли хоть один хардкорщик, который на реальной сетке менял K-value?
avatar
Кстати, маска подсети может и не совпадать.
комментарий был удален
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.