Привет! В этой статье я расскажу про интересные особенности протокола маршрутизации EIGRP.
Основы EIGRP отлично описаны в одной из статей цикла СДСМ: 6. Сети для самых маленьких. Часть шестая. Динамическая маршрутизация.
В первой половине статьи кратко описаны некоторые факты об этом протоколе, а во второй — несколько интересных примеров с топологией и командами.
Ну что, пора заняться практикой?
Про эту проблему в сетях вида 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.
Вот такая интересная особенность.
Но, наверное, вся статья задумывалась исключительно ради следующего примера.
Рассмотрим внимательно топологию:
Скачать файл топологии с начальной конфигурацией для 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.
Это мало относится к 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:
Клёво, правда? :)
Надеюсь, что вам понравилось!
Основы 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 показываются лишь соседи. В выводе этой команды стоит обратить внимание на поле Q Cnt: если там не ноль, то вполне возможно, что у вас есть проблема в сети (например, неустановленное adjacency).
- 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.
- Как верно добавил alk0v, в отличие от OSPF, EIGRP поддерживает балансировку нагрузки при разной метрике (unequal cost load balancing). Для этого необходимо использовать команду variance. Стоит помнить две вещи: это работает только для successors/feasible successors и, по умолчанию, CEF выполняет балансировку per-destination. Последнее значит, что 2 пакета, у которых соответствующие IP адреса отправителя и получателя одинаковые, всегда будут выходить из одного и того же интерфейса, что заметно усложняет проверку. Если вы всё же хотите это проверить, то можно переключить CEF в режим per-packet (в режиме конфигурации интерфейса используйте команду ip load-sharing per-packet) или вообще его отключить (команда no ip cef в глобальном конфигурационном режиме, не рекомендуется).
Ну что, пора заняться практикой?
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:
Клёво, правда? :)
Надеюсь, что вам понравилось!
