No 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):
- R2 отправляет Hello на multicast адрес (224.0.0.10).
- R1 отправляет пустой Update на unicast адрес R2 с установленным init bit.
- R2 отвечает ACK
- R1 отправляет Update с topology table.
Если в процессе 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.