Особливості протоколу маршрутизації 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 показуються всі сусіди, а для того, щоб дізнатися, чи є сусід суміжним (adjacent), необхідно переконатися, що значення в поле Q Cnt одно 0.
  •  
  • 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 .
  •  
Ну що, пора зайнятися практикою?
 
 
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 :
 
 
 
Кльово, правда? :)
Сподіваюся, що вам сподобалося!

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.