Questo post è il seguito del post precedente "DMVPN FASE 1 - PARTE I". Come citato alla fine di quel post, per completare l'implementazione del modello DMVPN è necessario abilitare un protocollo di routing IP. E qui nascono problematiche interessanti come, quale protocollo scegliere, come configurarlo ? Nelle applicazioni pratiche sono tre i protocolli di interesse: EIGRP, OSPF e BGP.

 

NOTA 1: in teoria può essere utilizzato anche il RIP, ma come noto questo vecchio protocollo ha due ordini di problemi: convergenza lenta e diametro delle rete limitato.

 

NOTA 2: tra i classici protocolli IGP, l'IS-IS non è supportato nel modello DMVPN. Secondo la documentazione Cisco, la ragione per cui IS-IS non è applicabile nel modello DMVPN è che i messaggi IS-IS sono trasportati direttamente dal Livello 2 e non da pacchetti IP ! La frase testuale che ho letto in una presentazione al Cisco Live 2013 dal titolo "Advanced Concepts of DMVPN", è la seguente: "IS-IS cannot be used since it doesn’t run over IP".

Questa ragione in teoria non sta in piedi poiché nei tunnel GRE è possibile trasportare di tutto, anche messaggi IS-IS, ma Cisco forse non aveva voglia di implementare un comando del tipo "ip nhrp map iso [dynamic | indirizzo NBMA]" ... . D'altra parte, nei tunnel GRE p2p, i messaggi IS-IS viaggiano tranquillamente, anche nei router Cisco.

 

Ciascuno di questi protocolli va valutato rispetto a caratteristiche importanti come la scalabilità della configurazione (nelle applicazioni pratiche ci si può tranquillamente trovare davanti a reti con centinaia, se non migliaia di router Spoke) e soprattutto la velocità di convergenza. 

In questo post, partendo dalla rete del post precedente, che riporto per completezza, illustrerò come utilizzare i tre protocolli EIGRP, OSPF e BGP, mettendo in evidenza gli aspetti di scalabilità e convergenza di ciascuna soluzione. In tutti i test successivi, utilizzerò una topologia Dual DMVPN. La rete test è la stessa del post precedente, che riporto qui per completezza.

 

L'abilitazione di EIGRP sulla rete test richiede un solo accorgimento fondamentale: disabilitare lo split-horizon sulle interfacce "tunnel X" dei router Hub. Questo è un aspetto ben noto nel funzionamento di EIGRP su reti NBMA. La regola dello split-horizon, quando abilitata, impedisce ai router Hub di annunciare i prefissi ricevuti da un router Spoke, agli altri router Spoke. In altre parole, a ciascun router Spoke viene impedita la visibilità delle reti raggiungibili attraverso gli altri router Spoke.

In realtà non è sempre necessario disabilitare lo split-horizon sulle interfacce "tunnel X" dei router Hub. Poiché il modello DMVPN fase 1 non prevede la comunicazione diretta tra router Spoke, una soluzione molto semplice e altamente scalabile potrebbe quella di far generare ai router Hub una default-route EIGRP, rendendo così inutile la presenza sulla Tabella di Routing dei router Spoke, dei prefissi IP raggiungibili attraverso gli altri router Spoke. In questo caso, disabilitare lo split-horizon non comporta alcunché. Comunque, per tranquillità, considerato che nel modello DMVPN fase 2, come si vedrà (e come è intuitivo) è invece obbligatorio disabilitarlo, consiglio comunque, in uno scenario DMVPN, di disabilitare sempre  lo split-horizon.

Un altro accorgimento classico da adottare, in presenza di topologie Hub-and-Spoke con protocollo di routing EIGRP, è abilitare la funzionalità EIGRP Stub sui router Spoke, per impedire che i router Spoke vengano utilizzati come transito per destinazioni raggiungibili attraverso i router Hub, nel caso di fuori servizio di uno dei due Hub.

Riporto di seguito le configurazioni dei router H1 e SP1 della rete Test. Come sempre, le configurazioni di H2 e SP2 sono analoghe e vengono lasciate come esercizio. Per semplicità, nella configurazione ho omesso il comando per l'autenticazione dei messaggi NHRP e sui router Spoke i comandi dei timer che regolano la registrazione delle associazioni <Indirizzo IP logico ; Indirizzo NBMA>.

 

 

Il comando "ip summary-address eigrp 200 0.0.0.0 0.0.0.0" consente di generare una default-route EIGRP, che viene inviata su tutte le adiacenze EIGRP stabilite attraverso l'interfaccia "tunnel 11". Si noti inoltre che, anche se non necessario a causa della generazione della default-route EIGRP, ho disabilito comunque sull'interfaccia "tunnel 11", lo split-horizon.

 

 

Si noti che le interfacce "tunnel X" configurate sui router Spoke non hanno alcun comando relativo a EIGRP. Si noti inoltre il comando "eigrp stub" all'interno del processo EIGRP, che abilita sul router Spoke SP1 la funzionalità EIGRP Stub. Ricordo che il comando "eigrp stub" consente di default l'annuncio dei prefissi direttamente connessi e delle summary route. 

Il risultato della configurazione è che il router Spoke SP1 vede due Next-Hop per la default-route annunciata da EIGRP, i tunnel 1 e 11. Ciò significa che i due tunnel 1 e 11 sono utilizzati in Load Balancing. 

 

Gateway of last resort is 30.0.0.11 to network 0.0.0.0
 

 

Qualora si volesse utilizzare un tunnel come primario (ad esempio il tunnel 1) e l'altro come backup, è sufficiente aumentare il costo complessivo con cui SP1 vede la default-route attraverso il tunnel di backup (ad esempio il tunnel 11), oppure, in modo equivalente, diminuire il costo complessivo con cui SP1 vede la default-route attraverso il tunnel primario.

Per fare questo, ricordo che è buona regola agire sul parametro delay dell'interfaccia "tunnel X". Si potrebbe anche agire sul parametro bandwidth, ma questo è utilizzato anche da altri protocolli e funzioni (es. OSPF per il calcolo delle metriche, meccanismi di QoS, ecc.), per cui è bene non variarlo.

Il parametro delay associato all'interfaccia "tunnel X" si può visualizzare con il classico comando "show interface tunnel X". Ad esempio, per l'interfaccia "tunnel 11" si ottiene:

 

 

da cui si evince che il parametro delay è pari a 50.000 microsec. Per aumentare questo valore, ad esempio per raddoppiarlo, si utilizza la seguente configurazione (NOTA: nella configurazione il nuovo valore va espresso in decine di microsec):

 

 

Una identica configurazione andrebbe fatta sugli altri router Spoke. Il risultato che si ottiene è il seguente:

 

 

 

Infine, per verificare che il traffico Spoke-Spoke fluisce effettivamente attraverso il router Hub H1, si può eseguire un classico traceroute:

 

 

"Et voilà", il gioco è fatto !!!

Concludendo, per abilitare EIGRP in uno scenario DMVPN fase 1, utilizzare i seguenti accorgimenti:

1) Disabilitare lo split-horizon sulle interfacce "tunnel X" dei router Hub.

2) Abilitare la funzionalità EIGRP Stub sui router Spoke.

Per una soluzione altamente scalabile:

3) Generare sui router Hub una default-route EIGRP verso i router Spoke. In questo caso non è necessario disabilitare lo split-horizon (ma magari fatelo comunque).

 

Un secondo protocollo supportato dal modello DMVPN fase 1 è l'OSPF. Nella sua implementazione è però necessario fare molta attenzione agli aspetti di scalabilità. Tutti noi conosciamo la vecchia regoletta Cisco di non realizzare mai aree di più di 50 router. Dicamo che oggi questa regoletta può essere notevolmente ampliata ed arrivare anche ad aree di centinaia di router. Ma tenete conto che in una implementazione reale di un modello DMVPN, i router Spoke non sono mai delle "schegge", e anche i router Hub non sono certo i CRS !!! Quindi io farei molta attenzione ad utlizzare OSPF quando i router Spoke superano qualche centinaio.

Nel modello DMVPN fase 1 comunque qualche accorgimento interessante c'è. Innanzitutto, poiché siamo in presenza di OSPF su una rete NBMA, è necessario scegliere la modalità di funzionamento. La più semplice è in questo caso la point-to-multipoint, che è tra l'altro una modalità standard descritta nella RFC 2328 "OSPF Version 2".  Le ragioni per il suo utilizzo sono che in questa modalità, ogni tunnel GRE viene trattato come fosse un collegamento punto-punto, e quindi non è necessario specificare manualmente i router vicini, né vi è bisogno di eleggere DR e BDR.

Un altro aspetto molto interessante, che ha un impatto molto importante sulla scalabilità, è la possibilità offerta dall'IOS Cisco di bloccare l'invio di LSA OSPF su una particolare interfaccia. Attenzione però, questo comporta un disallineamento dei LSDB all'interno dell'area, ma fortunatamente con una topologia Hub-and-Spoke questo non crea alcun problema. Infatti, disabilitando sui router Hub l'invio di LSA sull'interfaccia "tunnel X", si ha che i router Spoke non riceveranno informazioni sui prefissi raggiungibili dagli altri router Spoke. Ma il problema di connettività può essere risolto, come fatto con il protocollo EIGRP, con una default-route sui router Spoke verso i router Hub. Però attenzione a un aspetto. Se si disabilita sui router Hub l'invio dei LSA OSPF, non è possibile far generare ai router Hub una default-route OSPF. Questo perché la generazione avviene attraverso un LSA di tipo 5, che però non viene inviato se si disabilita sui router Hub l'invio dei LSA OSPF. La soluzione, benché un po' antipatica quando si ha che fare con centinaia di Spoke, è configurare delle default-route statiche sui router Spoke. 

I comandi da eseguire sono quindi i seguenti:

1) Su tutte le interfacce "tunnel X" dei router Hub e Spoke, abilitare la modalità "point-to-multipoint" con il comando "ip ospf network point-to-multipoint".

2) Sulle interfacce "tunnel X" dei soli router Hub, disabilitare l'invia dei LSA OSPF con il comando "ip ospf database-filter all out".

3) Configurare sui router Spoke delle default-route statiche verso gli Hub, eventualmente di tipo floating (ossia, con diversa distanza amministrativa).

Riporto di seguito le configurazioni dei router H1 e SP1 della rete test. Come sempre, le configurazioni di H2 e SP2 sono analoghe e vengono lasciate come esercizio. Per semplicità, anche qui nella configurazione ho omesso il comando per l'autenticazione dei messaggi NHRP e sui router Spoke i comandi dei timer che regolano la registrazione delle associazioni <Indirizzo IP logico ; Indirizzo NBMA>.

 

!  NOTA: La configurazione delle interfacce "tunnel 1" e "tunnel 11" è identica a quella già illustrata per il protocollo EIGRP, con la sola differenza che è necessario aggiungere il comando "ip ospf network point-to-multipoint".

 

Nella configurazione delle (floating) default-route statiche, ho ipotizzato di utilizzare come Hub primario H1, e di utilizzare H2 come Hub di backup. Qualora si volessero utilizzare le due default-route statiche in Load Balancing, è sufficente eliminare la distanza amministrativa nella seconda default-route.

 

 

NOTA 1: sia nella configurazione dei router Spoke che in quella dei router Hub, per annunciare le reti direttamente connesse ho utilizzato un comando di redistribuzione, piuttosto che inserire i prefissi nel processo OSPF attraverso il comando "network ...". La ragione è che, come gli esperti di OSPF sanno, è molto più efficiente annunciare i prefissi via redistribuzione, piuttosto che inserirli nel processo OSPF. Anche se il risultato finale è equivalente.

 

NOTA 2: nella configurazione ho utilizzato un'area OSPF standard. A volte, per maggiore scalabilità, potrebbe essere conveniente configurare aree NSSA (non aree Stub, altrimenti non sarebbe possibile la redistribuzione sui router con almeno un'interfaccia nell'area !).

 

Con queste configurazioni, sulla tabella di routing di H1 compaiono i prefissi annunciati (via OSPF) dai router Spoke:

 

 

Infine, anche qui, per verificare che il traffico Spoke-Spoke fluisce effettivamente attraverso il router Hub H1, si può eseguire un classico traceroute:

 

 

Concludendo, per abilitare OSPF in uno scenario DMVPN fase 1, utilizzare i seguenti accorgimenti:

1) Abilitare sulle interfacce "tunnel X" di tutti i router, la modalità OSPF su reti NBMA "point-to-multipoint".

2) Disabilitare sui soli router Hub la propagazione dei LSA OSPF.

3) Configurare sui router Spoke delle default-route statiche verso i router Hub, eventualmente di tipo floating.  

 

Attenzione che il punto 3), purtroppo necessario se utilizzate il punto 2), richiede configurazioni di default-route statiche su tutti i router Spoke, che potrebbero essere centinaia. A onor del vero è comunque possibile utilizzare il "copia e incolla", con un template di configurazione unico.

 

Infine il caro vecchio BGP. Il BGP ormai viene utilizzato dappertutto, poteva mancare sul modello DMVPN ? Certamente no, e forse è anche l'alternativa migliore.

Qualora si decida di utilizzare il BGP, e nella prossima sezione cercherò di dare qualche motivazione, la prima decisione da affrontare è se utilizzare sessioni iBGP o eBGP. In teoria si possono utilizzare entrambi i tipi. Utilizzare sessioni iBGP è sicuramente molto più semplice nel caso di DMVPN Fase 1, mentre richiede qualche accorgimento aggiuntivo nel caso di DMVPN Fase 2. L'utilizzo di sessioni eBGP richiede l'assegnazione di un diverso numero di AS a ciascun router e questo potrebbe esere un rompicapo quando si ha che fare con centinaia o migliaia di Spoke. Ci sono vari modi di aggirare il problema, il BGP è ricco di funzioni che consentono di effettuare configurazioni scalabili. Poi, molto è legato alla diversa gestione del BGP Next-Hop sulle sessioni iBGP ed eBGP. Quello che voglio fare in questo post che tratta del DMVPN Fase 1, è applicare entrambe le soluzioni e valutare sul campo pregi e difetti.

Per utilizzare sessioni iBGP bisogna scegliere un (unico) numero di AS. Tipicamente si sceglie un numero di AS privato, ma non è obbligatorio. Poi bisogna configurare sessioni iBGP tra router Hub e router Spoke (non sessioni Spoke-Spoke). Per rendere la configurazione scalabile, è possibile utilizzare il trucchetto dei BGP Dynamic Neighbor, introdotto nelle versioni più recenti dell'IOS Cisco (nel JUNOS era presente da molto tempo). Questo fa risparmiare moltissime righe di configurazione e, aspetto più interessante, consente di introdurre nuovi Spoke senza alcuna nuova configurazione sugli Hub. Infine, poiché lo scenario è DMVPN Fase 1, è sufficiente, come già fatto per EIGRP e OSPF, far annunciare ai router Hub una default-route BGP verso i router Spoke.

Con il solito nostro scenario di rete, queste sono le configurazioni da effettuare sui router SP1 e H1:

 

 

La configurazione del BGP è abbastanza classica e può essere utilizzata come template di configurazione per tutti i router Spoke. L'unica cosa che va valutata è la replicabilità della prefix-list, ma se uno ha fatto un piano di numerazione serio ...

 

 

La configurazione di H1 utilizza i già citati BGP Dynamic Neighbors. Il comando chiave è "bgp listen range 20.0.0.0/24 peer-group SPOKE", che richiede la definizione di un BGP peer-group. Il comando consente di accettare tutte le sessioni BGP aperte da altri BGP peer, che hanno come estremo remoto un indirizzo IP incluso nella subnet IP 20.0.0.0/24. Il comando "bgp listen limit 200" limita a 200 il numero di sessioni BGP accettate da H1. Non è obbligatorio, poiché vi è un limite comunque, dettato dalla "grandezza" della subnet IP. Però in alcune situazioni potrebbe risultare utile. Tutto dipende da quante sessioni BGP è in grado di supportare il router Hub (e per questo è necessario consultare la documentazione tecnica relativa alla piattaforma in uso).

Faccio notare che con l'utilizzo dei BGP Dynamic Neighbors, l'aggiunta di un nuovo Spoke, purché permessa dal limite massimo di sessioni BGP attivabili, non comporta sul router Hub alcuna riga di configurazione aggiuntiva.

Con queste configurazioni, sulla tabella di routing di H1 compaiono i prefissi annunciati (via iBGP) dai router Spoke:

 

Gateway of last resort is not set
 

 

Anche qui, per verificare che il traffico Spoke-Spoke fluisce effettivamente attraverso il router Hub H1, si può eseguire un classico traceroute:

 

 

Poi, utilizzando le classiche metriche del BGP è possibile implementare sui router Spoke scenari di tipo primario/backup, oppure si potrebbe abilitare il BGP multipath e utilizzare le due default-route disponibili in Load Balancing. Ma tutto questo esula da questo post, e lo lascio come eventuale esercizio.

Se invece di utilizzare sessioni iBGP si utilizzassero sessioni eBGP, la prima scelta da fare è se utilizzare numeri diversi di AS sugli Spoke o utilizzare lo stesso numero. Utilizzare numeri diversi ha due grossi svantaggi: la complessità di configurazione in presenza di un elevato numero di Spoke e l'impossibilità di utilizzare i BGP Dynamic Neighbors sugli Hub, poiché il loro utilizzo richiede che tutti i BGP peer dinamici appartengano allo stesso AS. Per cui mi sento di sconsigliare l'utilizzo di numeri di AS diversi. Secondo me la soluzione migliore, nel caso di sessioni eBGP, è di utilizzare un numero di AS per i router Hub e un diverso numero di AS per tutti gli Spoke. Nel nostro esempio utilizzerò i numeri 65101 per i router Hub e 65201 per i router Spoke. Le configurazioni del BGP su SP1 e H1 diventano così:

 

 

 

Quindi, con gli accorgimenti giusti, nel modello DMVPN Fase 1, utilizzare sessioni iBGP o eBGP, dal punto di vista della configurazione, non fa grandi differenze. Ad essere pignoli, un po' di differenza c'è sulla segnalazione. Mentre nel caso di sessioni iBGP, grazie alla nota regola dello split-horizon, gli Hub non annunciano ai router Spoke i prefissi annunciati dagli Spoke