Os vizinhos EIGRP não sobem na sobreposição DMVPN

O unicast pela sobreposição funciona e a adjacência continua a falhar, por isso verifique a replicação multicast do NHRP, a política EIGRP do túnel e o IPsec como três camadas separadas.

O túnel está ativo, um spoke consegue fazer ping a outro, e o EIGRP continua sem mostrar qualquer vizinho no hub. Essa combinação é normal e não misteriosa: o ping prova a alcançabilidade unicast através do NHRP, e os hello do EIGRP são multicast. Numa sobreposição DMVPN o modelo de entrega do protocolo de encaminhamento é uma segunda superfície de configuração, e é precisamente a que as pessoas saltam porque a primeira superfície já parece saudável. Cada camada abaixo é verificada com o seu próprio comando, por isso uma falha numa camada não o devolve ao topo da lista.

Anote as adjacências que espera

Antes de qualquer comando show, faça uma lista curta: que spoke deve emparelhar com que hub, por que interface de túnel e em que sistema autónomo EIGRP. Os desenhos com vários hubs falham nos intervalos entre hubs, e uma lista transforma «o EIGRP está avariado» em «o spoke 3 não se registra no hub 2». Inclua as sub-redes de túnel que espera em cada ligação, porque uma discrepância de endereços entre as duas pontas parece exatamente uma falha de protocolo. Escreva a lista no ticket, para que o turno seguinte compare com o desenho e não com a última captura de ecrã.

Verifique o NHRP e depois o caminho multicast

Comece pelo estado de registo e pelos mapeamentos que o hub realmente mantém. Um spoke sem entrada dinâmica no hub não se registou, e nenhum protocolo de encaminhamento corrige isso. Depois confirme que o spoke aceita multicast a partir do endereço NBMA do hub, que é uma linha separada da entrada NHS.

show dmvpn
show ip nhrp
show ip nhrp nhs detail
interface Tunnel0
 ip nhrp network-id 1
 ip nhrp nhs 203.0.113.1 nbma 198.51.100.1
 ip nhrp map multicast 198.51.100.1
 tunnel mode gre multipoint
 tunnel key 100

A linha ip nhrp map multicast é a que permite ao spoke enviar os seus hello ao hub como multicast replicado sobre a sobreposição, e a que permite que o multicast do hub chegue aos spokes que registou. Sem ela, o unicast pelo NHRP funciona e o multicast não, e é precisamente essa separação que faz um ping parecer uma prova. O guia da Cisco IOS XE DMVPN documenta o comportamento multicast do hub e dos spokes para cada fase, por isso ajuste a sua configuração à fase que realmente implementou em vez de copiar um fragmento de outra topologia.

Verifique a política de interface do próprio EIGRP

Um túnel que não está no processo EIGRP, ou que é passive, nunca formará uma adjacência, por muito saudável que esteja a sobreposição. Leia a participação da interface e a tabela de vizinhos em conjunto, porque a primeira explica a segunda.

show ip eigrp interfaces detail Tunnel0
show ip eigrp neighbors detail
show run | section router eigrp
router eigrp 100
 network 10.10.0.0 0.0.0.255
 passive-interface default
 no passive-interface Tunnel0

A autenticação e os pesos da métrica têm de coincidir nas duas pontas. Uma cadeia de chaves com o modo errado, ou uma discrepância no valor K, descarta os hello sem uma linha syslog evidente no recetor. Se o desenho usar vizinhos unicast configurados explicitamente, siga esse modelo por completo em vez de o empilhar sobre as definições multicast até algo levantar.

Mantenha o transporte GRE e a proteção IPsec separados

O DMVPN transporta multicast dentro do GRE, e o IPsec protege os pacotes GRE e não o multicast interno diretamente. É por isso que a afirmação genérica de que o IPsec não pode transportar multicast está errada para este desenho e é inútil como diagnóstico. Verifique o perfil IPsec no túnel, as associações de segurança de cada peer e o estado da interface de túnel como três factos separados.

show crypto ipsec sa peer 198.51.100.1
show interfaces Tunnel0 | include line protocol
show ip nhrp multicast

Uma SA ativa com contadores a avançar enquanto o EIGRP continua em baixo devolve a investigação para cima na pilha: os pacotes estão a ser protegidos e entregues, por isso o problema é quais pacotes o protocolo escolhe enviar.

Verifique rotas, não apenas o número de vizinhos

Depois de a adjacência se formar, leia o que ela anuncia e instala. Num túnel multiponto, o split horizon e o comportamento do next-hop decidem se um spoke consegue chegar a outro através do hub, e a sumarização pode esconder um prefixo mesmo quando a relação de vizinhança é perfeita.

Termine com uma aplicação permitida entre dois locais e confirme o caminho que ela percorre. Os atalhos diretos spoke-a-spoke são um requisito de encaminhamento com o seu próprio estado NHRP e de segurança, e adicioná-los para o número de vizinhos parecer melhor cria normalmente um segundo problema.

Registe o desenho por fases, o mapeamento multicast e a política EIGRP num único lugar. O próximo engenheiro vai precisar do desenho, não da transcrição.

Artigos relacionados