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 от поставщика рядом.