Dynamic Multipoint VPN (DMVPN): Aspetti Generali

È ormai un dato di fatto inconfutabile che la comunicazione aziendale rappresenti un vantaggio competitivo per ogni azienda, sia in termini di riduzione dei costi che di efficienza dei processi.

Le grandi aziende che hanno sedi disperse a livello metropolitano, sul territorio nazionale o internazionale, hanno necessità quindi di una "Rete di Telecomunicazione" che consenta lo scambio di informazioni tra i vari siti aziendali.

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 veicolato 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), 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 che ha un determinato indirizzo logico; 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 "Tunnel 0" 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 i router Hub .

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: 2 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: 2 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.