Иерархический DMVPN: одно облако на каждое туннельное отношение
Региональным и центральным уровням DMVPN нужны явные роли интерфейса, NHS и базовой сети. Идентификаторы сети и ключи GRE — это контекст, а не средства защиты.
Филиальный узел успешно регистрируется на своём региональном концентраторе и всё равно не может достичь сервиса в другом регионе. Туннель поднят, состояние NHS выглядит здоровым, а сбой проявляется только для назначений, пересекающих границу уровня. Такая картина обычно означает, что проект ни разу не указал, какие устройства участвуют в каком облаке DMVPN, поэтому уровни строились интуитивно и теперь не согласуются.
Симптом проявляется на границе уровней
В иерархическом проекте центральный концентратор, несколько региональных концентраторов и множество филиальных узлов занимают каждый свою позицию. Региональный концентратор может владеть более чем одним туннельным отношением, а филиалам не нужно регистрироваться на каждой центральной конечной точке. Важные пути — от филиала к региональному сервису, от филиала к другому одобренному региональному узлу и от филиала к центральному назначению.
Когда один из этих путей отказывает, а остальные работают, проблема почти всегда в отсутствующем или противоречивом определении роли, а не в сломанном туннеле. Запишите предполагаемые пути и сравните их с тем, что устройства действительно построили. Это сравнение занимает час и предотвращает неделю догадок. Храните его вместе с проектным документом.
Одно облако, один контракт интерфейса
Для каждого облака зафиксируйте интерфейс туннеля, адресацию верхнего уровня, локальный источник базовой сети, отношения NHS и NBMA, многоадресную доставку и политику защиты. Укажите также, какие маршруты проходят между региональным и центральным контекстами, потому что именно это предложение и есть проект.
Региональному концентратору с двумя туннельными интерфейсами нужно два контракта, а не один с двумя адресами. Источник базовой сети, домен NHRP и маршруты могут различаться для каждого интерфейса, и документ, который их объединяет, введёт в заблуждение того, кто настраивает второй.
Идентификаторы — локальный контекст, а не контроль доступа
Идентификаторы сети NHRP и ключи GRE — это два значения, которые чаще всего ошибочно принимают за глобальные настройки. Руководство по NHRP в IOS XE описывает идентификатор сети как локально значимый, поэтому совпадающие номера на удалённых маршрутизаторах ничего не аутентифицируют, а изменение локального номера одного маршрутизатора не создаёт границу доступа.
Ключ GRE, если проект его использует, помогает определить контекст принимающего туннеля и согласуется между конечными точками, которые разделяют этот контекст. Это не пароль, и он не заменяет аутентификацию IKE или политику маршрутизации. Рассматривайте оба значения как конфигурационный контекст, который должен совпадать внутри отношения, а не как средства защиты, разделяющие регионы.
Маршрутизируйте между уровнями осознанно
Решите, какие префиксы региональный концентратор объявляет вверх и какие центральные назначения предлагает своим филиалам. Затем проверьте фактический следующий переход и поведение сокращения, специфичное для фазы, для каждого пути, потому что суммарный маршрут и сокращение могут дать совсем другую пересылку, чем предполагает схема.
Используйте маршрутизацию и политику доступа, чтобы обеспечить региональное разделение. Если филиал не должен напрямую достигать другого региона, это должны говорить маршрут и политика, а не расчёт на идентификатор, который никогда не предназначался для этого. Запишите политику рядом с идентификатором. Иначе следующий инженер предположит, что работу выполняет номер.
Диагностируйте неожиданное сокращение
Когда филиал пытается создать прямое отношение с центральной конечной точкой, проверьте его маршрут, его сопоставление NHRP и выбранный контекст туннеля, прежде чем менять идентификаторы наугад. Недоступность, непреднамеренное отношение NHS и законное, но неразрешённое сокращение требуют трёх разных исправлений.
Руководство по настройке DMVPN показывает параметры туннеля и NHRP вместе, и именно поэтому области нужно сначала разделить на бумаге. Зафиксируйте контракты облака, держите маршруты уровней явными, и следующему сбою на границе будет на что указать.