DMVPN hierárquico: uma nuvem por relação de túnel

Um nó de filial registra-se com sucesso no seu hub regional e ainda assim não alcança um serviço noutra região. O túnel está ativo, o estado do NHS parece saudável, e a falha só aparece para destinos que cruzam uma fronteira de nível. Esse padrão normalmente significa que o projeto nunca declarou quais dispositivos participam em qual nuvem DMVPN, por isso os níveis foram construídos por intuição e agora não coincidem.

O sintoma aparece na fronteira dos níveis

Num projeto hierárquico, um hub central, vários hubs regionais e muitas filiais ocupam cada um uma posição. Um hub regional pode ter mais do que uma relação de túnel, e as filiais não precisam de se registar em cada ponto final central. Os caminhos que importam são de filial para serviço regional, de filial para outro nó regional aprovado e de filial para um destino central.

Quando um desses caminhos falha enquanto os outros funcionam, o problema é quase sempre uma definição de papel em falta ou contraditória e não um túnel avariado. Escreva os caminhos previstos e compare-os com o que os dispositivos realmente construíram. Essa comparação leva uma hora e evita uma semana de suposições. Guarde-a junto do documento de projeto.

Uma nuvem, um contrato de interface

Para cada nuvem, registe a interface do túnel, o endereçamento de sobreposição, a origem local da rede subjacente, as relações NHS e NBMA, a entrega multicast e a política de proteção. Indique também que rotas atravessam entre os contextos regional e central, porque essa frase é o projeto.

Um hub regional com duas interfaces de túnel precisa de dois contratos, não de um com dois endereços. A origem da rede subjacente, o domínio NHRP e as rotas podem diferir por interface, e um documento que as funde enganará quem configurar a segunda.

Os IDs são contexto local, não controlo de acesso

Os IDs de rede NHRP e as chaves GRE são os dois valores mais frequentemente confundidos com definições globais. O guia NHRP do IOS XE descreve o ID de rede como localmente significativo, por isso números coincidentes em routers remotos não autenticam nada e alterar o número local de um router não cria uma fronteira de acesso.

Uma chave GRE, quando o projeto usa uma, ajuda a identificar o contexto do túnel recetor, e é acordada entre os extremos que partilham esse contexto. Não é uma palavra-passe e não substitui a autenticação IKE nem a política de encaminhamento. Trate ambos os valores como contexto de configuração que tem de coincidir dentro de uma relação, não como controlos de segurança que separam regiões.

Encaminhe entre níveis deliberadamente

Decida que prefixos o hub regional anuncia para cima e que destinos centrais oferece às suas filiais. Depois verifique o próximo salto real e o comportamento de atalho específico da fase para cada caminho, porque uma rota resumo e um atalho podem produzir um encaminhamento muito diferente do que o diagrama sugere.

Use o encaminhamento e a política de acesso para impor a separação regional. Se uma filial não deve alcançar diretamente outra região, a rota e a política devem dizê-lo, em vez de confiar num ID que nunca foi concebido para o impor. Escreva a política junto ao ID. Caso contrário, o próximo engenheiro assumirá que o número faz o trabalho.

Diagnostique o atalho inesperado

Quando uma filial tenta criar uma relação direta com um ponto final central, examine a sua rota, o seu mapeamento NHRP e o contexto de túnel selecionado antes de alterar IDs ao acaso. A falta de alcance, uma relação NHS não intencional e um atalho legítimo mas não autorizado exigem três correções diferentes.

O guia de configuração do DMVPN mostra as definições do túnel e do NHRP em conjunto, e é precisamente por isso que os âmbitos devem ser separados primeiro no papel. Registe os contratos da nuvem, mantenha as rotas dos níveis explícitas, e a próxima falha de fronteira terá onde apontar.