- PVSM.RU - https://www.pvsm.ru -
Привет! В этой статье я расскажу про интересные особенности протокола маршрутизации EIGRP.
Основы EIGRP отлично описаны в одной из статей цикла СДСМ: 6. Сети для самых маленьких. Часть шестая. Динамическая маршрутизация [1]
В первой половине статьи кратко описаны некоторые факты об этом протоколе, а во второй — несколько интересных примеров с топологией и командами.
А если 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).
Ну что, пора заняться практикой?
Про эту проблему в сетях вида Hub-and-Spoke (Frame Relay, DMVPN) + EIGRP написано почти в каждой книге. Так зачем про это рассказывать в очередной раз, да ещё и с примером, спросите вы? А давайте посмотрим внимательно, здесь очень легко можно угодить в ловушку. Рассмотрим следующую топологию Frame-Relay сети:
Скачать топологию со стартовыми файлами конфигурации для GNS3 можно здесь [3]. Используемый образ 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 можно здесь [4]. Используемый образ 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 [5] от 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:
Клёво, правда? :)
Надеюсь, что вам понравилось!
Автор: Sourg
Источник [6]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/news/61283
Ссылки в тексте:
[1] 6. Сети для самых маленьких. Часть шестая. Динамическая маршрутизация: http://habrahabr.ru/post/156695/
[2] драфт RFC: http://tools.ietf.org/html/draft-savage-eigrp-02
[3] здесь: http://yadi.sk/d/HgIJ9ss6RYTqX
[4] здесь: http://yadi.sk/d/IB5HikFiRYTpp
[5] EIGRP Troubleshoot Lab: http://gns3vault.com/troubleshooting/eigrp-troubleshooting/
[6] Источник: http://habrahabr.ru/post/224927/
Нажмите здесь для печати.