Филиальный узел успешно регистрируется на своём региональном концентраторе и всё равно не может достичь сервиса в другом регионе. Туннель поднят, состояние NHS выглядит здоровым, а сбой проявляется только для назначений, пересекающих границу уровня. Такая картина обычно означает, что проект ни разу не указал, какие устройства участвуют в каком облаке DMVPN, поэтому уровни строились интуитивно и теперь не согласуются.

Симптом проявляется на границе уровней

В иерархическом проекте центральный концентратор, несколько региональных концентраторов и множество филиальных узлов занимают каждый свою позицию. Региональный концентратор может владеть более чем одним туннельным отношением, а филиалам не нужно регистрироваться на каждой центральной конечной точке. Важные пути — от филиала к региональному сервису, от филиала к другому одобренному региональному узлу и от филиала к центральному назначению.

Когда один из этих путей отказывает, а остальные работают, проблема почти всегда в отсутствующем или противоречивом определении роли, а не в сломанном туннеле. Запишите предполагаемые пути и сравните их с тем, что устройства действительно построили. Это сравнение занимает час и предотвращает неделю догадок. Храните его вместе с проектным документом.

Одно облако, один контракт интерфейса

Для каждого облака зафиксируйте интерфейс туннеля, адресацию верхнего уровня, локальный источник базовой сети, отношения NHS и NBMA, многоадресную доставку и политику защиты. Укажите также, какие маршруты проходят между региональным и центральным контекстами, потому что именно это предложение и есть проект.

Региональному концентратору с двумя туннельными интерфейсами нужно два контракта, а не один с двумя адресами. Источник базовой сети, домен NHRP и маршруты могут различаться для каждого интерфейса, и документ, который их объединяет, введёт в заблуждение того, кто настраивает второй.

Идентификаторы — локальный контекст, а не контроль доступа

Идентификаторы сети NHRP и ключи GRE — это два значения, которые чаще всего ошибочно принимают за глобальные настройки. Руководство по NHRP в IOS XE описывает идентификатор сети как локально значимый, поэтому совпадающие номера на удалённых маршрутизаторах ничего не аутентифицируют, а изменение локального номера одного маршрутизатора не создаёт границу доступа.

Ключ GRE, если проект его использует, помогает определить контекст принимающего туннеля и согласуется между конечными точками, которые разделяют этот контекст. Это не пароль, и он не заменяет аутентификацию IKE или политику маршрутизации. Рассматривайте оба значения как конфигурационный контекст, который должен совпадать внутри отношения, а не как средства защиты, разделяющие регионы.

Маршрутизируйте между уровнями осознанно

Решите, какие префиксы региональный концентратор объявляет вверх и какие центральные назначения предлагает своим филиалам. Затем проверьте фактический следующий переход и поведение сокращения, специфичное для фазы, для каждого пути, потому что суммарный маршрут и сокращение могут дать совсем другую пересылку, чем предполагает схема.

Используйте маршрутизацию и политику доступа, чтобы обеспечить региональное разделение. Если филиал не должен напрямую достигать другого региона, это должны говорить маршрут и политика, а не расчёт на идентификатор, который никогда не предназначался для этого. Запишите политику рядом с идентификатором. Иначе следующий инженер предположит, что работу выполняет номер.

Диагностируйте неожиданное сокращение

Когда филиал пытается создать прямое отношение с центральной конечной точкой, проверьте его маршрут, его сопоставление NHRP и выбранный контекст туннеля, прежде чем менять идентификаторы наугад. Недоступность, непреднамеренное отношение NHS и законное, но неразрешённое сокращение требуют трёх разных исправлений.

Руководство по настройке DMVPN показывает параметры туннеля и NHRP вместе, и именно поэтому области нужно сначала разделить на бумаге. Зафиксируйте контракты облака, держите маршруты уровней явными, и следующему сбою на границе будет на что указать.

Похожие статьи