Questo post è il seguito dei precedenti dedicati al modello DMVPN. Ricordo dai post precedenti, che la caratteristica fondamentale del modello DMVPN Fase 1 è che il traffico Spoke-Spoke deve necessariamente transitare per il router Hub, mentre quella del modello DMVPN Fase 2 è la possibilità che hanno i router Spoke di scambiare traffico direttamente, senza passare dai router Hub.

In questo post illustrerò una importante evoluzione del modello DMVPN fase 2, in cui è sempre permesso lo scambio diretto del traffico Spoke-Spoke, eliminando alcune restrizioni di questo modello, come ad esempio l'impossibilità per i router Hub di aggregare i prefissi IP annunciati dai router Spoke. Questa evoluzione è nota come modello DMVPN fase 3 (per fortuna l'ultimo stadio di evoluzione), ed è stata introdotta nell'IOS Cisco a partire dalla versione 12.4(6)T.

 

VANTAGGI DEL MODELLO DMVPN FASE 3

Il modello DMVPN fase 3, che come vedremo è basato su una idea già nota agli esperti del protocollo IP, consente  di eliminare alcune limitazioni del modello DMVPN fase 2. 

La prima e forse la più importante, è la possibilità di non poter effettuare aggregazioni di prefissi sui router Hub. Ricordo che nel modello DMVPN fase 2, la ragione per cui non è possibile effettuare aggregazioni sui router Hub è che altrimenti il prefisso aggregato verrebbe annunciato con il Next-Hop del router Hub, impedendo la comunicazione diretta Spoke-Spoke. Infatti, nel modello DMVPN fase 2 ricordo che è cruciale che il Next-Hop che i router Spoke "vedono" sia quello degli altri router Spoke. L'impossibilità di aggregare i prefissi in un modello DMVPN non deve essere trascurata, poiché potrebbe creare importanti problemi di scalabilità quando il numero di Spoke è elevato. Ad esempio, se una rete DMVPN ha 1.000 Spoke e ciascun Spoke annuncia un solo prefisso, ciascun router Hub deve inviare poco meno di 1.000.000 di annunci, con un carico di CPU non indifferente e una notevole occupazione di memoria  su tutti i router, Hub e Spoke. Questo, se sui router Hub potrebbe non creare grossi problemi, li può però creare sui router Spoke, che di solito sono router di "piccola taglia".

Una seconda limitazione riguarda l'utilizzo di topologie DMVPN gerarchiche. A volte, per aumentare la scalabilità si tende a creare DMVPN regionali, unite tra loro da Hub di livello gerarchico superiore, che vedono come propri Spoke gli Hub regionali. Con una simile topologia, se si utilizzasse il modello DMVPN fase 2, ciascuna rete DMVPN regionale sarebbe indipendente dalle altre e quindi il traffico Spoke-Spoke tra router Spoke di regioni diverse, deve necessariamente transitare sui router Hub regionali (non necessariamente sui router Hub di gerarchia superiore), aumentando i ritardi end-to-end. Per contro, con il modello DMVPN fase 3, le reti regionali e i router Hub di gerarchia superiore sono visti come una unica DMVPN, consentendo al traffico Spoke-Spoke percorsi ottimali.

Infine, un'altra limitazione, meno importante, che è possibile eliminare riguarda l'utilizzo di OSPF come protocollo di routing. Nel modello DMVPN fase 2, poiché è cruciale che gli annunci da Hub a Spoke mantengano il Next-Hop originale, si è costretti ad utilizzare la modalità "broadcast" di OSPF su reti NBMA. Questa modalità, come noto, richiede l'elezione di DR e BDR, e pone quindi delle limitazioni al numero di Hub, che al massimo possono essere due. Con il modello DMVPN fase 3 è invece possibile, come accennerò in seguito, l'utilizzo della modalità "point-to-multipoint", che non richiede l'elezione di DR e BDR, e quindi lascia maggiori libertà sulla scelta dei router Hub.

Infine, un ultimo vantaggio del modello DMVPN fase 3, anche questo meno importante, è che tutti pacchetti dati vengono inoltrati utilizzando le informazioni della tabella CEF, e non come avviene nel modello DMVPN fase 2, dove il primo pacchetto viene sempre "process switched".

 

FUNZIONAMENTO

A questo punto è necessario illustrare il funzionamento del modello DMVPN fase 3, mettendo in risalto le differenze con il funzionamento del modello DMVPN fase 2.

La prima e più importante differenza è che nel modello DMVPN fase 3 gli Spoke possono rispondere direttamente ai messaggi NHRP Resolution Request. Nel modello DMVPN fase 2 invece, sono solo i router Hub che possono rispondere a questi messaggi.

Vediamo il funzionamento passo per passo. Come nel modello DMVPN fase 2, i router Spoke registrano le loro associazioni <Indirizzo logico ; Indirizzo NBMA> al NHS (che è un router Hub). Questo, come nei modelli precedenti, consente ai router Hub di "scoprire" dinamicamente i router Spoke e quindi di stabilire le adiacenze di routing (o sessioni nel caso del BGP). A valle di tutto questo vengono scambiate le informazioni di routing. E fin qui nessuna novità. Ma in realtà una differenza sostanziale rispetto al modello DMVPN fase 2 c'è, e riguarda il Next-Hop. Ho ripetuto più volte che nel modello DMVPN fase 2 è cruciale preservare il Next-Hop originale, cosa non più necessaria nel modello DMVPN fase 3. Il perché di questo si capirà a breve, faccio notare però che è proprio questo aspetto che consente l'aggregazione dei prefissi sui router Hub.

Alla ricezione degli annunci del protocollo di routing, i router Spoke popolano la loro RIB e FIB (= tabella CEF). A questo punto, poiché il Next-Hop è l'indirizzo logico dell'Hub, noto ai router Spoke, non vi sono più nella tabella CEF adiacenze nello stato "invalid" o "glean", come invece accadeva nel modello DMVPN fase 2 a causa del fatto che il Next-Hop rimaneva quello originale dello Spoke, non noto agli altri router Spoke, ma solo al router Hub. Tutto questo implica che i pacchetti Spoke-Spoke utilizzano sempre la tabella CEF, e non sono mai "process switched", come invece avviene per il primo pacchetto nel modello DMVPN fase 2. Ma qui sorge il problema chiave: poiché non vi è più un trigger del protocollo NHRP per conoscere l'indirizzo NBMA dello Spoke destinazione, trigger che nel modello DMVPN fase 2 avveniva proprio grazie allo stato "invalid" del prefisso destinazione nella tabella CEF, come fa il router Spoke sorgente a conoscere l'indirizzo NBMA del router Spoke destinazione ? Tra l'altro, il router Spoke sorgente nella propria tabella di routing ha sempre come Next-Hop il router Hub, e quindi deve in qualche modo coinvolgere nella soluzione del mistero, anche il router Hub.

La magia che consente di risolvere l'arcano è l'analogo di una vecchia conoscenza del protocollo IP: la funzione ICMP redirect. Per chi non ne ricordasse il funzionamento, un caldo invito, prima di continuare la lettura, a rinfrescare la memoria (magari rileggendo la celebre RFC 791 di Jonathan (Jon) Postel del Settembre 1981 !!!). Quello che accade nel modello DMVPN fase 3 è che appena il router Spoke sorgente invia il primo pacchetto, questo viene regolarmente inoltrato al router Hub (che è il Next-Hop). Il router Hub riceve il pacchetto sull'interfaccia virtuale mGRE "tunnel X", e lo invia al router Spoke destinazione attraverso la stessa interfaccia mGRE "tunnel X". Questo fa da trigger a un messaggio NHRP redirect, che consente di informare il router sorgente dell'indirizzo NBMA dello Spoke destinazione, noto al router Hub dal processo iniziale di registrazione (vedi figura seguente). Il messaggio NHRP redirect informa il router Spoke sorgente che sta utilizzando un percorso non ottimo, e che invece dovrebbe utilizzare il percorso ottimo Spoke-Spoke.
 

A questo punto, il router Spoke sorgente, a seguito della ricezione del messaggio NHRP redirect, invia un messaggio NHRP Resolution Request non al NHS (l'Hub) ma direttamente al router Spoke destinazione. Il messaggio attraversa l'Hub (perché ?), che però non lo ispeziona ma fa da semplice "tramite" tra gli Spoke. 

 

Il router Spoke destinazione, e non il NHS, alla ricezione di questo messaggio risponde con un normale messaggio NHRP Resolution Reply. Tutte le informazioni necessarie per veicolare questo messaggio al router Spoke sorgente sono contenute nel messaggio NHRP Resolution Request ricevuto. Il messaggio NHRP Resolution Reply contiene l'intero prefisso IP di cui fa parte l'indirizzo IP destinazione del pacchetto inviato dallo Spoke sorgente. 

A questo punto il gioco è fatto. Il router Spoke sorgente, oltre a popolare la tabella delle associazioni ottenute via NHRP, riscrive il Next-Hop sulla tabella CEF, che verrà utilizzato successivamente per tutti i pacchetti destinati a indirizzi del prefisso appartenente al router Spoke destinazione.

 

 

 

Riassumendo:

A questo punto, come sempre, non ci rimane che passare "dalla poesia alla prosa" ...

 

ASPETTI DI CONFIGURAZIONE DEL PROTOCOLLO NHRP

La configurazione del protocollo NHRP, oltre ai comandi di base già visti per le fasi 1 e 2 richiede:

Illu strerò con un esempio cosa avviene utilizzando questi comandi. 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. Per questo test, nell'ottica di focalizzare meglio l'attenzione sul meccanismo di funzionamento del modello DMVPN Fase 3, non utilizzerò il router H2.

 

 

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

  ip nhrp map multicast dynamic

  ip nhrp network-id 200

  ip nhrp redirect

  tunnel source FastEthernet0/1

  tunnel mode gre multipoint

!

 

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

  ip nhrp shortcut

  tunnel source FastEthernet2/0

  tunnel mode gre multipoint

!

 

La configurazione del protocollo NHRP termina qui. A questo punto non è possibile vedere granché, il funzionamento del modello DMVPN fase 3 inizia con l'aggiunta di un protocollo di routing. 

 

ROUTING VIA EIGRP

L'utilizzo di EIGRP richiede gli stessi comandi già visti per il modello DMVPN fase 1, né uno in più né uno in meno. Faccio notare che il comando "no ip next-hop-self eigrp numero-AS" sui router Hub non va eseguito ! 

Inoltre è possibile, sui router Hub, effettuare aggregazione di prefissi con il comando "ip summary-address eigrp numero-AS prefisso maschera" a livello interfaccia "tunnel X". In particolare, è possibile utilizzare il comando "ip summary-address eigrp numero-AS 0.0.0.0 0.0.0.0" per generare una default-route.

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 split-horizon eigrp 200

  ip summary-address eigrp 200 0.0.0.0 0.0.0.0

  ip nhrp map multicast dynamic

  ip nhrp network-id 200

  ip nhrp redirect

  tunnel source FastEthernet0/1

  tunnel mode gre multipoint

!

router eigrp 200

  no auto-summary

  network 20.0.0.0

  network 50.0.0.0

!

NOTA: ricordo che 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". 

 

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

  ip nhrp shortcut

  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

!

Si noti che le interfacce "tunnel X" configurate sui router Spoke non hanno alcun comando relativo a EIGRP.  

A questo punto, per capire tutto l'handshake di messaggi NHRP, è necessario attivare un "debug nhrp packet" sui vari router e analizzare il risultato. Per non appesantire il post, ho riportato i risultati in un file allegato, a disposizione dei più curiosi.

Con i classici comandi "show ip route" e "show ip cef" in effetti non è possibile vedere granché. Una informazione importante si vede invece con il comando "show ip nhrp". Prima che un qualsiasi pacchetto dati fluisca da SP1 a SP2, il comando da il seguente risultato:

 

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

 

Per inviare un primo pacchetto a un Host del prefisso 50.0.12.0/24, ho utilizzato il solito 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 60 msec 52 msec

  2 20.0.0.2 98 msec *  85 msec

 

Come si può notare, i pacchetti IP del traceroute seguono il percorso attraverso il router Hub H1, per arrivare a destinazione. Lo stesso identico comportamento si aveva con il modello DMVPN fase 2.

Vediamo ora le associazioni <Indirizzo logico ; Indirizzo NBMA> presenti sul router SP1, dopo l'esecuzione del traceroute:

 

SP1# show ip nhrp

20.0.0.1/32 via 20.0.0.1, Tunnel1 created 00:00:05, expire 00:01:55

  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:00:05, expire 00:01:54

  Type: dynamic, Flags: router nat implicit

  NBMA address: 10.1.11.6

    (no-socket)

20.0.0.11/32 via 20.0.0.11, Tunnel1 created 00:27:13, never expire

  Type: static, Flags: nat used

  NBMA address: 172.16.1.1

50.0.12.0/24 via 20.0.0.2, Tunnel1 created 00:00:05, expire 00:01:53

  Type: dynamic, Flags: router nat used

  NBMA address: 10.1.11.6

 

Rispetto a quanto avveniva con il modello DMVPN fase 2, si ha una riga in più, l'ultima. Questo deriva dal fatto che, in base a quanto detto nella descrizione del funzionamento, il router SP2 invia a SP1 un NHRP Resolution Reply, contenente l'intero prefisso IP di cui fa parte l'indirizzo IP destinazione del pacchetto (= 50.0.12.12) inviato da SP1. 

Nella tabella di routing IP non vi è traccia di questo prefisso:

 

SP1#sh ip route 50.0.12.0

% Subnet not in table

 

mentre nella tabella CEF vi è l'informazione che il prefisso 50.0.12.0/24 viene instradato verso l'Hub.  

 

SP1#sh ip cef 50.0.12.0

0.0.0.0/0, version 34, epoch 0

0 packets, 0 bytes

  via 20.0.0.11, Tunnel1, 0 dependencies

    next hop 20.0.0.11, Tunnel1

    valid adjacency

 

Qualora dopo il primo traceroute, se ne eseguisse immediatamente un altro:
 

SP1#trace 50.0.12.12

Type escape sequence to abort.

Tracing the route to 50.0.12.12

  1 20.0.0.2 86 msec *  74 msec

 

si può notare che il traffico da SP1 verso l'indirizzo IP 50.0.12.12 non passa più 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 20.0.0.2 di SP2. Quest'ultimo indirizzo viene dedotto dalla tabella delle associazioni <Indirizzo logico ; Indirizzo NBMA> presenti sul router SP1, e ottenute da SP2 attraverso il protocollo NHRP (più precisamente attraverso un messaggio NHRP Resolution Reply).

Concludendo, per abilitare EIGRP in uno scenario DMVPN fase 3, è necessario utilizzare i seguenti accorgimenti:

1. Disabilitare sui router Hub lo split-horizon con il comando "no ip split-horizon eigrp numero-AS".

E per una soluzione altamente scalabile:

2. Effettuare sui router Hub aggregazione di prefissi con il comando "ip summary-address eigrp ..." a livello interfaccia "tunnel X", ed eventualmente, al  
    limite, generare una default-route EIGRP.

3. Abilitare la funzionalità EIGRP Stub sui router Spoke.

 

ROUTING VIA OSPF

Qualora si decidesse di utilizzare OSPF, poiché non è necessario preservare il Next-Hop originale, è possibile utilizzare la stessa modalità di OSPF su reti NBMA utilizzata per il modello DMVPN fase 1, ossia la "point-to-multipoint". 

Però vi voglio mettere in guardia dall'utilizzo di OSPF, perché con questo protocollo non è possibile effettuare alcuna aggregazione sugli Hub, a meno di non utilizzare qualche trucchetto diabolico. Il problema nasce dal fatto che di norma tutte le interfacce "tunnel X" della DMVPN vengono assegnate a una sola area OSPF, ed è noto che non è possibile aggregare alcunché all'interno di un'area OSPF. 

Il problema può essere aggirato con un po' di fantasia, che vi lascio volentieri (io per curiosità ho fatto delle prove e i trucchetti che ho elaborato funzionano). Ma il mio consiglio è di non utilizzare OSPF !!! E quindi con OSPF la finisco qui.

 

ROUTING VIA BGP

Qualora si decidese di utilizzare come protocollo di routing il BGP, valgono le stesse considerazioni fatte per il modello DMVPN fase 1. Per cui rimando alla discussione del post precedente "DMVPN FASE 1 - PARTE II". Vorrei però porre l'attenzione su un aspetto che riguarda l'utilizzo di sessioni iBGP. In questo scenario, l'applicazione della funzionalità di Route Reflection richiede qualcosa di aggiuntivo. Infatti, come noto e come visto nell'applicazione di questa funzionalità nel modello DMVPN fase 2, gli annunci iBGP riflessi dai Route Reflector, conservano il Next-Hop originario. E questo, mentre è necessario nel modello DMVPN fase 2, per quanto abbiamo detto sopra non va bene nel modello DMVPN fase 3. Recentemente, l'IOS Cisco ha introdotto un escamotage per variare questo che è il comportamento di default dei Route Reflector: si tratta del comando "neighbor ... next-hop-self all", che consente comunque di variare il BGP Next-Hop, ponendolo pari al proprio indirizzo IP utilizzato per le sessioni iBGP verso i Route Reflector Client. Va comunque detto che in uno scenario DMVPN fase 3, la funzionalità di Route Reflection non è necessaria. Vedi a questo proposito l'esempio di utilizzo di sessioni iBGP descritto nel post "DMVPN FASE 1 - PARTE II".

In questo post, voglio illustrare il funzionamento del modello DMVPN fase 3 con un prova su una topologia Dual DMVPN, utilizzando sessioni eBGP. La rete che utilizzerò è un po' più articolata ed è riportata nella figura seguente.

 

 

 

Il piano di numerazione logico è riportato nella figura seguente.

 

 

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.11

 ip nhrp map 20.0.0.11 172.16.1.11

 ip nhrp network-id 204

 ip nhrp holdtime 120

 ip nhrp nhs 20.0.0.11

 ip nhrp registration timeout 90

 ip nhrp shortcut

 tunnel source Serial0/0/0

 tunnel mode gre multipoint

!

interface Tunnel11

 ip address 30.0.0.1 255.255.255.0

 ip nhrp map multicast 172.16.1.12

 ip nhrp map 30.0.0.12 172.16.1.12

 ip nhrp network-id 304

 ip nhrp holdtime 120

 ip nhrp nhs 30.0.0.12

 ip nhrp registration timeout 90

 ip nhrp shortcut

 tunnel source Serial0/0/1

 tunnel mode gre multipoint

!

router bgp 65201

 redistribute connected

 neighbor 20.0.0.11 remote-as 65101  ! sessione eBGP verso H1

 neighbor 20.0.0.11 filter-list 1 out

 neighbor 30.0.0.12 remote-as 65102  ! sessione eBGP verso H2

 neighbor 30.0.0.12 filter-list 1 out

 neighbor 30.0.0.12 route-map SET-LP in  !   utilizzo l'interfaccia "tunnel 11" come backup

!

ip as-path access-list 1 permit ^$

!

route-map SET-LP permit 10

 set local-preference 90

!

 

La configurazione del BGP è abbastanza classica e può essere utilizzata come template di configurazione per tutti i router Spoke. Solo per "giocare" un po', ho assegnato agli annunci BGP provenienti dalla sessione con il BGP peer 30.0.0.12, un valore 90 di Local Preference. Poiché come noto, il valore di default del Local Preference è 100, ciò equivale ad utilizzare l'interfaccia "tunnel 1" come collegamento primario e l'interfaccia "tunnel 11" come backup. Inoltre, vorrei far notare la presenza del filtro AS_PATH con Regular Expression "^$". In questo esempio il filtro è necessario, oltre che per fare in modo che ciascun router Spoke annunci solamente i propri prefissi, per evitare che le default-route annunciate dai router Hub, vengano automaticamente propagate dai route Spoke all'altro Hub, facendo in modo che i router Spoke diventino di transito per il traffico tra router Hub. Ad, esempio, si consideri sul router SP1 la default-route ricevuta da H1. Poiché SP1 ha una seconda sessione eBGP con H2, senza alcun accorgimento, la default-route verrebbe automaticamente propagata da SP1 a H2. H2 quindi, in caso di fuori servizio dell'interfaccia Fa0/0, utilizzerebbe SP1 come transito per raggiungere la rete 50.1.1.0/24. Ma questo non è una buona cosa, poiché significherebbe riversare sui router Spoke, che di solito sono di "piccola taglia", un traffico che potrebbero non essere in grado di sostenere. Giusto per fare una analogia, questo filtro emula la funzionalità EIGRP stub nel caso il protocollo di routing utilizzato sia EIGRP. In realtà c'è una soluzione alternativa che evita l'utilizzo di quest'ultimo filtro, è sufficiente utilizzare sui due router Hub lo stesso identico numero di AS.

Vediamo ora la configurazione di H1.

 

hostname H1

!

interface Tunnel11

 ip address 20.0.0.11 255.255.255.0

 ip nhrp map multicast dynamic

 ip nhrp network-id 204

 ip nhrp redirect

 tunnel source FastEthernet0/1

 tunnel mode gre multipoint

!

router bgp 65101

 bgp listen range 20.0.0.0/24 peer-group SPOKE

 bgp listen limit 200

 neighbor SPOKE peer-group

 neighbor SPOKE remote-as 65201

 neighbor SPOKE default-originate

 neighbor SPOKE prefix-list SOLODEFAULT out

!

ip prefix-list SOLODEFAULT permit 0.0.0.0/0

 

La configurazione del processo BGP su 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". Inoltre, ho configurato un filtro di tipo "prefix-list" che consente l'annuncio della sola default-route.

Con queste configurazioni, sulla tabella BGP di H1 compaiono i prefissi annunciati dai router Spoke:

 

H1# show bgp ipv4 unicast

BGP table version is 4, local router ID is 192.168.1.1

. . .  < legenda omessa > . . .

   Network              Next Hop            Metric  LocPrf  Weight  Path

     0.0.0.0               0.0.0.0                    0                                          i

*> 50.0.11.0/24     20.0.0.1                 0                                    0    65201 ?

*> 50.0.12.0/24     20.0.0.2                 0                                    0    65201 ?

 

Su SP1 la tabella BGP è la seguente:

 

SP1# show bgp ipv4 unicast

BGP table version is 5, local router ID is 10.1.99.11

. . .  < legenda omessa > . . .

      Network          Next Hop            Metric LocPrf    Weight  Path

*>  0.0.0.0             20.0.0.11                                                      0  65101 i

*                              30.0.0.12                                  90               0  65102 i

*>  50.0.11.0/24   0.0.0.0                                                              32768  ?

 

Come si può notare, il BGP Next-Hop per la default-route best-path è 20.0.0.11 (H1). Ciò è confermato anche dal contenuto (parziale) della tabella di routing:

 

SP1# show ip route bgp

     Gateway of last resort is 20.0.0.11 to network 0.0.0.0

B*    0.0.0.0/0 [20/0] via 20.0.0.11, 00:02:26

 

A questo punto, è possibile ripetere tutte le considerazioni già illustrate con il protocollo EIGRP, considerazioni che non riporto per appesantire ulteriormente il post.

 

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.  
I post sul modello DMVPN però non finiscono qui, manca un argomento molto importante, come aggiungere gli aspetti di sicurezza, che consentono attraverso i classici tunnel IPsec, di cifrare il traffico. Poi, ho un amico che mi ha promesso un post sull'integrazione del modello DMVPN nelle L3VPN BGP/MPLS . . .  Arrivederci alle prossime puntate. 
Coming up next, un post  su un argomento poco noto che riguarda un "trucco" per migliorare la velocità di convergenza dei protocolli Link-State : "spf per-prefix prioritization".