Migrazione da DMVPN a FlexVPN su un hub diverso
Sommario
Introduzione
In questo documento viene illustrato come eseguire la migrazione da una rete DMVPN (Dynamic Multipoint VPN) esistente a FlexVPN su diversi dispositivi hub. Le configurazioni per entrambi i framework coesistono sui dispositivi. In questo documento viene mostrato solo lo scenario più comune: DMVPN con la chiave già condivisa per l'autenticazione e il protocollo EIGRP (Enhanced Interior Gateway Routing Protocol) come protocollo di routing. In questo documento viene illustrata la migrazione al Border Gateway Protocol (BGP), il protocollo di routing consigliato, e il meno desiderabile protocollo EIGRP.
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza di base dei seguenti argomenti:
- DMVPN
- FlexVPN
Componenti usati
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
- Cisco Integrated Service Router (ISR) versione 15.2(4)M1 o successive
- Cisco Aggregation Services Router serie 1000 (ASR1K) 3.6.2 release 15.2(2)S2 o successive
Uno dei vantaggi di una piattaforma e di un software più recenti è la possibilità di utilizzare la crittografia di nuova generazione, ad esempio AES (Advanced Encryption Standard) Galois/Counter Mode (GCM) per la crittografia in IPSec (Internet Protocol Security), come indicato in RFC (Request for Comments) 4106. AES GCM consente di raggiungere una velocità di crittografia molto più elevata su alcuni componenti hardware. Per ulteriori informazioni sui consigli di Cisco relativi all'utilizzo della crittografia di nuova generazione e alla migrazione a tale crittografia, fare riferimento all'articolo sulla crittografia di nuova generazione.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Procedura di migrazione
Al momento, il metodo consigliato per migrare da DMVPN a FlexVPN è che i due framework non funzionino contemporaneamente. Questa limitazione verrà rimossa a causa delle nuove funzionalità di migrazione da introdurre nell'ASR 3.10, rilevate nelle richieste di miglioramenti multipli sul lato Cisco, che includono l'ID bug Cisco CSCuc08066. Queste funzionalità saranno disponibili a fine giugno 2013.
Una migrazione in cui entrambi i framework coesistono e operano contemporaneamente sugli stessi dispositivi viene definita migrazione soft, che indica un impatto minimo e un failover senza problemi da un framework all'altro. Una migrazione in cui le configurazioni di entrambi i framework coesistono, ma non funzionano contemporaneamente viene definita migrazione rigida. Ciò significa che il passaggio da un framework all'altro implica una mancanza di comunicazione sulla VPN, anche se minima.
Migrazione completa tra due hub diversi
In questo documento viene descritta la migrazione dall'hub DMVPN attualmente utilizzato a un nuovo hub FlexVPN. Questa migrazione consente l'intercomunicazione tra spoke già migrati a FlexVPN e quelli ancora in esecuzione su DMVPN e può essere eseguita in più fasi, su ciascuno spoke separatamente.
A condizione che le informazioni di routing siano popolate correttamente, la comunicazione tra i spoke migrati e non migrati dovrebbe rimanere possibile. Tuttavia, è possibile osservare una latenza aggiuntiva perché i spoke migrati e non migrati non creano reciprocamente tunnel spoke-to-spoke. Allo stesso tempo, i spoke migrati dovrebbero essere in grado di stabilire tunnel spoke-to-spoke diretti tra loro. Lo stesso vale per i raggi non migrati.
Finché non sarà disponibile questa nuova funzionalità di migrazione, completare i seguenti passaggi per eseguire le migrazioni con un hub diverso da DMVPN e FlexVPN:
- Verificare la connettività su DMVPN.
- Aggiungere la configurazione FlexVPN e arrestare il tunnel che appartiene alla nuova configurazione.
- (Durante un intervento di manutenzione) Su ciascun spoke, uno per uno, arrestare il tunnel DMVPN.
- Nello stesso spoke del passo 3, sbloccare le interfacce del tunnel FlexVPN.
- Verificare la connettività spoke-to-hub.
- Verificare la connettività spoke-to-spoke all'interno di FlexVPN.
- Verificare la connettività spoke-to-spoke con DMVPN da FlexVPN.
- Ripetere i passaggi da 3 a 7 per ogni raggio separatamente.
- In caso di problemi con le verifiche descritte nei passaggi 5, 6 o 7, chiudere l'interfaccia FlexVPN e sbloccare le interfacce DMVPN per tornare a DMVPN.
- Verificare la comunicazione spoke-to-hub sulla DMVPN di backup.
- Verificare la comunicazione spoke sulla DMVPN di backup.
Approccio personalizzato
Se l'approccio precedente non è la soluzione migliore per la tua azienda a causa di complessità di rete o routing, avvia una discussione con il tuo rappresentante Cisco prima di procedere alla migrazione. La persona migliore con cui discutere di un processo di migrazione personalizzato è il tecnico di sistema o il tecnico dei servizi avanzati.
Topologia della rete
Topologia della rete di trasporto
Il diagramma mostra la topologia di connessione tipica degli host su Internet. Per terminare la sessione IPsec DMVPN, viene usato l'indirizzo IP loopback0 (172.25.1.1) dell'hub. L'indirizzo IP sul nuovo hub (172.25.2.1) viene utilizzato per FlexVPN.
Si noti il collegamento tra i due hub. Questo collegamento è cruciale per consentire la connettività tra i cloud FlexVPN e DMVPN durante la migrazione. Consente agli spoke già migrati a FlexVPN di comunicare con le reti DMVPN e viceversa.
Sovrapponi topologia di rete
Il diagramma della topologia mostra due cloud separati utilizzati per la sovrapposizione: DMVPN (connessioni verdi) e FlexVPN (connessioni rosse). I prefissi LAN vengono visualizzati per i siti corrispondenti. La subnet 10.1.1.0/24 non rappresenta una subnet effettiva in termini di indirizzamento dell'interfaccia, ma rappresenta un blocco di spazio IP dedicato al cloud FlexVPN. Le motivazioni alla base di questa operazione sono discusse più avanti nella sezione Configurazione FlexVPN.
Configurazione
In questa sezione vengono descritte le configurazioni di DMVPN e FlexVPN.
Configurazione DMVPN
In questa sezione viene descritta la configurazione di base per l'hub e lo spoke DMVPN.
La chiave già condivisa (PSK) viene utilizzata per l'autenticazione IKEv1. Una volta stabilito il protocollo IPsec, viene eseguita la registrazione del protocollo NHRP (Next Hop Resolution Protocol) da spoke a hub in modo che l'hub possa apprendere dinamicamente l'indirizzamento NBMA (Nonbroadcast Multiaccess) degli spoke.
Quando NHRP esegue la registrazione sul spoke e sull'hub, l'adiacenza di instradamento può essere stabilita e le route possono essere scambiate. Nell'esempio, il protocollo EIGRP viene usato come protocollo di routing di base per la rete di sovrapposizione.
Configurazione Spoke DMVPN
Qui è possibile trovare un esempio di configurazione di base di DMVPN con autenticazione PSK e EIGRP come protocollo di routing.
crypto isakmp policy 10
encr aes
authentication pre-share
crypto isakmp key cisco address 0.0.0.0
crypto isakmp keepalive 30 5
crypto isakmp profile DMVPN_IKEv1
keyring DMVPN_IKEv1
match identity address 0.0.0.0
crypto ipsec transform-set IKEv1 esp-aes esp-sha-hmac
mode transport
crypto ipsec profile DMVPN_IKEv1
set transform-set IKEv1
set isakmp-profile DMVPN_IKEv1
interface Tunnel0
ip address 10.0.0.101 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map 10.0.0.1 172.25.1.1
ip nhrp map multicast 172.25.1.1
ip nhrp network-id 1
ip nhrp holdtime 900
ip nhrp nhs 10.0.0.1
ip nhrp shortcut
ip tcp adjust-mss 1360
tunnel source Ethernet0/0
tunnel mode gre multipoint
tunnel protection ipsec profile DMVPN_IKEv1
router eigrp 100
network 10.0.0.0 0.0.0.255
network 192.168.102.0
passive-interface default
no passive-interface Tunnel0
Configurazione Hub DMVPN
Nella configurazione hub, il tunnel viene originato da loopback0 con indirizzo IP 172.25.1.1. Il resto è una distribuzione standard di un hub DMVPN con EIGRP come protocollo di routing.
crypto isakmp policy 10
encr aes
authentication pre-share
crypto isakmp key cisco address 0.0.0.0
crypto ipsec transform-set IKEv1 esp-aes esp-sha-hmac
mode transport
crypto ipsec profile DMVPN_IKEv1
set transform-set IKEv1
interface Tunnel0
ip address 10.0.0.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip nhrp holdtime 900
ip nhrp server-only
ip nhrp redirect
ip summary-address eigrp 100 192.168.0.0 255.255.0.0
ip tcp adjust-mss 1360
tunnel source Loopback0
tunnel mode gre multipoint
tunnel protection ipsec profile DMVPN_IKEv1
router eigrp 100
network 10.0.0.0 0.0.0.255
network 192.168.0.0 0.0.255.255
passive-interface default
no passive-interface Tunnel0
Configurazione FlexVPN
FlexVPN si basa sulle stesse tecnologie fondamentali:
- IPSec: A differenza dell'impostazione predefinita in DMVPN, IKEv2 viene utilizzato al posto di IKEv1 per negoziare le associazioni di sicurezza (SA) di IPSec. IKEv2 offre miglioramenti rispetto a IKEv1, ad esempio la resilienza e il numero di messaggi necessari per stabilire un canale dati protetto.
- GRE : A differenza di DMVPN, vengono utilizzate interfacce point-to-point statiche e dinamiche e non solo un'interfaccia GRE multipoint statica. Questa configurazione consente una maggiore flessibilità, in particolare per il comportamento per spoke/per hub.
- NHRP: In FlexVPN, NHRP viene utilizzato principalmente per stabilire la comunicazione spoke. I raggi non vengono registrati nell'hub.
- Instradamento: Poiché gli spoke non eseguono la registrazione NHRP all'hub, è necessario basarsi su altri meccanismi per assicurarsi che l'hub e gli spoke possano comunicare in modo bidirezionale. Analogamente a DMVPN, è possibile utilizzare protocolli di routing dinamico. Tuttavia, FlexVPN consente di utilizzare IPsec per introdurre informazioni di routing. Per impostazione predefinita, viene introdotto il percorso as /32 per l'indirizzo IP sull'altro lato del tunnel, che consente la comunicazione diretta spoke-to-hub.
In una migrazione rigida da DMVPN a FlexVPN, i due framework non funzionano contemporaneamente sugli stessi dispositivi. Si consiglia tuttavia di tenerli separati.
Separarli su più livelli:
- NHRP: utilizzare un ID di rete NHRP diverso (consigliato).
- Instradamento: utilizzare processi di instradamento separati (scelta consigliata).
- Routing e inoltro virtuale (VRF) - La separazione VRF consente una maggiore flessibilità, ma non viene discussa in questa sede (opzionale).
Configurazione Spoke FlexVPN
Una delle differenze nella configurazione spoke di FlexVPN rispetto a DMVPN è che potenzialmente si hanno due interfacce. Sono necessari un tunnel per la comunicazione spoke-to-hub e un tunnel opzionale per i tunnel spoke-to-spoke. Se si sceglie di non utilizzare il tunneling spoke-to-spoke dinamico e si preferisce che tutto passi attraverso il dispositivo hub, è possibile rimuovere l'interfaccia del modello virtuale e rimuovere il passaggio rapido NHRP dall'interfaccia del tunnel.
Si noti che l'interfaccia del tunnel statico riceve un indirizzo IP in base alla negoziazione. Questo consente all'hub di fornire dinamicamente l'indirizzo IP dell'interfaccia del tunnel allo spoke senza la necessità di creare indirizzi statici nel cloud FlexVPN.
aaa new-model
aaa authorization network default local
aaa session-id common
crypto ikev2 profile Flex_IKEv2
match identity remote fqdn domain cisco.com
local identity fqdn spoke.cisco.com
authentication remote rsa-sig
authentication local rsa-sig
aaa authorization group cert list default default
virtual-template 1
crypto ikev2 dpd 30 5 on-demand
Cisco consiglia di utilizzare AES GCM con l'hardware che lo supporta.
crypto ipsec transform-set IKEv2 esp-gcm
mode transport
crypto ipsec profile default
set ikev2-profile Flex_IKEv2
! set transform-set IKEv2
interface Tunnel1
ip address negotiated
ip mtu 1400
ip nhrp network-id 2
ip nhrp shortcut virtual-template 1
ip nhrp redirect
ip tcp adjust-mss 1360
shutdown
tunnel source Ethernet0/0
tunnel destination 172.25.2.1
tunnel path-mtu-discovery
tunnel protection ipsec profile default
interface Virtual-Template1 type tunnel
ip unnumbered Tunnel1
ip mtu 1400
ip nhrp network-id 2
ip nhrp shortcut virtual-template 1
ip nhrp redirect
ip tcp adjust-mss 1360
tunnel path-mtu-discovery
tunnel protection ipsec profile default
Infrastruttura a chiave pubblica (PKI, Public Key Infrastructure) è il metodo consigliato per eseguire l'autenticazione su larga scala in IKEv2. È tuttavia possibile utilizzare PSK purché se ne conoscano i limiti.
Di seguito è riportata una configurazione di esempio che utilizza cisco come chiave pubblica (PSK).
crypto ikev2 keyring Flex_key
peer Spokes
address 0.0.0.0 0.0.0.0
pre-shared-key local cisco
pre-shared-key remote cisco
crypto ikev2 profile Flex_IKEv2
match identity remote address 0.0.0.0
authentication remote pre-share
authentication local pre-share
keyring local Flex_key
aaa authorization group psk list default default
virtual-template 1
crypto ikev2 dpd 30 5 on-demand
Configurazione hub FlexVPN
In genere, un hub termina solo i tunnel spoke-to-hub dinamici. Ecco perché non si trova un'interfaccia tunnel statica per FlexVPN nella configurazione hub. Viene invece utilizzata un'interfaccia di modello virtuale.
Gli indirizzi di questo pool vengono aggiunti successivamente nella tabella di routing come route /32 per ogni spoke.
aaa new-model
aaa authorization network default local
aaa session-id common
crypto ikev2 authorization policy default
pool FlexSpokes
crypto ikev2 profile Flex_IKEv2
match identity remote fqdn domain cisco.com
local identity fqdn hub.cisco.com
authentication remote rsa-sig
authentication local rsa-sig
aaa authorization group cert list default default
virtual-template 1
crypto ikev2 dpd 30 5 on-demand
Cisco consiglia di utilizzare AES GCM con l'hardware che lo supporta.
crypto ipsec transform-set IKEv2 esp-gcm
mode transport
crypto ipsec profile default
set ikev2-profile Flex_IKEv2
! set transform-set IKEv2
interface Loopback0
description DMVPN termination
ip address 172.25.2.1 255.255.255.255
interface Loopback100
ip address 10.1.1.1 255.255.255.255
interface Virtual-Template1 type tunnel
ip unnumbered Loopback100
ip nhrp network-id 2
ip nhrp redirect
tunnel path-mtu-discovery
tunnel protection ipsec profile default
ip local pool FlexSpokes 10.1.1.100 10.1.1.254
Con l'autenticazione in IKEv2, lo stesso principio si applica all'hub e allo spoke. Per garantire scalabilità e flessibilità, utilizzare i certificati. Tuttavia, è possibile riutilizzare per PSK la stessa configurazione utilizzata per Spoke.
Se il requisito è l'utilizzo di chiavi già condivise per l'autenticazione, le modifiche alla configurazione sono simili a quelle descritte qui per il router spoke.
Connessione BGP inter-hub
Verificare che gli hub sappiano dove si trovano determinati prefissi. Questa operazione diventa sempre più importante in quanto alcuni spoke sono stati migrati a FlexVPN, mentre altri rimangono su DMVPN.
Di seguito è riportata la connessione BGP tra hub basata sulla configurazione dell'hub DMVPN:
router bgp 65001
network 192.168.0.0
neighbor 192.168.0.2 remote-as 65001
Migrazione del traffico
Eseguire la migrazione a BGP come protocollo di routing della sovrimpressione [consigliato]
BGP è un protocollo di routing basato sullo scambio unicast. Grazie alle sue caratteristiche, è il protocollo di scalabilità migliore nelle reti DMVPN.
Nell'esempio viene utilizzato il protocollo BGP (iBGP) interno.
Configurazione Spoke BGP
La migrazione del raggio è costituita da due parti. Innanzitutto, abilitare BGP come routing dinamico:
router bgp 65001
bgp log-neighbor-changes
network 192.168.101.0
neighbor 10.1.1.1 remote-as 65001
Dopo l'accensione del router BGP adiacente (vedere la sezione successiva) e l'apprendimento di nuovi prefissi su BGP, è possibile instradare il traffico dal cloud DMVPN corrente a un nuovo cloud FlexVPN.
Configurazione BGP hub
Hub FlexVPN - Configurazione BGP completa
Sull'hub, per evitare di mantenere separata la configurazione di prossimità per ogni spoke, configurare i listener dinamici. In questa configurazione, BGP non avvia nuove connessioni, ma accetta connessioni dal pool di indirizzi IP fornito. In questo caso, il pool indicato è 10.1.1.0/24, ovvero tutti gli indirizzi del nuovo cloud FlexVPN.
Due punti da notare:
- L'hub FlexVPN annuncia prefissi specifici all'hub DMVPN; viene quindi utilizzata la mappa di rimozione.
- Annunciare la subnet FlexVPN di 10.1.1.0/24 alla tabella di routing o accertarsi che l'hub DMVPN veda l'hub FlexVPN come hop successivo.
Il documento illustra quest 'ultimo approccio.
access-list 1 permit any
route-map ALL permit 10
match ip address 1
route-map SET_NEXT_HOP permit 10
set ip next-hop 192.168.0.2
router bgp 65001
network 192.168.0.0
bgp log-neighbor-changes
bgp listen range 10.1.1.0/24 peer-group Spokes
aggregate-address 192.168.0.0 255.255.0.0 summary-only
neighbor Spokes peer-group
neighbor Spokes remote-as 65001
neighbor 192.168.0.1 remote-as 65001
neighbor 192.168.0.1 route-reflector-client
neighbor 192.168.0.1 unsuppress-map ALL
neighbor 192.168.0.1 route-map SET_NEXT_HOP out
Hub DMVPN - Configurazione completa BGP ed EIGRP
La configurazione sull'hub DMVPN è di base, in quanto riceve solo prefissi specifici dall'hub FlexVPN e annuncia i prefissi che apprende da EIGRP.
router bgp 65001
bgp log-neighbor-changes
redistribute eigrp 100
neighbor 192.168.0.2 remote-as 65001
Migrazione del traffico a BGP/FlexVPN
Come descritto in precedenza, per eseguire la migrazione è necessario arrestare la funzionalità DMVPN e attivare FlexVPN.
Questa procedura garantisce un impatto minimo:
- In ogni raggio, separatamente, immettere quanto segue:
interface tunnel 0
shut
A questo punto, verificare che non vi siano sessioni IKEv1 stabilite per questo spoke. Per verificare questa condizione, controllare l'output del comando show crypto isakmp sa e monitorare i messaggi syslog generati dal comando crypto logging session. Una volta confermato, è possibile procedere per visualizzare FlexVPN. - Nello stesso raggio, immetti questo:
interface tunnel 1
no shut
Fasi di verifica
Stabilità IPSec
Il modo migliore per valutare la stabilità di IPSec è monitorare i sylog con il comando di configurazione crypto logging session abilitato. Se vengono rilevate sessioni attive e non attive, è possibile che si tratti di un problema a livello IKEv2/FlexVPN che deve essere corretto prima di poter avviare la migrazione.
Informazioni BGP popolate
Se IPsec è stabile, verificare che la tabella BGP sia popolata con le voci degli spoke (sull'hub) e il riepilogo dall'hub (sugli spoke). Nel caso di BGP, ciò può essere visualizzato con questi comandi:
show bgp
! or
show bgp ipv4 unicast
! or
show ip bgp summary
Di seguito è riportato un esempio di informazioni corrette provenienti dall'hub FlexVPN:
BGP router identifier 172.25.2.1, local AS number 65001
(...omitted...)
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
*10.1.1.100 4 65001 112 123 16 0 0 01:35:58 1
192.168.0.1 4 65001 97 99 16 0 0 01:24:12 4
L'output mostra che l'hub ha appreso un prefisso da ciascuno dei raggi ed entrambi i raggi sono dinamici e contrassegnati da un asterisco (*). Mostra inoltre che viene ricevuto un totale di quattro prefissi dalla connessione tra hub.
Di seguito è riportato un esempio di informazioni simili tratte da the spoke:
show ip bgp summary
BGP router identifier 192.168.101.1, local AS number 65001
(...omitted...)
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.1.1 4 65001 120 109 57 0 0 01:33:23 2
Spoke ha ricevuto due prefissi dall'hub. Nel caso di questa configurazione, un prefisso dovrebbe essere il riepilogo annunciato sull'hub FlexVPN. L'altro è la rete DMVPN 10.0.0.0/24 ridistribuita sulla DMVPN spoke in BGP.
Migrazione ai nuovi tunnel con EIGRP
EIGRP è una scelta popolare nelle reti DMVPN grazie alla sua installazione relativamente semplice e alla rapida convergenza. Tuttavia, ha una scalabilità peggiore di BGP e non offre molti meccanismi avanzati che possono essere utilizzati da BGP immediatamente. La sezione successiva descrive uno dei modi per passare a FlexVPN con un nuovo processo EIGRP.
Configurazione spoke aggiornata
Viene aggiunto un nuovo sistema autonomo (AS) con un processo EIGRP separato:
router eigrp 200
network 10.1.1.0 0.0.0.255
network 192.168.101.0
passive-interface default
no passive-interface Tunnel1
Configurazione hub FlexVPN aggiornata
Analogamente, per l'hub FlexVPN, preparare il protocollo di routing nell'appliance ASA appropriata, corrispondente a quello configurato sugli spoke.
router eigrp 200
network 10.1.1.0 0.0.0.255
Esistono due metodi per fornire un riepilogo verso il raggio.
- Ridistribuire una route statica che punta a null0 (opzione preferita).
ip route 192.168.0.0 255.255.0.0 null 0
ip route 10.1.1.0 255.255.255.0 null 0
ip prefix-list EIGRP_SUMMARY_ONLY seq 5 permit 192.168.0.0/16
ip prefix-list EIGRP_SUMMARY_ONLY seq 10 permit 10.1.1.0/24
route-map EIGRP_SUMMARY permit 20
match ip address prefix-list EIGRP_SUMMARY_ONLY
router eigrp 200
distribute-list route-map EIGRP_SUMMARY out Virtual-Template1
redistribute static metric 1500 10 10 1 1500 route-map EIGRP_SUMMARY
Questa opzione consente il controllo del riepilogo e della ridistribuzione senza modifiche alla configurazione della tecnologia di virtualizzazione (VT) dell'hub. Questa operazione è importante perché la configurazione della VT dell'hub non può essere modificata se è associato un accesso virtuale attivo. - Impostare un indirizzo di riepilogo di tipo DMVPN in un modello virtuale.
Questa configurazione non è consigliata, a causa dell'elaborazione interna e della replica di tale riepilogo in ogni accesso virtuale. Qui è mostrato come riferimento.
interface Virtual-Template1 type tunnel
ip summary-address eigrp 200 192.168.0.0 255.255.0.0
Un altro aspetto da considerare è lo scambio di routing tra hub. A tale scopo, è possibile ridistribuire le istanze EIGRP su iBGP.
DMVPN Hub - Configurazione BGP aggiornata
La configurazione rimane di base. È necessario ridistribuire prefissi specifici da EIGRP a BGP:
router bgp 65001
redistribute eigrp 100
neighbor 192.168.0.2 remote-as 65001
Hub FlexVPN - Configurazione BGP aggiornata
Analogamente all'hub DMVPN, in FlexVPN è necessario ridistribuire i prefissi del nuovo processo EIGRP in BGP:
router bgp 65001
redistribute eigrp 200 redistribute static
neighbor 192.168.0.1 remote-as 65001
Migrazione del traffico a FlexVPN
Per eseguire la migrazione, è necessario arrestare la funzionalità DMVPN e attivare FlexVPN su ogni spoke, uno alla volta. Questa procedura garantisce un impatto minimo:
- In ogni raggio, separatamente, immettere quanto segue:
interface tunnel 0
shut
A questo punto, verificare che non vi siano sessioni IKEv1 stabilite su questo spoke. Per verificare questa condizione, controllare l'output del comando show crypto isakmp sa e monitorare i messaggi syslog generati dal comando crypto logging session. Una volta confermato, è possibile procedere per visualizzare FlexVPN. - Nello stesso raggio, immetti questo:
interface tunnel 1
no shut
Fasi di verifica
Stabilità IPSec
Come nel caso di BGP, è necessario valutare se IPsec è stabile. Il modo migliore per farlo è monitorare i sylog con il comando di configurazione crypto logging session abilitato. Se le sessioni diventano attive e inattive, è possibile che si sia verificato un problema a livello IKEv2/FlexVPN che deve essere risolto prima di poter iniziare la migrazione.
Informazioni EIGRP nella tabella della topologia
Verificare che la tabella della topologia EIGRP sia popolata con voci LAN spoke sull'hub e riepilogo sugli spoke. È possibile verificare questa condizione se si immette questo comando negli hub e negli spoke:
show ip eigrp [AS_NUMBER] topology
Di seguito è riportato un esempio dell'output del raggio:
Spoke1#show ip eigrp 200 topology
EIGRP-IPv4 Topology Table for AS(200)/ID(192.168.101.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.1.1.1/32, 1 successors, FD is 26112000
via Rstatic (26112000/0)
via 10.1.1.1 (26240000/128256), Tunnel1
P 192.168.101.0/24, 1 successors, FD is 281600
via Connected, Ethernet1/0
P 192.168.0.0/16, 1 successors, FD is 26114560
via 10.1.1.1 (26114560/2562560), Tunnel1
P 10.1.1.100/32, 1 successors, FD is 26112000
via Connected, Tunnel1
P 10.1.1.0/24, 1 successors, FD is 26114560
via 10.1.1.1 (26114560/2562560), Tunnel1
L'output mostra che il spoke conosce la propria subnet LAN (in corsivo) e i relativi riepiloghi (in grassetto).
Di seguito è riportato un esempio di output dell'hub:
hub2# show ip eigrp 200 topology
EIGRP-IPv4 Topology Table for AS(200)/ID(172.25.2.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.1.1.1/32, 1 successors, FD is 128256
via Connected, Loopback200
P 192.168.101.0/24, 1 successors, FD is 26905600
via 10.1.1.100 (26905600/281600), Virtual-Access1
P 192.168.0.0/16, 1 successors, FD is 2562560
via Rstatic (2562560/0)
P 10.1.1.0/24, 1 successors, FD is 2562560
via Rstatic (2562560/0)
L'output mostra che l'hub è a conoscenza delle subnet LAN degli spoke (in corsivo), del prefisso di riepilogo pubblicizzato (in grassetto) e dell'indirizzo IP assegnato a ciascun spoke tramite negoziazione.
Ulteriori considerazioni
Tunnel spoke-to-spoke già esistenti
Poiché la chiusura dell'interfaccia del tunnel DMVPN determina la rimozione delle voci NHRP, i tunnel spoke già esistenti verranno eliminati.
Cancella voci NHRP
Un hub FlexVPN non si basa sul processo di registrazione NHRP dallo spoke per sapere come instradare il traffico indietro. Tuttavia, i tunnel spoke dinamici si basano su voci NHRP.
In DMVPN, se NHRP sull'hub viene cancellato, possono verificarsi problemi di connettività di breve durata. In FlexVPN, se si cancella NHRP sugli spoke, la sessione IPsec di FlexVPN, relativa ai tunnel spoke-to-spoke, verrà terminata. La cancellazione di NHRP sull'hub non ha alcun effetto sulla sessione FlexVPN.
Infatti, in FlexVPN per impostazione predefinita:
- I raggi non vengono registrati negli hub.
- Gli hub funzionano solo come redirector NHRP e non installano voci NHRP.
- Le voci di scelta rapida NHRP vengono installate su spoke per tunnel spoke e sono dinamiche.
Avvertenze note
Il traffico spoke potrebbe essere influenzato dall'ID bug Cisco CSCub07382.
Informazioni correlate
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
1.0 |
09-Jan-2015 |
Versione iniziale |
Feedback