Vicino EIGRP o transito DMVPN? Controllate prima il ruolo

L’adiacenza manca e il router in mezzo sembra il sospetto ovvio. Può essere innocente. Inoltrare i pacchetti esterni del tunnel e partecipare al protocollo di routing overlay sono due compiti diversi, e un dispositivo può fare il primo senza fare il secondo. Eseguite i cinque controlli qui sotto in ordine e fermatevi al primo che fallisce.

Passo 1: disegnate i due ruoli

Disegnate l’adiacenza EIGRP prevista come connessione logica tra due router, poi disegnate i router underlay che trasportano i suoi pacchetti del tunnel. Lo stesso dispositivo non deve per forza comparire in entrambi gli elenchi, e confondere gli elenchi è il motivo più comune per cui un router di transito sano viene accusato di rompere l’adiacenza.

Un router di transito inoltra i pacchetti esterni con il suo routing IP e la sua policy abituali. Non deve eseguire il protocollo trasportato all’interno del tunnel protetto, né gli serve un processo EIGRP per far passare quei pacchetti.

Passo 2: controllate cosa termina il dispositivo centrale

Se il router centrale termina il tunnel e deve formare adiacenze EIGRP con gli spoke, la risposta cambia del tutto. Quel dispositivo ha bisogno del comportamento di routing overlay supportato, e chiamarlo transito non elimina il requisito di vicino. Leggete la configurazione del tunnel prima di quella del routing. Quella risposta decide ogni controllo successivo.

La prima vera domanda quindi non è quale protocollo regolare. È se la scatola è un hub, uno spoke, un semplice salto underlay o un servizio Layer 2 che trasporta frame tra gli estremi.

Passo 3: verificate il piano di controllo del vicino

Su ogni dispositivo che deve essere vicino, confermate quattro cose: l’istanza EIGRP e il numero di sistema autonomo, i parametri di autenticazione, l’interfaccia che partecipa al processo e la dichiarazione di rete che copre quell’interfaccia. Una discrepanza in una di esse tiene l’adiacenza giù mentre l’interfaccia resta su e il ping continua a funzionare.

L’RFC 7868 descrive EIGRP come protocollo IP con uno scambio di controllo multicast, ed è per questo che una relazione di vicinato non è qualcosa che un router intermedio possa sostituire instradando pacchetti verso una destinazione. O lo scambio di controllo raggiunge il peer, oppure l’adiacenza non si forma.

Passo 4: verificate che il trasporto consegni lo scambio di controllo

Poi, controllate che l’overlay trasporti davvero il traffico di controllo tra gli estremi previsti. Esaminate la mappatura NHRP del peer e la rotta esterna che lo raggiunge, quindi confermate che l’interfaccia del tunnel sia su e lasci passare traffico. Un ping underlay riuscito prova che il percorso esterno esiste; non prova che lo scambio di controllo dell’overlay sia stato consegnato.

Un servizio Layer 2 trasparente, un tunnel punto a punto e una nuvola DMVPN multipunto consegnano il multicast in modi diversi. Seguite il modello di interfaccia, NHRP e multicast supportato per quello realmente distribuito invece di presumere che tutti e tre si comportino allo stesso modo.

Passo 5: ridisegnate il confine se non può partecipare

Se un dispositivo overlay necessario non può eseguire il protocollo, cambiate il progetto in modo esplicito. Usate un protocollo o un modello di scambio supportato su quel confine, oppure predisponete un tunnel da estremo a estremo adatto, così che i vicini siano gli estremi che parlano davvero tra loro. Non date per scontato che una rotta statica trasformi un non partecipante in un relè per ogni pacchetto di controllo.

Annotate il ruolo di ogni dispositivo nello schema e conservatelo con la configurazione. RFC 7868 definisce lo scambio di protocollo, e quella definizione è il riferimento per capire perché la relazione di vicinato non può essere simulata con l’inoltro di transito.

Quando l’adiacenza fallisce ancora dopo tutti e cinque i controlli, i sospetti rimasti sono funzioni di piattaforma come la gestione del multicast sull’interfaccia del tunnel e una policy che filtra il protocollo 88. Sono cause precise e verificabili, e valgono più di un altro giro di accuse al router in mezzo.