DMVPN фаза 3: читання скороченого шляху в обох напрямках

Ви бачите, як один ping іде від spoke до spoke довгим шляхом через hub, а другий іде напряму. У цей момент спокусливо оголосити скорочений шлях робочим. Цей висновок наполовину правильний. Шлях туди може бути скороченим, поки зворотний шлях ще йде через hub, і стан, який доводить кожен напрямок, — це різний стан. Пройдіть обидва напрямки і прочитайте три таблиці, перш ніж визнати схему здоровою.

Почніть зі шляху пакета, який ви справді бачите

Почніть на spoke з пунктом призначення, який має бути прямим. Простежте перший пакет: він іде маршрутом spoke у бік hub, бо скороченого шляху ще немає. Hub пересилає його і в схемі фази 3 також надсилає джерелу перенаправлення про те, що є кращий шлях.

Це перенаправлення — тригер, а не доказ. Воно каже, що hub побачив трафік, який можна оптимізувати. Воно не каже, що джерело збудувало скорочений шлях, що пункт призначення відповів на розв'язання чи що зворотний шлях його використовує.

Тому перше корисне спостереження — до і після: перший потік через hub, пізніший потік напряму.

Три стани, які виглядають як один тунель

Скорочений шлях залежить від трьох частин стану, і кожна має свій термін життя і свою команду.

Запис кешу NHRP зіставляє overlay-адресу з транспортною адресою NBMA. Маршрут або скорочений шлях вирішує, куди пересилається один внутрішній пункт призначення. Асоціація IPsec захищає трафік, який у результаті виникає. Відсутня відповідь може прийти з будь-якої з трьох частин, і команди показують, якої саме бракує.

Читайте їх у цьому порядку, бо відсутнє зіставлення робить два інші нецікавими.

Пройдіть запит і відповідь окремо

Зі spoke A запитайте розв'язання і подивіться, що повертається. Запит іде підтримуваним шляхом пересилання NHRP, і пункт призначення може відповісти напряму, а не через hub. Ця асиметрія нормальна, і саме тому відповідь — цікава половина обміну.

Тепер поміняйте ролі. Надішліть з B на A і повторіть ті самі три читання. Схема, яка скорочує один напрямок і не скорочує інший, не симетрична, і асиметрія зазвичай походить від відсутнього префікса з одного боку або від розв'язання, яке так і не отримало відповіді.

Відповідь партнера не зобов'язана проходити через hub лише тому, що запит пройшов. Не читайте це як помилку і не починайте шукати несправність маршрутизації, якої не існує.

Читайте перенаправлення hub, а не лише його маршрут

Таблиця маршрутів hub каже, куди hub надіслав би пакет. Перенаправлення каже, що hub попросив джерело з цим зробити. Це різні факти, і hub з правильним маршрутом і без перенаправлень утримуватиме кожен потік на довгому шляху нескінченно. Перевірте події NHRP на hub і переконайтеся, що для потрібного вам трафіку генеруються перенаправлення.

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

Саме це одне непорозуміння породжує більше заявок щодо DMVPN, ніж будь-що інше.

Запишіть висновок як відсутній об'єкт

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

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

Ця звичка окупається на наступній заявці. «Тунель піднято, але повільно» стає «У B немає скороченого шляху до хоста A», і друге твердження — виправлення на п'ять хвилин. Тримайте вивід команд разом із висновком і тримайте посібник із фази 3 від постачальника поруч.