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.
ROUTING VIA EIGRP
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>.
hostname H1
!
interface Tunnel11
ip address 20.0.0.11 255.255.255.0
no ip split-horizon eigrp 200
ip nhrp map multicast dynamic
ip nhrp network-id 200
ip summary-address eigrp 200 0.0.0.0 0.0.0.0
tunnel source FastEthernet0/1
tunnel mode gre multipoint
!
router eigrp 200
no auto-summary
network 20.0.0.0
network 50.0.0.0
!
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.
hostname SP1
!
interface Tunnel1
ip address 20.0.0.1 255.255.255.0
ip nhrp map multicast 172.16.1.1
ip nhrp map 20.0.0.11 172.16.1.1
ip nhrp network-id 200
ip nhrp nhs 20.0.0.11
tunnel source FastEthernet2/0
tunnel destination 172.16.1.1
!
interface Tunnel11
ip address 30.0.0.1 255.255.255.0
ip nhrp map multicast 172.16.1.2
ip nhrp map 30.0.0.11 172.16.1.2
ip nhrp network-id 300
ip nhrp nhs 30.0.0.11
tunnel source FastEthernet2/0
tunnel destination 172.16.1.2
!
router eigrp 200
no auto-summary
network 20.0.0.0
network 30.0.0.0
network 50.0.0.0
eigrp stub
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.
SP1# show ip route eigrp
. . . < legenda omessa > . . .
Gateway of last resort is 30.0.0.11 to network 0.0.0.0
D* 0.0.0.0/0 [90/26882560] via 30.0.0.11, 00:00:58, Tunnel11
[90/26882560] via 20.0.0.11, 00:00:58, Tunnel1
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:
SP1#sh int tunnel 11 | i DLY
MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
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):
interface tunnel 11
delay 10000
Una identica configurazione andrebbe fatta sugli altri router Spoke. Il risultato che si ottiene è il seguente:
SP1# show ip route eigrp
. . . < legenda omessa > . . .
Gateway of last resort is 20.0.0.11 to network 0.0.0.0
D* 0.0.0.0/0 [90/26882560] via 20.0.0.11, 00:15:04, Tunnel1
Infine, per verificare che il traffico Spoke-Spoke fluisce effettivamente attraverso il router Hub H1, si può eseguire un classico traceroute:
SP1# traceroute 50.0.12.12 source 50.0.11.11
Type escape sequence to abort.
Tracing the route to 50.0.12.12
VRF info: (vrf in name/id, vrf out name/id)
1 20.0.0.11 34 msec 44 msec 37 msec
2 20.0.0.2 38 msec * 34 msec
"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).
ROUTING VIA OSPF
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>.
hostname SP1
! 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".
!
router ospf 100
router-id 1.1.1.1
redistribute connected subnets
network 20.0.0.0 0.0.0.255 area 1
network 30.0.0.0 0.0.0.255 area 1
!
ip route 0.0.0.0 0.0.0.0 Tunnel1
ip route 0.0.0.0 0.0.0.0 Tunnel11 10
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.
hostname H1
!
interface Tunnel11
ip address 20.0.0.11 255.255.255.0
ip nhrp map multicast dynamic
ip nhrp network-id 200
ip ospf network point-to-multipoint
ip ospf database-filter all out
tunnel source FastEthernet0/1
tunnel mode gre multipoint
!
router ospf 100
router-id 11.11.11.11
redistribute connected subnets
network 20.0.0.0 0.0.0.255 area 1
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:
H1# show ip route ospf 100 | i O E2
O E2 50.0.11.0/24 [110/20] via 20.0.0.1, 00:18:42, Tunnel11
O E2 50.0.12.0/24 [110/20] via 20.0.0.2, 00:17:10, Tunnel11
Infine, anche qui, per verificare che il traffico Spoke-Spoke fluisce effettivamente attraverso il router Hub H1, si può eseguire un classico traceroute:
SP1# traceroute 50.0.12.12 source 50.0.11.11
Type escape sequence to abort.
Tracing the route to 50.0.12.12
VRF info: (vrf in name/id, vrf out name/id)
1 20.0.0.11 42 msec 44 msec 38 msec
2 20.0.0.2 48 msec 55 msec 42 msec
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.
ROUTING VIA BGP
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:
hostname SP1
! La configurazione delle interfacce "tunnel 1" e "tunnel 11" è identica a quella già illustrata per il protocollo EIGRP.
!
router bgp 65101
redistribute connected route-map ALLOW-DC
neighbor 20.0.0.11 remote-as 65101
neighbor 30.0.0.11 remote-as 65101
!
ip prefix-list NET-DC seq 5 permit 50.0.0.0/16 le 32
!
route-map ALLOW-DC permit 10
match ip address prefix-list NET-DC
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 ...
hostname H1
!
interface Tunnel11
ip address 20.0.0.11 255.255.255.0
ip nhrp map multicast dynamic
ip nhrp network-id 200
tunnel source FastEthernet0/1
tunnel mode gre multipoint
!
router bgp 65101
neighbor SPOKE peer-group
neighbor SPOKE remote-as 65101
neighbor SPOKE default-originate
bgp listen limit 200
bgp listen range 20.0.0.0/24 peer-group SPOKE
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:
H1# show ip route bgp
... < legenda omessa > ...
Gateway of last resort is not set
50.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
B 50.0.11.0/24 [200/0] via 20.0.0.1, 00:11:55
B 50.0.12.0/24 [200/0] via 20.0.0.2, 00:23:10
Anche qui, per verificare che il traffico Spoke-Spoke fluisce effettivamente attraverso il router Hub H1, si può eseguire un classico traceroute:
SP1# traceroute 50.0.12.12 source 50.0.11.11
Type escape sequence to abort.
Tracing the route to 50.0.12.12
VRF info: (vrf in name/id, vrf out name/id)
1 20.0.0.11 37 msec 34 msec 26 msec
2 20.0.0.2 44 msec 41 msec 45 msec
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ì:
hostname SP1
!
router bgp 65201
redistribute connected route-map ALLOW-DC
neighbor 20.0.0.11 remote-as 65101
neighbor 30.0.0.11 remote-as 65101
!
ip prefix-list NET-DC seq 5 permit 50.0.0.0/16 le 32
!
route-map ALLOW-DC permit 10
match ip address prefix-list NET-DC
hostname H1
!
router bgp 65101
neighbor SPOKE peer-group
neighbor SPOKE remote-as 65201
neighbor SPOKE default-originate
bgp listen limit 200
bgp listen range 20.0.0.0/24 peer-group SPOKE
!
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 stessi, nel caso di sessioni eBGP, a causa dell'automatismo nella propagazione degli annunci, i prefissi annunciati dai router Spoke agli Hub, vengono annunciati automaticamenti agli altri router Spoke, ma questi ultimi scarteranno gli annunci ricevuti dagli Hub a causa del controllo dell'AS_PATH. A dire il vero questo comportamento (poco efficiente, i router Juniper ad esempio non inviano in questa situazione i messaggi BGP UPDATE !) può essere evitato con un semplice filtro outbound basato sull'AS_PATH. Ma pochi lo fanno !
Si noti infine che se si utilizzassero sui router Spoke numeri di AS diversi, al fine di evitare che i prefissi annunciati dai router Spoke vengano automaticamente propagati agli altri router Spoke, e che questi li installino in Tabella di Routing (non necessario se si invia dagli Hub una default-route) è bene configurare sui router Hub un filtro outbound che consenta l'annuncio della sola default-route (oppure, per i più esperti, uno stupendo filtro basato sull'AS_PATH, con Regular Expression ^$). Tra l'altro questo filtro risolverebbe anche il problema di ottimizzazione appena descritto sopra, nel caso di numeri di AS uguali negli Spoke.
In conclusione, nel modello DMVPN Fase 1, nel caso si voglia utilizzare come protocollo di routing il BGP, io consiglio l'utilizzo di sessioni iBGP.
QUALE PROTOCOLLO UTILIZZARE ?
Ho illustrato nelle sezioni precedenti tre possibili protocolli di routing per l'utilizzo con le DMVPN Fase 1. Quale scegliere in pratica ? In termini di velocità di convergenza, non vi sono grandi differenze. Io personalemente non utilizzerei OSPF poiché poco scalabile per questo scenario e richiede la configurazione di default-route statiche sui router Spoke, a meno di non inondare questi ultimi con un numero elevato (pari al numero di router della DMVPN) di LSA di tipo 1. E poi non mi fido troppo dell'implementazione Cisco di OSPF su reti NBMA. Nei vecchi documenti, Cisco stessa consigliava di utilizzare sub-interfacce Frame Relay punto-punto in luogo di tutte le varie modalità disponibili !
Poi scarterei l'EIGRP perché poco flessibile per l'applicazione delle politiche di routing. E poi EIGRP è un protocollo proprietario (e a me i protocolli proprietari non piacciono !).
In ultima analisi, io consiglio l'utilizzo del BGP, per la sua elevata flessibilità e ricchezza di metriche e la scarsa occupazione di memoria (ricordo che il BGP è stato progettato per lavorare con centinaia di migliaia di prefissi). Di più, consiglio l'utilizzo di sessioni iBGP. Però, per non incorrerre in incubi notturni, è fondamentale l'utilizzo dei BGP Dynamic Neighbors sugli Hub. Altrimenti, anche io che ho un debole per il BGP, mi sentirei di sconsigliarlo. Ma il problema non si pone, a meno che non abbiate, per gli Hub, piattaforme che li supportano, nel qual caso utilizzate EIGRP !!!
Ovviamente, tutto ciò vale in reti con molti Spoke. In piccole reti "tutto fa brodo".
CONCLUSIONI
In questo post ho cercato di illustrare l'utilizzo di tre ben noti protocolli di routing al modello DMVPN, che era l'argomento mancante nel posto precedente "DMVPN Fase 1 - Parte I".
In realtà dovrei scrivere un post dal titolo "DMVPN Fase 1 - Parte III" trattando anche gli aspetti di sicurezza, ossia, come integrare IPSec nelle configurazioni effettuate. Ma questo in futuro, quando terminerò i post su DMVPN Fase 2 e Fase 3. L'integrazione di IPSec è comune e indipendente dalle varie fasi, per cui sarà trattata in post unico (spero !) dedicato.
In passato questo problema veniva risolto attraverso la realizzazione di vere e proprie "reti private fisiche", costituite da apparati di concentrazione e commutazione del traffico di proprietà dell’Azienda, fisicamente connessi tra loro attraverso collegamenti trasmissivi presi in affitto da un Operatore di Reti di Telecomunicazione. Questa soluzione, perseguita soprattutto dalle grandi Aziende, aveva però degli svantaggi che ne precludevano l’impiego su larga scala, tra i quali:
- Scarso utilizzo dei mezzi trasmissivi dovuto alla variabilità del profilo di traffico, che come noto dipende dall’ora del giorno, dal giorno della settimana e anche in molti casi dalla stagionalità.
- Elevati investimenti in tecnologia, sia nella fase di realizzazione della rete che successivamente per il suo aggiornamento.
- Forti spese di gestione, dovute alla necessità di avere del personale specializzato nell’esercizio della rete o al ricorso alla gestione in outsourcing.
Nonostante ciò, gli anni passati hanno visto il crescere di queste reti tanto che alcune sono diventate il trampolino di lancio, dalla fine degli anni ’90, per la costituzione di nuove società fornitrici di servizi di telecomunicazione che, grazie alla liberalizzazione del mercato, hanno iniziato le loro attività in competizione con le tradizionali società di telecomunicazioni.
MODELLI DI RETI PRIVATE VIRTUALI
Con l’avvento delle prime reti pubbliche a commutazione di pacchetto, basate inizialmente sugli standard X.25 e Frame Relay, lo scenario è pian piano cambiato. I maggiori Operatori pubblici di Reti di Telecomunicazione hanno infatti iniziato ad offrire servizi sostitutivi dei costosi collegamenti trasmissivi dedicati. In particolare, in questo nuovo scenario il collegamento tra gli apparati di commutazione (router) non avviene più tramite collegamenti fisici dedicati, ma attraverso una rete condivisa.
La convenienza è ovviamente la maggiore economicità della soluzione, non dovendo il Cliente ricorrere a costose linee dedicate. Per le reti costruite secondo questo paradigma, è stato coniato il termine "Reti Private Virtuali" (Virtual Private Network, VPN), dove l’aggettivo "Private" indica che queste permettono la comunicazione tra i vari siti aziendali alla stessa stregua di una rete privata fisica, mentre l’aggettivo "Virtuali" indica che queste sono collegate attraverso una rete condivisa.
Un aspetto importante legato alle VPN è se la rete condivisa si fa carico o meno dell’instradamento del traffico IP o funge da mero mezzo di collegamento (a Livello 2 o Livello 3) tra i router. La differenza tra le due modalità da luogo a due diversi modelli di realizzazione delle VPN:
- Modello overlay.
- Modello peer-to-peer.
Nel modello overlay la rete condivisa non partecipa all’instradamento di Livello 3. Ciò significa che il ruolo della rete condivisa è di fornire un collegamento virtuale tra i router costituenti la VPN. In un certo senso, questo modello è simile ad una rete privata fisica in quanto il Cliente ha il completo controllo della rete, ma il collegamento tra i router è effettuato attraverso più economici Canali Virtuali Permanenti (CVP) su reti di Livello 2 (tipicamente Frame Relay o ATM) o Tunnel IP di vario tipo su reti IP (GRE, IPsec, L2TPv3, ecc.).
La filosofia rimane comunque la stessa di una rete privata fisica, ossia quella di una rete privata dove però gli apparati dei Clienti sono connessi attraverso "collegamenti virtuali» (e non fisici) realizzati su una rete pubblica. Per questo tipo di soluzione viene utilizzato il termine di modello overlay poiché la VPN (rete logica) utilizza i servizi di connettività di una rete di trasporto fisica (a commutazione di pacchetto).
Il concetto di VPN si è evoluto negli anni fino a comprendere un modello molto più efficiente ed economico, secondo il quale i siti aziendali sono collegati a una rete pubblica, che si occupa dell’instradamento e della segregazione del traffico (modello peer-to-peer). In tal modo le necessità di gestione degli apparati di proprietà dell’Azienda vengono ridotte al minimo, lasciando tutto il lavoro complesso, e i relativi elevati investimenti in tecnologia, al fornitore del servizio. Questo modello ha avuto grande successo a partire dai primi anni 2000 grazie all'introduzione di MPLS nelle reti IP, ed è oggi uno dei più utilizzati nelle applicazioni pratiche (VPN IP BGP/MPLS).
La figura seguente riporta una classificazione dei vari modelli di VPN oggi utilizzati.
Si noti che nella figura ho utilizzato, per indicare i servizi VPN che sto trattando, la notazione L3VPN. Questo perché è possibile realizzare anche servizi L2VPN, dove tra i router del Cliente vengono scambiate direttamente trame L2 (es. trame Ethernet, PPP, celle ATM, ecc.) e non direttamente pacchetti IP.
Tra i modelli di L3VPN di tipo overlay, vi sono alcuni che utilizzano per il trasporto una rete IP (ad esempio l'Internet pubblica), utilizzando meccanismi di "tunneling IP" (es. GRE, IPsec, SSL, ecc.). In questo post, al quale ne seguiranno altri più "operativi" sullo stesso tema, inizierò a parlare di un modello overlay basato su reti IP (pubbliche o private), che negli ultimi anni ha avuto un discreto successo nelle applicazioni pratiche. Questo tipo di VPN è stato proposto da Cisco ed è noto come Dynamic Multipoint VPN (DMVPN).
DMVPN: ASPETTI BASE
Le VPN realizzate attraverso il modello DMVPN si poggiano su reti IP e utilizzano come protocollo di tunneling IP il "multipoint GRE" (mGRE), una estensione del classico protocollo GRE, dove non è necessario determinare, in fase di configurazione, la destinazione del tunnel. La destinazione viene determinata dinamicamente attraverso il protocollo NHRP (Next Hop Resolution Protocol), un protocollo che può essere pensato come l’equivalente dell’inverse-ARP nelle reti Frame Relay, o dell'ARP nelle reti Ethernet.
Il modello DMVPN si basa quindi su due elementi fondamentali: tunnel IP mGRE e protocollo NHRP. In realtà a questi due protocolli si aggiunge sempre il protocollo IPsec, che come noto garantisce proprietà di sicurezza della comunicazione, sempre opportune quando il traffico viene veivolato attraverso una rete pubblica. Tratterò questi aspetti di sicurezza in uno dei prossimi post. In questo post cercherò, prima di continuare, di dare qualche informazione in più su questi due elementi. Poi illustrerò come questi, combinati tra loro, formano la base del modello DMVPN.
TUNNEL mGRE
Tutti noi conosciamo i tunnel GRE di tipo punto-punto (p2p). Sono particolari tunnel IP dove il protocollo passeggero può essere qualsiasi, e il protocollo di trasporto è IP. Il "protocol ID" del pacchetto IP di trasporto che identifica un tunnel GRE è 47. Il protocollo passeggero è identificato da 4 byte (più eventualmente altri opzionali), di cui 2 byte sono il codice (nel formato Ethertype) del protocollo passeggero (es. IPv4 0x0800, IPv6 0x86dd).
Quando si configura un tunnel GRE p2p, è necessario specificare gli indirizzi IP sorgente e destinazione utilizzati dall'header IP di trasporto.
I tunnel mGRE sono invece del tipo punto-multipunto, ossia, a partire da un qualsiasi router sorgente predefinito, è possibile raggiungere un qualsiasi router destinazione. Il meccanismo di trasporto è identico a quello dei tunnel GRE p2p, ossia i pacchetti del protocollo passeggero viaggiano incapsulati direttamente in pacchetti IPv4. Il principio di funzionamento si basa sul fatto che l’estremo remoto del tunnel (indirizzo IP destinazione) è definito automaticamente, mentre quello locale (sorgente) è definito manualmente su base configurazione.
Quando si configura un tunnel mGRE, è bene che l’indirizzo sorgente del tunnel sia routable sull’Internet pubblica (sarebbe obbligatorio se si utilizzassero come reti IP di trasporto delle reti pubbliche). L’indirizzo destinazione viene scelto dinamicamente, ma nel caso di utilizzo di reti IP pubbliche per il trasporto, anche questo deve essere routable.
Tutti i tunnel che partecipano a mGRE devono avere le interfacce tunnel con indirizzo IP appartenente alla stessa subnet IP, tipicamente presa dallo spazio di indirizzamento privato del Cliente.
IL PROTOCOLLO NHRP
NHRP è un vecchio protocollo standardizzato nella
RFC 2332 "
NBMA Next Hop Resolution Protocol (NHRP)", dell’Aprile 1998, nato originariamente per creare uno schema di routing ottimizzato per reti
Non Broadcast Multiple Access (
NBMA), come ATM,
Frame Relay e
SMDS (NOTA:
SMDS,
Switched Multi-megabit Data Service, è un vecchio protocollo (
connectionless) per l'interconnessione di LAN/MAN/WAN, sviluppato dai celebri laboratori Bellcore nei primi anni '90, che i più giovani probabilmente non hanno mai nemmeno sentito nominare. Da qui si deduce che io sono a pieno titolo parte dell'associazione VIT, "Vecchi Ingegneri delle TLC").
Nel modello DMVPN, NHRP viene utilizzato per determinare l'indirizzo IP destinazione dei tunnel mGRE. In pratica, mette in corrispondenza un indirizzo IP logico, che è l'indirizzo IP assegnato all'interfaccia "tunnel mGRE", con un indirizzo IP fisico, detto comunemente indirizzo NBMA, che è l'indirizzo IP destinazione del tunnel GRE. Il protocollo NHRP è del tipo Client-Server: un NHRP Client (NHC) invia a un NHRP Server (NHS) una richiesta per ottenere l'indirizzo fisico (NBMA) di un altro router cha ha un determinato indirizzo logico, e il NHS risponde con l'associazione <Indirizzo Logico ; Indirizzo NBMA>.
Naturalmente, questo processo richiede un passo preliminare: la registrazione sul NHS, da parte di ciascun NHC, della propria associazione <Indirizzo Logico ; Indirizzo NBMA>. Per rendere possibile la registrazione, ogni NHC deve avere l'indirizzo del NHS su cui registrare la sua associazione. Il NHS agisce come un database, che può essere interrogato da ciascun NHC per ottenere l'associazione desiderata. Per gli esperti di routing multicast, questo processo è simile a ciò che avviene nel PIM-SM, dove le sorgenti di traffico si registrano presso un router particolare, il Rendezvous-Point.
DMVPN = mGRE + NHRP (+ ROUTING IP)
Il modello DMVPN utilizza i concetti di tunnel mGRE e protocollo NHRP descritti sopra, per creare VPN overlay con trasporto su una rete IP. Per completare il funzionamento si ha ovviamente bisogno anche di un protocollo di routing che consenta di creare in ciascun router, i percorsi verso le varie subnet IP presenti sui router della VPN.
Il routing tra i router della DMVPN può essere realizzato attraverso un protocollo di routing dinamico (es. RIPv2, EIGRP, OSPF, BGP). È possibile, grazie al fatto che i tunnel mGRE sono in grado di trasportare pacchetti multicast, abilitare tra i router della DMVPN, anche il routing multicast.
Per maggiore sicurezza nel trasporto dei dati, è poi possibile implementare "mGRE over IPsec", ossia trasportare i pacchetti incapsulati nei tunnel GRE, all'interno di un tunnel IPsec.
Mostrerò ora, con l'ausilio della figura seguente, il legame tra tunnel mGRE, NHRP e routing IP.
Il router R1 riceve un pacchetto IP diretto a una LAN raggiungibile via R4, con indirizzi IP sorgente e destinazione rispettivamente 172.20.1.1 e 172.20.4.1. Il router R1 evince da un lookup sulla Tabella di Routing IP, che l'interfaccia Next-Hop è l'interfaccia Tunnel0 e l'indirizzo IP Next-Hop è 10.1.1.4 (indirizzo logico del tunnel GRE su R4). Questa riga della Tabella di Routing viene costruita attraverso un protocollo di routing dinamico. Ora, R1 ha bisogno di conoscere l'indirizzo NBMA corrispondente all'indirizzo logico 10.1.1.4. Per questo consulta la propria Tabella NHRP, dalla quale ottiene l'associazione <10.1.1.4 --> 192.168.0.4> (NOTA: la Tabella NHRP può essere pensata come l'equivalente dell'ARP Cache negli Host e nei router). A questo punto, R1 incapsula il pacchetto IP originale in un pacchetto GRE, con indirizzi IP sorgente e destinazione rispettivamente 192.168.0.1 (indirizzo sorgente del tunnel GRE configurato manualmente su R1) e 192.168.0.4 (dedotto dalla Tabella NHRP). Il pacchetto IP risultante viene quindi instradato verso R4 dalla rete IP, e da R4 decapsulato. Il pacchetto IP risultante è quello originale, che viene instradato fino alla destinazione.
L'applicazione naturale del modello DMVPN è con topologie di tipo Hub-and-Spoke. Vi sono due implementazioni possibili del modello DMVPN:
- DMVPN fase 1 : la comunicazione diretta è limitata solo tra Hub e Spoke. La comunicazione Spoke-Spoke può avvenire, ma solo transitando attraverso un Hub.
- DMVPN fase 2: è possibile realizzare comunicazioni dirette Spoke-Spoke (senza quindi passare attraverso un Hub) tra tutti o un sottoinsieme di Spoke.
Esiste anche un modello DMVPN fase 3, di cui parlerò in seguito, che comunque è un miglioramento del modello DMVPN fase 2. Il ruolo di NHS è assegnato al router (o ai router, vedi sezione successiva) Hub, mentre i router Spoke hanno il ruolo di NHC.
Si noti che una topologia Hub-and-Spoke potrebbe tranquillamente essere realizzata anche con tunnel GRE p2p, ma questo limiterebbe di molto la scalabilità, data la necessità di avere sull’Hub tante interfacce tunnel quanti sono i router Spoke, con conseguente maggiore consumo di memoria a causa della necessità di creare tanti IDB (Interface Descriptor Block). L’utilizzo di mGRE ha bisogno invece di una sola interfaccia tunnel (di tipo punto-multipunto), limitando di fatto a uno il numero di IDB. Inoltre, l’utilizzo di tunnel GRE p2p ha l’ulteriore svantaggio di aumentare di molto lo spazio di indirizzamento necessario.
TOPOLOGIE DMVPN
Nelle applicazione pratiche, le topologie Hub-and-Spoke non hanno (quasi) mai, per ovvie ragioni di affidabilità, un singolo Hub, ma Hub ridondati. Con Hub ridondati, si possono avere due topologie diverse: Dual DMVPN Cloud e Single DMVPN Cloud.
Nella topologia Dual DMVPN Cloud vengono utilizzate due diverse istanze DMVPN, come mostrato nella figura seguente:
Gli Hub richiedono ciascuno la configurazione di un singolo tunnel mGRE, mentre gli Spoke la configurazione di due tunnel GRE (p2p nelle DMVPN fase 1 e mGRE nelle DMVPN fase 2 e 3). Sono inoltre necessarie due subnet IP per assegnare gli indirizzi logici alle interfacce tunnel, una subnet per ciascuna istanza DMVPN. Si noti che con questa topologia, non è possibile la comunicazione Spoke-Spoke utilizzando diverse istanze DMVPN. La comunicazione Spoke-Spoke è possible solo all'interno della stessa istanza DMVPN.
Nella topologia Single DMVPN Cloud viene invece utilizzata una singola istanza DMVPN, come mostrato nella figura seguente:
Con questa topologia, sia gli Hub che gli Spoke richiedono la configurazione di un singolo tunnel mGRE, e inoltre è necessaria una singola subnet IP per assegnare gli indirizzi logici alle interfacce tunnel. Qualora si volesse inibire la comunicazione diretta Spoke-Spoke, non è possibile utilizzare questa topologia, poiché non esiste alcun meccanismo di failover per gli Hub router.
La raccomandazione Cisco in ogni caso è utilizzare sempre la topologia Dual DMVPN Cloud. Questo perché la topologia Single DMVPN cloud deve far affidamento a meccanismi diversi dal tunnel mGRE, per determinare l'Hub di backup in caso di fuori servizio dell'Hub primario. Per contro, nel caso di topologie Dual DMVPN Cloud, un router Hub può far affidamento al protocollo di routing abilitato all'interno del tunnel mGRE per determinare percorsi alternativi.
Sono possibili anche topologie più sofisticate come quelle con Hub gerarchici (Hub e Super-Hub), che comunque non tratterò, anche perché da un punto di visto concettuale hanno poco da aggiungere.
VANTAGGI DELLE DMVPN
Riassumendo, le maggiori caratteristiche del modello DMVPN sono le seguenti:
- Consistente riduzione delle righe di configurazione (con conseguente riduzione della probabilità di errore !) e implementazione "no-touch" di nuovi Spoke. L'introduzione di un nuovo Spoke non comporta alcuna nuova configurazione sui router Hub.
- Supporto IP Unicast (IPv4 e IPv6), IP Multicast, e dei protocolli di routing dinamici (RIPv2, EIGRP, OSPF, BGP).
- Supporto di peer remoti con indirizzi IP assegnati dinamicamente. Ossia, un router Hub non ha bisogno di alcuna configurazione statica degli indirizzi IP logici dei router Spoke.
- Supporto di router Spoke dietro NAT dinamico e Hub router dietro NAT statico.
- Possibilità di tunnel dinamici Spoke-Spoke per la realizzazione di VPN partial/full-mesh.
- Utilizzabile con o senza cifratura IPsec.
Giusto per avere un'idea della consistente riduzione delle righe di configurazione, vediamo con qualche numero un confronto nella configurazione degli Hub, tra VPN costruite con tunnel GRE p2p e VPN realizzate con il modello DMVPN.
Con tunnel GRE p2p:
- Singola interfaccia GRE, o due nel caso di Hub ridondati, per ciascun Spoke.
- Tutti i tunnel GRE hanno bisogno di indirizzi IP fisici sorgente e destinazione statici. Ciascun tunnel GRE ha bisogno di un indirizzamento logico separato (molte subnet IP, anche se questo è evitabile utilizzando interfacce di tipo "unnumbered").
Esempio: Due Hub con 500 Spoke
- N.ro interfacce tunnel sugli Hub = 2*500 = 1.000.
- N.ro interfacce tunnel su ciascun Spoke = 2.
- N.ro totale interfacce tunnel = 2*500 + 1.000 = 2.000.
- N.ro minimo di righe di configurazione per i tunnel GRE sugli Hub (4 righe per tunnel) = 4*1.000 = 4.000 (= 2.000/Hub).
- 4 subnet IP /30 per Spoke (due per ciascun Hub) = 4*500 = 2.000 subnet IP (totale di 8.000 indirizzi IP).
- L'aggiunta di uno Spoke richiede variazioni nella configurazione di ciascun Hub.
- Il traffico diretto Spoke-Spoke non è possibile.
Con il modello DMVPN:
- Una interfaccia tunnel mGRE per tutti gli Spoke.
- Non è necessario assegnare staticamente l'indirizzo IP destinazione dei tunnel GRE, semplificando il supporto di Spoke con indirizzo IP dinamico.
- Configurazione del protocollo NHRP.
Esempio: Due Hub con 500 Spoke
- N.ro interfacce tunnel sugli Hub = 2 (una per ciascun Hub).
- N.ro interfacce tunnel su ciascun Spoke = 2.
- N.ro totale interfacce tunnel = 2*500 + 2 = 1.002.
- N.ro minimo di righe di configurazione per i tunnel mGRE sugli Hub (circa 15 righe, inclusa la configurazione di NHRP) = 2*15 = 30.
- Due subnet IP /23, una per ciascun Hub e 500 Spoke (totale di 1.024 indirizzi IP, di cui utilizzati 1.002).
- L'aggiunta di uno Spoke NON richiede variazioni nella configurazione degli Hub.
- Possibilità di traffico diretto Spoke-Spoke.
CONCLUSIONI
Questo è il primo di una lunga serie di post sul modello DMVPN. Questo modello è stato introdotto da Cisco e gode di un certo favore tra i progettisti e amministratori di rete. Nei prossimi post vedremo gli aspetti operativi, le configurazioni, e vedremo molti dettagli di funzionamento.
Come sempre, alla fine di questa lunga serie di post cercherò di raccogliere tutto in un documento organico che potrà essere di ausilio nel caso siate interessati ad applicazioni reali.
