EIGRP Lab | EIGRP Lab — Answers
Продолжим изучение лаб для экзамена ROUTE курса CCNP.
Я думал объединить ответы на задачки прошлой лабы с лабой по OSPF, но этот топик и без того получается настолько большим, что, боюсь, как бы его все дочитали до конца. Здесь будет очень много конфигов, скриншотов из Wireshark и дебрей технологии, но все это только для того, чтобы лучше проиллюстрировать внутреннюю логику EIGRP, без понимания которой этот экзамен сдать невозможно.
Будущие, бывшие и настоящие CCNP, добро пожаловать под кат!
Предлагаю, проходясь по пунктам лабы, рассматривать все возможные варианты и причины, а не идти целенаправленно к известному выводу. Одну и ту же неполадку может вызвать несколько вещей, и, так или иначе, знать их нужно все – ведь впереди еще экзамен TSHOOT.
Для удобства повторю здесь топологию лабы из прошлого поста:
1. Почему Hub роутер не может установить EIGRP соседство со Spoke 2? Исправьте это.
И правда, команда show ip eigrp neighbors показывает, что установлено соседство с четырьмя роутерами но среди них нет Spoke 2 с адресом 192.168.100.3:
А ходит ли трафик между двумя роутерами?
Ходит. Соединение есть, EIGRP соседства – нет. Надо смотреть интерфейсы.
Согласно данным Frame Relay свича, к Spoke 2 от Hub ведет DLCI 203. Также мы видим, что все Frame Relay соединения используют сабинтерфейсы порта Serial 0/0. Проверим, какие DLCI присвоены какому из сабинтерфейсов.
Ага, видим, что к Spoke 2 ведет Serial0/0.202 сабинтерфейс, этот сабинтерфейс – multipoint, и на нем также висит соединение со Spoke 1. Никаких фильтров на интерфейсах нет. Давайте смотреть настройки EIGRP.
Видим, что Spoke1 указан как статический нейбор на интерфейсе Serial0/0.202. Почему же тогда Spoke2 не находится динамически?
Все дело в особенностях работы EIGRP со статическими нейборами. По умолчанию, EIGRP рассылает Hello пакеты мультикастом, направляя их всем роутерам, которые работают с EIGRP. Но когда нейбор указан статически, роутер начинает слать EIGRP пакеты юникастом, направляя их только тем устройствам, которые сконфигурированы как нейборы. Мультикаст пакеты на этом порту больше не отправляются.
В этом причина невозможности установить соседство с Spoke2. Отправляя юникаст пакеты Spoke1, Hub роутер не шлет мультикаст с интерфейса Serial0/0.202 и не принимает его. Второй нейбор остается без связи.
Чтобы исправить это, можно либо настроить второго нейбора статически, либо убрать первого. Предлагаю пойти первым вариантом:
Соседство установлено, все в порядке.
2. Как посмотреть Hello таймер на интерфейсе Serial0/0.202 роутера MainOfficeHub? Какой командой посмотреть значение Hold таймера?
Стандартная команда show ip eigrp interfaces тут не поможет:
К ней нужно добавить ключевое слово details
Тут же можно увидеть, что на этом интерфейсе отключены мультикасты и для «общения» с нейборами используются юникаст пакеты.
А вот как посмотреть Hold таймер я не знаю :-) Единственный вариант: часто-часто вводить команду show ip eigrp neighbors и по изменения значения Hold таймера, зная значение Hello, угадать значение Hold. Так что если кто-нибудь подскажет мне правильный способ узнать эту информацию, буду очень благодарен.
3. Потеряется ли EIGRP соседство с Spoke роутерами, если поменять значение Hello таймера на Hub роутере на 5 секунд? А если в 120 секунд? Каким будет значение Hold таймера у Hub Роутера, если поставить Hello интервал в 5 секунд? Как это проверить?
Для EIGRP не обязательно, чтобы таймеры нейборов совпадали, достаточно, чтобы Hello пакеты приходили до истечения Hold таймера. Hello интервал по-умолчанию зависит от типа интерфейса и инкапсуляции, так для последовательных интерфейсов с bandwidth T1 или ниже, Hello интервал составляет 60 секунд.
Потому если поставить Hello интервал в 5 секунд на интерфейсе Serial 0/0.202, к примеру, соседство сохранится. А если 120 – нет.
Интересный нюанс: Hold таймер для нашего нового значения Hello нужно смотреть на роутере-нейборе. По-умолчанию значение Hold таймера в три раза больше значения дефолтного Hello, и такое значение Hold роутер анонсирует своему соседу. Как бы говорит ему: если от меня не придет Hello за этот промежуток времени, считайте меня мертвым. Но при этом при изменении Hello таймера значение Hold автоматически не меняется:
Потому значение Hold таймера на Spoke 1, к примеру, никогда не опустится ниже 170:
При таком положении вещей, однако, подтверждения смерти Hub роутера Spoke 1 придется ждать слишком долго. Потому имеет смысл уменьшить это время ожидания:
Этим упражнением хорошо иллюстрируется особенность настройки таймеров EIGRP: когда вы указываете Hello интервал на интерфейсе, вы действительно указываете, как часто слать через этот интерфейс EIGRP Hello пакеты. Но когда вы конфигурите Hold таймер, это не значит, что вы меняете время, которое ваш роутер будет ожидать Hello пакеты от нейборов с этого интерфейса. Это значит, что вы меняете время, которое нейборы с этого интерфейса будут ждать Hello пакеты от вас.
4. Сейчас интерфейс Spoke3 роутера и соединенный с ним сабинтерфейс Hub роутера находятся в сети 192.168.101.0/29 и имеют адреса .1 и .2, соответственно. Если поменять маску адреса интерфейса Spoke роутера на /30, сохранится ли EIGRP соседство?
Еще один интересный нюанс: для установления EIGRP соседства интерфейсы нейборов вовсе не должны обязательно находиться в одной сети. Достаточно, чтобы каждый из них считал, что IP адрес нейбора находится в его сети. Потому при таком изменении соседство сохранится:
5. 10.10.10.10 и 20.20.20.20 – адреса loopback интерфейсов роутеров Spoke 1 и Spoke 2 соответственно. На Hub роутере видны обе эти сети, но Spoke 1 не видит сеть 20.20.20.20, а Spoke 2 не видит 10.10.10.10. При этом остальные сети (например, сеть 30.30.30.30 роутера Spoke 3) они видят нормально. Почему так получается и как исправить эту ситуацию?
И правда, роутер Spoke 1 видит все сети, кроме сетей роутера Spoke 2, а роутер Spoke 2 видит все сети, кроме сетей роутера Spoke 1. Из-за чего такое может случиться?
Первое предположение: фильтрация маршрутов. Смотрим:
Фильтрации нет. Смотрим дальше: всю информацию о маршрутах оба эти Spoke роутера получают от единого Hub роутера. Но там фильтрации нет – мы уже смотрели его router eigrp 100 секцию. Что еще может быть причиной того, что маршруты анонсируются так избирательно?
Причина происходящего в том, что EIGRP – дистанционно-векторный протокол. Он не знает всей топологии, он знает только какую-то метрику и направление до сети (next hop роутер). В этих обстоятельствах дистанционно-векторным протоколам гораздо проще получить routing loop, и все они используют три механизма для предотвращения таких петель: Route Poisoning, Holddown Timer и Split Horizon. Помните, как работает Split Horizon? Роутер не анонсирует сети через те интерфейсы, через которые он о них узнал.
Теперь посмотрите на нашу топологию. Роутеры Spoke 1 и Spoke 2 подключены к Hub через единый multipoint сабинтерфейс: Serial0/0.202. Согласно правилу Route Poisoning, Hub роутер не анонсирует через него те сети, о которых он узнал из него же. Потому Hub роутер не будет анонсировать Spoke 1 сеть 20.20.20.20 – о ней он узнал через тот же интерфейс, хоть и от другого нейбора.
Потому для того, чтобы исправить этот глюк, нужно выключить Split Horizon на интерфейсе Serial 0/0.202 Hub роутера. При этом, дабы свести ущерб к минимуму, его можно выключить для конкретного инстанса (AS Number) конкретного протокола:
6. Spoke 1 и Spoke 2 роутеры настроены как eigrp stub, но сети их loopback интерфейсов все равно анонсируются hub роутеру. Почему так получается и как сделать, чтобы они не анонсировали ничего?
Роутеры Spoke 1 и Spoke 2, как и полагается Spoke роутерам в топологии Hub&Spoke, настроены как stub роутеры командой eigrp stub. Однако обратите внимание, что в конфиге она отображается как eigrp stub connected summary. По умолчанию, несмотря на то, что вы не выбираете этих опций, роутер выбирает режим stub, при котором он не анонсирует ничего, кроме connected сетей и summary сетей. Для того, чтобы роутер не анонсировал ничего, нужно ввести команду eigrp stub receive-only.
7. Если hub роутер потеряет линк к сети 10.10.10.10, куда он будет слать EIGRP Query и почему?
Как известно, когда EIGRP роутер теряет путь в какую-то сеть, он переводит ее в состояние Active и начинает рассылать EIGRP Query сообщения соседям со словами: а не знаете ли вы, случайно, пути в эту сеть, потому как я ее только что потерял?
Давайте посмотрим вживую, куда же он будет их слать Hub роутер, если он потеряет путь в сеть 10.10.10.10.
Вот такие EIGRP Query пакеты Hub роутер отправил из интерфейсов FastEthernet 0/0 и FastEthernet 0/1, но он не отправлял их из интерфейсов Serial 0/0.202 и Serial 0/0.204, хотя на них тоже были нейборы. В чем причина этого?
Hub роутер делает это из-за того, что все нейборы на интерфейсах Serial 0/0.202 и Serial 0/0.204 настроены как stub роутеры. Будучи сконфигурирован как stub, роутер информирует об этом всех нейборов, включая эту информацию в свои Hello пакеты:
Stub роутерам не имеет смысла слать EUGRP Query, и это логично, они ведь не ретранслируют чужие сети по EIGRP, следовательно, они никак не могут сообщить альтернативный маршрут для потерянного префикса. Потому Hub роутер и не шлет Query всем трем Spoke роутерам.
8. Сколько максимально пропускной способности линка к Spoke 3 могут занимать EIGRP пакеты?
Одна из фич EIGRP – bandwidth control. Ее придумали для того, чтобы не допускать случаев, когда медленный WAN линк может быть целиком забит EIGRP сообщениями (в случае, например, когда на этим линке появляется новый EIGRP нейбор или происходит какое-то большое изменение в сети). Потому по умолчанию EIGRP может занимать максимум половину полосы пропускания интерфейса. Но вот в случае с сабинтерфейсами и Frame Relay этот подсчет бывает неочевидным.
Каждый сабинтерфейс получает как отсчетную точку bandwidth интерфейса, на котором он сконфигурирован. Так оба интерфейса на Hub роутере: Serial 0/0.202 и Serial 0/0.204 будут иметь bandwidth в 1544 кбит/с. К Spoke 3 ведет один сабинтерфейс: Serial 0/0.204, и EIGRP в потоке данных может занимать максимум половину bandwidth: 772 кбит/с.
Для мультипоинт сабинтерфейсов EIGRP ограничивает не только передачу обновлений через единый интерфейс, но еще и максимальную нагрузку этими обновлениями на один DLCI. Так, общая пропускная способность интерфейса делится на количество DLCI в нем, и из полученного результата для каждого DLCI выделяется половины пропускной способности под EIGRP. Так для сабинтерфейса Serial 0/0.202 на каждый DLCI для EIGRP будет доступна максимальный bandwidth в 386 кбит/с.
9. Между Hub роутером и R5 настроена EIGRP аутентификация, но роутеры не могут установить соседство. При этом на Hub роутере соседство с R5 то устанавливается, то теряется. В чем причина этого и как ее устранить?
И правда, на Hub роутере происходит достаточно странная активность, соседство с 192.168.201.2 (R5) то устанавливается, то исчезает:
При этом на самом R5 ничего подобного не происходит, роутер и не думает устанавливать соседство с Hub:
В чем тут может быть причина?
На интерфейсе FastEthernet0/1 роутера Hub настроена аутентификация для EIGRP нейборов:
Аналогичная же настроена на R5:
Названия key chain на роутерах не совпадают, но они и не должны – соседству это не помеха. Причина странного поведения в accept lifetime на R5. Этот роутер постоянно «подписывает» свои сообщения валидным для Hub роутера паролем, а вот принимать подписанные этим же паролем Hello начнет только с 1 апреля 2012 года.
Получается, что Hub роутер получает Hello пакет с корректным паролем, идентифицирует R5 как нейбора (выводит строчку в терминал), и пытается произвести с ним обмен маршрутами. Но R5 не отвечает на такой запрос, потому что, хотя он и рассылает этот пароль, но не принимает его в качестве правильного. Hub роутер какое-то время ждет ответа, после чего идентифицирует R5 как мертвого нейбора (выводит строчку в терминал) и круг замыкается.
Для того, чтобы его прервать, нужно убрать временное ограничение на пароль на R5:
Соседство установлено.
10. ASBR имеет подключение к Интернет через интерфейс loopback 4 с адресом 50.0.0.1/24. Надо анонсировать по EIGRP default route в эту сеть.
(Тут я немного усложнил задачу: поменял адрес сети с 150.0.0.1/24 на 50.0.0.1/24)
Для анонсирования маршрута по умолчанию EIGRP поддерживает концепцию default network – полноклассовая сеть может бать анонсирована по EIGRP как default gateway. Вест трафик, для которого не будет найдено маршрутов, будет направляться маршрутизатору, подключенному к этой сети.
Но – такая сеть должна быть полноклассовой. У нас же наш путь к провайдеру имеет адрес: 50.0.0.1/24. Как быть в этом случае?
Анонсировать по EIGRP нам надо полноклассовую сеть – тут уже не выкрутишься. В итоге весь трафик будет доставлен нам. Но ведь дальше уже мы вольны делать с ним, что захотим, верно? Вовсе не обязательно пихать его в эту самую полноклассовую сеть, можем направить его статическим маршрутом, куда захотим.
Потому – создадим еще один loopback интерфейс, скажем, loopback 10 c полноклассовым адресом: 160.0.0.1/24.
Дальше создадим статический маршрут на ASBR для default route – в сеть 50.0.0.1/24 через интерфейс loopback 4.
(Да, я знаю, что так некорректно, но что уж поделаешь – лупбеки. Считайте, что я тут указал hext hop IP address)
Теперь определим сеть 160.0.0.1/24 как default-network и анонсируем ее по EIGRP.
В итоге, мы получаем на всех роутерах нашей сети, кроме ASBR, маршрут по умолчанию – в сеть 160.0.0.0:
А на ASBR – статический маршрут, который перенаправляет трафик с loopback 10 (который представляет default network) реальному провайдеру в бесклассовую сеть.
11. На Hub роутере настроен summary route для сети 192.168.100.0/22. Почему его метрика установлена в 2169856?
Для того, чтобы выяснить это, нам нужно взглянуть на таблицу топологии EIGRP на Hub роутере.
Как видно из таблицы топологии, summary route 192.168.100.0/22 объединяет в себе маршруты к сетям 192.168.100.0/29 и P 192.168.101.0/29. 2169856 – наименьшая метрика из них. Для суммарного маршрута EIGRP ставит в качестве метрики минимальную метрику из всех агрегированных маршрутов.
12. В связи с автоматическим суммированием маршрутов сеть интерфейса Loopback 1 роутера Spoke 1 и сеть Loopback 0 – 3 роутера ASBR анонсируются как одинаковые сети 172.16.0.0/16. Где нужно убрать автоматическое суммирование, чтобы они все роутеры сети видели их как разные сети?
EIGRP автоматически суммирует до полноклассовых только connected сети, полученные по EIGRP маршруты не автосуммируются даже если auto-summary включена (для того, чтобы суммировать такие маршруты нужно использовать ручную суммаризацию на каждом из интерфейсов). Потому сети 172.16.10.1/24 и 172.16.0.1/24, 172.16.1.1/24, 172.16.2.1/24 суммируются роутерами Spoke 1 и ASBR соответственно, и передаются остальным роутерам уже как summary. Для того, чтобы определить их как отдельные сети, нужно отключить суммирование на этих двух роутерах. Тогда на всех остальных маршруты к ним будут корректны, даже если auto-summary включено.
13. На Hub роутере настроена балансировака трафика по маршрутам с различной метрикой. Коэффициент variance 2. Как видно из таблицы топологии EIGRP (да и из схемы), метрики двух маршрутов составляют порядка 15000 и 16000, но несмотря на это в таблицу маршрутизации установлен только один. Почему так получилось?
Возможность балансировать нагрузку по маршрутам с неодинаковой метрикой – одна из самых интересных, на мой взгляд, фич EIGRP. Но и тут у протокола есть определенные ограничения. Снова вспомним, что EIGRP – дистанционно-векторный протокол, и у него есть свои механизмы недопущения петель маршрутизации.
EIGRP не знает о сети ничего, кроме направления, в котором она достижима (next hop) и ее метрику. Алгоритм DUAL, лежащий в основе EIGRP, определяет loop-free пути и использует в качестве successor/feasible successor только их. Если путь не loop-free, трафик по нему передавать нельзя.
DUAL выбирает feasible successor как альтернативные пути до определенной сети. Эти пути могут быть моментально подставлены в таблицу маршрутизации в случае падения линка до основного next hop, либо же по ним может балансироваться трафик. Только по successor/feasible successor!
EIGRP, снова-таки, не знает топологии. Но он знает свою метрику до сети и метрику соседнего роутера. Он предполагает, что если метрика соседнего роутера меньше, чем его собственная метрика, значит, это альтернативный loop-free путь. А вот если метрика соседнего роутера больше, чем его собственная, значит, не факт, что это loop-free путь, потому как эта метрика может быть его метрикой, плюс какой-то еще путь в кольце. Потому такие маршруты не используются как feasible successor.
Это не значит, что они не будут использоваться никогда. Если основной линк упадет, роутер отправит EIGRP Query и найдет этот роут. Но балансировка трафика по нему невозможна.
Теперь давайте посмотрим на таблицу топологии Hub роутера для сетей ASBR:
К примеру, у маршрута в сеть 172.16.0.0/24 есть два пути, но у второго метрика FD больше, чем текущая метрика AD для Hub роутера. Потому второй маршрут не установился в таблицу маршрутизации и по нему не происходит балансирование нагрузки.
Получилось очень много буков, конфигов и картинок, но с меньшим их количеством объяснить каждый нюанс не получалось. Надеюсь, статья будет полезна тем, кто готовится к сдаче экзамена и хочет еще раз просмотреть все тонкости и скользкие моменты технологии.
P.S. Если кто-то знает, как можно оформить конфиги без выделений синим, но при этом с сохранением порядка знаков, – напишите, пожалуйста, буду очень признателен.
Продолжим изучение лаб для экзамена ROUTE курса CCNP.
Я думал объединить ответы на задачки прошлой лабы с лабой по OSPF, но этот топик и без того получается настолько большим, что, боюсь, как бы его все дочитали до конца. Здесь будет очень много конфигов, скриншотов из Wireshark и дебрей технологии, но все это только для того, чтобы лучше проиллюстрировать внутреннюю логику EIGRP, без понимания которой этот экзамен сдать невозможно.
Будущие, бывшие и настоящие CCNP, добро пожаловать под кат!
Предлагаю, проходясь по пунктам лабы, рассматривать все возможные варианты и причины, а не идти целенаправленно к известному выводу. Одну и ту же неполадку может вызвать несколько вещей, и, так или иначе, знать их нужно все – ведь впереди еще экзамен TSHOOT.
Для удобства повторю здесь топологию лабы из прошлого поста:
Решение задач
1. Почему Hub роутер не может установить EIGRP соседство со Spoke 2? Исправьте это.
И правда, команда show ip eigrp neighbors показывает, что установлено соседство с четырьмя роутерами но среди них нет Spoke 2 с адресом 192.168.100.3:
MainOfficeHub#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 192.168.201.2 Fa0/1 11 00:00:03 1 3000 2 0
3 192.168.101.2 Se0/0.204 159 00:00:27 1306 5000 0 5
2 192.168.100.2 Se0/0.202 171 00:01:08 451 2706 0 3
0 192.168.200.2 Fa0/0 12 00:02:49 427 2562 0 19
А ходит ли трафик между двумя роутерами?
MainOfficeHub#ping 192.168.100.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/112/296 ms
Ходит. Соединение есть, EIGRP соседства – нет. Надо смотреть интерфейсы.
Согласно данным Frame Relay свича, к Spoke 2 от Hub ведет DLCI 203. Также мы видим, что все Frame Relay соединения используют сабинтерфейсы порта Serial 0/0. Проверим, какие DLCI присвоены какому из сабинтерфейсов.
MainOfficeHub#show running-config interface serial 0/0.202
Building configuration...
Current configuration : 148 bytes
!
interface Serial0/0.202 multipoint
ip address 192.168.100.1 255.255.255.248
frame-relay interface-dlci 202
frame-relay interface-dlci 203
end
MainOfficeHub#show running-config interface serial 0/0.204
Building configuration...
Current configuration : 138 bytes
!
interface Serial0/0.204 point-to-point
bandwidth 100
ip address 192.168.101.1 255.255.255.248
frame-relay interface-dlci 204
end
Ага, видим, что к Spoke 2 ведет Serial0/0.202 сабинтерфейс, этот сабинтерфейс – multipoint, и на нем также висит соединение со Spoke 1. Никаких фильтров на интерфейсах нет. Давайте смотреть настройки EIGRP.
MainOfficeHub#show running-config | section router eigrp 100
router eigrp 100
variance 5
network 192.168.0.0 0.0.255.255
auto-summary
neighbor 192.168.100.2 Serial0/0.202
Видим, что Spoke1 указан как статический нейбор на интерфейсе Serial0/0.202. Почему же тогда Spoke2 не находится динамически?
Все дело в особенностях работы EIGRP со статическими нейборами. По умолчанию, EIGRP рассылает Hello пакеты мультикастом, направляя их всем роутерам, которые работают с EIGRP. Но когда нейбор указан статически, роутер начинает слать EIGRP пакеты юникастом, направляя их только тем устройствам, которые сконфигурированы как нейборы. Мультикаст пакеты на этом порту больше не отправляются.
В этом причина невозможности установить соседство с Spoke2. Отправляя юникаст пакеты Spoke1, Hub роутер не шлет мультикаст с интерфейса Serial0/0.202 и не принимает его. Второй нейбор остается без связи.
Чтобы исправить это, можно либо настроить второго нейбора статически, либо убрать первого. Предлагаю пойти первым вариантом:
BranchOfficeSpoke2(config-router)#neighbor 192.168.100.1 serial 0/0
MainOfficeHub(config-router)#neighbor 192.168.100.3 serial 0/0.202
MainOfficeHub#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
4 192.168.100.3 Se0/0.202 162 00:00:18 161 1449 0 3
1 192.168.201.2 Fa0/1 11 00:00:44 1 5000 2 0
3 192.168.101.2 Se0/0.204 162 00:16:11 1199 5000 0 5
2 192.168.100.2 Se0/0.202 163 00:16:52 511 3066 0 3
0 192.168.200.2 Fa0/0 14 00:18:33 345 2070 0 22
Соседство установлено, все в порядке.
2. Как посмотреть Hello таймер на интерфейсе Serial0/0.202 роутера MainOfficeHub? Какой командой посмотреть значение Hold таймера?
Стандартная команда show ip eigrp interfaces тут не поможет:
MainOfficeHub#show ip eigrp interfaces serial 0/0.202
IP-EIGRP interfaces for process 100
Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
Se0/0.202 2 0/0 336 0/15 1326 0
К ней нужно добавить ключевое слово details
MainOfficeHub#show ip eigrp interfaces detail serial 0/0.202
IP-EIGRP interfaces for process 100
Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
Se0/0.202 2 0/0 336 0/15 1326 0
Hello interval is 60 sec
Next xmit serial <none>
Un/reliable mcasts: 0/0 Un/reliable ucasts: 0/11
Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 5
Retransmissions sent: 2 Out-of-sequence rcvd: 0
Interface has all stub peers
Authentication mode is not set
Use unicast
Тут же можно увидеть, что на этом интерфейсе отключены мультикасты и для «общения» с нейборами используются юникаст пакеты.
А вот как посмотреть Hold таймер я не знаю :-) Единственный вариант: часто-часто вводить команду show ip eigrp neighbors и по изменения значения Hold таймера, зная значение Hello, угадать значение Hold. Так что если кто-нибудь подскажет мне правильный способ узнать эту информацию, буду очень благодарен.
3. Потеряется ли EIGRP соседство с Spoke роутерами, если поменять значение Hello таймера на Hub роутере на 5 секунд? А если в 120 секунд? Каким будет значение Hold таймера у Hub Роутера, если поставить Hello интервал в 5 секунд? Как это проверить?
Для EIGRP не обязательно, чтобы таймеры нейборов совпадали, достаточно, чтобы Hello пакеты приходили до истечения Hold таймера. Hello интервал по-умолчанию зависит от типа интерфейса и инкапсуляции, так для последовательных интерфейсов с bandwidth T1 или ниже, Hello интервал составляет 60 секунд.
Потому если поставить Hello интервал в 5 секунд на интерфейсе Serial 0/0.202, к примеру, соседство сохранится. А если 120 – нет.
Интересный нюанс: Hold таймер для нашего нового значения Hello нужно смотреть на роутере-нейборе. По-умолчанию значение Hold таймера в три раза больше значения дефолтного Hello, и такое значение Hold роутер анонсирует своему соседу. Как бы говорит ему: если от меня не придет Hello за этот промежуток времени, считайте меня мертвым. Но при этом при изменении Hello таймера значение Hold автоматически не меняется:
Потому значение Hold таймера на Spoke 1, к примеру, никогда не опустится ниже 170:
BranchOfficeSpoke1#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.100.1 Se0/0 171 00:27:32 323 1938 0 20
BranchOfficeSpoke1#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.100.1 Se0/0 179 00:27:32 323 1938 0 20
При таком положении вещей, однако, подтверждения смерти Hub роутера Spoke 1 придется ждать слишком долго. Потому имеет смысл уменьшить это время ожидания:
MainOfficeHub(config-subif)#ip hold-time eigrp 100 30
BranchOfficeSpoke1#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.100.1 Se0/0 25 00:30:42 323 1938 0 20
Этим упражнением хорошо иллюстрируется особенность настройки таймеров EIGRP: когда вы указываете Hello интервал на интерфейсе, вы действительно указываете, как часто слать через этот интерфейс EIGRP Hello пакеты. Но когда вы конфигурите Hold таймер, это не значит, что вы меняете время, которое ваш роутер будет ожидать Hello пакеты от нейборов с этого интерфейса. Это значит, что вы меняете время, которое нейборы с этого интерфейса будут ждать Hello пакеты от вас.
4. Сейчас интерфейс Spoke3 роутера и соединенный с ним сабинтерфейс Hub роутера находятся в сети 192.168.101.0/29 и имеют адреса .1 и .2, соответственно. Если поменять маску адреса интерфейса Spoke роутера на /30, сохранится ли EIGRP соседство?
Еще один интересный нюанс: для установления EIGRP соседства интерфейсы нейборов вовсе не должны обязательно находиться в одной сети. Достаточно, чтобы каждый из них считал, что IP адрес нейбора находится в его сети. Потому при таком изменении соседство сохранится:
BranchOfficeSpoke3#show run interface serial 0/0
Building configuration...
Current configuration : 128 bytes
!
interface Serial0/0
ip address 192.168.101.2 255.255.255.248
encapsulation frame-relay
frame-relay interface-dlci 103
end
BranchOfficeSpoke3#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.101.1 Se0/0 5 00:00:26 460 2760 0 22
BranchOfficeSpoke3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
BranchOfficeSpoke3(config)#int s0/0
BranchOfficeSpoke3(config-if)#ip address 192.168.101.2 255.255.255.252
BranchOfficeSpoke3(config-if)#
*Mar 1 00:02:39.537: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.101.1 (Serial0/0) is down: address changed
BranchOfficeSpoke3(config-if)#
*Mar 1 00:02:45.923: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.101.1 (Serial0/0) is up: new adjacency
BranchOfficeSpoke3(config-if)#^Z
BranchOfficeSpoke3#sh
*Mar 1 00:02:50.487: %SYS-5-CONFIG_I: Configured from console by console
BranchOfficeSpoke3#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.101.1 Se0/0 5 00:00:09 1 4500 2 0
5. 10.10.10.10 и 20.20.20.20 – адреса loopback интерфейсов роутеров Spoke 1 и Spoke 2 соответственно. На Hub роутере видны обе эти сети, но Spoke 1 не видит сеть 20.20.20.20, а Spoke 2 не видит 10.10.10.10. При этом остальные сети (например, сеть 30.30.30.30 роутера Spoke 3) они видят нормально. Почему так получается и как исправить эту ситуацию?
И правда, роутер Spoke 1 видит все сети, кроме сетей роутера Spoke 2, а роутер Spoke 2 видит все сети, кроме сетей роутера Spoke 1. Из-за чего такое может случиться?
Первое предположение: фильтрация маршрутов. Смотрим:
BranchOfficeSpoke1#show running-config | section router eigrp 100
router eigrp 100
network 10.0.0.0
network 172.16.0.0
network 192.168.0.0 0.0.255.255
auto-summary
eigrp stub connected summary
neighbor 192.168.100.1 Serial0/0
BranchOfficeSpoke2#show running-config | section router eigrp 100
router eigrp 100
network 20.0.0.0
network 192.168.0.0 0.0.255.255
auto-summary
eigrp stub connected summary
Фильтрации нет. Смотрим дальше: всю информацию о маршрутах оба эти Spoke роутера получают от единого Hub роутера. Но там фильтрации нет – мы уже смотрели его router eigrp 100 секцию. Что еще может быть причиной того, что маршруты анонсируются так избирательно?
Причина происходящего в том, что EIGRP – дистанционно-векторный протокол. Он не знает всей топологии, он знает только какую-то метрику и направление до сети (next hop роутер). В этих обстоятельствах дистанционно-векторным протоколам гораздо проще получить routing loop, и все они используют три механизма для предотвращения таких петель: Route Poisoning, Holddown Timer и Split Horizon. Помните, как работает Split Horizon? Роутер не анонсирует сети через те интерфейсы, через которые он о них узнал.
Теперь посмотрите на нашу топологию. Роутеры Spoke 1 и Spoke 2 подключены к Hub через единый multipoint сабинтерфейс: Serial0/0.202. Согласно правилу Route Poisoning, Hub роутер не анонсирует через него те сети, о которых он узнал из него же. Потому Hub роутер не будет анонсировать Spoke 1 сеть 20.20.20.20 – о ней он узнал через тот же интерфейс, хоть и от другого нейбора.
Потому для того, чтобы исправить этот глюк, нужно выключить Split Horizon на интерфейсе Serial 0/0.202 Hub роутера. При этом, дабы свести ущерб к минимуму, его можно выключить для конкретного инстанса (AS Number) конкретного протокола:
MainOfficeHub(config-subif)#no ip split-horizon eigrp 100
BranchOfficeSpoke1#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
D 20.0.0.0/8 [90/2809856] via 192.168.100.1, 00:02:19, Serial0/0
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
! Output omitted
6. Spoke 1 и Spoke 2 роутеры настроены как eigrp stub, но сети их loopback интерфейсов все равно анонсируются hub роутеру. Почему так получается и как сделать, чтобы они не анонсировали ничего?
Роутеры Spoke 1 и Spoke 2, как и полагается Spoke роутерам в топологии Hub&Spoke, настроены как stub роутеры командой eigrp stub. Однако обратите внимание, что в конфиге она отображается как eigrp stub connected summary. По умолчанию, несмотря на то, что вы не выбираете этих опций, роутер выбирает режим stub, при котором он не анонсирует ничего, кроме connected сетей и summary сетей. Для того, чтобы роутер не анонсировал ничего, нужно ввести команду eigrp stub receive-only.
7. Если hub роутер потеряет линк к сети 10.10.10.10, куда он будет слать EIGRP Query и почему?
Как известно, когда EIGRP роутер теряет путь в какую-то сеть, он переводит ее в состояние Active и начинает рассылать EIGRP Query сообщения соседям со словами: а не знаете ли вы, случайно, пути в эту сеть, потому как я ее только что потерял?
Давайте посмотрим вживую, куда же он будет их слать Hub роутер, если он потеряет путь в сеть 10.10.10.10.
Вот такие EIGRP Query пакеты Hub роутер отправил из интерфейсов FastEthernet 0/0 и FastEthernet 0/1, но он не отправлял их из интерфейсов Serial 0/0.202 и Serial 0/0.204, хотя на них тоже были нейборы. В чем причина этого?
Hub роутер делает это из-за того, что все нейборы на интерфейсах Serial 0/0.202 и Serial 0/0.204 настроены как stub роутеры. Будучи сконфигурирован как stub, роутер информирует об этом всех нейборов, включая эту информацию в свои Hello пакеты:
Stub роутерам не имеет смысла слать EUGRP Query, и это логично, они ведь не ретранслируют чужие сети по EIGRP, следовательно, они никак не могут сообщить альтернативный маршрут для потерянного префикса. Потому Hub роутер и не шлет Query всем трем Spoke роутерам.
8. Сколько максимально пропускной способности линка к Spoke 3 могут занимать EIGRP пакеты?
Одна из фич EIGRP – bandwidth control. Ее придумали для того, чтобы не допускать случаев, когда медленный WAN линк может быть целиком забит EIGRP сообщениями (в случае, например, когда на этим линке появляется новый EIGRP нейбор или происходит какое-то большое изменение в сети). Потому по умолчанию EIGRP может занимать максимум половину полосы пропускания интерфейса. Но вот в случае с сабинтерфейсами и Frame Relay этот подсчет бывает неочевидным.
Каждый сабинтерфейс получает как отсчетную точку bandwidth интерфейса, на котором он сконфигурирован. Так оба интерфейса на Hub роутере: Serial 0/0.202 и Serial 0/0.204 будут иметь bandwidth в 1544 кбит/с. К Spoke 3 ведет один сабинтерфейс: Serial 0/0.204, и EIGRP в потоке данных может занимать максимум половину bandwidth: 772 кбит/с.
Для мультипоинт сабинтерфейсов EIGRP ограничивает не только передачу обновлений через единый интерфейс, но еще и максимальную нагрузку этими обновлениями на один DLCI. Так, общая пропускная способность интерфейса делится на количество DLCI в нем, и из полученного результата для каждого DLCI выделяется половины пропускной способности под EIGRP. Так для сабинтерфейса Serial 0/0.202 на каждый DLCI для EIGRP будет доступна максимальный bandwidth в 386 кбит/с.
9. Между Hub роутером и R5 настроена EIGRP аутентификация, но роутеры не могут установить соседство. При этом на Hub роутере соседство с R5 то устанавливается, то теряется. В чем причина этого и как ее устранить?
И правда, на Hub роутере происходит достаточно странная активность, соседство с 192.168.201.2 (R5) то устанавливается, то исчезает:
MainOfficeHub#
*Mar 1 01:03:20.658: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.201.2 (FastEthernet0/1) is down: retry limit exceeded
MainOfficeHub#
*Mar 1 01:03:22.974: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.201.2 (FastEthernet0/1) is up: new adjacency
MainOfficeHub#
*Mar 1 01:04:42.500: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.201.2 (FastEthernet0/1) is down: retry limit exceeded
MainOfficeHub#
*Mar 1 01:04:46.006: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.201.2 (FastEthernet0/1) is up: new adjacency
При этом на самом R5 ничего подобного не происходит, роутер и не думает устанавливать соседство с Hub:
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.203.2 Fa0/0 10 01:06:39 281 2529 0 71
В чем тут может быть причина?
На интерфейсе FastEthernet0/1 роутера Hub настроена аутентификация для EIGRP нейборов:
MainOfficeHub#show running-config interface fastEthernet 0/1
Building configuration...
Current configuration : 188 bytes
!
interface FastEthernet0/1
ip address 192.168.201.1 255.255.255.252
ip authentication mode eigrp 100 md5
ip authentication key-chain eigrp 100 main-chain
duplex auto
speed auto
end
MainOfficeHub#show key chain main-chain
Key-chain main-chain:
key 1 -- text "qwerty"
accept lifetime (always valid) - (always valid) [valid now]
send lifetime (always valid) - (always valid) [valid now]
Аналогичная же настроена на R5:
R5#show running-config interface fa0/1
Building configuration...
Current configuration : 185 bytes
!
interface FastEthernet0/1
ip address 192.168.201.2 255.255.255.252
ip authentication mode eigrp 100 md5
ip authentication key-chain eigrp 100 mychain
duplex auto
speed auto
end
R5#show key chain mychain
Key-chain mychain:
key 1 -- text "qwerty"
accept lifetime (12:00:00 UTC Apr 1 2012) - (infinite)
send lifetime (always valid) - (always valid) [valid now]
Названия key chain на роутерах не совпадают, но они и не должны – соседству это не помеха. Причина странного поведения в accept lifetime на R5. Этот роутер постоянно «подписывает» свои сообщения валидным для Hub роутера паролем, а вот принимать подписанные этим же паролем Hello начнет только с 1 апреля 2012 года.
Получается, что Hub роутер получает Hello пакет с корректным паролем, идентифицирует R5 как нейбора (выводит строчку в терминал), и пытается произвести с ним обмен маршрутами. Но R5 не отвечает на такой запрос, потому что, хотя он и рассылает этот пароль, но не принимает его в качестве правильного. Hub роутер какое-то время ждет ответа, после чего идентифицирует R5 как мертвого нейбора (выводит строчку в терминал) и круг замыкается.
Для того, чтобы его прервать, нужно убрать временное ограничение на пароль на R5:
R5(config)#key chain mychain
R5(config-keychain)#key 1
R5(config-keychain-key)#no accept-lifetime 12:00:00 Apr 1 2012 infinite
R5(config-keychain-key)#
*Mar 1 01:14:01.048: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.201.1 (FastEthernet0/1) is up: new adjacency
Соседство установлено.
10. ASBR имеет подключение к Интернет через интерфейс loopback 4 с адресом 50.0.0.1/24. Надо анонсировать по EIGRP default route в эту сеть.
(Тут я немного усложнил задачу: поменял адрес сети с 150.0.0.1/24 на 50.0.0.1/24)
Для анонсирования маршрута по умолчанию EIGRP поддерживает концепцию default network – полноклассовая сеть может бать анонсирована по EIGRP как default gateway. Вест трафик, для которого не будет найдено маршрутов, будет направляться маршрутизатору, подключенному к этой сети.
Но – такая сеть должна быть полноклассовой. У нас же наш путь к провайдеру имеет адрес: 50.0.0.1/24. Как быть в этом случае?
Анонсировать по EIGRP нам надо полноклассовую сеть – тут уже не выкрутишься. В итоге весь трафик будет доставлен нам. Но ведь дальше уже мы вольны делать с ним, что захотим, верно? Вовсе не обязательно пихать его в эту самую полноклассовую сеть, можем направить его статическим маршрутом, куда захотим.
Потому – создадим еще один loopback интерфейс, скажем, loopback 10 c полноклассовым адресом: 160.0.0.1/24.
ASBR(config)#int loopback 10
*Mar 1 01:42:07.148: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback10, changed state to up
ASBR(config-if)#ip address 160.0.0.1 255.255.255.0
Дальше создадим статический маршрут на ASBR для default route – в сеть 50.0.0.1/24 через интерфейс loopback 4.
ASBR(config)#ip route 0.0.0.0 0.0.0.0 loopback 4
(Да, я знаю, что так некорректно, но что уж поделаешь – лупбеки. Считайте, что я тут указал hext hop IP address)
Теперь определим сеть 160.0.0.1/24 как default-network и анонсируем ее по EIGRP.
ASBR(config)#ip default-network 160.0.0.0
ASBR(config)#router eigrp 100
ASBR(config-router)#network 160.0.0.0
В итоге, мы получаем на всех роутерах нашей сети, кроме ASBR, маршрут по умолчанию – в сеть 160.0.0.0:
MainOfficeHub#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 192.168.200.2 to network 160.0.0.0
! Output omitted
D* 160.0.0.0/16 [90/158720] via 192.168.200.2, 00:01:19, FastEthernet0/0
MainOfficeHub#ping 50.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 50.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/149/465 ms
А на ASBR – статический маршрут, который перенаправляет трафик с loopback 10 (который представляет default network) реальному провайдеру в бесклассовую сеть.
11. На Hub роутере настроен summary route для сети 192.168.100.0/22. Почему его метрика установлена в 2169856?
Для того, чтобы выяснить это, нам нужно взглянуть на таблицу топологии EIGRP на Hub роутере.
MainOfficeHub#show ip eigrp topology
IP-EIGRP Topology Table for AS(100)/ID(192.168.200.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 30.30.30.30/32, 1 successors, FD is 2297856
via 192.168.101.2 (2297856/128256), Serial0/0.204
P 10.0.0.0/8, 1 successors, FD is 2297856
via 192.168.100.2 (2297856/128256), Serial0/0.202
P 192.168.100.0/22, 1 successors, FD is 2169856
via Summary (2169856/0), Null0
P 192.168.100.0/24, 1 successors, FD is 2169856
via Summary (2169856/0), Null0
P 192.168.100.0/29, 1 successors, FD is 2169856
via Connected, Serial0/0.202
P 192.168.101.0/24, 1 successors, FD is 4168960
via Summary (4168960/0), Null0
P 192.168.101.0/29, 1 successors, FD is 4168960
via Connected, Serial0/0.204
P 20.0.0.0/8, 1 successors, FD is 2297856
via 192.168.100.3 (2297856/128256), Serial0/0.202
P 160.0.0.0/16, 1 successors, FD is 158720
via 192.168.200.2 (158720/156160), FastEthernet0/0
P 192.168.200.0/24, 1 successors, FD is 28160
via Summary (28160/0), Null0
P 192.168.200.0/30, 1 successors, FD is 28160
via Connected, FastEthernet0/0
P 192.168.201.0/24, 1 successors, FD is 28160
via Summary (28160/0), Null0
P 192.168.201.0/30, 1 successors, FD is 28160
via Connected, FastEthernet0/1
P 192.168.202.0/24, 1 successors, FD is 30720
via 192.168.200.2 (30720/28160), FastEthernet0/0
P 192.168.203.0/24, 1 successors, FD is 33536
via 192.168.201.2 (33536/30976), FastEthernet0/1
P 172.16.0.0/16, 1 successors, FD is 158720
via 192.168.200.2 (158720/156160), FastEthernet0/0
via 192.168.100.2 (2297856/128256), Serial0/0.202
Как видно из таблицы топологии, summary route 192.168.100.0/22 объединяет в себе маршруты к сетям 192.168.100.0/29 и P 192.168.101.0/29. 2169856 – наименьшая метрика из них. Для суммарного маршрута EIGRP ставит в качестве метрики минимальную метрику из всех агрегированных маршрутов.
12. В связи с автоматическим суммированием маршрутов сеть интерфейса Loopback 1 роутера Spoke 1 и сеть Loopback 0 – 3 роутера ASBR анонсируются как одинаковые сети 172.16.0.0/16. Где нужно убрать автоматическое суммирование, чтобы они все роутеры сети видели их как разные сети?
EIGRP автоматически суммирует до полноклассовых только connected сети, полученные по EIGRP маршруты не автосуммируются даже если auto-summary включена (для того, чтобы суммировать такие маршруты нужно использовать ручную суммаризацию на каждом из интерфейсов). Потому сети 172.16.10.1/24 и 172.16.0.1/24, 172.16.1.1/24, 172.16.2.1/24 суммируются роутерами Spoke 1 и ASBR соответственно, и передаются остальным роутерам уже как summary. Для того, чтобы определить их как отдельные сети, нужно отключить суммирование на этих двух роутерах. Тогда на всех остальных маршруты к ним будут корректны, даже если auto-summary включено.
MainOfficeHub#show running-config | section eigrp 100
router eigrp 100
variance 5
network 192.168.0.0 0.0.255.255
auto-summary
neighbor 192.168.100.3 Serial0/0.202
neighbor 192.168.100.2 Serial0/0.202
MainOfficeHub#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 192.168.200.2 to network 160.0.0.0
172.16.0.0/24 is subnetted, 4 subnets
D 172.16.10.0 [90/2297856] via 192.168.100.2, 00:05:57, Serial0/0.202
D 172.16.0.0 [90/158720] via 192.168.200.2, 00:05:53, FastEthernet0/0
D 172.16.1.0 [90/158720] via 192.168.200.2, 00:05:53, FastEthernet0/0
D 172.16.2.0 [90/158720] via 192.168.200.2, 00:05:53, FastEthernet0/0
! Output omitted
13. На Hub роутере настроена балансировака трафика по маршрутам с различной метрикой. Коэффициент variance 2. Как видно из таблицы топологии EIGRP (да и из схемы), метрики двух маршрутов составляют порядка 15000 и 16000, но несмотря на это в таблицу маршрутизации установлен только один. Почему так получилось?
Возможность балансировать нагрузку по маршрутам с неодинаковой метрикой – одна из самых интересных, на мой взгляд, фич EIGRP. Но и тут у протокола есть определенные ограничения. Снова вспомним, что EIGRP – дистанционно-векторный протокол, и у него есть свои механизмы недопущения петель маршрутизации.
EIGRP не знает о сети ничего, кроме направления, в котором она достижима (next hop) и ее метрику. Алгоритм DUAL, лежащий в основе EIGRP, определяет loop-free пути и использует в качестве successor/feasible successor только их. Если путь не loop-free, трафик по нему передавать нельзя.
DUAL выбирает feasible successor как альтернативные пути до определенной сети. Эти пути могут быть моментально подставлены в таблицу маршрутизации в случае падения линка до основного next hop, либо же по ним может балансироваться трафик. Только по successor/feasible successor!
EIGRP, снова-таки, не знает топологии. Но он знает свою метрику до сети и метрику соседнего роутера. Он предполагает, что если метрика соседнего роутера меньше, чем его собственная метрика, значит, это альтернативный loop-free путь. А вот если метрика соседнего роутера больше, чем его собственная, значит, не факт, что это loop-free путь, потому как эта метрика может быть его метрикой, плюс какой-то еще путь в кольце. Потому такие маршруты не используются как feasible successor.
Это не значит, что они не будут использоваться никогда. Если основной линк упадет, роутер отправит EIGRP Query и найдет этот роут. Но балансировка трафика по нему невозможна.
Теперь давайте посмотрим на таблицу топологии Hub роутера для сетей ASBR:
MainOfficeHub#show ip eigrp topology all-links
IP-EIGRP Topology Table for AS(100)/ID(192.168.200.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
! Output omitted
P 172.16.0.0/24, 1 successors, FD is 158720, serno 40
via 192.168.200.2 (158720/156160), FastEthernet0/0
via 192.168.201.2 (161536/158976), FastEthernet0/1
P 172.16.1.0/24, 1 successors, FD is 158720, serno 41
via 192.168.200.2 (158720/156160), FastEthernet0/0
via 192.168.201.2 (161536/158976), FastEthernet0/1
P 172.16.2.0/24, 1 successors, FD is 158720, serno 42
via 192.168.200.2 (158720/156160), FastEthernet0/0
via 192.168.201.2 (161536/158976), FastEthernet0/1
К примеру, у маршрута в сеть 172.16.0.0/24 есть два пути, но у второго метрика FD больше, чем текущая метрика AD для Hub роутера. Потому второй маршрут не установился в таблицу маршрутизации и по нему не происходит балансирование нагрузки.
Вывод
Получилось очень много буков, конфигов и картинок, но с меньшим их количеством объяснить каждый нюанс не получалось. Надеюсь, статья будет полезна тем, кто готовится к сдаче экзамена и хочет еще раз просмотреть все тонкости и скользкие моменты технологии.
P.S. Если кто-то знает, как можно оформить конфиги без выделений синим, но при этом с сохранением порядка знаков, – напишите, пожалуйста, буду очень признателен.