CCNP Route "Full Scale" Лаба: EIGRP

План неизменен:
Advanced IGP routing  (IPv4)

- Configure authentication (plain-text, MD5)
- Metris
- Load balancing (equal, unequal)
- Configure Summarization

Все посты по CCNP Route.

Authentication

Конфигурация аутентификации схожа с таковой в RIP, также используются связки ключей. Однако в EIGRP нет возможности настроить plain-text аутентификацию вообще.

Итак, предлагаю настроить md5 между E1 и E3 на линках E0/0. Конечно же, как это часто бывает в EIGRP, команды будут отличаться...

B4-E1-R1(config)#key chain EIGRPKEY
B4-E1-R1(config-keychain)#key 1
B4-E1-R1(config-keychain-key)#key-string EIGRPKEY

B4-E1-R1(config)#int e0/0
B4-E1-R1(config-if)#ip authentication mode eigrp 90 md5

*Sep 13 08:09:59.421: %DUAL-5-NBRCHANGE: EIGRP-IPv4 90: Neighbor 10.30.13.2 (Ethernet0/0) is down: authentication mode changed

B4-E1-R1(config-if)#ip authentication key-chain eigrp 90 EIGRPKEY

Ну вот почему не сделать команду унифицированной ip {rip | ospf | eigrp} authentication...

Ладно, настроим симметричный конфиг на E3. Кстати, на весь процесс аутентификацию настроить тоже не получится, только per interface. Конфигурация на E3 полностью идентична.

Metrics

Метрика - мощная штука в EIGRP. Ей посвящены целые "простыни" на специализированных форумах и труды вроде EIGRP_Metric_Calculation_Demystified. Основных вопросов два. 

Первый вопрос комплексный. Передается ли метрика в апдейтах или нет? Добавляет ли роутер к метрике в апдейте свою метрику или каждый роутер считает метрику сам?

Ответ: Каждый роутер считает метрику сам. В апдейтах содержится только следующее (выделенное жирным участвует в калькулировании метрики на каждом роутере независимо)

• Подсеть и префикс
• Delay
• Bandwidth
• Load
• Reliability
• MTU
• Hop Count

Второй вопрос - Почему часто возникает разница между метрикой из команд show и посчитанной в ручную. 

Ответ: Роутер на любом этапе калькулирования отбрасывает десятичную часть.

Все это мы сейчас рассмотрим не примере, "hop by hop" скажем так. Для примера возьмем подсеть 10.31.0.0/16, которая настроена на одном из loopback интерфейсов на E1. Далее посмотрим как информация об этой сети распространяется к другим устройствам и как они калькулируют свои метрики.

Заходим на E1 и смотрим что же процесс EIGRP знает про этот префикс.

 

Ну, во-первых, роут находится в состоянии Passive и это хорошо. Если бы он находился в состоянии Active, это бы значило, что маршрутизатор активно пытается восстановить доступность путем отправки Query сообщений.

Для этого префикса есть один Successor с просчитаной  FD равной 128256. Это число маршрутизатор посчитал сам взяв за основу вывод из команды чуть ниже.

Маршрут может состоять из нескольких Descriptor Bloсk'ов. Однако в данном случае, он один. Просто потому что Е1 является источником этого маршрута.

Далее видно, что интересующая нас подсеть 10.31.0.0/16 доступна через 0.0.0.0 и интерфейса lo30. Это значит, что данная сеть терминируется локально. Далее так и написано - Connected. Строчкой ниже видна композитная метрика для этого префикса (128256/0). Первую часть мы разберем уже скоро, а вторая часть равно нулю. Это Reported Distance - та стоимость до сети, которую имеет наш сосед. Однако у нас про эту сеть никто ничего не рассказывал, поэтому и стоимость равна нулю.

Ну а тут самое интересное. Минимальная ширина канала для этого префикса равна 8000000 Kbit. Маршрут локальный, поэтому минимальная ширина в нашем случае это bandwidth с lo интерфейса. Такая же история и с суммарной задержкой, сейчас про сумму речь не идет, это просто задержка на Lo30. Это можно проверить командой sh ip int lo30

По умолчанию, reliability и load при подсчете не учитывается. Мы отходить от такого поведения не будем, более того, сама Cisco не рекомендует без особой надобности модифицировать алгоритм.

Далее в show ip eigrp topo видно значение MTU. Вопреки заблуждениям, MTU не участвует в калькулировании метрики, а используется только когда нужно выбрать один маршрут из двух одинаковых. Тогда выбирается маршрут с наибольшим MTU.

Hop count равен 0, что указывает на то, что роутер Е1 является источником этого маршрута. Это же явно указано строчкой ниже, Originating router is 10.0.30.1.

Пришло время посчитать метрику руками.

Metic = (10^7/LeastBandwidth in kbps + CumulativeDelay in TensOfMicroseconds) * 256

Короче, берем Bandwidth равный 8000000. Он у нас уже в kbps. 

Теперь берем Delay равный 5000 и делим его на 10, чтобы получить Tens of Microsecond.

Подставляем все это в формулу.

Metric = (10000000/8000000 + 500) * 256 = (1.25 + 500) * 256 = 128320

Как видно, мы почти попали в нужное значение 128256. Как я уже говорил, на любом этапе нужно отбрасывать десятичную часть. В нашем случае 10000000/8000000 = 1, а не 1.25

Metric = (10000000/8000000 + 500) * 256 = (1 + 500) * 256 = 128256

Бинго!

Теперь E1 передает апдейт в сторону своих соседей E3 и E4. Ниже кусок дампа Update сообщения. Довольно много информации, но сейчас нас интересует только та, что находится в секции Wide Metric, а именно Delay, Bandwidth, Reliability, Load, MTU.

Как я уже говорил, этот апдейт уходит по двум линкам от E1 к Е3 и Е4. Те, обработав его, отправляют его дальше. Давайте посмотрим на Е3.

E3 получает информацию о 10.31.0.0/16 от трех маршрутизаторов.

Верхняя запись - "оригинальное" сообщение от Е1

Вторая запись - уже прошедшее через Е4 сообщение

Нижний блок представляет из себя сообщение, которое прошло через Е3, а затем ещё и через Е7.

Вывод может показаться странным. Update пришел со стороны Е7, но не пришел от Е5 и Е6. Почему? Ответ простой - Е5 и Е7 настроены как стаб роутеры. А стаб роутер, как известно, не должен передавать трафик между двумя другими EIGRP маршрутизаторами. Вот именно это поведение и показывают два стаб роутера - E5 и E6.

Ладно, возьмем первый анонс, который получен напрямую от E1. Понятно, что это самый лучший маршрут. Посчитаем метрику для него.

Для начала FD. Нам понадобится наименьший bandwidth и суммарный Delay. Помним, какие значения приходят в анонсе от E1. Это Delay = 5000ms и bandwidth = 8000000kbit. Теперь нужно посмотреть что там у нас на интерфейсе в сторону Е1. Нужно это для того чтобы узнать delay и bandwidth, которые мы будем далее использовать в формуле.

BW = 10000kbit, DLY = 1000usec. В итоговой формуле нас интересует CumulativeDelay = 5000 + 1000 = 6000ms. Ну и нам надо выбрать наименьший bandwidth, равен он 10000kbit. Теперь считаем.

Metic = (10^7/LeastBandwidth in kbps + CumulativeDelay in TensOfMicroseconds) * 256

Metric = (10000000/10000 + 600) * 256 = 1600 * 256 = 409600

Подобным образом E3 поступает со всеми апдейтами, которые к нему пришли. 

Теперь нужно посчитать RD. На самом деле мы её уже посчитали для первого маршрута. Е3, для того чтобы посчитать ее, просто возьмет данные из апдейта и засунет в формулу и получит те самые 128256.

Теперь пришло время посмотреть, а есть ли для Successor маршрута Feasible Successor... В этом вся сила EIGRP. 

Если RD потенциального запасного маршрута меньше, чем FD рабочего, то он становится Feasible Successor.

Сначала, E3 посчитал все FD и выбрал наименьший - это его рабочий основной маршрут.

В выводе sh ip eigrp topo, все FD указаны в первой части метрики. Вторая часть метрики - RD. Это та метрика, которую имеет до этого префикса сосед, который про эту метрику и рассказал. Стоит помнить важный момент - сама метрика между роутерами не передается, каждый считает её сам. Для упрощения понимания,  уберем роутер Е7, понятно, что он точно не Feasible Successor.

Кратчайший путь от E4 до Е1 (FD) имеет метрику 409600. E3 при просчете метрики со своей стороны трактует это число как RD. Это и видно в выводе.

Здесь условие не выполняется, потому что RD равен FD, а должен быть меньше. Отличный прецедент для того, чтобы подкрутить метрику.

Здесь, в рамках CCNP Route, нам предлагается несколько вариантов.

1. Менять bandwidth (так себе способ).
2. Менять delay.
3. Менять метрику добавляя к ней некий offset

Допустим, наша задача сейчас сделать так, чтобы маршрут через E4 для E3 стал Feasible Successor машрутом. Для этого нам достаточно уменьшить RD хотя бы на единицу.

Для начала сделаем это поменяв Delay. Чем меньше Delay, тем лучше становится метрика. Немного улучшим метрику от E4 до Е1, уменьшим Delay на линке e0/2. Для начала глянем, какая метрика выставлена по умолчанию. И должно быть это число равным 1000ms.

Очевидный шаг - зайти на интерфейс и написать delay 900. Но это неправильно, потому что конфигурится delay в десятках микросекунд. )

Так что правильная команда - delay 90. После чего, можно идти на E3 и смотреть что там с метрикой.

407040 < 409600, теперь условие выполняется, а значит у нас появился Feasible Successor. Красота, теперь переключение трафика на запасной маршрут будет очень быстрым.

Теперь заморочимся с offset листом. Инструмент этот мы уже использовали, так что быстренько настроим и пойдем дальше. С помощью этого инструмента можно только добавлять к метрике некоторое количество единиц, отнять не получится. Поэтому для префикса 10.31.0.0/16, который приходит от E1 к Е3 в интерфейс eth0/0, ухудшим метрику на единицу.

E3-R2(config)#access-list 11 permit 10.31.0.0 /16

E3-R2(config)#router eigrp 90
E3-R2(config-router)#offset-list 11 in 1 ethernet 0/0

*Sep 13 06:35:58.775: %DUAL-5-NBRCHANGE: EIGRP-IPv4 90: Neighbor 10.30.13.1 (Ethernet0/0) is resync: intf route configuration changed

Определяем префикс простым ACL, выбираем интерфейс на котором хотим увеличить метрику на единичку и направление. В нашем случае, это интерфейс eth0/0 и входящее направление. Далее соседство обновляется и мы также получаем две записи в таблице топологий.

Load balancing

Тут мы подходим ко второй "киллер-фиче" EIGRP - Unequal load balancing. Штука эта, конечно, классная, но вот в жизни я её так и не повидал пока. По умолчанию этот режим выключен и, как и в RIP с OSPF, происходит балансировка между равноценными маршрутами с параметром maximum-paths равным 4.

Управлять Unequal load balancing (load sharing) можно с помощью параметра variance. По умолчанию он равен единице. Рассмотрим все тот же пример с 10.31.0.0/16 на Е3.

E3 знает как добраться до 10.31.0.0/16 с помощью трех путей. FD этих путей 409601, 435200 и 2349056.

Помним, что первый маршрут является у нас "сакцессором", а второй "физибл саксессером". Третий маршрут, подчеркиваю, ни тем ни другим не является.

С дефолтными настройками variance = 1, maximum-paths = 4 только один маршрут попадет в таблицу маршрутизации. Для того чтобы узнать это нужно перемножить метрику "сакцессора" на значение variance. Т.е. по молчанию только маршруты с одинаковой метрикой будут добавлены в таблицу маршрутизации для балансировки, причем таких маршрутов может быть до 4. Проверяем, что маршрут действительно один.

А теперь мы хотим добавить второй маршрут и балансировать трафик между ними (причем балансировка будет происходить согласно метрике, т.е. больше трафика будет идти по лучшему маршруту). Сделать такой финт нам поможет увеличение значения variance. Нам нужно, чтобы число 435200 туда тоже попало. Самое близкое значение, увы, 2. Таки образом, 409601 * 2 = 819202,
435200 точно пападает. )

E3-R2(config)#router eigrp 90
E3-R2(config-router)#variance 2

Вуаля!

Теперь трафик будет балансироваться. А вот добавить сюда третий маршрут с метрикой 2349056 без дополнительного тюнинга метрики не получится, даже выставив variance в подходящее значение. Почему? Потому что только Successor и Feaseble Successor маршруты могут быть добавлены в таблицу маршрутизации. Чтобы поместить роут через Е7 в таблицу, нам нужно улучшить его RD. С точки зрения реальной жизни, смысла в этом нет никакого. Нам надо уменьшить RD до значения, которое будет меньше 409601. Только вот у самого E7 FD равен 409600. )

Cчитаем, что с балансировкой разобрались.

Summarization

В EIGRP суммаризовать можно где угодно, потому что протокол этот distance-vector'ный. Делается это командой ip summary-address eigrp на интерфейсе.

Предлагаю добавить несколько сетей на Е7 и настроить суммаризацию на нем. Заодно убедимся в том, что стаб роутер передает суммарный маршрут по умолчанию.

E5#sh run int lo1000
Building configuration...

Current configuration : 200 bytes
!
interface Loopback1000
 ip address 10.1.1.1 255.255.255.0 secondary
 ip address 10.1.2.1 255.255.255.0 secondary
 ip address 10.1.3.1 255.255.255.0 secondary
 ip address 10.1.0.1 255.255.255.0
end

E5(config)#router eigrp 90
E5(config-router)#network 10.1.0.0 0.0.255.255
E5(config-router)#no passive-interface lo1000

Апдейты про эти сети уходят на всех соседей, а именно на E3, E4 и E6. Последний не передает информацию дальше, потому что является стаб роутером. Давайте взглянем как ситуация сложилось на E3.

Для того, чтобы достичь сети 10.1.0.0/24, которую анонсирует E5, мы будем отправлять трафик через E4 или через E1. Казалось бы самый выгодный маршрут не выбран. Какие вообще варианты есть у E3?

Через Е4, Е1, Е7 и Е5 соответственно. Получилось так из-за того, что разница в delay и bandwidth на этих линках довольно значительна. Тут у нас противостояние прогрессивного Ethernet'a и медленных Serial интерфейсов. Борьба больших пропускных и маленьких задержек с маленькими пропускными и большими задержками. Суммарные задержки через сериальные интерфейсы измеряются десятками тысяч микросекунд, а вот Ethernet хвастается тысячами. С пропускной обратная ситуация, 1500Kbit против 10000.

Это приводит к тому, что трафик идет не самым коротким, зато (якобы) быстрым путем.

Так, суммаризация...

E5(config)#int serial 1/0.100
E5(config-subif)#ip summary-address eigrp 90 10.1.0.0 255.255.0.0

*Sep 13 10:00:52.517: %DUAL-5-NBRCHANGE: EIGRP-IPv4 90: Neighbor 10.30.35.1 (Serial1/0.100) is resync: summary configured

E5(config)#int e0/0
E5(config-if)#ip summary-address eigrp 90 10.1.0.0 255.255.0.0

*Sep 13 10:01:09.557: %DUAL-5-NBRCHANGE: EIGRP-IPv4 90: Neighbor 10.30.45.1 (Ethernet0/0) is resync: summary configured

После чего на Е3 видно только суммарный маршрут.

Пока все. Что называется, "галопом по Европам". За кадром осталось много интересного, попытаемся всему этому посвятить отдельный пост, подобно тому, как я делал это для OSPF LSA Types.