DMVPN fase 3: ler o atalho nos dois sentidos
Um único ping direto não prova um atalho DMVPN fase 3. Percorra o caminho de ida e o de volta e depois leia separadamente o estado de NHRP, rota e IPsec.
Você vê um ping ir de spoke a spoke, ele pega o caminho longo pelo hub, e o segundo vai direto. É tentador declarar o atalho funcionando nesse ponto. Essa conclusão está meio certa. O caminho de ida pode ser um atalho enquanto o de volta ainda passa pelo hub, e o estado que prova cada direção é um estado diferente. Percorra os dois sentidos e leia três tabelas antes de aceitar o desenho como saudável.
Comece pelo caminho do pacote que você realmente consegue ver
Comece em um spoke com um destino que deveria ser direto. Rastreie o primeiro pacote: ele segue a rota do spoke em direção ao hub, porque ainda não existe atalho. O hub o encaminha e, em um desenho de fase 3, também envia um redirecionamento à origem dizendo que existe um caminho melhor.
Esse redirecionamento é o gatilho, não a prova. Ele diz que o hub viu tráfego que poderia ser otimizado. Não diz que a origem construiu o atalho, que o destino respondeu à resolução ou que o caminho de volta o usa.
Então a primeira observação útil é um antes e depois: o primeiro fluxo pelo hub, o fluxo posterior direto.
Três estados que parecem um único túnel
O atalho depende de três peças de estado, e cada uma tem seu próprio tempo de vida e seu próprio comando.
| State | What it answers | Where to read it |
|---|---|---|
| NHRP cache | Which transport address maps to this overlay address | show ip nhrp |
| Route or shortcut | Where one specific inner prefix is forwarded | show ip route 10.10.20.5 |
| IPsec association | Which peer traffic is protected, and by which SA | show crypto ipsec sa peer 203.0.113.5 |
Uma entrada de cache NHRP mapeia um endereço overlay para um endereço de transporte NBMA. Uma rota ou atalho decide para onde um destino interno é encaminhado. Uma associação IPsec protege o tráfego que resultar. Uma resposta ausente pode vir de qualquer um dos três, e os comandos dizem qual falta.
Leia-as nessa ordem, porque um mapeamento ausente torna as outras duas desinteressantes.
Percorra a requisição e a resposta separadamente
Do spoke A, peça a resolução e observe o que volta. A requisição passa pelo caminho de encaminhamento NHRP suportado, e o destino pode responder diretamente em vez de pelo hub. Essa assimetria é normal, e é por isso que a resposta é a metade interessante da troca.
Agora inverta os papéis. Envie de B para A e repita as mesmas três leituras. Um desenho que faz atalho em um sentido e não no outro não é simétrico, e a assimetria geralmente vem de um prefixo ausente de um lado ou de uma resolução que nunca recebeu resposta.
A resposta do par não precisa atravessar o hub só porque a requisição atravessou. Não leia isso como erro nem comece a caçar uma falha de roteamento que não existe.
Leia o redirecionamento do hub, não só a rota dele
A tabela de rotas do hub diz onde o hub enviaria um pacote. O redirecionamento diz o que o hub pediu à origem para fazer a respeito. São fatos diferentes, e um hub com a rota correta e sem redirecionamentos manterá cada fluxo no caminho longo indefinidamente. Verifique os eventos NHRP do hub e confirme que redirecionamentos são gerados para o tráfego que lhe interessa.
A fase 3 também muda o que significa sumarização. Com o comportamento de atalho, os spokes não precisam do conjunto completo de rotas remotas específicas que um desenho de fase 2 esperava, então uma rota resumida no spoke não é automaticamente uma rede ausente. Confirme a fase e a política de roteamento antes de ler um resumo como falha.
Esse único mal-entendido causa mais tickets de DMVPN do que qualquer outra coisa.
Registre a conclusão como um objeto que faltava
Termine com um fluxo de aplicação autorizado e sua resposta, e anote para cada sentido se ele usou o caminho direto. Depois escreva a conclusão como o objeto que faltava: um mapeamento, um atalho de encaminhamento, uma associação de proteção ou uma resposta de aplicação.
Uma adjacência de roteamento e uma associação de segurança compartilhada são provas de saúde, não provas do caminho. Ambas podem estar perfeitas enquanto cada pacote ainda dá a volta longa. Verifique primeiro a decisão de encaminhamento e depois a associação que a carrega. A ordem importa, porque a associação se forma de qualquer maneira.
Esse hábito compensa no próximo ticket. «O túnel está no ar mas lento» vira «B não tem atalho para o host de A», e a segunda afirmação é uma correção de cinco minutos. Guarde a saída dos comandos com a conclusão e mantenha o roteiro de fase 3 do fornecedor ao lado.