Questo post è il seguito del precedente "DMVPN Fase 1 - Parte I". Come citato alla fine di quel post, per completare l'implementazione del modello DMVPN è necessario abilitare un protocollo di routing IP. E qui nascono problematiche interessanti come: quale protocollo scegliere, come configurarlo ? Nelle applicazioni pratiche sono tre i protocolli di interesse: EIGRP, OSPF e BGP.
NOTA 2: tra i classici protocolli IGP, l'IS-IS non è supportato nel modello DMVPN. Secondo la documentazione Cisco, la ragione per cui IS-IS non è applicabile nel modello DMVPN è che i messaggi IS-IS sono trasportati direttamente dal Livello 2 e non da pacchetti IP ! La frase testuale che ho letto in una presentazione al Cisco Live 2013 dal titolo "Advanced Concepts of DMVPN", è la seguente: "IS-IS cannot be used since it doesn’t run over IP". Questa ragione in teoria non sta in piedi poiché nei tunnel GRE è possibile trasportare di tutto, anche messaggi IS-IS, ma Cisco forse non aveva voglia di implementare un comando del tipo "ip nhrp map iso [dynamic | indirizzo NBMA]" ... . D'altra parte, nei tunnel GRE p2p, i messaggi IS-IS viaggiano tranquillamente, anche nei router Cisco.
Ciascuno di questi protocolli va valutato rispetto a caratteristiche importanti come la scalabilità della configurazione (nelle applicazioni pratiche ci si può tranquillamente trovare davanti a reti con centinaia, se non migliaia di router Spoke) e soprattutto la velocità di convergenza.
In questo post, partendo dalla rete del post precedente, che riporto per completezza, illustrerò come utilizzare i tre protocolli EIGRP, OSPF e BGP, mettendo in evidenza gli aspetti di scalabilità e convergenza di ciascuna soluzione. In tutti i test successivi, utilizzerò una topologia Dual DMVPN (vedi post precedente). La rete test è la stessa del post precedente, che riporto qui per completezza.
ROUTING VIA EIGRP
L'abilitazione di EIGRP sulla rete test richiede un solo accorgimento fondamentale: disabilitare lo split-horizon sulle interfacce "tunnel X" dei router Hub. Questo è un aspetto ben noto nel funzionamento di EIGRP su reti NBMA. La regola dello split-horizon, quando abilitata, impedisce ai router Hub di annunciare i prefissi ricevuti da un router Spoke, agli altri router Spoke. In altre parole, a ciascun router Spoke viene impedita la visibilità delle reti raggiungibili attraverso gli altri router Spoke.
In realtà non è sempre necessario disabilitare lo split-horizon sulle interfacce "tunnel X" dei router Hub. Poiché il modello DMVPN Fase 1 non prevede la comunicazione diretta tra router Spoke, una soluzione molto semplice e altamente scalabile potrebbe quella di far generare ai router Hub una default-route EIGRP, rendendo così inutile la presenza sulla Tabella di Routing dei router Spoke, dei prefissi IP raggiungibili attraverso gli altri router Spoke. In questo caso, disabilitare lo split-horizon non comporta alcunché. Comunque, per tranquillità, considerato che nel modello DMVPN fase 2, come si vedrà (e come è intuitivo) è invece obbligatorio disabilitarlo, consiglio comunque, in uno scenario DMVPN, di disabilitare sempre lo split-horizon.
Un altro accorgimento classico da adottare, in presenza di topologie Hub-and-Spoke con protocollo di routing EIGRP, è abilitare la funzionalità EIGRP Stub sui router Spoke, per impedire che i router Spoke vengano utilizzati come transito per destinazioni raggiungibili attraverso i router Hub, nel caso di fuori servizio di uno dei due 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à, nella configurazione ho omesso il comando per l'autenticazione dei messaggi NHRP e sui router Spoke i comandi dei timer che regolano la registrazione delle associazioni <Indirizzo IP logico ; Indirizzo NBMA>.
hostname H1
!
interface Tunnel11
ip address 20.0.0.11 255.255.255.0
no ip split-horizon eigrp 200
ip nhrp map multicast dynamic
ip nhrp network-id 200
ip summary-address eigrp 200 0.0.0.0 0.0.0.0
tunnel source FastEthernet0/1
tunnel mode gre multipoint
!
router eigrp 200
no auto-summary
network 20.0.0.0
network 50.0.0.0
!
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". Si noti inoltre che, anche se non necessario a causa della generazione della default-route EIGRP, ho disabilito comunque sull'interfaccia "tunnel 11", lo split-horizon.
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 network-id 200
ip nhrp nhs 20.0.0.11
tunnel source FastEthernet2/0
tunnel destination 172.16.1.1
!
interface Tunnel11
ip address 30.0.0.1 255.255.255.0
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
tunnel source FastEthernet2/0
tunnel destination 172.16.1.2
!
router eigrp 200
no auto-summary
network 20.0.0.0
network 30.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. Si noti inoltre il comando "eigrp stub" all'interno del processo EIGRP, che abilita sul router Spoke SP1 la funzionalità EIGRP Stub. Ricordo che il comando "eigrp stub", consente di default l'annuncio dei prefissi direttamente connessi e delle summary route.
Il risultato della configurazione è che il router Spoke SP1 vede due Next-Hop per la default-route annunciata da EIGRP, i tunnel 1 e 11. Ciò significa che i due tunnel 1 e 11 sono utilizzati in load balancing.
SP1# show ip route eigrp
. . . < legenda omessa > . . .
Gateway of last resort is 30.0.0.11 to network 0.0.0.0
D* 0.0.0.0/0 [90/26882560] via 30.0.0.11, 00:00:58, Tunnel11
[90/26882560] via 20.0.0.11, 00:00:58, Tunnel1
Qualora si volesse utilizzare un tunnel come primario (ad esempio il tunnel 1) e l'altro come backup, è sufficiente aumentare il costo complessivo con cui SP1 vede la default-route attraverso il tunnel di backup (ad esempio il tunnel 11), oppure, in modo equivalente, diminuire il costo complessivo con cui SP1 vede la default-route attraverso il tunnel primario. Per fare questo, ricordo che è buona regola agire sul parametro "delay" dell'interfaccia "tunnel X". Si potrebbe anche agire sul parametro "bandwidth", ma questo è utilizzato anche da altri protocolli e funzioni (es. OSPF per il calcolo delle metriche, meccanismi di QoS, ecc.), per cui è bene non variarlo.
Il parametro "delay" associato all'interfaccia "tunnel X" si può visualizzare con il classico comando "show interface tunnel X". Ad esempio, per l'interfaccia "tunnel 11" si ottiene:
SP1# show interface tunnel 11 | i DLY
MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
da cui si evince che il parametro "delay" è pari a 50.000 microsec. Per aumentare questo valore, ad esempio per raddoppiarlo, si utilizza la seguente configurazione (NOTA: nella configurazione il nuovo valore va espresso in decine di microsec):
interface tunnel 11
delay 10000
Una identica configurazione andrebbe fatta sugli altri router Spoke. Il risultato che si ottiene è il seguente:
SP1# show ip route eigrp
. . . < legenda omessa > . . .
Gateway of last resort is 20.0.0.11 to network 0.0.0.0
D* 0.0.0.0/0 [90/26882560] via 20.0.0.11, 00:15:04, Tunnel1
Infine, per verificare che il traffico Spoke-Spoke fluisce effettivamente 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
VRF info: (vrf in name/id, vrf out name/id)
1 20.0.0.11 34 msec 44 msec 37 msec
2 20.0.0.2 38 msec * 34 msec
"Et voilà", il gioco è fatto !!!
Concludendo, per abilitare EIGRP in uno scenario DMVPN Fase 1, utilizzare i seguenti accorgimenti:
- Disabilitare lo split-horizon sulle interfacce "tunnel X" dei router Hub.
- Abilitare la funzionalità EIGRP Stub sui router Spoke.
- Generare sui router Hub una default-route EIGRP verso i router Spoke. In questo caso non è necessario disabilitare lo split-horizon (ma magari fatelo comunque).
ROUTING VIA OSPF
Un secondo protocollo supportato dal modello DMVPN fase 1 è l'OSPF. Nella sua implementazione è però necessario fare molta attenzione agli aspetti di scalabilità. Tutti noi conosciamo la vecchia regoletta Cisco di non realizzare mai aree di più di 50 router. Dicamo che oggi questa regoletta può essere notevolmente ampliata ed arrivare anche ad aree di centinaia di router. Ma tenete conto che in una implementazione reale di un modello DMVPN, i router Spoke non sono mai delle "schegge", e anche i router Hub non sono certo i CRS !!! Quindi io farei molta attenzione ad utlizzare OSPF quando i router Spoke superano qualche centinaio.
Nel modello DMVPN Fase 1 comunque qualche accorgimento interessante c'è. Innanzitutto, poiché siamo in presenza di OSPF su una rete NBMA, è necessario scegliere la modalità di funzionamento. La più semplice è in questo caso la point-to-multipoint, che è tra l'altro una modalità standard descritta nella RFC 2328 - OSPF Version 2, Aprile 1998. Le ragioni per il suo utilizzo sono che in questa modalità, ogni tunnel GRE viene trattato come fosse un collegamento punto-punto, e quindi non è necessario specificare manualmente i router vicini, né vi è bisogno di eleggere DR e BDR.
Un altro aspetto molto interessante, che ha un impatto molto importante sulla scalabilità, è la possibilità offerta dall'IOS Cisco di bloccare l'invio di LSA OSPF su una particolare interfaccia. Attenzione però, questo comporta un disallineamento dei LSDB all'interno dell'area, ma fortunatamente con una topologia Hub-and-Spoke questo non crea alcun problema. Infatti, disabilitando sui router Hub l'invio di LSA sull'interfaccia "tunnel X", si ha che i router Spoke non riceveranno informazioni sui prefissi raggiungibili dagli altri router Spoke. Ma il problema di connettività può essere risolto, come fatto con il protocollo EIGRP, con una default-route sui router Spoke verso i router Hub. Però attenzione a un aspetto. Se si disabilita sui router Hub l'invio dei LSA OSPF, non è possibile far generare ai router Hub una default-route OSPF. Questo perché la generazione avviene attraverso un LSA di tipo 5, che però non viene inviato se si disabilita sui router Hub l'invio dei LSA OSPF. La soluzione, benché un po' antipatica quando si ha che fare con centinaia di Spoke, è configurare delle default-route statiche sui router Spoke.
I comandi da eseguire sono quindi i seguenti:
- Su tutte le interfacce "tunnel X" dei router Hub e Spoke, abilitare la modalità "point-to-multipoint" con il comando "ip ospf network point-to-multipoint".
- Sulle interfacce "tunnel X" dei soli router Hub, disabilitare l'invia dei LSA OSPF con il comando "ip ospf database-filter all out".
- Configurare sui router Spoke delle default-route statiche verso gli Hub, eventualmente di tipo floating (ossia, con diversa distanza amministrativa).
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 e sui router Spoke i comandi dei timer che regolano la registrazione delle associazioni <Indirizzo IP logico ; Indirizzo NBMA>.
hostname SP1
!
! NOTA: La configurazione delle interfacce "tunnel 1" e "tunnel 11" è identica a quella già
! illustrata per il protocollo EIGRP, con la sola differenza che è necessario aggiungere il
! comando "ip ospf network point-to-multipoint".
! illustrata per il protocollo EIGRP, con la sola differenza che è necessario aggiungere il
! comando "ip ospf network point-to-multipoint".
!
router ospf 100
router-id 1.1.1.1
redistribute connected subnets
network 20.0.0.0 0.0.0.255 area 0
network 30.0.0.0 0.0.0.255 area 0
!
ip route 0.0.0.0 0.0.0.0 Tunnel1
ip route 0.0.0.0 0.0.0.0 Tunnel11 10
!
Nella configurazione delle (floating) default-route statiche, ho ipotizzato di utilizzare come Hub primario H1, e di utilizzare H2 come Hub di backup. Qualora si volessero utilizzare le due default-route statiche in load balancing, è sufficiente eliminare la distanza amministrativa nella seconda default-route.
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 ospf network point-to-multipoint
ip ospf database-filter all out
tunnel source FastEthernet0/1
tunnel mode gre multipoint
!
router ospf 100
router-id 11.11.11.11
redistribute connected subnets
network 20.0.0.0 0.0.0.255 area 0
!
NOTA 1: sia nella configurazione dei router Spoke che in quella dei router Hub, per annunciare le reti direttamente connesse ho utilizzato un comando di redistribuzione, piuttosto che inserire i prefissi nel processo OSPF attraverso il comando "network ...". La ragione è che, come gli esperti di OSPF sanno, è molto più efficiente annunciare i prefissi via redistribuzione, piuttosto che inserirli nel processo OSPF. Anche se il risultato finale è equivalente.
NOTA 2: nella configurazione ho utilizzato un'area OSPF standard. A volte, per maggiore scalabilità, potrebbe essere conveniente configurare aree NSSA (non aree Stub, altrimenti non sarebbe possibile la redistribuzione sui router con almeno un'interfaccia nell'area !).
Con queste configurazioni, sulla tabella di routing di H1 compaiono i prefissi annunciati (via OSPF) dai router Spoke:
H1# show ip route ospf 100 | i O E2
O E2 50.0.11.0/24 [110/20] via 20.0.0.1, 00:18:42, Tunnel11
O E2 50.0.12.0/24 [110/20] via 20.0.0.2, 00:17:10, Tunnel11
Infine, anche qui, per verificare che il traffico Spoke-Spoke fluisce effettivamente 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
VRF info: (vrf in name/id, vrf out name/id)
1 20.0.0.11 42 msec 44 msec 38 msec
2 20.0.0.2 48 msec 55 msec 42 msec
Concludendo, per abilitare OSPF in uno scenario DMVPN fase 1, utilizzare i seguenti accorgimenti:
- Abilitare sulle interfacce "tunnel X" di tutti i router, la modalità OSPF su reti NBMA "point-to-multipoint".
- Disabilitare sui soli router Hub la propagazione dei LSA OSPF.
- Configurare sui router Spoke delle default-route statiche verso i router Hub, eventualmente di tipo floating.
Attenzione che il punto 3), purtroppo necessario se utilizzate il punto 2), richiede configurazioni di default-route statiche su tutti i router Spoke, che potrebbero essere centinaia. A onor del vero è comunque possibile utilizzare il "copia e incolla", con un template di configurazione unico.
ROUTING VIA BGP
Infine il caro vecchio BGP. Il BGP ormai viene utilizzato dappertutto, poteva mancare sul modello DMVPN ? Certamente no, e forse è anche l'alternativa migliore.
Qualora si decida di utilizzare il BGP, e nella prossima sezione cercherò di dare qualche motivazione, la prima decisione da affrontare è se utilizzare sessioni iBGP o eBGP. In teoria si possono utilizzare entrambi i tipi.
Utilizzare sessioni iBGP è sicuramente molto più semplice nel caso di DMVPN Fase 1, mentre richiede qualche accorgimento aggiuntivo nel caso di DMVPN Fase 2. L'utilizzo di sessioni eBGP richiede l'assegnazione di un diverso numero di AS a ciascun router e questo potrebbe essere un rompicapo, quando si ha che fare con centinaia o migliaia di Spoke. Ci sono vari modi di aggirare il problema, il BGP è ricco di funzioni che consentono di effettuare configurazioni scalabili. Poi, molto è legato alla diversa gestione del BGP Next-Hop sulle sessioni iBGP ed eBGP. Quello che voglio fare in questo post che tratta del DMVPN Fase 1, è applicare entrambe le soluzioni e valutare sul campo pregi e difetti.
Utilizzare sessioni iBGP è sicuramente molto più semplice nel caso di DMVPN Fase 1, mentre richiede qualche accorgimento aggiuntivo nel caso di DMVPN Fase 2. L'utilizzo di sessioni eBGP richiede l'assegnazione di un diverso numero di AS a ciascun router e questo potrebbe essere un rompicapo, quando si ha che fare con centinaia o migliaia di Spoke. Ci sono vari modi di aggirare il problema, il BGP è ricco di funzioni che consentono di effettuare configurazioni scalabili. Poi, molto è legato alla diversa gestione del BGP Next-Hop sulle sessioni iBGP ed eBGP. Quello che voglio fare in questo post che tratta del DMVPN Fase 1, è applicare entrambe le soluzioni e valutare sul campo pregi e difetti.
Per utilizzare sessioni iBGP bisogna scegliere un (unico) numero di AS. Tipicamente si sceglie un numero di AS privato, ma non è obbligatorio. Poi bisogna configurare sessioni iBGP tra router Hub e router Spoke (non sessioni Spoke-Spoke).
Per rendere la configurazione scalabile, è possibile utilizzare il trucchetto dei BGP Dynamic Neighbor, introdotto nelle versioni più recenti dell'IOS Cisco (nel JUNOS era presente da molto tempo). Questo fa risparmiare moltissime righe di configurazione e, aspetto più interessante, consente di introdurre nuovi Spoke senza alcuna nuova configurazione sugli Hub. Infine, poiché lo scenario è DMVPN Fase 1, è sufficiente, come già fatto per EIGRP e OSPF, far annunciare ai router Hub una default-route via BGP, verso i router Spoke.
Per rendere la configurazione scalabile, è possibile utilizzare il trucchetto dei BGP Dynamic Neighbor, introdotto nelle versioni più recenti dell'IOS Cisco (nel JUNOS era presente da molto tempo). Questo fa risparmiare moltissime righe di configurazione e, aspetto più interessante, consente di introdurre nuovi Spoke senza alcuna nuova configurazione sugli Hub. Infine, poiché lo scenario è DMVPN Fase 1, è sufficiente, come già fatto per EIGRP e OSPF, far annunciare ai router Hub una default-route via BGP, verso i router Spoke.
Con il solito nostro scenario di rete, queste sono le configurazioni da effettuare sui router SP1 e H1:
hostname SP1
!
!
! La configurazione delle interfacce "tunnel 1" e "tunnel 11" è identica a quella già
! illustrata per il protocollo EIGRP.
! illustrata per il protocollo EIGRP.
!
router bgp 65101
redistribute connected route-map ALLOW-DC
neighbor 20.0.0.11 remote-as 65101
neighbor 30.0.0.11 remote-as 65101
!
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 è 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 se uno ha fatto un piano di numerazione serio ...
hostname H1
!
interface Tunnel11
ip address 20.0.0.11 255.255.255.0
ip nhrp map multicast dynamic
ip nhrp network-id 200
tunnel source FastEthernet0/1
tunnel mode gre multipoint
!
router bgp 65101
neighbor SPOKE peer-group
neighbor SPOKE remote-as 65101
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. Il comando chiave è "bgp listen range 20.0.0.0/24 peer-group SPOKE", che richiede la definizione di un BGP peer-group. Il comando consente di accettare tutte le sessioni BGP aperte da altri BGP peer, che hanno come estremo remoto un indirizzo IP incluso nella subnet IP 20.0.0.0/24. Il comando "bgp listen limit 200" limita a 200 il numero di sessioni BGP accettate da H1. Non è obbligatorio, poiché vi è un limite comunque, dettato dalla "grandezza" della subnet IP. Però in alcune situazioni potrebbe risultare utile. Tutto dipende da quante sessioni BGP è in grado di supportare il router Hub (e per questo è necessario consultare la documentazione tecnica relativa alla piattaforma in uso).
Faccio notare che con l'utilizzo dei BGP Dynamic Neighbors, l'aggiunta di un nuovo Spoke, purché permessa dal limite massimo di sessioni BGP attivabili, non comporta sul router Hub alcuna riga di configurazione aggiuntiva.
Con queste configurazioni, sulla tabella di routing di H1 compaiono i prefissi annunciati (via iBGP) dai router Spoke:
H1# show ip route bgp
... < legenda omessa > ...
Gateway of last resort is not set
50.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
B 50.0.11.0/24 [200/0] via 20.0.0.1, 00:11:55
B 50.0.12.0/24 [200/0] via 20.0.0.2, 00:23:10
Anche qui, per verificare che il traffico Spoke-Spoke fluisce effettivamente 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
VRF info: (vrf in name/id, vrf out name/id)
1 20.0.0.11 37 msec 34 msec 26 msec
2 20.0.0.2 44 msec 41 msec 45 msec
Poi, utilizzando le classiche metriche del BGP è possibile implementare sui router Spoke scenari di tipo primario/backup, oppure si potrebbe abilitare il BGP multipath e utilizzare le due default-route disponibili in load balancing. Ma tutto questo esula da questo post, e lo lascio come eventuale esercizio.
Se invece di utilizzare sessioni iBGP si utilizzassero sessioni eBGP, la prima scelta da fare è se utilizzare numeri diversi di AS sugli Spoke o utilizzare lo stesso numero. Utilizzare numeri diversi ha due grossi svantaggi: la complessità di configurazione in presenza di un elevato numero di Spoke e l'impossibilità di utilizzare i BGP Dynamic Neighbors sugli Hub, poiché il loro utilizzo richiede che tutti i BGP peer dinamici appartengano allo stesso AS. Per cui mi sento di sconsigliare l'utilizzo di numeri di AS diversi. Secondo me la soluzione migliore, nel caso di sessioni eBGP, è di utilizzare un numero di AS per i router Hub e un diverso numero di AS per tutti gli Spoke. Nel nostro esempio utilizzerò i numeri 65101 per i router Hub e 65201 per i router Spoke. Le configurazioni del BGP su SP1 e H1 diventano così:
hostname SP1
!
router bgp 65201
redistribute connected route-map ALLOW-DC
neighbor 20.0.0.11 remote-as 65101
neighbor 30.0.0.11 remote-as 65101
!
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
hostname H1
!
router bgp 65101
neighbor SPOKE peer-group
neighbor SPOKE remote-as 65201
neighbor SPOKE default-originate
bgp listen limit 200
bgp listen range 20.0.0.0/24 peer-group SPOKE
!
Quindi, con gli accorgimenti giusti, nel modello DMVPN Fase 1, utilizzare sessioni iBGP o eBGP, dal punto di vista della configurazione, non fa grandi differenze. Ad essere pignoli, un po' di differenza c'è sulla segnalazione. Mentre nel caso di sessioni iBGP, grazie alla nota regola dello split-horizon, gli Hub non annunciano ai router Spoke i prefissi annunciati dagli Spoke stessi, nel caso di sessioni eBGP, a causa dell'automatismo nella propagazione degli annunci, i prefissi annunciati dai router Spoke agli Hub, vengono annunciati automaticamente agli altri router Spoke, ma questi ultimi scarteranno gli annunci ricevuti dagli Hub a causa del controllo dell'AS_PATH. A dire il vero questo comportamento (poco efficiente, i router Juniper ad esempio non inviano in questa situazione i messaggi BGP UPDATE !) può essere evitato con un semplice filtro outbound basato sull'AS_PATH. Ma pochi lo fanno !
Si noti infine che se si utilizzassero sui router Spoke numeri di AS diversi, al fine di evitare che i prefissi annunciati dai router Spoke vengano automaticamente propagati agli altri router Spoke, e che questi li installino in Tabella di Routing (non necessario se si invia dagli Hub una default-route) è bene configurare sui router Hub un filtro outbound che consenta l'annuncio della sola default-route (oppure, per i più esperti, uno stupendo filtro basato sull'AS_PATH, con Regular Expression ^$). Tra l'altro questo filtro risolverebbe anche il problema di ottimizzazione appena descritto sopra, nel caso di numeri di AS uguali negli Spoke.
In conclusione, nel modello DMVPN Fase 1, nel caso si voglia utilizzare come protocollo di routing il BGP, io consiglio l'utilizzo di sessioni iBGP.
QUALE PROTOCOLLO UTILIZZARE ?
Ho illustrato nelle sezioni precedenti tre possibili protocolli di routing per l'utilizzo con le DMVPN Fase 1. Quale scegliere in pratica ? In termini di velocità di convergenza, non vi sono grandi differenze. Io personalmente non utilizzerei OSPF, poiché poco scalabile per questo scenario e richiede la configurazione di default-route statiche sui router Spoke, a meno di non inondare questi ultimi con un numero elevato (pari al numero di router della DMVPN) di LSA di tipo 1. E poi non mi fido troppo dell'implementazione Cisco di OSPF su reti NBMA. Nei vecchi documenti, Cisco stessa consigliava di utilizzare sub-interfacce Frame Relay punto-punto in luogo di tutte le varie modalità disponibili !
Poi scarterei l'EIGRP perché poco flessibile per l'applicazione delle politiche di routing. E poi EIGRP è un protocollo proprietario (e a me i protocolli proprietari non piacciono !).
In ultima analisi, io consiglio l'utilizzo del BGP, per la sua elevata flessibilità e ricchezza di metriche e la scarsa occupazione di memoria (ricordo che il BGP è stato progettato per lavorare con centinaia di migliaia di prefissi). Di più, consiglio l'utilizzo di sessioni iBGP. Però, per non incorrere in incubi notturni, è fondamentale l'utilizzo dei BGP Dynamic Neighbors sugli Hub. Altrimenti, anche io che ho un debole per il BGP, mi sentirei di sconsigliarlo. Ma il problema non si pone, a meno che non abbiate, per gli Hub, piattaforme che li supportano, nel qual caso utilizzate EIGRP !!!
Ovviamente, tutto ciò vale in reti con molti Spoke. In piccole reti "tutto fa brodo".
CONCLUSIONI
In questo post ho cercato di illustrare l'utilizzo di tre ben noti protocolli di routing al modello DMVPN, che era l'argomento mancante nel posto precedente "DMVPN Fase 1 - Parte I". In realtà dovrei scrivere un post dal titolo "DMVPN Fase 1 - Parte III" trattando anche gli aspetti di sicurezza. Ma come ho detto nel post precedente, la parte sugli aspetti di sicurezza, non la tratterò perché non da alcun valore aggiunto rispetto alle normali configurazioni di IPsec
Nessun commento:
Posta un commento