Заметки к CCNP Route: EIGRP часть 1

dynamic routing is sexyNo rest for the wicked. Прошел почти месяц со сдачи экзамена NCDA и вот я уже ощущаю непонятный зуд и, похоже, это не глисты. Самый простой для меня способ что-то запомнить – это написать статью, чем я, собственно, и собираюсь заняться, раскрыв темы по EIGRP, OSPF, BGP и др.

Освежим в памяти материал по EIGRP из CCNA трэка, прежде чем залезать по колено в хардкор.

Преимущества EIGRP:
  • позволяет осуществлять балансировку нагрузки по маршрутам с разной метрикой;
  • позволяет легко и быстро производить префиксную агрегацию (routing summarization) в любой точке;
  • хранит в таблице топологии (topology table) резервный маршрут (feasible successor) и позволяет практически моментально на него переключиться, в отличии от RIP, который начинает лихорадочно искать соседей или OSPF, который хранит всю таблицу целиком и в случае пропажи маршрута будет вынужден запустить жадный до ресурсов алгоритм поиска кратчайшего пути;
  • потребляет меньше ресурсов чем OSPF;
  • меньше условий для установления соседства, чем у OSPF, легче настройка
Почему нет?
EIGRP таблицы и прочая терминология
  • neighbor table – содержит directly connected соседей, в которых, в отличии от того же RIP, который просто рассылает на Multicast адрес сведения о сетях.
  • topology table – таблица, которая содержит не только основной маршрут до указанной сети (successor), но и возможные резервные маршруты (feasible successor);
  • routing table – общая таблица маршрутизации, для которой EIGRP отбирает только самые сочные маршруты;
  • feasible distance (FD) – дистанция, показывающая насколько далеко сеть находится от вашего маршрутизатора;
  • advertised distance (AD) или reported distance (RD) – дистанция, по которой можно оценить насколько далеко сеть находится от соседа, который разослал анонс;
  • successor – основной маршрут;
  • feasible successor (FS) – резервный, возможный маршрут;
  • feasible сondition (FC) – есть механизм предотвращения петель. Чтобы маршрут стал feasible successor должно быть выполнено следующее условие: reported distance резервного маршрута должна быть меньше, чем feasible distance основного;
  • active – DUAL весь в мыле, считаем метрики, ищет маршруты – не бро;
  • passive – DUAL все досчитал и отдыхает – бро
Типы EIGRP пакетов

EIGRP в своей работе использует 5 различных типов пакетов:

  • Hello – EIGRP отправляет Hello пакеты с того момента как протокол был включен на маршрутизаторе для определенной сети. Эти пакеты используются для идентификации соседей и с того момента как маршрутизатор получает Hello пакет соседа они начинают выполнять функцию keepalive. EIGRP Hello отправляются на multicast адрес 224.0.0.10. Hello пакеты не требуют подтверждения (ACK) о том, что они были приняты.
  • Acknowledgement (ACK) – EIGRP ACK пакет представляет собой Hello пакет, не содержащий никакой информации. Эти пакеты используются протоколом как гарантированное подтверждение доставки других пакетов (update, query, reply). ACK, в отличии от Hello, отправляются на unicast адрес, значащийся в source adress отправителя пакета, требующего подтверждения доставки.
  • Update – служат для передачи маршрутной информации. После того как сосед был обнаружен отправляются update пакеты с тем, чтобы сосед смог сформировать topology table. В таком случае update передается на unicast адрес соседа, однако так происходит не всегда. Так, в случае изменения характеристик канала (а значит изменение его коэффициента) update отправляется на multicast адрес. Update пакет требует подтверждения о доставке.
  • Query – эти пакеты служат для запроса информации по маршрутам. EIGRP отправляет query пакеты на multicast адрес соседям в том случае если маршрут не достижим или нужно запросить его статус для быстрой сходимости. В том случае если маршрутизатор не получает ответ от соседа(ей) на свой Query пакет от засылает его снова, в этот раз в виде unicast.
  • Reply – отправляются unicast’ом в ответ на Query, говоря соседу о том, что все ок, вот он Feasible Successor, не проваливайся в Active State.
  • Request – могут отправляться unicast’ом и multicast’ом, не требуют подтверждения о доставке. Служат для запроса специфичной информации от одного или нескольких соседей.
Формирования соседства, обработка исчезновения соседа и/или маршрута

Представим ситуацию, когда у R1 появился сосед R2 (а это значит совпадают AS и k-values):

  1. R2 отправляет Hello на multicast адрес (224.0.0.10).
  2. R1 отправляет пустой Update на unicast адрес R2 с установленным init bit.
  3. R2 отвечает ACK
  4. R1 отправляет Update с topology table.
Если в процессе появляются или исчезают новые сеточки, то соседи рассказывают об этом в update и ожидают в ответ услышать ack.

Если в процессе R2 куда-то пропадает, а у R1 имеются другие соседи, то он начинает докучать их (пакет query) запросами о том, не знают ли они как достичь сети, доступ к которым изначально проходил через R2. На что R1 должен будет придти ответ (reply) о том, что маршрут найден и метрика до него составляет столько-то, либо о том, что маршрут не найден, метрика бесконечность (а, точнее 4.2 с чем-то миллиарда), звиняйте. Таймаут на получения ответа на запрос – 3 минуты, после этого включается механизм stuck in active, о котором мы поговорим в части два.

Механизм подсчета метрики

Есть 5 коэффициентов, которые участвуют в этом процессе:

  • bandwidth (k1)
  • delay (k3)
  • reliablitiy (k4 и k5)
  • load (k2)

Формула выглядит следующим образом и от нее меня пучит:

metric = k1 * bw ((k2 * bw)/(256 – load)) + k3*delay) * (k5/reliablitiy + k4)

Хорошо, что по умолчанию k2, k4 и k5 равны 0, а значит формула принимает вид:

И чтобы вам не говорили на форумах, в старых книгах и других злачных местах – MTU не участвует в процессе расчета метрики. Вообще. Тем не менее сосед информируется о нем, MTU помещается в topology table, но в отличии от ospf, mtu mismatch не влияет на установление соседства.

Если метрики одинаковые, то коммутатор выберет маршрут с большим MTU.

Базовая настройка

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

Начнем с CoreRouter:

CoreRouter(config)#router eigrp 100
! EIGRP теперь бесклассовый протокола маршрутизации
CoreRouter(config-router)#no auto-summary
! по поводу суммаризации на CoreRouter политика молчит
CoreRouter(config-router)#network 192.168.0.0 0.0.7.255
CoreRouter(config-router)#network 10.0.0.0
CoreRouter(config-router)#^Z
! с этого момента можно считать что процесс EIGRP запущен
! проверим с помощью show ip protocols
CoreRouter#sh ip protocols
--- опущено --- 
  Routing for Networks:
    10.0.0.0
    192.168.0.0/21
--- опущено ---

О чем говорит выражение network network wildcard_mask ? Это значит маршрутизатор должен будет отправлять Hello пакеты c интерфейсов, попадающих под это значение , а так же рассказывать о данных сетях другим маршрутизаторам. Brnch1:

Brnch1(config)#router eigrp 100
Brnch1(config-router)#no auto-summary
Brnch1(config-router)#network 10.1.1.0 0.0.0.3
Brnch1(config-router)#network 172.16.0.0 0.0.0.255
Brnch1(config-router)#network 172.17.0.0 0.0.0.31

А с brnch2 позволим себе небольшой hack. Допустим вы на экзамене и у вас нет времени высчитывать wildcard mask для /15 сети, к примеру. Вместо этого можно запустить процесс EIGRP непосредственно на интерфейсе, заставляя только его формировать соседства и оповещать о присоединенной к нему сети.

Brnch2(config)#router eigrp 100
Brnch2(config-router)#network 10.2.2.2 0.0.0.0
Brnch2(config-router)#network 172.16.0.0 0.0.0.255

Проверим связность, посмотрим соседей:

Brnch2#sh ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   172.16.0.1              Fa0/0             12 00:00:48 2634  5000  0  18
0   10.2.2.1                Se1/0             11 00:19:37  101   606  0  29

Где:

  • H – говорит нам о том, в какой последовательности были заучены соседи;
  • Address – адрес соседа;
  • Interface – интерфейс, за которым находится сосед;
  • Hold – таймер, по истечению времени которого будет принято решение о том через сколько времени сосед будет признан погибшим. Обновляется hello пакетами каждые 5 секунд и по умолчанию равен времени между отправкой hello пакетов умноженным на 3;
  • SRTT – source round trip timer – время, которое требуется для прохождения пакета до соседа и обратно
  • RTO – retransmit timeout – время, через которое будет отправлено повторное сообщение;
  • Q – количество пакетов, которое должно быть отправлено этому соседу. Отличное от нуля значение говорит о том, что на интерфейс перегружен;
  • Seq – версия базы данных;

Посмотрим на маршруты, полученные из eigrp:

CoreRouter#sh ip route eigrp
      172.16.0.0/24 is subnetted, 1 subnets
D        172.16.0.0 [90/2172416] via 10.2.2.2, 00:06:49, Serial1/0
      172.17.0.0/27 is subnetted, 1 subnets
D        172.17.0.0 [90/2174976] via 10.2.2.2, 00:06:49, Serial1/0

Не смотря на то, что путь до 172.17.0.0/27 кажется ближе через Brnch1 (1 hop) CoreRouter выбрал путь через Brnch2 из-за лучших условий (bandwidth & delay).

CoreRouter#sh ip eigrp topology
--- опущено ---
P 172.17.0.0/27, 1 successors, FD is 2174976
        via 10.2.2.2 (2174976/30720), Serial1/0
        via 10.1.1.2 (5514496/28160), Serial1/1
--- опущено ---

при этом Brnch1 помечен как FS и в случае утраты связности трафик пойдет через него. А все почему? Потому что RD у FS Brnch1 (28160) меньше, чем FD у Successor’а (2174976) Brnch2.

Обязательную программу откатали, теперь посмотрим на дополнительную.

Редистрибуция маршрута по умолчанию

Можно сделать это 4-мя способами

  • ip route network/mask и redistribute static (external route)
  • ip route 0.0.0.0/0 и network 0.0.0.0 (internal route)
  • ip default-network network и network network (internal route)
  • ip summary-address eigrp AS 0.0.0.0 0.0.0.0

Например, мы хотим всем рассказать про то, что мы знаем маршрут до волшебной сети 0.0.0.0/0. После соответствующей конфигурации в таблице маршрутизации на branch-маршрутизаторах мы сможем лицезреть следующее. По

BrnchX#sh ip route
--- опущено ---
Gateway of last resort is 10.2.2.1 to network 0.0.0.0
D*EX  0.0.0.0/0 [170/2681856] via 10.2.2.1, 00:00:07, Serial1/0
-- опущено ---

Иногда просят (экзамены, собеседования, you name it) передать по eigrp маршрут по умолчанию в какую-либо сеть без использования  redistribute static. Можно это сделать с помощью второго способа.

Brnch2#sh ip route
--- опущено ---
Gateway of last resort is not set
D*    192.168.0.0/24 [90/2681856] via 10.2.2.1, 00:10:33, Serial1/0
--- опущено ---

В этом случае рядам с маршрутом появится звезда, означающая что этот маршрут – candidate default. Обратите внимание, что команда default-network полноклассовая.

Если мы хотим чтобы информация поступала, но маршрут в это сеть не становился candidate default, то в режиме конфигурации автономной системы нужно подать команду:

No default-information allowed in
Passive-Interface

И вот, немного вспотев, мы таки настроили EIGRP. Но тут выясняется, что в 172.17.0.0/27 сетке обитает кулхацкер, который может свести все усилия на нет и испортить всю таблицу маршрутизации , притащив на работу тот же GNS3, . Так как про аутентификацию, которая будет в следующей статье, мы еще не читали, а с нависшей опасностью надо сделать что-то еще вчера, то давайте-ка познакомимся с функционалом passive interface.

Как вы помните смысл команды network – отправлять с интерфейса hello приглашения на установления соседства и рассказывать о присоединенных сетях. Passive-interface убирает только рассылку hello пакетов.

Brnch1(config-if)#router eigr 100
Brnch1(config-router)#passive-interface fastEthernet 0/1
Brnch1(config-router)#do sh ip proto
--- опущено ---
  Routing for Networks:
    10.1.1.2/32
    10.1.1.0/30
    172.16.0.0/24
 172.17.0.0/27
  Passive Interface(s):
 FastEthernet0/1
--- опущено ---

Cool, eh? Сеть объявляй@соседства не формируй.

А что если такие интерфейсов с добрый десяток, спросит меня любопытный читатель? Не проблема, отвечу я:

CoreRouter(config)#router eigrp 100
CoreRouter(config-router)#passive-interface default
! ой-ой, теперь все пассивные
*Aug 31 17:48:42.243: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.1.2 (Serial1/1) is down: interface passive *Aug 31 17:48:42.279: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.2.2.2 (Serial1/0) is down: interface passive 
CoreRouter(config-router)#no passive-interface serial 1/0
CoreRouter(config-router)#no passive-interface serial 1/1
*Aug 31 17:48:48.723: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.2.2.2 (Serial1/0) is up: new adjacency *Aug 31 17:48:49.899: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.1.2 (Serial1/1) is up: new adjacency 
Summarization

Осталось навести лоск и снизить количество анонсируемых маршрутов из центрального офиса, суммаризировав 192.168.1.0/24-192.168.3.0/24 в 192.168.0.0/22.

CoreRouter(config)#int s1/0
CoreRouter(config-if)#ip summary-address eigrp 100 192.168.0.0 255.255.252.0
Brnch2#sh ip route eigrp
--- опущено ---
D     192.168.0.0/22 [90/2172416] via 10.2.2.1, 00:06:39, Serial1/0
D     192.168.1.0/24 [90/5517056] via 172.16.0.1, 00:06:39, FastEthernet0/0
D     192.168.2.0/24 [90/5517056] via 172.16.0.1, 00:06:39, FastEthernet0/0
D     192.168.3.0/24 [90/5517056] via 172.16.0.1, 00:06:39, FastEthernet0/0
D     192.168.4.0/24 [90/2172416] via 10.2.2.1, 00:18:31, Serial1/0

“Но что за фигня?!” – спросите вы. Brnch2 все равно видит 192.168.1.0/24-192.168.3.0/24 как отдельные сети, да еще и получает их с Brnch1. Все верно, тут играет правило longest prefix match, по которому в таблицу маршрутизации попадают маршруты с наиболее длинным префиксом. Повторив процедуру на другом serial-интерфейсе CoreRouter, смотрящим в сторону Brnch1, мы нормализуем ситуацию:

Brnch2(config-router)#do sh ip route
--- опущено ---
D     192.168.0.0/22 [90/2172416] via 10.2.2.1, 00:14:31, Serial1/0
D     192.168.4.0/24 [90/2172416] via 10.2.2.1, 00:26:23, Serial1/0

Вот теперь полный порядок.

Метрика для суммарного маршрута выбирается так: берется наименьшая метрика из всех маршрутов, входящих в суммаризированный.

Помимо очевидных плюсов:

  • меньше таблицы маршрутизации
  • уменьшено количество целей для query-запросов
  • поддержка суммаризации в любой точке сети
  • суммарный маршрут имеет метрику, аналогичную лучшей метрике из всех суммаризированных сетей

Есть и минусы:

  • может быть выбран не оптимальный путь
  • пакеты, направляемые до сети, связность с которой утеряна, таки дойдут до маршрутизатора, производящего суммаризацию
Variance

Смысл variance состоит в том, чтобы помещать в таблицу маршрутизации маршрут feasible successor, метрика которого хуже. В нашем случае

CoreRouter(config)#do sh ip eig topo
--- опущено ---
P 172.16.0.0/24, 1 successors, FD is 2172416
        via 10.2.2.2 (2172416/28160), Serial1/0
        via 10.1.1.2 (5514496/28160), Serial1/1
--- опущено ---

канал между CoreRouter и Brnch1 хуже в 2.5 раза (5514496/2172416), чем канал между CoreRouter и Brnch2. По умолчанию variance равно 1 и балансировка производится между маршрутами с одинаковыми метриками. Изменим это, получив балансировку между двумя каналами:

CoreRouter(config)#router eigrp 100
CoreRouter(config-router)#variance 3
CoreRouter(config-router)#do sh ip route
--- опущено ---
D        172.16.0.0 [90/2172416] via 10.2.2.2, 00:00:04, Serial1/0
                    [90/5514496] via 10.1.1.2, 00:00:04, Serial1/1
      172.17.0.0/27 is subnetted, 1 subnets
D        172.17.0.0 [90/2174976] via 10.2.2.2, 00:00:04, Serial1/0
                    [90/5514496] via 10.1.1.2, 00:00:04, Serial1/1
--- опущено ---

При чем будет осуществлена интеллектуальная балансировка. В этом случае 3 пакета отправятся по CoreRouter – Brnch2 пути, 1 пакет по CoreRouter – Brnch1.

На сегодня все. Обещаю больше хардкора в части 2.

  • Все хорошо, но еще бы чуть подробнее раскрывали теории – вообще замечательно бы было. Касается вообще большинства статей.

  • Чего не хватает? Пишите – дополним :)

  • Кирилл

    Все хорошо. Вот только командой passive-int [int/int_num] мы запрещаем не только рассылку Hello-сообещний, но и рассылку маршрутов – т.е. говорим раутеру не общаться с другими раутерами по eigrp через этот интерфейс вообще никак (это можно легко проверить, имея под рукой даже GNS). Во такой вот вариант ручного управления наилучшим маршрутом.

    When the passive-interface command is used in EIGRP, the router cannot form neighbor adjacencies on the interface, or send or receive routing updates ©Cisco.com

  • Нет hello, нет adjacency, нет анонсов маршрутов. Все справедливо :)

  • Кирилл

    Значит я слегка не верно понял в тексте статьи резюмирующую строчку “Cool, eh? Сеть объявляй@соседства не формируй.” НУ сам виноват :”)
    Спасибо за статьи, кстати. Пригождаются, чтобы быстренько освежить в памяти наглухо забытые технологии :”) Жалко только, что по MP-BGP, MPLS и прочего нет :”) Хотя это вроде в курсе BSCI не читают…

  • Денис

    Спасибо за статьи, полезно и отлично написано.

    Одно хочется поправить, то что формула метрики должна быть какой-то такой:

    EIGRP Metric = 256*((K1*Bw) + (K2*Bw)/(256-Load) + K3*Delay)*(K5/(Reliability + K4)))

    K1 = Bandwidth
    K2 = Load
    K3 = Delay
    K4 = Reliability
    K5 = Maximum Transmission Unit (MTU)

  • MTU не принимает участие в подсчете метрики.

  • Денис

    MTU приводится в таблице 7-4 (стр 353) серт. гайда BSCN.

    я более свежие гайды ещё не смотрел, там изменения?

  • Да. Если вы возьмете любой свежий IOS в этом можно будет убедиться на практике :)

    Так же можно заняться редистрибуцией в EIGRP из других IGP с различными значениями MTU и посмотреть как (не) меняется метрика.

  • Денис

    ох=)
    значит, зря я люблю по старым гайдам готовится

  • Stas Lavrin

    немного хочу поправить тему формирование соседства.

    1. R1 отправляет hello > R2
    /// тип пакета hello никогда не подтверждается
    2. R2 отправляет свой hello > R1
    /// каждый шлет свой hello отдельно и независимо. так же замечу, что это не ответный hello. (чтобы не получилось что R1 сказал всем привет, и ему в ответ все привет,привет, привет )
    3. После этого когда R1 и R2 друг друга увидели. Что это значит ? это значит что пакет пришел на тот же интерфейс с которого ушел. (он же не подтверждается)
    4. Ставится сессия на соседа. (появление соседских отношений)
    5. Передача update – основного рабочего пакета который передает маршрут.
    //// Причем начинает передавать тот роутер у кого ip-адрес больше.
    6. А вот он уже подтверждается ack

    Итого по пакетам имеем
    hello – никогда не подтверждается
    ПАРЫ
    Ack – ответ на Update
    Reply ответ на Query

  • Спасибо за исправление, обновил секции с типами пакетов и с формированием соседства. С ACK в ответ на Hello вышел косяк.

    Можно пруф по поводу большего IP? В литературе пишут, что маршрутизатор генерирует пустой Update пакет с init bit в ответ на Hello от доселе неизвестного маршрутизатора.

    По поводу ACK в ответ на Update верно, Reply в ответ на Query верно, только сами пакеты Reply и Query требуют подтверждения о доставке – ACK.

  • Alexey

    По поводу вычисления метрики хочу обратить внимание, что “slowest bw” в формуле metric (default) = 256 * (slowest bw + summ of all links delays). На самом деле НЕ величина bandwidth – т.е. не скорость канала (интерфейса), а 10000000/bandwidth (Kbit/c). Что логично, иначе получалось бы, что чем больше скорость, тем больше метрика. Непонятно только зачем вносят путаницу, лучше бы в формуле сразу писали её в знаменателе.
    ПС MTU учитывается при выборе маршрута. Если метрика одинаковая, то используется маршрут с бОльшим MTU.

  • Алексей, ценные дополнения, спасибо. Внесу исправления в статью.