Сусід EIGRP чи транзит DMVPN? Спершу перевірте роль

Сусідства немає, і маршрутизатор посередині виглядає очевидним підозрюваним. Можливо, він невинний. Пересилання зовнішніх пакетів тунелю й участь у протоколі маршрутизації overlay — дві різні задачі, і пристрій може виконувати першу, не виконуючи другу. Виконайте п'ять перевірок нижче по порядку й зупиніться на першій невдалій.

Крок 1: намалюйте дві ролі

Намалюйте передбачуване сусідство EIGRP як логічне з'єднання між двома маршрутизаторами, потім намалюйте маршрутизатори underlay, які переносять його пакети тунелю. Один і той самий пристрій не обов'язково має бути в обох списках, і плутанина в списках — найчастіша причина, чому справний транзитний маршрутизатор звинувачують у руйнуванні сусідства.

Транзитний маршрутизатор пересилає зовнішні пакети своєю звичайною маршрутизацією IP і політикою. Йому не потрібно запускати протокол, що переноситься всередині захищеного тунелю, і не потрібен процес EIGRP, щоб передавати ці пакети далі.

Крок 2: перевірте, що завершує середній пристрій

Якщо середній маршрутизатор завершує тунель і має формувати сусідства EIGRP зі spoke, відповідь змінюється цілком. Цьому пристрою потрібна підтримувана поведінка маршрутизації overlay, і назва «транзит» не знімає вимогу сусідства. Прочитайте конфігурацію тунелю раніше за конфігурацію маршрутизації. Ця відповідь визначає кожну наступну перевірку.

Отже, перше справжнє питання — не який протокол налаштовувати. Питання в тому, чи коробка є hub, spoke, чистим переходом underlay або службою Layer 2, яка переносить кадри між кінцевими точками.

Крок 3: перевірте площину керування сусіда

На кожному пристрої, який має бути сусідом, підтвердьте чотири речі: екземпляр EIGRP і номер автономної системи, параметри автентифікації, інтерфейс, що бере участь у процесі, і мережеву команду, яка охоплює цей інтерфейс. Невідповідність у будь-якій із них утримує сусідство внизу, поки інтерфейс лишається піднятим і ping продовжує працювати.

RFC 7868 описує EIGRP як протокол IP з багатоадресним обміном керування, тому сусідські відносини — це не те, що проміжний маршрутизатор може підмінити, маршрутизуючи пакети до призначення. Або обмін керування доходить до партнера, або сусідство не формується.

Крок 4: перевірте, що транспорт доставляє обмін керування

Далі перевірте, чи overlay справді переносить керівний трафік між передбачуваними кінцевими точками. Огляньте відображення NHRP для партнера і зовнішній маршрут, що до нього веде, потім підтвердьте, що інтерфейс тунелю піднятий і пропускає трафік. Успішний ping underlay доводить, що зовнішній шлях існує; він не доводить, що обмін керування overlay було доставлено.

Прозора служба Layer 2, тунель «точка — точка» і багатоточкова хмара DMVPN доставляють багатоадресний трафік по-різному. Дотримуйтеся підтримуваної моделі інтерфейсу, NHRP і багатоадресності для того, що реально розгорнуто, а не припускайте, що всі три поводяться однаково.

Крок 5: перепроєктуйте межу, якщо вона не може брати участь

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

Запишіть роль кожного пристрою на схемі й зберігайте її разом із конфігурацією. RFC 7868 визначає обмін протоколу, і саме це визначення є орієнтиром для розуміння того, чому сусідські відносини не можна імітувати транзитним пересиланням.

Якщо сусідство не піднімається й після всіх п'яти перевірок, залишаються підозрювані — функції платформи, як-от обробка багатоадресного трафіку на інтерфейсі тунелю й політика, що фільтрує протокол 88. Це конкретні, перевірювані причини, і вони цінніші за чергове коло звинувачень на адресу маршрутизатора посередині.