El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe cómo realizar una migración de software donde tanto la VPN dinámica multipunto (DMVPN) como FlexVPN funcionan en un dispositivo simultáneamente sin necesidad de una solución alternativa y proporciona un ejemplo de configuración.
Nota: Este documento se extiende sobre los conceptos descritos en la Migración de FlexVPN: Cambio difícil de DMVPN a FlexVPN en los mismos dispositivos y Migración de FlexVPN: Cambio difícil de DMVPN a FlexVPN en artículos de Cisco de un centro diferente. Ambos documentos describen migraciones duras, que causan alguna interrupción en el tráfico durante la migración. Las limitaciones en estos artículos se deben a una deficiencia en el software Cisco IOS® que ahora se rectifica.
Cisco recomienda que tenga conocimiento sobre estos temas:
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
Nota: No todo el software y el hardware admiten el intercambio de claves de Internet versión 2 (IKEv2). Consulte Cisco Feature Navigator para obtener más información.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Una de las ventajas de la plataforma y el software Cisco IOS más nuevos es la capacidad de utilizar la criptografía de última generación. Un ejemplo es el uso del estándar de cifrado avanzado (AES) en el modo Galois/Counter (GCM) para el cifrado en IPsec, como se describe en RFC 4106. AES GCM permite velocidades de cifrado mucho más rápidas en algunos equipos.
Nota: Para obtener información adicional sobre el uso y la migración a la criptografía de última generación, refiérase al artículo Cifrado de última generación de Cisco.
Este ejemplo de configuración se centra en una migración de una configuración de la Fase 3 de DMVPN a una FlexVPN, porque ambos diseños funcionan de forma similar.
Fase 2 de DMVPN | Fase 3 de DMVPN | FlexVPN | |
Transporte | GRE sobre IPsec | GRE sobre IPsec | GRE sobre IPsec, VTI |
Uso de NHRP | Registro y resolución | Registro y resolución | Resolución |
Siguiente salto desde Spoke | Otros radios o concentrador | Resumen del hub | Resumen del hub |
Switching de acceso directo NHRP | No | Yes | Sí (opcional) |
Redirección NHRP | No | Yes | Yes |
IKE e IPsec | IPsec opcional, IKEv1 típico | IPsec opcional, IKEv1 típico | IPsec, IKEv2 |
Esta sección proporciona diagramas de red de transporte y superposición.
La red de transporte utilizada en este ejemplo incluye un único hub con dos radios conectados. Todos los dispositivos están conectados a través de una red que simula Internet.
La red superpuesta utilizada en este ejemplo incluye un único hub con dos radios conectados. Recuerde que tanto DMVPN como FlexVPN están activos simultáneamente, pero utilizan diferentes espacios de direcciones IP.
Esta configuración migra la implementación más popular de la Fase 3 de DMVPN a través del protocolo de routing de gateway interior mejorado (EIGRP) a FlexVPN con protocolo de gateway fronterizo (BGP). Cisco recomienda el uso de BGP con FlexVPN, ya que permite que las implementaciones se amplíen mejor.
Nota: El hub finaliza las sesiones IKEv1 (DMVPN) e IKEv2 (FlexVPN) en la misma dirección IP. Esto sólo es posible con las versiones recientes de Cisco IOS.
Se trata de una configuración muy básica, con dos excepciones notables que permiten la interoperabilidad de IKEv1 e IKEv2, así como dos marcos que utilizan Generic Routing Encapsulation (GRE) sobre IPsec para el transporte con el fin de coexistir.
Nota: Los cambios relevantes en la configuración de IKEv2 y de la Asociación de seguridad de Internet (ISAKMP) se resaltan en negrita.
crypto keyring DMVPN_IKEv1
pre-shared-key address 0.0.0.0 0.0.0.0 key cisco
crypto logging session
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
crypto isakmp policy 10
encr aes
authentication pre-share
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
crypto ipsec profile default
set ikev2-profile Flex_IKEv2
interface Tunnel0
desciption DMVPN tunnel
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 key 0
tunnel protection ipsec profile DMVPN_IKEv1 isakmp-profile DMVPN_IKEv1
interface Tunnel1
description FlexVPN spoke-to-hub tunnel
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
tunnel source Ethernet0/0
tunnel destination 172.25.1.1
tunnel protection ipsec profile default ikev2-profile Flex_IKEv2
interface Virtual-Template1 type tunnel
description FlexVPN spoke-to-spoke
ip unnumbered Ethernet1/0
ip mtu 1400
ip nhrp network-id 2
ip nhrp shortcut virtual-template 1
ip nhrp redirect
ip tcp adjust-mss 1360
tunnel protection ipsec profile default ikev2-profile Flex_IKEv2
Cisco IOS Release 15.3 le permite unir los perfiles IKEv2 e ISAKMP en una configuración de protección de túnel. Junto con algunos cambios internos en el código, esto permite que IKEv1 e IKEv2 funcionen en el mismo dispositivo simultáneamente.
Debido a la forma en que Cisco IOS selecciona los perfiles (IKEv1 o IKEv2) en las versiones anteriores a 15.3, se derivaron algunas advertencias, como situaciones en las que se inicia IKEv1 a IKEv2 a través del par. La separación de IKE se basa ahora en el nivel de perfil, no en el nivel de interfaz, que se logra a través de la nueva CLI.
Otra actualización en la nueva versión de Cisco IOS es la adición de la clave de túnel. Esto es necesario porque tanto DMVPN como FlexVPN utilizan la misma interfaz de origen y la misma dirección IP de destino. Con esto en su lugar, no hay manera de que el túnel GRE sepa qué interfaz de túnel se utiliza para desencapsular el tráfico. La clave de túnel le permite diferenciar tunnel0 y tunnel1 con la adición de una sobrecarga pequeña (4 bytes). Se puede configurar una clave diferente en ambas interfaces, pero normalmente sólo necesita diferenciar un túnel.
Nota: La opción de protección de túnel compartido no es necesaria cuando DMVPN y FlexVPN comparten la misma interfaz.
Por lo tanto, la configuración del protocolo de ruteo spoke es básica. EIGRP y BGP funcionan por separado. EIGRP se anuncia solamente a través de la interfaz de túnel para evitar el peering sobre los túneles de spoke a spoke, lo que limita la escalabilidad. BGP mantiene una relación solamente con el router hub (10.1.1.1) para anunciar la red local (192.168.101.0/24).
router eigrp 100
network 10.0.0.0 0.0.0.255
network 192.168.101.0
passive-interface default
no passive-interface Tunnel0
router bgp 65001
bgp log-neighbor-changes
network 192.168.101.0
neighbor 10.1.1.1 remote-as 65001
Debe realizar cambios similares en la configuración del eje de conexión como los descritos en la sección Configuración de radio.
Nota: Los cambios relevantes en la configuración ISAKMP e IKEV2 se resaltan en negrita.
crypto ikev2 authorization policy default
pool FlexSpokes
route set interface
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
crypto isakmp policy 10
encr aes
authentication pre-share
crypto isakmp key cisco address 0.0.0.0
crypto ipsec profile DMVPN_IKEv1
set transform-set IKEv1
crypto ipsec profile default
set ikev2-profile Flex_IKEv2
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 key 0
tunnel protection ipsec profile DMVPN_IKEv1
interface Virtual-Template1 type tunnel
ip unnumbered Loopback100
ip mtu 1400
ip nhrp network-id 2
ip tcp adjust-mss 1360
tunnel protection ipsec profile default
En el lado del hub, el enlace entre el perfil IKE y el perfil IPsec ocurre en el nivel del perfil, a diferencia de la configuración spoke, donde esto se completa a través del comando tunnel protection. Ambos enfoques son métodos viables para completar este enlace.
Es importante tener en cuenta que las ID de red del protocolo de resolución de salto siguiente (NHRP) son diferentes para DMVPN y FlexVPN en la nube. En la mayoría de los casos, no es deseable cuando NHRP crea un dominio único sobre ambos marcos.
La clave de túnel diferencia los túneles DMVPN y FlexVPN en el nivel GRE para alcanzar el mismo objetivo mencionado en la sección Configuración de radio.
La configuración de ruteo en el hub es bastante básica. El dispositivo hub mantiene dos relaciones con cualquier spoke dado, una que utiliza EIGRP y otra que utiliza BGP. La configuración BGP utiliza el rango de escucha para evitar una configuración larga por radio.
Las direcciones de resumen se introducen dos veces. La configuración EIGRP envía un resumen con el uso de la configuración tunnel0 (IP summary-address EIGRP 100), y el BGP introduce un resumen con el uso de aggregate-address. Los resúmenes son necesarios para asegurarse de que se produzca la redirección NHRP y para simplificar las actualizaciones de ruteo. Puede enviar una redirección NHRP (al igual que una redirección de protocolo de mensajes de control de Internet (ICMP)) que indica si existe un mejor salto para un destino determinado, lo que permite establecer un túnel de radio a radio. Estos resúmenes también se utilizan para minimizar la cantidad de actualizaciones de ruteo que se envían entre el hub y cada spoke, lo que permite que las configuraciones se escalen mejor.
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
router bgp 65001
bgp log-neighbor-changes
bgp listen range 10.1.1.0/24 peer-group Spokes
network 192.168.0.0
aggregate-address 192.168.0.0 255.255.0.0 summary-only
neighbor Spokes peer-group
neighbor Spokes remote-as 65001
La verificación para este ejemplo de configuración se divide en varias secciones.
Dado que tanto DMVPN/EIGRP como FlexVPN/BGP funcionan simultáneamente, debe verificar que el spoke mantiene una relación sobre IPsec con IKEv1 e IKEv2, y que los prefijos apropiados se aprenden a través de EIGRP y BGP.
En este ejemplo, Spoke1 muestra que se mantienen dos sesiones con el router hub; uno utiliza IKEv1/Tunnel0 y uno utiliza IKEv2/Tunnel1.
Nota: Se mantienen dos asociaciones de seguridad IPsec (una entrante y otra saliente) para cada uno de los túneles.
Spoke1#show cry sess
Crypto session current status
Interface: Tunnel0
Profile: DMVPN_IKEv1
Session status: UP-ACTIVE
Peer: 172.25.1.1 port 500
Session ID: 0
IKEv1 SA: local 172.16.1.2/500 remote 172.25.1.1/500 Active
IPSEC FLOW: permit 47 host 172.16.1.2 host 172.25.1.1
Active SAs: 2, origin: crypto map
Interface: Tunnel1
Profile: Flex_IKEv2
Session status: UP-ACTIVE
Peer: 172.25.1.1 port 500
Session ID: 1
IKEv2 SA: local 172.16.1.2/500 remote 172.25.1.1/500 Active
IPSEC FLOW: permit 47 host 172.16.1.2 host 172.25.1.1
Active SAs: 2, origin: crypto map
Cuando verifica los protocolos de ruteo, debe verificar que se ha formado una vecindad y que se han aprendido los prefijos correctos. Esto se verifica primero con el EIGRP. Verifique que el hub esté visible como vecino y que la dirección 192.168.0.0/16 (el resumen) se obtenga del hub:
Spoke1#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.0.0.1 Tu0 10 00:04:02 7 1398 0 13
Spoke1#show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(100)/ID(192.168.101.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
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 26880000
via 10.0.0.1 (26880000/256), Tunnel0
P 10.0.0.0/24, 1 successors, FD is 26880000
via Connected, Tunnel0
Luego, verifique el BGP:
Spoke1#show bgp summary
(...)
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.1.1 4 65001 13 11 3 0 0 00:06:56 1
Spoke1#show bgp
BGP table version is 3, local router ID is 192.168.101.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
r>i 192.168.0.0/16 10.1.1.1 0 100 0 i
*> 192.168.101.0 0.0.0.0 0 32768 i
El resultado muestra que la dirección IP FlexVPN del hub (10.1.1.1) es un vecino a través del cual el spoke recibe un prefijo (192.168.0.0/16). Además, el BGP informa al administrador de que se ha producido una falla en la Base de información de routing (RIB) para el prefijo 192.168.0.0/16. Esta falla ocurre porque hay una mejor ruta para ese prefijo que ya existe en la tabla de ruteo. EIGRP origina esta ruta y puede confirmarse si verifica la tabla de ruteo.
Spoke1#show ip route 192.168.0.0 255.255.0.0
Routing entry for 192.168.0.0/16, supernet
Known via "eigrp 100", distance 90, metric 26880000, type internal
Redistributing via eigrp 100
Last update from 10.0.0.1 on Tunnel0, 00:10:07 ago
Routing Descriptor Blocks:
* 10.0.0.1, from 10.0.0.1, 00:10:07 ago, via Tunnel0
Route metric is 26880000, traffic share count is 1
Total delay is 50000 microseconds, minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1400 bytes
Loading 1/255, Hops 1
La sección anterior verificó que los protocolos IPsec y de ruteo se configuran y funcionan como se esperaba. Una de las formas más sencillas de migrar de DMVPN a FlexVPN en el mismo dispositivo es cambiar la distancia administrativa (AD). En este ejemplo, el BGP interno (iBGP) tiene un AD de 200, y el EIGRP tiene un AD de 90.
Para que el tráfico fluya correctamente a través de FlexVPN, el BGP debe tener un mejor AD. En este ejemplo, el EIGRP AD se cambia a 230 y 240 para las rutas internas y externas, respectivamente. Esto hace que el BGP AD (de 200) sea más preferible para el prefijo 192.168.0.0/16.
Otro método que se utiliza para lograr esto es para disminuir el BGP AD. Sin embargo, el protocolo que se ejecuta después de la migración tiene valores no predeterminados, lo que puede afectar a otras partes de la implementación.
En este ejemplo, se utiliza el comando debug ip routing para verificar la operación en el spoke.
Nota: Si la información de esta sección se utiliza en una red de producción, evite el uso de los comandos debug y confíe en los comandos show enumerados en la siguiente sección. Además, el proceso EIGRP radial debe restablecer la adyacencia con el hub.
Spoke1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Spoke1(config)#router eigrp 100
Spoke1(config-router)# distance eigrp 230 240
Spoke1(config-router)#^Z
Spoke1#
*Oct 9 12:12:34.207: %SYS-5-CONFIG_I: Configured from console by console
*Oct 9 12:12:43.648: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.0.1
(Tunnel0) is down: route configuration changed
*Oct 9 12:12:43.648: RT: delete route to 192.168.0.0 via 10.0.0.1,
eigrp metric [90/26880000]
*Oct 9 12:12:43.648: RT: no routes to 192.168.0.0, delayed flush
*Oct 9 12:12:43.648: RT: delete network route to 192.168.0.0/16
*Oct 9 12:12:43.650: RT: updating bgp 192.168.0.0/16 (0x0) :
via 10.1.1.1
*Oct 9 12:12:43.650: RT: add 192.168.0.0/16 via 10.1.1.1, bgp metric [200/0]
Spoke1#
*Oct 9 12:12:45.750: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.0.1
(Tunnel0) is up: new adjacency
Hay tres acciones importantes que deben tenerse en cuenta en este resultado:
Cuando cambia el AD en un dispositivo, sólo afecta el trayecto del dispositivo a las otras redes; no afecta al modo en que otros routers realizan el ruteo. Por ejemplo, después de aumentar la distancia EIGRP en Spoke1 (y utiliza FlexVPN en la nube para enrutar el tráfico), el hub mantiene los AD configurados (predeterminados). Esto significa que utiliza DMVPN para rutear el tráfico nuevamente a Spoke1.
En algunos escenarios, esto puede causar problemas, como cuando los firewalls esperan tráfico de retorno en la misma interfaz. Por lo tanto, debe cambiar el AD en todos los radios antes de cambiarlo en el hub. FlexVPN migra completamente el tráfico solo una vez que se ha completado.
En este documento no se analiza en profundidad una migración de DMVPN a FlexVPN que ejecuta solamente EIGRP; sin embargo, se menciona aquí para más detalles.
Es posible agregar DMVPN y EIGRP a la misma instancia de routing del sistema autónomo EIGRP (AS). Con esto en su lugar, la adyacencia de ruteo se establece sobre ambos tipos de nubes. Esto puede hacer que se produzca un balanceo de carga, lo que normalmente no se recomienda.
Para asegurarse de que se elige FlexVPN o DMVPN, un administrador puede asignar diferentes valores de retraso por interfaz. Sin embargo, es importante recordar que no es posible realizar cambios en las interfaces de plantilla virtual mientras que las interfaces de acceso virtual correspondientes están presentes.
De manera similar al proceso utilizado en la sección Verificaciones previas a la migración, se debe verificar el IPSec y el protocolo de ruteo.
Primero, verifique el IPSec:
Spoke1#show crypto session
Crypto session current status
Interface: Tunnel0
Profile: DMVPN_IKEv1
Session status: UP-ACTIVE
Peer: 172.25.1.1 port 500
Session ID: 0
IKEv1 SA: local 172.16.1.2/500 remote 172.25.1.1/500 Active
IPSEC FLOW: permit 47 host 172.16.1.2 host 172.25.1.1
Active SAs: 2, origin: crypto map
Interface: Tunnel1
Profile: Flex_IKEv2
Session status: UP-ACTIVE
Peer: 172.25.1.1 port 500
Session ID: 1
IKEv2 SA: local 172.16.1.2/500 remote 172.25.1.1/500 Active
IPSEC FLOW: permit 47 host 172.16.1.2 host 172.25.1.1
Active SAs: 2, origin: crypto map
Como antes, se ven dos sesiones, ambas con dos SA IPSec activas.
En el spoke, la ruta agregada (192.168.0.0/16) apunta desde el hub y se aprende sobre el BGP.
Spoke1#show ip route 192.168.0.0 255.255.0.0
Routing entry for 192.168.0.0/16, supernet
Known via "bgp 65001", distance 200, metric 0, type internal
Last update from 10.1.1.1 00:14:07 ago
Routing Descriptor Blocks:
* 10.1.1.1, from 10.1.1.1, 00:14:07 ago
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: none
De manera similar, la LAN de radio que está prefijada en el hub debe ser conocida a través del EIGRP. En este ejemplo, la subred LAN Spoke2 está marcada:
Hub#show ip route 192.168.102.0 255.255.255.0
Routing entry for 192.168.102.0/24
Known via "bgp 65001", distance 200, metric 0, type internal
Last update from 10.1.1.106 00:04:35 ago
Routing Descriptor Blocks:
* 10.1.1.106, from 10.1.1.106, 00:04:35 ago
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: none
Hub#show ip cef 192.168.102.100
192.168.102.0/24
nexthop 10.1.1.106 Virtual-Access2
En el resultado, la trayectoria de reenvío se actualiza correctamente y se señala desde una interfaz de acceso virtual.
Esta sección describe algunas áreas adicionales de importancia que son relevantes para este ejemplo de configuración.
Con una migración de EIGRP a BGP, los túneles de spoke a spoke no se ven afectados, porque el switching de acceso directo todavía está en funcionamiento. El switching de acceso directo en el spoke inserta una ruta NHRP más específica con un AD de 250.
Aquí hay un ejemplo de tal ruta:
Spoke1#show ip route 192.168.102.100
Routing entry for 192.168.102.0/24
Known via "nhrp", distance 250, metric 1
Last update from 10.1.1.106 on Virtual-Access1, 00:00:42 ago
Routing Descriptor Blocks:
* 10.1.1.106, from 10.1.1.106, 00:00:42 ago, via Virtual-Access1
Route metric is 1, traffic share count is 1
Si un spoke que ya se encuentra en un FlexVPN/BGP desea comunicarse con un dispositivo para el que el proceso de migración no ha comenzado, el tráfico siempre fluye a través del hub.
Este es el proceso que ocurre:
Nota: El ID de red NHRP en la configuración del hub anterior es diferente tanto para FlexVPN como para DMVPN.
Incluso si los ID de red NHRP están unificados, puede ocurrir un problema cuando el spoke migrado enruta objetos a través de la red FlexVPN. Esto incluye la directiva utilizada para configurar la conmutación de acceso directo. El spoke no migrado intenta ejecutar objetos a través de la red DMVPN, con un objetivo específico para realizar el switching de acceso directo.
En esta sección se describen las dos categorías que se utilizan habitualmente para solucionar la migración.
Complete estos pasos si falla la negociación IKE:
Nota: A diferencia de IKEv1, en este resultado el valor Diffie-Hellman (DH) Diffie-Secrecy Perfect Forward Secrecy (PFS) Group aparece como PFS (Y/N): N, grupo DH: ninguno durante la primera negociación del túnel; sin embargo, después de que se produce una nueva clave, aparecen los valores correctos. Esto no es un error, aunque el comportamiento se describe en CSCug67056. La diferencia entre IKEv1 e IKEv2 es que en este último, las SAs secundarias se crean como parte del intercambio AUTH. El grupo DH configurado bajo el mapa criptográfico se utiliza solamente durante una nueva clave. Por esta razón, verá PFS (Y/N): N, grupo DH: ninguno hasta la primera llave. Con IKEv1, verá un comportamiento diferente porque la creación de SA secundaria ocurre durante el modo rápido, y el mensaje CREATE_CHILD_SA contiene disposiciones para la transferencia de la carga útil de intercambio de claves que especifica los parámetros DH para derivar un nuevo secreto compartido.
Estos son algunos comandos útiles que puede utilizar para resolver problemas de EIGRP y topología:
Es importante saber que un prefijo aprendido es diferente de un prefijo que está instalado en la tabla de ruteo. Para obtener más información sobre esto, refiérase al artículo Selección de ruta en routers Cisco de Cisco o al Libro de Cisco Press sobre TCP/IP de enrutamiento.
Existe una limitación que coincide con el manejo del túnel GRE en el ASR1K. Esto se rastrea bajo el ID de bug de Cisco CSCue00443. En este momento, la limitación tiene una corrección programada en Cisco IOS XE Software Release 3.12.
Controle este error si desea una notificación una vez que la corrección esté disponible.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
24-Feb-2014 |
Versión inicial |