Особливості протоколу маршрутизації EIGRP

Привіт! У цій статті я розповім про цікаві особливості протоколу маршрутизації EIGRP.

Основи EIGRP відмінно описані в одній зі статей циклу СДСМ: 6. Мережі для найменших. Частина шоста. Динамічна маршрутизація.

У першій половині статті коротко описано деякі факти про цей протокол, а в другій - кілька цікавих прикладів з топологією і командами.

Факти про EIGRP

• У лютому 2013 року Cisco вирішила відкрити EIGRP. Варто зазначити, що був відкритий не вихідний код, а лише інформація, необхідна для реалізації протоколу. У підсумку з'явився драфт RFC. Останнє оновлення 10.04.2014. У цьому документі не була розкрита ключова особливість - Stub, без якої користуватися протоколом практично марно. Цікава реакція інших вендорів: на сьогоднішній день ніхто, крім Cisco, не впровадив підтримку цього протоколу в своєму обладнанні.
• EIGRP для розрахунку метрики використовує 5 K-values, які є лише модифікаторами (коефіцієнтами), і 4 значення метрики. Надійність (reliability) і завантаження лінка (load) є динамічними параметрами, тому ці значення перераховуються тільки при зміні в мережі. K5 - це додатковий коефіцієнт надійності, і ніякого відношення до MTU він не має! Нагадаю загальну формулу розрахунку метрики:

А якщо K5 = 0, формула має такий вигляд:

де min_bandwidth - це пропускна здатність найгіршого лінка в kbps,

а total_delay - це сума затримок всіх лінків в мкс (мікросекундах).

Для зміни метрики зазвичай змінюють delay, оскільки bandwidth впливає на QoS, крім цього, зміна bandwidth не завжди змінює метрику (якщо найгірший лінк не змінився).

Мінімальне значення MTU дійсно підраховується, але не приймає ніякої ролі у визначенні кращого шляху. У своїй топології в GNS3 я тестував кілька десятків разів за допомогою команд redistribute connected metric і maximum-paths 1. Незважаючи на різне значення MTU, кращий шлях вибирається той, який був вивчений раніше. Також цікаво, що в драфті RFC згадується додатковий коефіцієнт K6 і 2 додаткових значення метрики: джиттер (jitter) і енергія (energy).

• Feasibility Condition не завжди легко зрозуміти в перший раз. Але логіка дуже проста: якщо ти кажеш мені, що у тебе метрика більше, ніж метрика мого кращого шляху, значить є шанс, що твій шлях проходить через мене, що в свою чергу означає петлю. Через це часто очевидні для інженера «шляхи-без-петлі» можуть не розглядаються протоколом як feasible successors. Пам'ятайте, EIGRP не бачить усієї мережі, а лише те, що говорять сусіди.
• EIGRP - Distance Vector протокол, ніякої гібридності в ньому немає.
• За допомогою show ip eigrp neighbors detail можна подивитися, чи є сусід тупиковим (stub) роутером.
• Пам'ятайте, що за допомогою show ip eigrp topology видно лише successors і feasible successors. Щоб подивитися всі можливі шляхи, необхідно додати ключове слово «all-links»: show ip eigrp topology all-links.
• В IOS 15 нарешті відключена за замовчуванням автоматична сумаризація, ура! Прощавай команда no auto-summary!
• Значення таймерів (hello і hold) можуть бути неоднаковими. До речі, значення таймера hold передається сусідові і означає: «якщо протягом X секунд ти від мене не отримаєш hello, значить я більше недоступний».
• EIGRP використовує свій транспортний протокол (IP protocol number: 88) — RTP (Reliable Transport Protocol). Не варто плутати його з іншим відомим протоколом Real-time Transport Protocol (теж RTP), який використовується для передачі потоків реального часу, наприклад VoIP (у зв'язці з SIP). EIGRP також використовує мультикаст: 224.0.0.10. Не забувайте у вхідному ACL дозволяти EIGRP трафік, наприклад, за допомогою запису: permit eigrp any any.
• Через різні значення адміністративної дистанції (AD) для внутрішніх (90) і зовнішніх (170) маршрутів EIGRP дозволяє уникнути деяких проблем при редистриб'юції (redistribution).
• Пам'ятайте, що 2 роутери можуть бути сусідами, і при цьому у них може не бути adjacency. За допомогою show ip eigrp neighbors показуються лише сусіди. У висновку цієї команди варто звернути увагу на поле Q Cnt: якщо там не нуль, то цілком можливо, що у вас є проблема в мережі (наприклад, невстановлене adjacency).
• EIGRP крім сумарного маршруту може відправити і конкретний специфічний маршрут. Ця особливість називається EIGRP Leak Map. Це корисно, якщо ми хочемо зробити traffic engineering. Ідея дуже схожа на bgp unsuppress-map. Для цього необхідно застосувати команду: ip summary-address eigrp as-number summary-address summary-mask leak-map leak-map-route-map.
• Як вірно додав alk0v, на відміну від OSPF, EIGRP підтримує балансування навантаження при різній метриці (unequal cost load balancing). Для цього необхідно використовувати команду variance. Варто пам'ятати дві речі: це працює тільки для successors/feasible successors і, за замовчуванням, CEF виконує балансування per-destination. Останнє означає, що 2 пакети, у яких відповідні IP адреси відправника і одержувача однакові, завжди будуть виходити з одного і того ж інтерфейсу, що помітно ускладнює перевірку. Якщо ви хочете перевірити це, ви можете перемкнути CEF у режим per-packet (у режимі налаштування інтерфейсу використовуйте команду ip load-sharing per-packet) або взагалі його вимкнути (команда no ip cef у глобальному конфігураційному режимі, не рекомендується).

Ну що, пора зайнятися практикою?

EIGRP Split Horizon

Про цю проблему в мережах виду Hub-and-Spoke (Frame Relay, DMVPN) + EIGRP написано майже в кожній книзі. Так навіщо про це розповідати в черговий раз, та ще й з прикладом, запитаєте ви? А давайте подивимося уважно, тут дуже легко можна потрапити в пастку. Розглянемо наступну топологію Frame-Relay мережі:

Звантажити топологію зі стартовими файлами налаштувань для GNS3 можна тут. Штамп IOS: c3640-jk9s-mz.124-16.bin

Нічого особливого правда? 2 віртуальних з'єднання (PVC), одна загальна мережа 192.168.123.0/24, працює все на фізичних інтерфейсах, а не на саб-інтерфейсах. На кожному роутері також налаштовано Loopback адресу. EIGRP увімкнено на всіх інтерфейсах.

Подивимося таблицю маршрутизації на хабі R1:

У R1 є маршрути до всіх мереж. А тепер на споуці R2:

У R2 чомусь немає маршруту до мережі 3.3.3.0/24.

Ви напевно вже подумки кричите: "Та що тут такого? Очевидно, що необхідно відключити split horizon на інтерфейсі s0/0 роутера R1! "

Давайте перевіримо за допомогою команди show ip interface s0/0:

???

І в цей момент можна легко розгубитися. Це ж була чудова здогадка!

Але я все ж спробую команду no ip split-horizon eigrp 100:

А тепер перевіримо таблицю маршрутизації:

О! З'явився маршрут.

Перевіримо пінг:

Пінгується, все відмінно.

Так в чому ж справа? Чому команда show ip interface s0/0 показала, що split horizon відключений, якщо насправді він був увімкнений? Відповідь проста. Цей рядок говорить лише про те, що split horizon вимкнено для протоколу RIP.

А як тоді подивитися для EIGRP? Взагалі-то ніяк, крім наявності рядка в поточній конфігурації:

До речі, в IOS 15 з'явилася можливість це перевірити за допомогою команди show ip eigrp interfaces detail s0/0.

Ось така цікава особливість.

Але, напевно, вся стаття замислювалася виключно заради наступного прикладу.

EIGRP Router-ID

Розглянемо уважно топологію:

Звантажити файл топології з початковою конфігурацією для GNS3 можна тут. Штамп IOS: c3640-jk9s-mz.124-16.bin.

4 роутери, 2 роутинг домену: OSPF area 0 и EIGRP AS 100. Роутер R1 виконує редистриб'юцію в обидва боки. Loopback0 R1 анонсовано в домен EIGRP, Loopback1 R1 не анонсовано нікуди.

Давайте подивимося на таблицю маршрутизації роутера R2:

Відмінно, маршрути до ospf мереж 172.16.x.0/24 видно, як D EX (EIGRP External, AD 170).

А тепер на таблицю маршрутизації R3:

???

А де маршрути до ospf мереж?

Давайте глянемо на сусідів R1:

Все нормально, правда? І потім, R3 бачить інші EIGRP маршрути: наприклад, 2.2.2.0/24 та 1.1.1.0/24. Наступним кроком було б логічно подивитися роут-мепи на R1 і R2. Але в цьому прикладі я їх не використовував. Якщо не знати в чому причина, то віддебажити дану проблему важко. Тому давайте подивимося в чому справа. На R1 і R3 використовуємо команду show ip eigrp topology:

Так, проблема в однакових eigrp router-id. Є одна чудова, захована в IOS, команда (не видно за допомогою ""? "), яка допоможе зрозуміти, що відбувається: show ip eigrp events на R3.

[Ця команда може допомогти з іншими проблемами з EIGRP]

Ми бачимо, що R3 все ж отримує маршрути до мереж 172.16.x.0/24, але відкидає їх через дублікат router-id.

Виявляється, що в загальному випадку EIGRP все одно, які router-id у вас в AS. Рівно до тих пір, поки на одному з роутерів з однаковим router-id не налаштована редистриб'юція. Тоді інжектовані маршрути отримують спеціальну мітку з router-id роутера, який зробив редистриб'юцію. Якщо роутер отримує маршрут з такою міткою і бачить, що його router-id збігається, то такий маршрут відкидається. Router-id визначається також, як і в OSPF: спеціальною командою або найвищу Loopback адресу, або найвищу IP адресу, якщо немає Loopback.

В даному випадку на роутері R1 є Loopback1: 11.11.11.11, а на R3 була використана команда eigrp router-id 11.11.11.11. Скасуємо її за допомогою ключового слова no і перевіримо таблицю маршрутизації знову:

Маршрути з'явилися, проблема вирішена!

У реальній мережі набагато більш ймовірно, що на двох роутерах можуть бути випадково налаштовані однакові Loopback адреси. Ніколи не чувши про цю проблему, траблшутінг може перетворитися на захоплююче заняття і попсувати чимало нервів.

Якщо ви відчуваєте, що знаєте EIGRP досить добре, то я рекомендую спробувати EIGRP Troubleshoot Lab від GNS3Vault.

Бонус. Key Chain

Це мало стосується EIGRP, але з трійці протоколів маршрутизації EIGRP, OSPF, BGP лише EIGRP використовує key chain для автентифікації. Key chain дозволяє використовувати різні ключі в різний час. Наприклад, ви можете змінити пароль автентифікації EIGRP без обвалення «adjacency». Але подивимося ми на трохи інше. У цього механізму є цікава особливість. Напевно всі знають, що команда service password-encryption використовує алгоритм, що зламується (Type 7). В інтернеті можна знайти багато сайтів, які відновлять пароль з такого хеша. Але, виявляється, що можна змусити сам роутер відновити пароль. Давайте, я покажу як. Спочатку створюємо користувача з паролем у локальній базі даних і включаємо service password-encryption:

Дивимося running config і копіюємо значення хеша:

Тепер створюємо key chain, номер ключа і вводимо цей хеш:

А тепер використовуємо команду show key chain:

Кльово, правда?)

Сподіваюся, що вам сподобалося!