Сводные маршруты DMVPN и карта сводки NHRP: разные таблицы
Сводка маршрутов меняет объявляемый префикс и следующий хоп. Карта сводки NHRP меняет то, что возвращает ответ разрешения. То же слово, другая таблица.
Кто-то просит вас объединить spoke-узлы, и тикет закрывается с меньшим числом префиксов на hub. Через неделю трафик между филиалами, который раньше шёл напрямую, снова идёт через hub, и никто не связывает эти два изменения. Фраза объединить spoke-узлы охватывает две разные операции, затрагивающие две разные таблицы. Назовите, какое состояние вы уменьшаете, прежде чем заимствовать команду из другого примера DMVPN.
Симптом: прямой трафик spoke вернулся на hub
Это различие важнее всего, когда обсуждение Phase 2 применяют к проекту Phase 3. Одни и те же слова звучат в обоих разговорах, а влияние на пересылку не одинаково.
Именно поэтому изменение выглядело верным при проверке: проверка смотрела на таблицу маршрутизации, а это лишь одно из трёх задействованных состояний.
Одна агрегация, две таблицы
Две операции выглядят так:
| Operation | What it actually changes |
|---|---|
| Routing summary | Aggregates the prefixes the routing protocol advertises and changes the next hop the receiver installs |
| NHRP summary map | Changes the network returned in a resolution reply, so a requesting spoke resolves to a different address |
| Protection path | IPsec state for the peer you actually resolved; neither aggregation changes it |
Сводка маршрутов — это утверждение о том, что объявляет hub и что принимающий spoke устанавливает как маршрут. Карта сводки NHRP — это утверждение об ответе, который spoke отправляет, когда другой spoke спрашивает, как добраться до адреса. Это разные вопросы с разными режимами отказа, и проект может изменить одно, оставив другое в точности как было. Обращение с ними как с одним рычагом — это путь, которым изменение агрегации тихо становится изменением пересылки.
Ни одна из операций не является утверждением о пути защиты, потому что он согласуется для того peer, который вы действительно разрешили.
Что на самом деле меняет сводка на hub
Руководство Cisco по картам сводки NHRP между spoke-узлами описывает схему Phase 3, в которой hub объявляет сводку и остаётся следующим хопом маршрутизации. Затем перенаправление и последующее разрешение NHRP дают более прямой путь пересылки. Поэтому чтение только агрегированного маршрута не описывает всё состояние пересылки и не означает, что каждый пакет обязан вечно идти через hub. Сводка касается достижимости, а не пути.
Поэтому проектная проверка, которая останавливается на таблице маршрутизации, может одобрить изменение, меняющее поведение разрешения. Проверяйте выбранный маршрут, результат NHRP и путь защиты как три отдельных наблюдения.
Если вы не можете сказать, какое из трёх изменилось, вы не закончили изменение.
Что меняет карта сводки NHRP
Возьмите spoke, которому принадлежит 10.32.0.0/19 через несколько более конкретных LAN-маршрутов, а hub объявляет более крупную агрегацию остальным spoke-узлам. Запрос на 10.32.12.10 иначе получил бы информацию разрешения для соответствующей меньшей сети. Документированная функция карты сводки NHRP позволяет spoke вернуть вместо этого свой настроенный покрывающий префикс, что может сократить повторную работу разрешения для сетей, принадлежащих этому spoke. Она не делает сводку маршрутов hub и сводку разрешения spoke одним и тем же объектом.
Дайте этому покрывающему префиксу продуманную модель владения. Широкий ответ, включающий адреса, принадлежащие в другом месте, или пробелы, недостижимые вовсе, может направить последующий трафик к неподходящему peer.
Проверьте фактические маршруты и предполагаемые случаи отказа до того, как увеличите префикс, а не после.
Сравните первый пункт назначения и один внутри сводки
Выберите два пункта назначения: первый, который вы проверили, и другой, находящийся внутри предложенной сводки. Для каждого запишите выбранный маршрут, состояние NHRP, использованное для достижения, и реальный путь ответа. Это сравнение скажет, изменили ли вы масштаб маршрутизации, масштаб разрешения или ошибку пересылки, и это единственный полезный вывод. Дисплей с меньшим числом префиксов не является доказательством ни одного из этого.
Подтвердите развёрнутую фазу и поведение следующего хопа протокола маршрутизации, прежде чем применять пример Phase 3 к своей сети. Короткий пример не доказывает, что другой проект сохраняет тот же прямой путь spoke.
В тикете должно быть сказано, какую таблицу вы уменьшили и какую оставили нетронутой. Всё меньшее будет снова диагностировано с нуля через месяц.