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. La ragione è 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 (= Tabella di Routing) 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:
- I messaggi NHRP Resolution Request non sono più innescati da adiacenze "invalid" e "glean" della tabella CEF. L'implicazione più importante di questo punto è che non è necessario mantenere negli annunci del protocollo di routing il Next-Hop originale, e quindi è possibile eseguire aggregazioni di prefissi sugli Hub.
- I router Hub non sono più le sole fonti di informazioni NHRP, ma al gioco partecipano anche i router Spoke. Oltre a un modello NHRP client-server, DMVPN Fase 3 utilizza anche un modello NHRP di tipo peer-to-peer.
- I messaggi NHRP Reply contengono informazioni su un intero prefisso, invece che delle sole informazioni sulla risoluzione del Next-Hop.
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:
- Sui soli router Hub il comando "ip nhrp redirect", che abilita l'invio dei messaggi NHRP Redirect.
- Sui soli router Spoke il comando "ip nhrp shortcut", che consente di riscrivere sulla tabella CEF il nuovo Next-Hop comunicato attraverso il messaggio NHRP Redirect. Si noti che senza questo comando, un router Spoke si comporta esattamente come in un modello DMVPN Fase 1, con il traffico Spoke-Spoke che fa sempre transito su un router Hub.
Illustrerò 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 che potete scaricare qui, 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# show 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# show 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# traceroute 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:
- Disabilitare sui router Hub lo split-horizon con il comando "no ip split-horizon eigrp numero-AS".
E per una soluzione altamente scalabile:
- 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.
- 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 questa 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.
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".
Nessun commento:
Posta un commento