venerdì 27 febbraio 2015

DMVPN Fase 1 - Parte I

Nel post precedente sul modello DMVPN, ho introdotto due diverse implementazioni, che differiscono dalla modalità con cui è possibile la comunicazione tra Spoke. In questo post tratterò la modalità DMVPN Fase 1, dove la comunicazione diretta è limitata solo tra Hub e Spoke. La comunicazione Spoke-Spoke può avvenire, ma solo transitando attraverso un Hub


In questo post introdurrò, come passo preliminare, le configurazioni base per la realizzazione dei tunnel mGRE e l'attivazione del protocollo NHRP, configurazioni che risulteranno valide anche quando tratteremo nel seguito l'implementazione DMVPN Fase 2.

RETE TEST
Per illustrare le configurazioni, utilizzerò la seguente rete test, dove inizialmente utilizzerò un solo router Hub e successivamente entrambi.





La figura riporta gli indirizzi IP utilizzati nelle varie interfacce.

Per consentire la comunicazione tra gli indirizzi IP che verranno utilizzati come sorgente dei tunnel GRE, ho attivato un'area 0 OSPF come specificato nella figura. Faccio notare che questa una soluzione non è "esportabile" nelle reti in produzione, dove di norma la comunicazione tra questi indirizzi IP, si ottiene attraverso un processo di redistribuzione nel processo di routing IGP o BGP dell'ISP, in funzione dell'architettura di routing adottata.

CONFIGURAZIONI BASE DEL PROTOCOLLO NHRP E DEL TUNNEL mGRE
Partirò dal caso più semplice di topologia con un singolo Hub. Utilizzerò come router Hub, il router H1 della figura sopra.

Prima di qualsiasi configurazione, è necessario scegliere la subnet IP per la numerazione degli indirizzi logici dei tunnel GRE/mGRE. Ricordo che tutti gli indirizzi logici devono appartenere alla stessa subnet IP. Nell'esempio, vedi figura seguente, utilizzerò la subnet IP 20.0.0.0/24. La figura seguente riporta il piano di numerazione logico (oltre al piano di numerazione delle LAN fisiche presenti su ciascun router, che sarà utilizzato quando, nel post successivo, sarà aggiunto alla rete il routing IP).





L'attivazione dei protocolli NHRP e mGRE avviene all'interno della configurazione di una interfaccia vituale "tunnel X", con X numero intero arbitrario (non negativo). Come già detto nel post precedente sugli aspetti generali del modello DMVPN, in uno scenario simile solo l'Hub ha bisogno di un tunnel mGRE, mentre sugli Spoke viene configurato un normale tunnel GRE punto-punto (p2p). Il ruolo di NHRP Server (NHS) è assegnato al router Hub H1, mentre i router Spoke sono NHRP Client (NHC).

Riporto di seguito le configurazioni rilevanti delle interfacce "tunnel X" sui router H1 e SP1. La configurazione sul router SP2 è identica a quella del router SP1, a parte l'indirizzo IP logico. 

hostname SP1
!
interface Tunnel1
  ip address 20.0.0.1 255.255.255.0
  ip nhrp authentication SSGRR
  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
  ip nhrp registration timeout 90
  ip nhrp holdtime 120
  tunnel source FastEthernet2/0
  tunnel destination 172.16.1.1

hostname H1
!
interface Tunnel11
  ip address 20.0.0.11 255.255.255.0
  ip nhrp authentication SSGRR
  ip nhrp map multicast dynamic
  ip nhrp network-id 200
  tunnel source FastEthernet0/1
  tunnel mode gre multipoint

La configurazione prevede vari passi, di cui alcuni obbligatori e alcuni opzionali. Inoltre, alcuni comandi sono specifici dei router Spoke, altri del router HubPrima commento i comandi sul router Spoke SP1 e poi per differenza quelli sul router Hub H1.

Il primo comando (obbligatorio) sul router SP1 è l'assegnazione dell'indirizzo IP logico all'interfaccia "tunnel X". L'indirizzo utilizzato è tratto, come da figura sopra, dalla subnet IP 20.0.0.0/24.

Il secondo comando (opzionale) è l'assegnazione di una password per l'autenticazione dei messaggi NHRP. La password deve coincidere su tutti i router.

I due comandi successivi sono obbligatori e molto importanti. Il primo, "ip nhrp map multicast 172.16.1.1" consente di specificare la lista di destinazioni a cui è possibile inviare pacchetti multicast (NOTA: per chi di voi ricorda le basi della configurazione del Frame Relay in ambiente Cisco, questo comando è analogo al classico comando "frame-relay map ... broadcast"). Nell'esempio, l'indirizzo 172.16.1.1 corrisponde al router Hub H1. Si noti che questo comando è fondamentale per attivare successivamente un protocollo di routing IP dinamico poiché come noto, molti messaggi di questi protocolli utilizzano indirizzi IP destinazione multicast

Il comando successivo, "ip nhrp map 20.0.0.11 172.16.1.1", consente di stabilire un'associazione statica tra l'indirizzo logico 20.0.0.11 del tunnel mGRE sul router Hub H1, e l'indirizzo fisico (anche detto indirizzo NBMA) da utilizzare nell'incapsulamente GRE.

Il comando seguente "ip nhrp network-id 200" è obbligatorio e il valore di "network-id" (= 200 nell'esempio) deve coincidere su tutti i router. Questo consente di creare più istanze DMVPN sulla stessa rete IP, assegnando a ciascuna un diverso "network-id"

Il comando "ip nhrp nhs 20.0.0.11" specifica al router Spoke quale NHS utilizzare per la registrazione delle associazioni <Indirizzo logico ; Indirizzo fisico>. Nell'esempio, il NHS è individuato dall'indirizzo logico 20.0.0.11, che corrisponde all'indirizzo logico dell'interfaccia "tunnel 11" sul router Hub H1, che ha il ruolo di NHS. Si noti che l'indirizzo utilizzato è un indirizzo logico, che è risolto dall'associazione statica definita tramite il comando precedente "ip nhrp map 20.0.0.11 172.16.1.1". Ricordo che il NHS è utilizzato dai router Spoke per la registrazione delle associazioni <Indirizzo logico ; Indirizzo fisico>.

Infine, gli ultimi due comandi che riguardano il protocollo NHRP sono opzionali e riguardano due timer che regolano la durata delle registrazioni sul NHS. Il comando "ip nhrp holdtime 120" indica che ogni registrazione ha un tempo di vita di 120 sec (il valore di default è 7.200 sec, pari a due ore), per cui va rinfrescata prima della scadenza. Il tempo di rinfresco, ossia il periodo con cui i router Spoke inviano di nuovo la registrazione, è di default pari a 1/3 del valore di holdtime. Questo valore può comunque essere variato con il comando "ip nhrp registration timeout ...". Nell'esempio abbiamo utilizzato il valore 90, che indica che i router Spoke "rinfrescano" il messaggio di registrazione ogni 90 sec. Senza questo comando, il periodo di rinfresco sarebbe stato 40 sec (= 1/3 di 120).

Gli ultimi due comandi della configurazione dell'interfaccia "tunnel X" riguardano il tunnel GRE, che per gli Spoke, nel modello DMVPN fase 1, sono di tipo p2p. I due comandi specificano gli indirizzi IP sorgente e destinazione da utilizzare nei pacchetti IP utilizzati nell'incapsulamento GRE. L'indirizzo IP sorgente è specificato tramite l'interfaccia. Potrebbe essere specificato anche attraverso un indirizzo IP, ma utilizzare direttamente l'interfaccia risulta più comodo in caso rinumerazione.

Sul router Hub H1 non serve specificare alcuna associazione statica, né specificare (ovviamente) il NHS. E' però necessario anche qui specificare le destinazioni a cui è possibile inviare pacchetti multicast. A differenza dei router Spoke, non è però necessario specificare staticamente la lista delle destinazioni. Il router Hub infatti, invia i pacchetti multicast a tutti i router Spoke registrati attraverso il protocollo NHRP. Per questo nel comando "ip nhrp map multicast ..." compare l'opzione "dynamic" piuttosto che un indirizzo IP.

Infine, gli ultimi due comandi su H1 riguardano la configurazione del tunnel mGRE. Come si può notare, l'indirizzo IP sorgente viene specificato nel modo usuale, ma l'indirizzo destinazione non è specificato. A causa della presenza del comando "tunnel mode gre multipoint", il tunnel viene definito come mGRE, per cui l'indirizzo IP destinazione non è statico, ma determinato dinamicamente, come spiegato nel post precedente sugli aspetti generali del modello DMVPN.

Con le configurazioni appena commentate, ho impostato un test di laboratorio, utilizzando router con IOS 15.2(4)S6. Per verificare i risultati si utilizzano vari comandi, di cui ne riporto un paio fondamentali sul router H1:

H1# show ip nhrp
20.0.0.1/32 via 20.0.0.1
  Tunnel11 created 00:00:33, expire 00:01:26
  Type: dynamic, Flags: unique registered used
  NBMA address: 10.1.11.2
20.0.0.2/32 via 20.0.0.2
  Tunnel11 created 00:00:34, expire 00:01:25
  Type: dynamic, Flags: unique registered used
  NBMA address: 10.1.11.6

Questa visualizzazione mostra che sul router H1 sono registrate le due associazioni <20.0.0.1 ; 10.1.11.2> e <20.0.0.2 ; 10.1.11.6>. La registrazione è stata possibile dall'invio di messaggi NHRP Register inviati al router H1, che ha il ruolo di NHS, dai due NHC SP1 e SP2. Per la spiegazione di tutti i vari campi della visualizzazione (alcuni molto intuitivi) vi rimando alla documentazione Cisco.

Per i più curiosi, potete scaricare qui il file H1.cap, visualizzabile con wireshark, dove è riportata la struttura anche dei messaggi NHRP Registration e NHRP Reply (vedi messaggi dal 70 al 73), e da dove è possibile vedere anche il refresh periodico dei messaggi di registrazione, con un periodo pari al valore configurato di 90 sec.

H1# show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface: Tunnel11, IPv4 NHRP Details
Type:Hub, NHRP Peers:2,

# Ent      Peer NBMA Addr   Peer Tunnel Add   State   UpDn Tm    Attrb
-----       --------------------   ---------------------  -------  ------------   -------
     1      10.1.11.2              20.0.0.1               UP      00:07:02           D
     1      10.1.11.6              20.0.0.2               UP      00:07:03           D


Questa visualizzazione mostra invece le caratteristiche della DMVPN. Sono specificati il nome dell'interfaccia "tunnel X" (Interface: Tunnel11), il ruolo del router (Type:Hub), il numero di Spoke (NHRP Peers:2). Inoltre sono specificati l'indirizzo NBMA degli Spoke (Peer NBMA Addr), l'indirizzo logico (Peer Tunnel Add), lo stato (UP), e come sono sono stati scoperti gli Spoke (Attrb), dove "D" sta per Dynamic (vedi legenda).

Gli stessi due comandi eseguiti su SP1 forniscono i seguenti risultati, il cui (facile) commento lo lascio come utile esercizio.

SP1# show ip nhrp
20.0.0.11/32 via 20.0.0.11
  Tunnel1 created 00:08:51, never expire
  Type: static, Flags:
  NBMA address: 172.16.1.1


SP1# show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
Interface: Tunnel1, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,

# Ent      Peer NBMA Addr   Peer Tunnel Add   State   UpDn Tm    Attrb
-----       --------------------   ---------------------  -------  ------------   -------
    1        172.16.1.1            20.0.0.11             UP      00:08:14           S

A questo punto del test, è stata stabilita la connettività tra gli indirizzi logici della DMVPN. Ciò si può verificare effettuando dei banali ping:

SP1# ping 20.0.0.11
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.0.11, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 18/24/31 ms

SP1# ping 20.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 15/19/18 ms


CONFIGURAZIONI BASE NEL CASO DI TOPOLOGIA DUAL DMVPN
Le configurazioni viste nella sezione precedente possono essere facilmente generalizzate al caso di topologia Dual DMVPN, che ricordo, prevede due router Hub e due diverse istanze DMVPN. Sono necessarie quindi due diverse subnet IP per la numerazione degli indirizzi logici. Utilizzerò come seconda subnet IP 30.0.0.0/24. Esporrò le configurazioni su H1 e SP1 senza aggiungere alcun commento, che lascio al lettore come utile esercizio. Le configurazioni su SP2 e H2, a parte gli indirizzi IP logici e fisici, sono identiche.

hostname SP1
!
interface Tunnel1
  ip address 20.0.0.1 255.255.255.0
  ip nhrp authentication SSGRR-1
  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
  ip nhrp registration timeout 90
  ip nhrp holdtime 120
  tunnel source FastEthernet2/0
  tunnel destination 172.16.1.1
!
interface Tunnel11
  ip address 30.0.0.1 255.255.255.0
  ip nhrp authentication SSGRR-2
  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
  ip nhrp registration timeout 90
  ip nhrp holdtime 120
  tunnel source FastEthernet2/0
  tunnel destination 172.16.1.2

Si noti che sui router Spoke sono necessari in questo caso due differenti tunnel GRE p2p. La configurazione di H1 è identica al caso di Hub singolo.

hostname H1
!
interface Tunnel11
  ip address 20.0.0.11 255.255.255.0
  ip nhrp authentication SSGRR
  ip nhrp map multicast dynamic
  ip nhrp network-id 200
  tunnel source FastEthernet0/1
  tunnel mode gre multipoint

INTRODUZIONE DEL ROUTING IP
Per completare l'implementazione manca all'appello il routing IP. Scopo ultimo del modello DMVPN è quello di mettere in comunicazione le LAN raggiungibili dai router Hub e Spoke, e quindi affinché ciascun router sappia come raggiungerle è necessario abilitare un protocollo di routing IP.

Ma questo post è diventato troppo lungo, per cui vi rimando al prossimo "DMVPN Fase 1 - Parte II".

CONCLUSIONI 
Con questo post, continuo la discussione iniziata con il post precedente sul modello DMVPN. In particolare ho msso in evidenza le configurazioni del protocollo NHRP e dei tunnel mGRE (e p2p sugli Spoke). Mancano all'appello due tasselli fondamentali: l'introduzione del routing IP, che come detto sopra sarà trattata nel post successivo, e la parte sugli aspetti di sicurezza, che non sarà trattata perché non da alcun valore aggiunto rispetto alle normali configurazioni di IPsec.

Nessun commento:

Posta un commento