I vicini EIGRP non salgono sull’overlay DMVPN

Il tunnel è su, uno spoke riesce a fare ping verso un altro, e EIGRP continua a non mostrare alcun vicino sull’hub. Questa combinazione è normale, non misteriosa: il ping dimostra la raggiungibilità unicast tramite NHRP, e gli hello di EIGRP sono multicast. Su un overlay DMVPN il modello di consegna del protocollo di routing è una seconda superficie di configurazione, ed è proprio quella che la gente salta perché la prima superficie sembra già sana. Ogni livello sottostante si verifica con il proprio comando, quindi un guasto su uno non ti riporta in cima all’elenco.

Annota le adiacenze che ti aspetti

Prima di qualsiasi comando show, fai un elenco breve: quale spoke deve fare peering con quale hub, su quale interfaccia tunnel, in quale sistema autonomo EIGRP. I progetti multi-hub falliscono negli spazi tra gli hub, e un elenco trasforma «EIGRP è rotto» in «lo spoke 3 non si registra sull’hub 2». Includi le sottoreti tunnel che ti aspetti su ogni collegamento, perché una discordanza di indirizzi tra i due estremi sembra esattamente un guasto di protocollo. Scrivi l’elenco nel ticket, così il turno successivo confronta con il progetto e non con l’ultimo screenshot.

Verifica NHRP, poi il percorso multicast

Parti dallo stato di registrazione e dalle mappature che l’hub detiene davvero. Uno spoke senza voce dinamica sull’hub non si è registrato, e nessun protocollo di routing lo sistemerà. Poi conferma che lo spoke accetti multicast dall’indirizzo NBMA dell’hub, che è una riga separata dalla voce 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

La riga ip nhrp map multicast è quella che permette allo spoke di inviare i propri hello all’hub come multicast replicato sull’overlay, e che permette al multicast dell’hub di raggiungere gli spoke registrati. Senza di essa l’unicast tramite NHRP funziona e il multicast no, ed è proprio questa separazione che fa sembrare il ping una prova. La guida Cisco IOS XE DMVPN documenta il comportamento multicast di hub e spoke per ogni fase, quindi allinea la tua configurazione alla fase che hai davvero distribuito invece di copiare un frammento da un’altra topologia.

Verifica la policy di interfaccia propria di EIGRP

Un tunnel che non è nel processo EIGRP, o che è passive, non formerà mai un’adiacenza, per quanto sano sia l’overlay. Leggi insieme la partecipazione dell’interfaccia e la tabella dei vicini, perché la prima spiega la seconda.

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

L’autenticazione e i pesi della metrica devono corrispondere su entrambi gli estremi. Una key chain con la modalità sbagliata, o una discordanza sul valore K, fa cadere gli hello senza una riga syslog evidente sul ricevitore. Se il progetto usa vicini unicast configurati esplicitamente, segui quel modello per intero invece di impilarlo sopra le impostazioni multicast finché qualcosa non sale.

Tieni separati il trasporto GRE e la protezione IPsec

DMVPN trasporta il multicast dentro GRE, e IPsec protegge i pacchetti GRE e non il multicast interno direttamente. Per questo l’affermazione generale che IPsec non possa trasportare multicast è sbagliata per questo progetto e inutile come diagnosi. Verifica il profilo IPsec sul tunnel, le associazioni di sicurezza di ogni peer e lo stato dell’interfaccia tunnel come tre fatti separati.

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

Una SA attiva con i contatori che avanzano mentre EIGRP resta giù riporta l’indagine più in alto nello stack: i pacchetti vengono protetti e consegnati, quindi il problema è quali pacchetti il protocollo sceglie di inviare.

Verifica le rotte, non solo il numero di vicini

Una volta formata l’adiacenza, leggi cosa annuncia e installa. Su un tunnel multipoint, lo split horizon e il comportamento del next-hop decidono se uno spoke può raggiungere un altro spoke attraverso l’hub, e la summarizzazione può nascondere un prefisso anche quando la relazione di vicinato è perfetta.

Chiudi con un’applicazione consentita tra due sedi e conferma il percorso che prende. Le scorciatoie dirette spoke-to-spoke sono un requisito di inoltro con un proprio stato NHRP e di sicurezza, e aggiungerle per far sembrare migliore il conteggio dei vicini di solito crea un secondo problema.

Registra il progetto per fasi, la mappatura multicast e la policy EIGRP in un unico posto. Il prossimo ingegnere avrà bisogno del progetto, non della trascrizione.