Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Escalabilidad

Funciones esenciales

Antecedentes

FlexVPN y NHRP

Proceso NHRP

Configuración de FlexVPN Spoke a Spoke mediante EIGRP

Diagrama de topología

Consideraciones clave para la topología basada en EIGRP

Ejemplo 1: utilización de NHO (reemplazo de salto siguiente) para la comunicación de radio a radio

Servidor FlexVPN

Cliente FlexVPN 1

Cliente FlexVPN 2

Ejemplo 2: Utilización de rutas instaladas de NHRP para la comunicación de radio a radio

Servidor FlexVPN

Verificación y resolución de problemas

Ejemplo 1: utilización de NHO (reemplazo de salto siguiente) para la comunicación de radio a radio

Spoke 1 (antes de Spoke to Spoke NHRP Resolution & Tunnel Establishment)

Spoke 2 (antes de Spoke to Spoke NHRP Resolution & Tunnel Establishment)

Spoke 1 (Resolución NHRP después de Spoke to Spoke y establecimiento de túnel)

Spoke 2 (Resolución NHRP después de Spoke to Spoke y establecimiento de túnel)

Ejemplo 2: Utilización de rutas instaladas de NHRP para la comunicación de radio a radio

Servidor FlexVPN

Clientes FlexVPN

Información Relacionada

Introducción

Este documento describe la implementación y solución de problemas de Cisco FlexVPN spoke-to-spoke usando IKEv2 y NHRP para túneles criptográficos de cliente directo.

Prerequisites

- Configuración del hub Flex VPN y del cliente Flex VPN

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

- IKEv2

- VPN basada en ruta

- Interfaces de túnel virtual (VTI)

- NHRP

- IPSec

- EIGRP

- VRF-Lite

Componentes Utilizados

La información de este documento se basa en:

- Cisco IOS XE 17.9.4a

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Escalabilidad

FlexVPN puede ampliarse fácilmente de pequeñas oficinas a redes de grandes empresas. Puede administrar muchas conexiones VPN sin necesidad de mucho trabajo adicional, lo que es ideal para organizaciones que están creciendo o que tienen muchos usuarios remotos.

Funciones esenciales

- Configuración dinámica y túneles a demanda:

- Interfaces de túnel virtual (VTI): FlexVPN utiliza VTI que se pueden crear y eliminar según sea necesario. Esto significa que los túneles VPN se configuran solo cuando hay tráfico y se eliminan cuando no se necesitan, lo que ahorra recursos y mejora la escalabilidad.

- Protocolos de enrutamiento dinámico: Funciona con protocolos de ruteo como OSPF, EIGRP y BGP sobre túneles VPN. Esto mantiene la información de ruteo actualizada automáticamente, lo cual es importante para las redes grandes y dinámicas.

- Flexibilidad en la implementación:

- Modelo de hub y radio: Un hub central se conecta a varias sucursales. FlexVPN simplifica la configuración de estas conexiones con una única estructura, lo que la convierte en la opción ideal para redes de gran tamaño.

- Topologías de malla completa y de malla parcial: Todos los sitios se pueden comunicar directamente sin pasar por un hub central, lo que reduce el retraso y mejora el rendimiento.

- Alta disponibilidad y redundancia:

- Concentradores redundantes: Admite varios concentradores para realizar copias de seguridad. Si un hub falla, las sucursales pueden conectarse a otro hub, lo que garantiza una conectividad continua.

- Equilibrio de carga: Distribuye las conexiones VPN a través de varios dispositivos para evitar que se sobrecargue un solo dispositivo, lo que es fundamental para mantener el rendimiento en grandes implementaciones.

- Autenticación y autorización escalables:

- Integración de AAA: Funciona con servidores AAA como Cisco ISE o RADIUS para la gestión centralizada de credenciales y políticas de usuario, esencial para un uso a gran escala.

- PKI y certificados: Admite la infraestructura de clave pública (PKI) y certificados digitales para una autenticación segura, que es más escalable que el uso de claves previamente compartidas, especialmente en entornos de gran tamaño.

Antecedentes

FlexVPN y NHRP

El servidor FlexVPN proporciona la funcionalidad de servidor de FlexVPN. El cliente FlexVPN establece un túnel VPN IPsec seguro entre un cliente FlexVPN y otro servidor FlexVPN.

NHRP es un protocolo similar al protocolo de resolución de direcciones (ARP) que alivia los problemas de red de acceso múltiple sin difusión (NBMA). Con NHRP, las entidades NHRP conectadas a una red NBMA aprenden dinámicamente la dirección NBMA de las otras entidades que forman parte de esa red, lo que les permite comunicarse directamente sin que el tráfico tenga que utilizar un salto intermedio.

La función de radio a radio de FlexVPN integra el cliente NHRP y FlexVPN (spoke) para establecer un canal criptográfico directo con otro cliente en una red FlexVPN existente. Las conexiones se crean mediante interfaces de túnel virtual (VTI), IKEv2 y NHRP, donde NHRP se utiliza para resolver los clientes FlexVPN de la red.

Cisco recomienda asegurarse de que:

- Las entradas de enrutamiento no se intercambian entre radios. Una consideración clave, que se explica más adelante a medida que avanzamos en la solución de problemas de topología basada en EIGRP.

- Se utilizan perfiles diferentes para los spokes y el comando config-exchange no se configura para los spokes.

Proceso NHRP

La ilustración muestra el flujo de tráfico entre Spoke 1 y Spoke 2, con las redes 198.51.100.0/29/24 y 198.51.100.8/29, ambas anunciadas a través de EIGRP que se asemejan directamente a los spokes a través del hub. Este es el aspecto del flujo de tráfico cuando se establece la comunicación entre Spoke 1(198.51.100.0/29/24) y Spoke 2 (198.51.100.8/29).

1. Host1 envía tráfico destinado al Host2. La búsqueda de rutas en el host 1 provoca su reenvío a la interfaz de túnel de hub porque el hub anuncia esa red a través de EIGRP.

2. Cuando el tráfico llega al hub, la búsqueda de rutas de extremo del hub confirma que la red spoke 2 198.51.100.8/29 se aprende a través del acceso virtual spoke 2.

3. El concentrador inicia la redirección NHRP, ya que ambas interfaces de acceso virtual (spoke 1 y spoke 2) forman parte de la misma red NHRP con el mismo ID de red NHRP.

4. Al recibir la redirección, Spoke1 inicia una solicitud de resolución para la red spoke 2 a través de la interfaz de túnel (la misma interfaz a través de la cual recibió la redirección). Spoke 2 repite el mismo proceso para la solicitud de resolución de la red spoke 1.

5. Spoke2 recibe la solicitud de resolución en la interfaz de túnel y recupera el número de plantilla virtual según se define en la configuración. El número de plantilla virtual se utiliza para crear la interfaz de acceso virtual para establecer una sesión de cifrado entre dos radios. Una vez que las SA crypto entre los dos spokes están activas, ambos spokes instalan las rutas de la dirección IP del salto siguiente aprendida vía IPSEC después del establecimiento de las interfaces de acceso virtual.

6. A continuación, ambos radios proceden a verificar la disponibilidad del siguiente salto antes de enviar la respuesta de resolución a través del acceso virtual de interfaz recién creado para la conectividad de radio a radio.

7. Una vez que se puede alcanzar el salto siguiente, ambos radios se envían una respuesta de resolución entre sí.

8. Ambos spokes ahora pueden invalidar cada una de sus direcciones IP de siguiente salto de red para el acceso virtual a través de NHO.

9. Spoke1 instala las entradas de caché necesarias para la IP de salto siguiente de Spoke2 y su red. Spoke1 también elimina la entrada de caché temporal que apunta al hub para resolver la red bajo la interfaz de túnel 1.

10. El mismo paso es repetido por spoke 2, también instala entradas de caché para spoke 1 next-hop IP y su red avanzando en la eliminación de la antigua entrada hub a través del túnel.

11. NHRP agrega rutas de acceso directo como la ruta de reemplazo de salto siguiente (NHO) o H (NHRP).

Configuración de FlexVPN Spoke a Spoke mediante EIGRP

Diagrama de topología

Consideraciones clave para la topología basada en EIGRP

Antes de proceder a la configuración, hay algunos conceptos clave que debemos comprender:

- Para cualquier implementación de EIGRP, si los spokes reciben una tabla de ruteo completa de otros spokes o solamente rutas de resumen, se debe instalar una lista de prefijos en el lado del hub para que las actualizaciones de ruteo salientes filtren las direcciones IP de los spokes de túnel para que se anuncien entre sí.

- El horizonte dividido en EIGRP funciona de manera diferente que en IBGP. EIGRP solo detiene la publicidad de redes fuera de una interfaz de la que se han aprendido. Por ejemplo, el hub tiene dos spokes, uno conectado a través de interfaces de acceso virtual 1 y el otro a través de interfaces de acceso virtual 2. Las rutas aprendidas por el hub a través de VA 1 desde el Spoke 1 se anuncian de nuevo al spoke 2 a través de VA 2 y viceversa, ya que VA 1 y VA 2 son interfaces diferentes. En el caso de IBGP, no anuncia ninguna red aprendida de su peer de vuelta a otro peer. En un ejemplo similar, un hub configurado con IBGP no anuncia las redes que aprendió de VA 1 a VA 2 y viceversa.

- Este comportamiento en EIGRP crea un conflicto en la adyacencia CEF para la dirección IP del siguiente salto (una dirección IP de interfaz de acceso virtual para un túnel de radio a radio) ya que primero se aprende a través de EIGRP usando una interfaz de túnel de hub y luego a través de IPsec usando una interfaz de acceso virtual. Esto provoca un ruteo asimétrico para el tráfico NHRP y también resulta en una entrada NHRP duplicada en la tabla NHRP y entradas NHO duplicadas en la tabla de ruteo así como para las interfaces de salto siguiente (túnel a través del hub) y (acceso virtual a través del spoke).

- La plantilla virtual del lado del concentrador necesita tener IP de un conjunto diferente al de las interfaces de túnel de radios, ya que queremos filtrar las actualizaciones EIGRP salientes para asegurarnos de que el peering EIGRP del concentrador y el radio no se vea afectado.

Aquí hay dos ejemplos que muestran cómo configurar el spoke de FlexVPN para spoke usando EIGRP en el servidor FlexVPN y el cliente FlexVPN. Hemos seguido las prácticas recomendadas para segregar el tráfico subyacente y superpuesto colocándolos en VRF específicos. VRF A es para la superposición, mientras que B se utiliza para la superposición.

Ejemplo 1: utilización de NHO (reemplazo de salto siguiente) para la comunicación de radio a radio

Servidor FlexVPN

ip local pool FLEXPOOL 192.0.2.129 192.0.2.254

crypto ikev2 authorization policy CISCO_FLEX

pool FLEXPOOL

def-domain cisco.com

route set interface

crypto ikev2 proposal CISCO_PROP

encryption aes-gcm-256

prf sha256

group 21

crypto ikev2 policy CISCO_POL

match fvrf A

proposal CISCO_PROP

crypto ikev2 profile CISCO_IKEV2

match fvrf A

match identity remote fqdn domain cisco.com

identity local fqdn hub.cisco.com

authentication remote pre-share key cisco

authentication local pre-share key cisco

aaa authorization group psk list default CISCO_FLEX

virtual-template 1

crypto ipsec transform-set CISCO_TRANSFORM esp-aes 256 esp-sha256-hmac

mode transport

crypto ipsec profile CISCO_PROF

set transform-set CISCO_TRANSFORM

set pfs group19

set ikev2-profile CISCO_IKEV2

interface Loopback0

ip vrf forwarding B

ip address 192.0.2.1 255.255.255.255

interface GigabitEthernet1

ip vrf forwarding A

ip address 203.0.113.2 255.255.255.252

interface Virtual-Template1 type tunnel

ip vrf forwarding B

ip unnumbered Loopback0

ip nhrp network-id 1

ip nhrp redirect

tunnel vrf A

tunnel protection ipsec profile CISCO_PROF

ip prefix-list CISCO_PREFIX seq 5 deny 192.0.2.128/25 le 32

ip prefix-list CISCO_PREFIX seq 6 permit 0.0.0.0/0 le 32

router eigrp B

!

address-family ipv4 unicast vrf B autonomous-system 1

!

af-interface default

hello-interval 2

hold-time 10

exit-af-interface

!

topology base

distribute-list prefix CISCO_PREFIX out

exit-af-topology

network 192.0.2.128 0.0.0.127

network 192.0.2.1 0.0.0.0

exit-address-family

Cliente FlexVPN 1

ip host vrf A hub.cisco.com 203.0.113.2

crypto ikev2 authorization policy CISCO_FLEX

route set interface

crypto ikev2 proposal CISCO_PROP

encryption aes-gcm-256

prf sha256

group 21

crypto ikev2 policy CISCO_POL

match fvrf A

proposal CISCO_PROP

crypto ikev2 client flexvpn CISCO_CLIENT

peer 1 fqdn hub.cisco.com dynamic

client connect Tunnel1

crypto ikev2 profile CISCO_IKEV2

match fvrf A

match identity remote fqdn domain cisco.com

identity local fqdn spoke1.cisco.com

authentication remote pre-share key cisco

authentication local pre-share key cisco

aaa authorization group psk list default CISCO_FLEX

virtual-template 1

crypto ipsec transform-set CISCO_TRANSFORM esp-aes 256 esp-sha256-hmac

mode transport

crypto ipsec profile CISCO_PROF

set transform-set CISCO_TRANSFORM

set pfs group19

set ikev2-profile CISCO_IKEV2

interface Tunnel1

ip vrf forwarding B

ip address negotiated

ip nhrp network-id 1

ip nhrp shortcut virtual-template 1

tunnel source GigabitEthernet1

tunnel destination dynamic

tunnel vrf A

tunnel protection ipsec profile CISCO_PROF

end

interface GigabitEthernet1

ip vrf forwarding A

ip address 203.0.113.6 255.255.255.252

interface Loopback1

ip vrf forwarding B

ip address 198.51.100.1 255.255.255.248

interface Virtual-Template1 type tunnel

ip vrf forwarding B

ip unnumbered Tunnel1

ip nhrp network-id 1

ip nhrp shortcut virtual-template 1

tunnel vrf A

tunnel protection ipsec profile CISCO_PROF

router eigrp B

address-family ipv4 unicast vrf B autonomous-system 1

af-interface default

hello-interval 2

hold-time 10

passive-interface

exit-af-interface

af-interface Tunnel1

no passive-interface

exit-af-interface

topology base

exit-af-topology

network 198.51.100.0 0.0.0.7

network 192.0.2.128 0.0.0.127

exit-address-family

Cliente FlexVPN 2

ip host vrf A hub.cisco.com 203.0.113.2

crypto ikev2 authorization policy CISCO_FLEX

route set interface

crypto ikev2 proposal CISCO_PROP

encryption aes-gcm-256

prf sha256

group 21

crypto ikev2 policy CISCO_POL

match fvrf A

proposal CISCO_PROP

crypto ikev2 client flexvpn CISCO_CLIENT

peer 1 fqdn hub.cisco.com dynamic

client connect Tunnel1

crypto ikev2 profile CISCO_IKEV2

match fvrf A

match identity remote fqdn domain cisco.com

identity local fqdn spoke2.cisco.com

authentication remote pre-share key cisco

authentication local pre-share key cisco

aaa authorization group psk list default CISCO_FLEX

virtual-template 1

crypto ipsec transform-set CISCO_TRANSFORM esp-aes 256 esp-sha256-hmac

mode transport

crypto ipsec profile CISCO_PROF

set transform-set CISCO_TRANSFORM

set pfs group19

set ikev2-profile CISCO_IKEV2

interface Tunnel1

ip vrf forwarding B

ip address negotiated

ip nhrp network-id 1

ip nhrp shortcut virtual-template 1

tunnel source GigabitEthernet1

tunnel destination dynamic

tunnel vrf A

tunnel protection ipsec profile CISCO_PROF

end

interface GigabitEthernet1

ip vrf forwarding A

ip address 203.0.113.10 255.255.255.252

interface Loopback1

ip vrf forwarding B

ip address 198.51.100.9 255.255.255.248

interface Virtual-Template1 type tunnel

ip vrf forwarding B

ip unnumbered Tunnel1

ip nhrp network-id 1

ip nhrp shortcut virtual-template 1

tunnel vrf A

tunnel protection ipsec profile CISCO_PROF

router eigrp B

address-family ipv4 unicast vrf B autonomous-system 1

af-interface default

hello-interval 2

hold-time 10

passive-interface

exit-af-interface

af-interface Tunnel1

no passive-interface

exit-af-interface

topology base

exit-af-topology

network 198.51.100.8 0.0.0.7

network 192.0.2.128 0.0.0.127

exit-address-family

Ejemplo 2: Utilización de rutas instaladas de NHRP para la comunicación de radio a radio

Servidor FlexVPN

El único cambio en la configuración de EIGRP es introducir rutas de resumen en lugar de una tabla de ruteo completa en los spokes. Asegúrese de bajar la plantilla virtual para introducir la configuración de resumen en la topología EIGRP. Consulte el ID de bug de Cisco CSCwn84303.

router eigrp B

!

address-family ipv4 unicast vrf B autonomous-system 1

!

af-interface default

hello-interval 2

hold-time 10

exit-af-interface

!

af-interface Virtual-Template1

summary-address 198.51.100.0 255.255.255.0 <<<<<<<<<<< Summary address

exit-af-interface

!

topology base

distribute-list prefix CISCO_PREFIX out

exit-af-topology

network 192.0.2.128 0.0.0.127

network 192.0.2.1 0.0.0.0

exit-address-family

Verificación y resolución de problemas

Ejemplo 1: utilización de NHO (reemplazo de salto siguiente) para la comunicación de radio a radio

Spoke 1 (antes de Spoke to Spoke NHRP Resolution & Tunnel Establishment)

Spoke 2 (antes de Spoke to Spoke NHRP Resolution & Tunnel Establishment)

Spoke 1 (Resolución NHRP después de Spoke to Spoke y establecimiento de túnel)

Inicie el ICMP para activar el túnel de radio a radio:

Verificar acceso directo NHRP:

Verificar la creación de accesos directos posteriores a rutas NHO:

Verificar contadores NHRP:

Spoke 2 (Resolución NHRP después de Spoke to Spoke y establecimiento de túnel)

Verificar acceso directo NHRP:

Verificar la creación de accesos directos posteriores a rutas NHO:

Verificar contadores NHRP:

A continuación se explica paso a paso cómo se establece un túnel directo de radio a radio con la ayuda de depuraciones de uno de los radios.

- ICMP iniciado por Spoke 1:

Spoke1#ping vrf B 198.51.100.9 source 198.51.100.1 repeat 1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 198.51.100.9, timeout is 2 seconds:

Packet sent with a source address of 198.51.100.1

!

Success rate is 100 percent (1/1), round-trip min/avg/max = 111/111/111 ms

- El hub recibió ICMP e inició la redirección (indicación de tráfico) a ambos spokes:

*Feb 3 16:15:35.280: NHRP: Receive Traffic Indication via Tunnel1 vrf: B(0x4), packet size: 104

.

*Feb 3 16:15:35.280: (M) traffic code: redirect(0)

*Feb 3 16:15:35.280: src NBMA: 203.0.113.2

*Feb 3 16:15:35.280: src protocol: 192.0.2.1, dst protocol: 198.51.100.1

.

*Feb 3 16:15:35.281: NHRP-DETAIL: NHRP traffic indication for afn 1 received on interface Tunnel1 , for vrf: B(0x4) label: 0

- Ambos spokes activaron una solicitud de resolución que pasó a través del túnel 1:

*Feb 3 16:15:35.295: NHRP: Sending NHRP Resolution Request for dest: 198.51.100.9 to nexthop: 198.51.100.9 using our src: 192.0.2.130 vrf: B(0x4)

*Feb 3 16:15:35.295: NHRP: Attempting to send packet through interface Tunnel1 via DEST dst 198.51.100.9

*Feb 3 16:15:35.295: NHRP-DETAIL: First hop route lookup for 198.51.100.9 yielded 192.0.2.1, Tunnel1

*Feb 3 16:15:35.295: NHRP: Send Resolution Request via Tunnel1 vrf: B(0x4), packet size: 72

*Feb 3 16:15:35.295: src: 192.0.2.130, dst: 198.51.100.9

.

*Feb 3 16:15:35.296: src NBMA: 203.0.113.6

*Feb 3 16:15:35.296: src protocol: 192.0.2.130, dst protocol: 198.51.100.9

- Ambos radios recibieron una solicitud de resolución a través del túnel 1:

*Feb 3 16:15:35.392: NHRP: Receive Resolution Request via Tunnel1 vrf: B(0x4), packet size: 92

.

*Feb 3 16:15:35.392: src NBMA: 203.0.113.10

*Feb 3 16:15:35.392: src protocol: 192.0.2.129, dst protocol: 198.51.100.1

*Feb 3 16:15:35.392: (C-1) code: no error(0), flags: none

.

*Feb 3 16:15:35.392: NHRP-DETAIL: Resolution request for afn 1 received on interface Tunnel1 , for vrf: B(0x4) label: 0

- Ambos spokes realizaron route-lookup para sus redes locales 198.51.100.0/29/24 y 198.51.100.8/29:

*Feb 3 16:15:35.392: NHRP-DETAIL: Multipath IP route lookup for 198.51.100.1 in vrf: B(0x4) yielded Loopback1, pfx:198.51.100.0/29 (netid_in:1 if_in:Tunnel1)

*Feb 3 16:15:35.392: NHRP: Route lookup for destination 198.51.100.1 in vrf: B(0x4) yielded interface Loopback1, prefixlen 29

.

*Feb 3 16:15:35.392: NHRP: We are egress router. Process the NHRP Resolution Request.

.

*Feb 3 16:15:35.393: NHRP-DETAIL: Multipath IP route lookup for 198.51.100.1 in vrf: B(0x4) yielded Loopback1, pfx:198.51.100.0/29 (netid_in:1 if_in:Tunnel1)

*Feb 3 16:15:35.393: NHRP: nhrp_rtlookup for 198.51.100.1 in vrf: B(0x4) yielded interface Loopback1, prefixlen 29, label none(0)

*Feb 3 16:15:35.393: NHRP-DETAIL: netid_out 0, netid_in 1

*Feb 3 16:15:35.393: NHRP: We are egress router for target 198.51.100.1, recevied via Tunnel1 vrf: B(0x4)

- La respuesta de resolución se puso en cola y el establecimiento de IPsec se inició ya que ambos spokes ahora conocen las direcciones NBMA de los demás:

*Feb 3 16:15:35.393: NHRP: Checking for delayed event 192.0.2.129/198.51.100.1 on list (Tunnel1 vrf: B(0x4))

*Feb 3 16:15:35.393: NHRP: No delayed event node found.

*Feb 3 16:15:35.394: NHRP-DETAIL: Updated delayed event with ep src:203.0.113.6 dst:203.0.113.10 ivrf:B

*Feb 3 16:15:35.394: NHRP: Enqueued Delaying resolution request nbma src:203.0.113.6 nbma dst:203.0.113.10 reason:IPSEC-IFC: need to wait for IPsec SAs.

*Feb 3 16:15:35.394: NHRP: Interface: Tunnel1 configured with FlexVPN. Deferring cache creation for nhop 192.0.2.129

*Feb 3 16:15:35.406: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down

*Feb 3 16:15:35.456: NHRP: Virtual-Access1: Tunnel mode changed from

'Uninitialized tunnel mode' to 'GRE over point to point IPV4 tunnel mode'

*Feb 3 16:15:35.456: NHRP: Virtual-Access1: NHRP not enabled in delay_if_up

*Feb 3 16:15:35.511: NHRP: Registration with Tunnels Decap Module succeeded

*Feb 3 16:15:35.511: NHRP: Rejecting addr type 1

*Feb 3 16:15:35.511: NHRP: Adding all static maps to cache

*Feb 3 16:15:35.511: NHRP-DETAIL: Adding summary-prefix entry: nhrp router block not configured

*Feb 3 16:15:35.512: NHRP:

*Feb 3 16:15:35.512: Instructing NHRP to create Virtual-Access from Virtual template 1 for interface Virtual-Access1

*Feb 3 16:15:35.537: %SYS-5-CONFIG_P: Configured programmatically by process Crypto INT from console as console

*Feb 3 16:15:35.539: NHRP-CACHE: Virtual-Access1: Cache add for target 192.0.2.130/32 vrf: B(0x4) label none next-hop 192.0.2.130

*Feb 3 16:15:35.540: 203.0.113.6 (flags:0x20)

.

*Feb 3 16:15:35.548: NHRP: Updating delayed event with destination 203.0.113.10 on interfaceTunnel1 with the new interface Virtual-Access1

*Feb 3 16:15:35.788: NHRP:

*Feb 3 16:15:35.788: Fetched address from underlying IKEv2 for interfaceVirtual-Access1. Pre-NATed = 203.0.113.6, Post-NATed = UNKNOWN

*Feb 3 16:15:35.788: %DMVPN-5-CRYPTO_SS: Virtual-Access1: local address : 203.0.113.6 remote address : 203.0.113.10 socket is UP

- Durante el establecimiento de IPSEC y el proceso de creación de accesos directos NHRP, ambos spokes aprendieron e instalaron cada uno de los otros túneles de direcciones IP en su tabla de ruteo como ruta IPSEC y sondearon la disponibilidad del siguiente salto:

*Feb 3 16:15:35.788: NHRP: Processing delayed event on interface Tunnel1 with NBMA 203.0.113.10

.

*Feb 3 16:15:35.789: NHRP-CACHE: Virtual-Access1: Cache add for target 192.0.2.129/32 vrf: B(0x4) label none next-hop 192.0.2.129

*Feb 3 16:15:35.789: 203.0.113.10 (flags:0x2080)

*Feb 3 16:15:35.789: NHRP-RT: Adding route entry for 192.0.2.129/32 via 192.0.2.129, Virtual-Access1 vrf: B(0x4)) to RIB

*Feb 3 16:15:35.791: NHRP-RT: Route addition to RIB Successful

*Feb 3 16:15:35.791: NHRP-EVE: NHP-UP: 192.0.2.129, NBMA: 203.0.113.10

*Feb 3 16:15:35.791: %DMVPN-5-NHRP_NHP_UP: Virtual-Access1: Next Hop NHP : (Tunnel: 192.0.2.129 NBMA: 203.0.113.10) for (Tunnel: 192.0.2.130 NBMA: 203.0.113.6) is UP

*Feb 3 16:15:35.791: NHRP-CACHE:

*Feb 3 16:15:35.791: Next-hop not reachable for 192.0.2.129

*Feb 3 16:15:35.791: %NHRP-5-NHOP_UNREACHABLE: Nexthop address 192.0.2.129 for 192.0.2.129/32 is not routable

- Hasta la finalización de la instalación de acceso directo y NHO, spoke A realizó la búsqueda de salto siguiente de las direcciones IP de acceso virtual de spoke B y viceversa, pero la búsqueda de esperanza siguiente devolvió "cedió N/A" debido a que spoke A envió una indicación de error a spoke B confirmando que el salto siguiente es inalcanzable. La búsqueda en particular se puede referir como una búsqueda de múltiples rutas:

*Feb 3 16:15:35.791: NHRP-DETAIL: Multipath recursive nexthop lookup(if_in:, netid:1) for 192.0.2.129 in vrf: B(0x4) yielded N/A, Virtual-Access1

*Feb 3 16:15:35.791: NHRP: Sending error indication. Reason: 'Cache pak failure' LINE: 13798

*Feb 3 16:15:35.791: NHRP: Attempting to send packet through interface Virtual-Access1 via DEST dst 192.0.2.129

*Feb 3 16:15:35.791: NHRP-DETAIL: Multipath recursive nexthop lookup(if_in:, netid:1) for 192.0.2.129 in vrf: B(0x4) yielded 192.0.2.129, Virtual-Access1

*Feb 3 16:15:35.791: NHRP: Send Error Indication via Virtual-Access1 vrf: B(0x4), packet size: 132

*Feb 3 16:15:35.791: src: 192.0.2.130, dst: 192.0.2.129

.

*Feb 3 16:15:35.791: (M) error code: protocol address unreachable(6), offset: 0

*Feb 3 16:15:35.791: src NBMA: 203.0.113.6

*Feb 3 16:15:35.791: src protocol: 192.0.2.130, dst protocol: 192.0.2.129

- Una vez que la NHO entró en acción para el siguiente salto y se creó el acceso directo, ambos spokes enviaron solicitudes de resolución para cada una de sus redes nuevamente:

*Feb 3 16:15:35.813: NHRP: No need to delay processing of resolution event nbma src:203.0.113.6 nbma dst:203.0.113.10

*Feb 3 16:15:35.813: NHRP-CACHE: Virtual-Access1: Cache update for target 192.0.2.129/32 vrf: B(0x4) label none next-hop 192.0.2.129

*Feb 3 16:15:35.813: 203.0.113.10 (flags:0x2280)

*Feb 3 16:15:35.813: NHRP-RT: Adding route entry for 192.0.2.129/32 via 192.0.2.129, Virtual-Access1 vrf: B(0x4)) to RIB

*Feb 3 16:15:35.814: NHRP-RT: Route addition to RIB Successful

.

*Feb 3 16:15:35.841: NHRP-RT: Route entry 192.0.2.129/32 via 192.0.2.129 (Vi1) clobbered by distance

*Feb 3 16:15:35.847: NHRP-RT: Unable to stop route watch for 192.0.2.129/32 interface Virtual-Access1 . No handle

*Feb 3 16:15:35.847: NHRP-RT: Adding route entry for 192.0.2.129/32 via 192.0.2.129, Virtual-Access1 vrf: B(0x4)) to RIB

*Feb 3 16:15:35.847: NHRP-RT: Route addition failed (admin-distance)

*Feb 3 16:15:35.847: NHRP-RT: nexthop-override added to RIB

.

*Feb 3 16:15:37.167: NHRP: Sending NHRP Resolution Request for dest: 198.51.100.9 to nexthop: 198.51.100.9 using our src: 192.0.2.130 vrf: B(0x4)

*Feb 3 16:15:37.167: NHRP: Attempting to send packet through interface Tunnel1 via DEST dst 198.51.100.9

*Feb 3 16:15:37.167: NHRP-DETAIL: First hop route lookup for 198.51.100.9 yielded 192.0.2.1, Tunnel1

*Feb 3 16:15:37.167: NHRP: Send Resolution Request via Tunnel1 vrf: B(0x4), packet size: 72

*Feb 3 16:15:37.167: src: 192.0.2.130, dst: 198.51.100.9

.

*Feb 3 16:15:37.167: src NBMA: 203.0.113.6

*Feb 3 16:15:37.167: src protocol: 192.0.2.130, dst protocol: 198.51.100.9

- Una vez que ambos radios recibieron solicitudes de resolución para cada una de sus redes, NHO reemplazó la ruta EIGRP a través del túnel (HUB) con acceso virtual:

*Feb 3 16:30:57.768: NHRP-CACHE: Virtual-Access1: Cache add for target 198.51.100.8/29 vrf: B(0x4) label none next-hop 192.0.2.129

*Feb 3 16:30:57.768: 203.0.113.10 (flags:0x1000)

*Feb 3 16:30:57.768: NHRP-RT: Adding route entry for 198.51.100.8/29 via 192.0.2.129, Virtual-Access1 vrf: B(0x4)) to RIB

*Feb 3 16:30:57.769: NHRP-RT: Route addition failed (admin-distance)

*Feb 3 16:30:57.769: NHRP-RT: nexthop-override added to RIB

*Feb 3 16:30:57.769: NHRP-EVE: NHP-UP: 192.0.2.129, NBMA: 203.0.113.10

*Feb 3 16:30:57.769: %DMVPN-5-NHRP_NHP_UP: Virtual-Access1: Next Hop NHP : (Tunnel: 192.0.2.129 NBMA: 203.0.113.10) for (Tunnel: 192.0.2.130 NBMA: 203.0.113.6) is UP

*Feb 3 16:30:57.769: NHRP-CACHE: Deleting incomplete entry for 198.51.100.9/32 interface Tunnel1 vrf: B(0x4)

*Feb 3 16:30:57.769: NHRP-EVE: NHP-DOWN: 198.51.100.9, NBMA: 198.51.100.9

- Después, ambos spokes envían una respuesta de resolución a través de la interfaz de acceso virtual:

*Feb 3 16:30:57.436: NHRP-CACHE: Virtual-Access1: Internal Cache add for target 198.51.100.0/29 vrf: B(0x4) label none next-hop 192.0.2.130

*Feb 3 16:30:57.436: 203.0.113.6 (flags:0x20)

*Feb 3 16:30:57.436: NHRP: Attempting to send packet through interface Virtual-Access1 via DEST dst 192.0.2.129

*Feb 3 16:30:57.436: NHRP-DETAIL: Multipath recursive nexthop lookup(if_in:, netid:1) for 192.0.2.129 in vrf: B(0x4) yielded 192.0.2.129, Virtual-Access1

*Feb 3 16:30:57.436: NHRP: Send Resolution Reply via Virtual-Access1 vrf: B(0x4), packet size: 120

*Feb 3 16:30:57.436: src: 192.0.2.130, dst: 192.0.2.129

.

*Feb 3 16:30:57.437: src NBMA: 203.0.113.10

*Feb 3 16:30:57.437: src protocol: 192.0.2.129, dst protocol: 198.51.100.1

.

*Feb 3 16:30:57.437: client NBMA: 203.0.113.6

*Feb 3 16:30:57.437: client protocol: 192.0.2.130

*Feb 3 16:30:57.437: NHRP: 144 bytes out Virtual-Access1

Ejemplo 2: Utilización de rutas instaladas de NHRP para la comunicación de radio a radio

Servidor FlexVPN

Verifique la topología EIGRP para la ruta de resumen introducida:

Clientes FlexVPN

Verifique la presencia de la ruta de resumen:

Intente establecer un túnel de radio a radio iniciando el tráfico:

Vuelva a verificar:

Hay un cambio muy pequeño en el resultado de los debugs para la instalación de red de spokes donde muestra la instalación exitosa de la ruta en lugar de la falla de RIB y la adición de NHO:

*Feb 3 16:43:38.957: NHRP-CACHE: Virtual-Access1: Cache add for target 198.51.100.8/29 vrf: B(0x4) label none next-hop 192.0.2.131

*Feb 3 16:43:38.957: 203.0.113.10 (flags:0x1000)

*Feb 3 16:43:38.957: NHRP-RT: Adding route entry for 198.51.100.8/29 via 192.0.2.131, Virtual-Access1 vrf: B(0x4)) to RIB

*Feb 3 16:43:38.957: NHRP-RT: Route addition to RIB Successful

*Feb 3 16:43:38.957: NHRP-EVE: NHP-UP: 192.0.2.131, NBMA: 203.0.113.10

Información Relacionada

- Configuración de FlexVPN Spoke a Spoke

- Ejemplo de Configuración de Spoke FlexVPN en el Diseño de Hub Redundante con Bloque de Cliente FlexVPN