PREMESSA: ho scritto questo post per completezza e per mostrare l'evoluzione completa del modello DMVPN nelle varie fasi. E poi anche perché vi sono in produzione DMVPN basate su questo modello. Ma sappiate che questo modello è stato migliorato notevolmente con la Fase 3, per cui se dovete creare una DMVPN ex-novo, con necessità di scambio di traffico diretto Spoke-Spoke, è fortemente consigliato utilizzare il modello DMVPN fase 3, che tratterò diffusamente in un prossimo post.
Questo post è il seguito dei precedenti dedicati al modello DMVPN. Ricordo dai post precedenti, che la caratteristica fondamentale del modello DMVPN Fase 2 è la possibilità che hanno i router Spoke di scambiare traffico direttamente, senza passare dai router Hub.
Le configurazioni di base del protocollo NHRP sono le stesse già viste per il modello DMVPN Fase 1. Per quanto riguarda invece tunnel mGRE e routing vi sono delle differenze importanti.
Abbiamo visto nel modello DMVPN Fase 1 che sui router Spoke è sufficiente configurare tunnel GRE p2p e solo sui router Hub è necessario attivare tunnel mGRE. Nel modello DMVPN Fase 2 invece, è necessario configurare tunnel mGRE anche sui router Spoke. Il perché è abbastanza intuitivo: un router Spoke deve poter scambiare traffico anche con altri router Spoke, e quindi a meno che non si voglia attivare tunnel p2p verso ciascun altro Spoke, cosa assolutamente non scalabile, è necessario e opportuno anche qui utilizzare tunnel mGRE.
Per quanto riguarda il routing invece, un aspetto chiave da considerare è che quando un router Hub propaga verso i router Spoke un annunci ricevuto da un router Spoke, deve conservare il Next-Hop originale. In altre parole, sulla tabella di routing dei router Spoke, i prefissi raggiungibili da altri router Spoke devono avere come Next-Hop un indirizzo IP del router Spoke che li annuncia. Ma questo genera un problema molto interessante: come fa un router Spoke a conoscere l'indirizzo NBMA corrispondente all'indirizzo logico del Next-Hop ? Infatti, un router Spoke di norma, attraverso il protocollo NHRP registra la sua associazione <Indirizzo logico ; Indirizzo NBMA> al NHS, ma il NHS non comunica agli altri Spoke, via NHRP, le associazioni registrate. Per fare un parallelo, lo stesso problema si ha su un segmento Ethernet: cosa avviene quando un Host sul segmento deve inviare un pacchetto IP a un altro Host dello stesso segmento (il cosiddetto routing diretto !) ? L'Host origine non conosce l'indirizzo fisico (MAC) corrispondente all'indirizzo logico (IP) dell'Host destinazione. E come tutti sappiamo, il problema è risolto dal protocollo ARP, che è attivato dall'invio del primo pacchetto IP. Bene, nel modello DMVPN Fase 2 avviene una cosa simile, solo che il ruolo del protocollo ARP è svolto dal protocollo NHRP e il trigger del messaggio NHRP Resolution Request è dato dalla tabella CEF.
La rete test che utilizzerò è la stessa dei post precedenti sull'argomento, e riportata nella figura seguente.
I router sono tutti equipaggiati con IOS 12.4(11)T.
ROUTING VIA EIGRP
Per questo test, nell'ottica di focalizzare meglio l'attenzione sul meccanismo di funzionamento del modello DMVPN Fase 2, non utilizzerò il router H2.
L'utilizzo di EIGRP richiede, rispetto al modello DMVPN Fase 1, l'aggiunta sul router Hub di un comando che consenta di preservare il Next-Hop originale. Il comando è "no ip next-hop-self eigrp numero-AS". Inoltre:
- Non è possibile, sui router Hub, effettuare aggregazione di prefissi con il comando "ip summary-address eigrp numero-AS prefisso maschera" a livello interfaccia "tunnel X", altrimenti il prefisso aggregato verrebbe annunciato con il Next-Hop del router Hub, impedendo la comunicazione diretta Spoke-Spoke. In particolare, non è possibile utilizzare il comando "ip summary-address eigrp numero-AS 0.0.0.0 0.0.0.0" per generare una default-route, altrimenti non verrebbero annunciati dal router Hub i prefissi ricevuti dai router Spoke.
- Ricordare di disabilitare sui soli router Hub lo split-horizon con il comando "no ip split-horizon eigrp numero-AS".
- Ricordare che è buona pratica abilitare la funzionalità EIGRP Stub sui router Spoke.
Qualora si volesse utilizzare la default-route per raggiungere dai router Spoke i prefissi "dietro" ai router Hub, è possibile configurarla direttamente sui router Spoke attraverso una normale default-route statica. Un esempio classico è la raggiungibilità dei prefissi off-net, per i quali potrebbe essere richiesto il passaggio sui router Hub (es. i prefissi Internet, quando i router Hub svolgono il ruolo di Internet Gateway).
Riporto di seguito le configurazioni dei router H1 e SP1 della rete test. La configurazione di SP2 è analoga e viene lasciata come esercizio.
hostname H1
!
interface Tunnel11
ip address 20.0.0.11 255.255.255.0
no ip next-hop-self eigrp 200
no ip split-horizon eigrp 200
ip nhrp map multicast dynamic
ip nhrp network-id 200
tunnel source FastEthernet0/1
tunnel mode gre multipoint
!
router eigrp 200
no auto-summary
network 20.0.0.0
network 50.0.0.0
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 nhs 20.0.0.11
ip nhrp network-id 200
ip nhrp holdtime 120
ip nhrp registration timeout 90
tunnel source FastEthernet2/0
tunnel mode gre multipoint
!
router eigrp 200
no auto-summary
network 20.0.0.0
network 50.0.0.0
eigrp stub
!
ip route 0.0.0.0 0.0.0.0 Tunnel1
Si noti che le interfacce "tunnel X" configurate sui router Spoke non hanno alcun comando relativo a EIGRP. Il risultato della configurazione è che il router Spoke SP1 vede il prefisso 50.0.12.0/24 annunciato dal router SP2, con Next-Hop 20.0.0.2, ossia l'indirizzo IP logico dell'interfaccia tunnel di SP2.
SP1# show ip route 50.0.12.0
Routing entry for 50.0.12.0/24
Known via "eigrp 200", distance 90, metric 310172416, type internal
Redistributing via eigrp 200
Last update from 20.0.0.2 on Tunnel1, 00:00:27 ago
Routing Descriptor Blocks:
* 20.0.0.2, from 20.0.0.11, 00:00:27 ago, via Tunnel1
Route metric is 310172416, traffic share count is 1
Total delay is 1005000 microseconds, minimum bandwidth is 9 Kbit
Reliability 255/255, minimum MTU 1472 bytes
Loading 1/255, Hops 2
Però a questo punto sorge un problema: SP1 non ha un percorso valido verso il Next-Hop 20.0.0.2 (SP2) poiché SP2 ha registrato la sua associazione <Indirizzo logico ; Indirizzo NBMA> al NHS H1, il quale non ha propagato questa informazione a SP1. Ciò si evince facilmente dalla tabella CEF su SP1, che mostra per il prefisso 50.0.12.0/24 una "invalid adjacency":
SP1# show ip cef 50.0.12.0
50.0.12.0/24, version 34, epoch 0
0 packets, 0 bytes
via 20.0.0.2, Tunnel1, 0 dependencies
next hop 20.0.0.2, Tunnel1
invalid adjacency
La stessa tabella CEF, per il Next-Hop 20.0.0.2 mostra invece una "glean adjacency":
SP1# show ip cef 20.0.0.2
20.0.0.0/24, version 19, epoch 0, attached, connected
0 packets, 0 bytes
via Tunnel1, 0 dependencies
valid glean adjacency
Una "glean adjacency" indica che il Next-Hop 20.0.0.2 non è ancora stato risolto, ossia che SP1 non ha un'associazione <Indirizzo logico ; Indirizzo NBMA> per l'indirizzo logico 20.0.0.2. Il problema è che con il CEF abilitato, i messaggi NHRP Resolution Request sono inviati per la risoluzione del Next-Hop e non del prefisso 50.0.12.0/24. Il trigger del messaggio NHRP Resolution Request si ha sul piano dati, quando viene inviato il primo pacchetto dati verso un Host del prefisso 50.0.12.0/24 (la stessa cosa avviene con l'ARP, l'ARP Request è inviato non appena un Host sorgente tenta di inviare un pacchetto IP verso l'Host destinazione; solo dopo la ricezione dell'ARP Reply il pacchetto IP viene effettivamente veicolato verso la destinazione).
Per inviare un primo pacchetto a un Host del prefisso 50.0.12.0/24, ho utilizzato un banale traceroute (NOTA: avrei potuto utilizzare anche un semplice ping, ma fra poco capirete perché ho preferito utilizzare un traceroute):
SP1# traceroute 50.0.12.12
Type escape sequence to abort.
Tracing the route to 50.0.12.12
1 20.0.0.11 48 msec 8 msec 4 msec
2 20.0.0.2 14 msec * 8 msec
Come si può notare, i pacchetti IP del traceroute seguono il percorso attraverso il router Hub H1, per arrivare a destinazione. Potrebbe a questo punto venire il sospetto che c'è qualche errore di configurazione, poiché siamo in presenza di un modello DMVPN Fase 2. In realtà, come sarà visto tra poco, non è così, solo il primo pacchetto passa attraverso il router Hub.
Vediamo ora le associazioni <Indirizzo logico ; Indirizzo NBMA> presenti sul router SP1, prima e dopo l'esecuzione del traceroute:
Prima dell'esecuzione del traceroute:
SP1# show ip nhrp
20.0.0.11/32 via 20.0.0.11, Tunnel1 created 00:21:21, never expire
Type: static, Flags: nat used
NBMA address: 172.16.1.1
Dopo l'esecuzione del traceroute:
SP1# show ip nhrp
20.0.0.1/32 via 20.0.0.1, Tunnel1 created 00:07:31, expire 00:01:35
Type: dynamic, Flags: router unique nat local
NBMA address: 10.1.11.2
(no-socket)
20.0.0.2/32 via 20.0.0.2, Tunnel1 created 00:07:31, expire 00:01:21
Type: dynamic, Flags: router nat used
NBMA address: 10.1.11.6
20.0.0.11/32 via 20.0.0.11, Tunnel1 created 00:21:21, never expire
Type: static, Flags: nat used
NBMA address: 172.16.1.1
A questo punto, la tabella CEF mostra un'adiacenza valida sia per il prefisso 50.0.12.0/24 che per il Next-Hop 20.0.0.2:
SP1# show ip cef 50.0.12.0
50.0.12.0/24, version 34, epoch 0
0 packets, 0 bytes
via 20.0.0.2, Tunnel1, 0 dependencies
next hop 20.0.0.2, Tunnel1
valid adjacency
SP1# show ip cef 20.0.0.2
20.0.0.2/32, version 35, epoch 0, connected
0 packets, 0 bytes
via 20.0.0.2, Tunnel1, 0 dependencies
next hop 20.0.0.2, Tunnel1
valid adjacency
E infine, eseguiamo di nuovo il traceroute verso l'indirizzo IP 50.0.12.12:
SP1# traceroute 50.0.12.12
Type escape sequence to abort.
Tracing the route to 50.0.12.12
1 20.0.0.2 120 msec * 104 msec
Come si può notare, il traffico da SP1 verso l'indirizzo IP 50.0.12.12 non passa attraverso l'Hub H1, ma segue un percorso diretto SP1-->SP2. In particolare, i pacchetti IP vengono incapsulati un tunnel GRE con indirizzo IP sorgente coincidente con quello dell'interfaccia FastEthernet2/0 (= 10.1.11.2) e indirizzo IP destinazione l'indirizzo NBMA 10.1.11.6, corrispondente all'indirizzo logico di SP2 20.0.0.2. Quest'ultimo indirizzo viene dedotto dalla tabella delle associazioni <Indirizzo logico ; Indirizzo NBMA> presenti sul router SP1, e ottenute attraverso il protocollo NHRP.
E' importante notare che, come avviene con gli entry di una ARP Cache, anche le associazioni <Indirizzo logico ; Indirizzo NBMA> hanno una scadenza, che nell'esempio è 120 sec (valore definito via configurazione). Ciò significa che passati 120 secondi senza traffico tra SP1 e SP2, il primo pacchetto SP1-->SP2 successivo alla scadenza passa per H1, e quindi reinizia tutto il processo descritto sopra.
Concludendo, per abilitare EIGRP in uno scenario DMVPN fase 2, è necessario utilizzare i seguenti accorgimenti:
- Disabilitare sui router Hub, con il comando "no ip next-hop-self eigrp numero-AS", il "Next-Hop self" automatico dell'EIGRP.
- Disabilitare sui router Hub lo split-horizon con il comando "no ip split-horizon eigrp numero-AS".
- Non effettuare sui router Hub aggregazione di prefissi con il comando "ip summary-address eigrp ..." a livello interfaccia "tunnel X".
- Abilitare la funzionalità EIGRP Stub sui router Spoke.
Inoltre, per una soluzione più scalabile:
5. Configurare sui router Spoke una default-route statica verso i router Hub, per il traffico Spoke-->Hub.
ROUTING VIA OSPF
OSPF non è un protocollo consigliato per il modello DMVPN, per le ragioni che ho esposto nel post "DMVPN Fase 1 - Parte II". Però molti networker hanno familiarità con OSPF, e anche se questo non è molto scalabile in questo ambito, nelle reti di medie dimensioni ha una sua ragion d'essere.
Una limitazione di OSPF, oltre agli aspetti legati alla scalabilità, è di tipo architetturale: non è possibile avere più di due Hub, di cui uno avrà il ruolo di DR e l'altro di BDR. Topologie sofisticate come gerarchie di Hub, con OSPF non possono essere implementate.
Per preservare il Next-Hop, l'accorgimento principale da utilizzare è scegliere la modalità "broadcast" di OSPF su reti NBMA. E poi, è necessario fare in modo che i due Hub siano eletti DR e BDR. Ma questo è semplice, basta assegnare la priorità 0 alle interfacce tunnel dei router Spoke.
Infine, anche qui, come detto per EIGRP, per raggiungere prefissi "dietro" i router Hub è possibile configurare sui router Spoke delle default-route statiche verso gli 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à, anche qui nella configurazione ho omesso il comando per l'autenticazione dei messaggi NHRP.
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 map multicast 172.16.1.2
ip nhrp map 20.0.0.12 172.16.1.2
ip nhrp network-id 200
ip nhrp holdtime 120
ip nhrp nhs 20.0.0.11
ip nhrp nhs 20.0.0.12
ip nhrp registration timeout 90
ip ospf network broadcast
ip ospf priority 0
tunnel source FastEthernet2/0
tunnel mode gre multipoint
!
router ospf 123
router-id 20.1.1.1
network 20.0.0.0 0.0.0.255 area 1
redistribute connected subnets
!
ip route 0.0.0.0 0.0.0.0 Tunnel1
Si noti che nella configurazione del protocollo NHRP, sono stati definiti come NHS entrambi i router Hub, e di conseguenza è stato definito un mapping statico <Indirizzo logico ; Indirizzo NBMA> per entrambi i router Hub. Lo stesso, il mapping dei pacchetti multicast è stato abilitato per entrambi i router Hub (comandi "ip nhrp map multicast ..."). Per la configurazione del processo OSPF valgono le stesse considerazioni sul tipo di area e sulla modalità degli annunci delle reti direttamente connesse, già fatte nel post "DMVPN Fase 1 - Parte II".
hostname H1
!
interface Tunnel11
ip address 20.0.0.11 255.255.255.0
ip nhrp map multicast dynamic
ip nhrp map multicast 172.16.1.2
ip nhrp map 20.0.0.12 172.16.1.2
ip nhrp network-id 200
ip ospf network broadcast
ip ospf priority 100
tunnel source FastEthernet0/1
tunnel mode gre multipoint
!
router ospf 123
router-id 20.0.0.11
network 20.0.0.0 0.0.0.255 area 1
Si noti che nella configurazione del protocollo NHRP, è stato definito un mapping statico <Indirizzo logico ; Indirizzo NBMA> verso l'altro router Hub. Lo stesso, il mapping dei pacchetti multicast è stato abilitato per entrambi i router Hub (comandi "ip nhrp map multicast ...").
Il risultato della configurazione è che i router Spoke e i due router Hub sono visti dal processo OSPF come appartenenti a un normale segmento broadcast, e quindi i router seguono le usuali regole di OSPF su reti broadcast. Ad esempio, le adiacenze viste da H1, che viene eletto DR poiché ho configurato il valore di priorità associata all'interfaccia tunnel su H2 pari a 10, sono quelle classiche:
H1# show ip ospf 123 neighbor
Neighbor ID Pri State Dead Time Address Interface
20.1.1.1 0 FULL/DROTHER 00:00:39 20.0.0.1 Tunnel11
20.1.1.2 0 FULL/DROTHER 00:00:39 20.0.0.2 Tunnel11
20.1.1.12 10 FULL/BDR 00:00:31 20.0.0.12 Tunnel11
Il prefisso 50.0.12.0/24 è visto sulla tabella di routing di SP1 con Next-Hop 20.0.0.2 (SP2):
SP1# show ip route ospf 123
50.0.0.0/24 is subnetted, 2 subnets
O 50.0.12.0 [110/11112] via 20.0.0.2, 00:01:46, Tunnel1
A questo punto, tutte le considerazioni fatte nella sezione precedente circa la tabella CEF e la risoluzione del Next-Hop, valgono esattamente allo stesso modo anche qui. Concludendo, per abilitare OSPF in uno scenario DMVPN Fase 2, è necessario utilizzare i seguenti accorgimenti:
- Abilitare sulle interfacce "tunnel X" di tutti i router, la modalità OSPF su reti NBMA "broadcast" (comando "ip ospf network broadcast").
- Definire sui router Spoke una priorità nulla per l'elezione di DR e BDR.
- (Opzionale) Configurare sui router Spoke delle default-route statiche verso i router Hub.
ROUTING VIA BGP
Infine il caro vecchio BGP. Qui valgono molte delle considerazioni già fatte per il modello DMVPN Fase 1. Qualora si decida di utilizzare il BGP, anche qui, come nel modello DMVPN Fase 1, la prima decisione da affrontare è se utilizzare sessioni iBGP o eBGP.
In teoria anche nel modello DMVPN Fase 2 si possono utilizzare entrambi i tipi. Personalmente io propendo per l'utilizzo di sessioni iBGP per le seguenti ragioni:
- E' richiesto l'utilizzo di un solo numero di AS. Per contro, con sessioni eBGP è necessario utilizzare più numeri di AS, al limite un numero di AS per ciascun router.
- L'utilizzo del trucchetto dei BGP Dynamic Neighbor diviene molto più semplice, aumentando di molto la scalabilità della configurazione.
- Utilizzando sessioni iBGP è possibile sfruttare la funzionalità BGP Route Reflection, eleggendo (via configurazione) i router Hub come Route Reflector (RR) e i router Spoke come Route Reflector Client (RRC). Ricordo che i RR non cambiano il BGP Next-Hop quando riflettono gli annunci ai RRC, e questo è fondamentale per l'applicazione del modello DVPN Fase 2.
Vedremo che con il modello DMVPN Fase 3, alcune di queste ragioni verranno meno, per cui si ritornerà alle considerazioni fatte nel modello DMVPN Fase 1. Qualora sia necessario, per i router Spoke, utilizzare una default-route per raggiungere i prefissi "dietro" i router Hub, questa può essere tranquillamente inviata via BGP con il comando "neighbor <IP-RRC> default-originate".
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.
hostname SP1
!
La configurazione dell'interfaccia "tunnel 1" è identica a quella già illustrata per il protocollo OSPF (senza ovviamente i comandi relativi a OSPF !).
!
router bgp 65101
redistribute connected route-map ALLOW-DC
neighbor 20.0.0.11 remote-as 65101 ! sessione iBGP verso il RR H1
neighbor 20.0.0.12 remote-as 65101 ! sessione iBGP verso il RR H2
!
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 su SP1 è 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 ripeto ciò che ho detto in un precedente post, se uno ha fatto un piano di numerazione serio ... (per gli esperti di BGP, una possibile alternativa è utilizzare un filtro basato sull'AS_PATH: ip as-path access-list 1 permit ^$ ; neighbor <IP-peer> filter-list 1 out).
Vediamo ora la configurazione del router Hub H1.
Vediamo ora la configurazione del router Hub H1.
hostname H1
!
interface Tunnel11
ip address 20.0.0.11 255.255.255.0
ip nhrp map multicast dynamic
ip nhrp map 20.0.0.12 172.16.1.2
ip nhrp map multicast 172.16.1.2
ip nhrp network-id 200
tunnel source FastEthernet0/1
tunnel mode gre multipoint
!
router bgp 65101
neighbor 20.0.0.12 remote-as 65101
neighbor SPOKE peer-group
neighbor SPOKE remote-as 65101
neighbor SPOKE route-reflector-client
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. Per chi non ricordasse il loro funzionamento e le loro proprietà di scalabilità, invito alla rilettura del post "DMVPN Fase 1 - Parte II".
Con queste configurazioni, sulla tabella BGP di H1 compaiono i prefissi annunciati dai router Spoke (due annunci per ciascun prefisso, uno proveniente da un RRC e l'altro proveniente da H2 poiché non ho configurato un BGP Cluster-ID comune):
H1# show bgp ipv4 unicast
BGP table version is 3, local router ID is 192.168.1.1
... < legenda omessa > ...
Network Next Hop Metric LocPrf Weight Path
* i 50.0.11.0/24 20.0.0.1 0 100 0 ?
*>i 20.0.0.1 0 100 0 ?
* i 50.0.12.0/24 20.0.0.2 0 100 0 ?
*>i 20.0.0.2 0 100 0 ?
Su SP1 la tabella BGP è la seguente:
SP1# show bgp ipv4 unicast
BGP table version is 4, local router ID is 50.0.11.11
... < legenda omessa > ...
Network Next Hop Metric LocPrf Weight Path
*>i 0.0.0.0 20.0.0.11 0 100 0 i
* i 20.0.0.12 0 100 0 i
*> 50.0.11.0/24 0.0.0.0 0 32768 ?
*>i 50.0.12.0/24 20.0.0.2 0 100 0 ?
* i 20.0.0.2 0 100 0 ?
Come si può notare, il BGP Next-Hop per il prefisso 50.0.12.0/24 è 20.0.0.2 (SP2), così come richiesto dal modello DMVPN Fase 2. Ciò è confermato anche dal contenuto (parziale) della tabella di routing:
SP1# show ip route bgp
50.0.0.0/24 is subnetted, 2 subnets
B 50.0.12.0 [200/0] via 20.0.0.2, 00:25:50
B* 0.0.0.0/0 [200/0] via 20.0.0.11, 00:25:50
A questo punto, anche qui possiamo ripetere tutte le considerazioni sulla tabella CEF e sui messaggi NHRP già illustrate con il protocollo EIGRP. In realtà sulla tabella CEF c'è una minima differenza, comunque inifluente. Il CEF infatti, prima dell'invio del primo pacchetto al router Spoke, per gli annunci BGP considera sempre il Next-Hop di tipo ricorsivo e quindi l'adiacenza è sempre di tipo "glean" e mai "invalid", come invece accade per EIGRP e OSPF.
SP1# show ip cef 50.0.12.12
50.0.12.0/24, version 29, epoch 0
0 packets, 0 bytes
via 20.0.0.2, 0 dependencies, recursive
next hop 20.0.0.2, Tunnel1 via 20.0.0.0/24
valid glean adjacency
Anche qui, dopo l'invio del primo pacchetto, l'adiacenza CEF diventa "valid":
SP1# show ip cef 50.0.12.12
50.0.12.0/24, version 29, epoch 0
0 packets, 0 bytes
via 20.0.0.2, 0 dependencies, recursive
next hop 20.0.0.2, Tunnel1 via 20.0.0.2/32
valid adjacency
Infine, per verificare che il traffico Spoke-Spoke fluisce effettivamente senza passare 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
1 20.0.0.2 84 msec * 80 msec
CONCLUSIONI
In questo post ho cercato di illustrare l'utilizzo degli stessi tre ben noti protocolli di routing al modello DMVPN Fase 2. Sulla scelta valgono le stesse considerazioni già illustrate nel post "DMVPN Fase 1 - Parte II". Io non avrei dubbi, comunque l'unico protocollo che mi sento di sconsigliare è OSPF.
