Implemente el diseño de varias subredes DMVPN de fase 3

Introducción

Este documento describe las consideraciones de ruteo en un diseño de multisubred DMVPN fase 3 para garantizar que los túneles de radio a radio directo se construyan correctamente. 

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Conocimientos básicos de Dynamic Multipoint VPN (DMVPN)
• Conocimiento básico del protocolo de resolución de próximo salto (NHRP)

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

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.

Antecedentes

Las implementaciones de fase 2 y fase 3 de DMVPN permiten que un dispositivo spoke cree un túnel de spoke a spoke y no necesite pasar a través del hub. Sin embargo, la fase 3 de DMVPN proporciona una escalabilidad mucho mejor gracias al mecanismo de redirección NHRP para que el spoke detecte dinámicamente las redes remotas a través de NHRP y, posteriormente, instale rutas NHRP (H) en la tabla de routing. Esto elimina la restricción de la fase 2 de requerir que cada radio tenga prefijos de red específicos para las redes remotas en su tabla de ruteo. Con la fase 3, la respuesta de resolución NHRP del radio de destino (punto de salida NBMA) debe pasar por el túnel directo de radio a radio. Sin embargo, se debe prestar especial atención a un diseño de fase 3 de subred múltiple para que el túnel de radio a radio se pueda construir correctamente. Este artículo trata estos requisitos en detalle.

Problema

La fase 3 de DMVPN se puede implementar en una superposición de subred única o en una superposición de subred múltiple. En una topología de superposición de subred única, el hub y todas las direcciones de túnel del router radial se asignan desde una única subred IP lógica; mientras que en un diseño de subred múltiple, el túnel radial a radial debe crearse para radios con sus direcciones de túnel en diferentes subredes IP. Este último es un escenario común utilizado en un diseño DMVPN jerárquico que se muestra en la imagen siguiente.

Topología de subred múltiple DMVPN Fase 3

Detalles del problema

Con DMVPN fase 3, se entiende comúnmente que cuando se recibe la solicitud de resolución NHRP, el spoke de destino inicia el túnel IPsec al spoke de origen y, posteriormente, envía la respuesta de resolución a través de ese túnel. Sin embargo, esto es sólo el caso con una sola superposición de subred. Cuando las interfaces de túnel de los radios están en diferentes subredes lógicas IP, los paquetes de control NHRP pueden atravesar a través de la trayectoria spoke-hub-spoke en lugar de con el túnel spoke a spoke directo. Esta es la secuencia de eventos cuando Spoke1 envía una Solicitud de resolución a Spoke2 después de recibir una redirección NHRP desde Hub1:

1. Spoke2 recibe la solicitud de resolución
   
   

   *Feb  7 20:57:22.272: NHRP: Receive Resolution Request via Tunnel0 vrf global(0x0), packet size: 144
   *Feb  7 20:57:22.272:  (F) afn: AF_IP(1), type: IP(800), hop: 252, ver: 1
   *Feb  7 20:57:22.272:      shtl: 4(NSAP), sstl: 0(NSAP)
   *Feb  7 20:57:22.272:      pktsz: 144 extoff: 52
   *Feb  7 20:57:22.272:  (M) flags: "router auth src-stable nat ", reqid: 5 
   *Feb  7 20:57:22.272:      src NBMA: 172.16.1.1
   *Feb  7 20:57:22.272:      src protocol: 10.0.1.101, dst protocol: 192.168.101.1
   *Feb  7 20:57:22.272:  (C-1) code: no error(0)
   *Feb  7 20:57:22.272:        prefix: 32, mtu: 17912, hd_time: 900
   *Feb  7 20:57:22.272:        addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 255
   

2. Spoke2 agrega una entrada de caché NHRP implícita para 10.0.1.101 indagando el paquete de solicitud de resolución.
3. Spoke2 agrega una adyacencia para 10.0.1.101 para Tunnel0 con la dirección NBMA de Spoke1.
4. Spoke2 responde con una respuesta de resolución. Observe que en este punto, la ruta para la dirección del túnel radial solicitante apunta al Hub2:
   
   

   Spoke2#show ip route 10.0.1.101
   Routing entry for 10.0.1.0/24
     Known via "eigrp 1", distance 90, metric 3609600, type internal
     Redistributing via eigrp 1
     Last update from 10.0.2.1 on Tunnel0, 00:17:44 ago
     Routing Descriptor Blocks:
     * 10.0.2.1, from 10.0.2.1, 00:17:44 ago, via Tunnel0
         Route metric is 3609600, traffic share count is 1
         Total delay is 41000 microseconds, minimum bandwidth is 1000 Kbit
         Reliability 255/255, minimum MTU 1400 bytes
         Loading 1/255, Hops 3
   Spoke2#
   Spoke2#
   Spoke2#show ip cef 10.0.1.101
   10.0.1.0/24
     nexthop 10.0.2.1 Tunnel0
   

   Dado que el paquete de control NHRP se reenvía a lo largo del trayecto ruteado, se envía al Hub2 en lugar del túnel spoke to spoke recién creado al Spoke1:
   
   

   *Feb  7 20:57:22.360: NHRP: Send Resolution Reply via Tunnel0 vrf global(0x0), packet size: 172
   *Feb  7 20:57:22.360:  src: 10.0.2.101, dst: 10.0.1.101
   *Feb  7 20:57:22.360:  (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
   *Feb  7 20:57:22.360:      shtl: 4(NSAP), sstl: 0(NSAP)
   *Feb  7 20:57:22.360:      pktsz: 172 extoff: 60
   *Feb  7 20:57:22.360:  (M) flags: "router auth dst-stable unique src-stable nat ", reqid: 5 
   *Feb  7 20:57:22.360:      src NBMA: 172.16.1.1
   *Feb  7 20:57:22.360:      src protocol: 10.0.1.101, dst protocol: 192.168.101.1
   *Feb  7 20:57:22.360:  (C-1) code: no error(0)
   *Feb  7 20:57:22.360:        prefix: 24, mtu: 17912, hd_time: 900
   *Feb  7 20:57:22.360:        addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 255
   *Feb  7 20:57:22.360:        client NBMA: 172.16.2.1
   *Feb  7 20:57:22.360:        client protocol: 10.0.2.101
   *Feb  7 20:57:22.360: NHRP: Encapsulation succeeded.  Sending NHRP Control Packet  NBMA Address: 172.17.0.5

En teoría, durante el tiempo que todos los concentradores intermedios puedan rutear el paquete de control NHRP de vuelta al túnel de Spoke1, entonces todo debe seguir funcionando. Pero no siempre es así necesariamente. Si la respuesta de resolución no se puede reenviar de nuevo a Spoke1, no se puede crear el túnel de radio a radio directo. 

Con una sola superposición de subred, esto no es un problema porque cada radio tiene una ruta conectada directamente a la red del túnel. Esto da como resultado una búsqueda de adyacencia para la dirección de túnel radial solicitante antes de que se envíe de vuelta la respuesta de resolución. En una red superpuesta de múltiples subredes, dado que las direcciones de túnel de los spokes no están en la misma subred IP, no se garantiza que el paquete de respuesta de resolución se envíe a través del túnel de spoke directo a spoke.

Solución

Para un diseño de fase 3 de DMVPN con múltiples subredes, se recomienda que un spoke tenga una entrada de ruteo que señale la interfaz de túnel para cualquier subred de túnel de spoke remoto a la que necesite construir un túnel de spoke a spoke directo. Por ejemplo:

Spoke2#show run | in ip route
ip route 10.0.101.0 255.255.255.0 Tunnel0

Esto permite que el spoke intente resolver la adyacencia para la dirección del túnel spoke que solicita y, posteriormente, envíe la respuesta de resolución por el túnel spoke a spoke. 

Alternativamente, la respuesta de resolución puede atravesar los túneles spoke-hub-spoke. En tal caso, todos los concentradores intermedios deben tener una ruta a la subred del túnel radial solicitante para garantizar que los paquetes de control NHRP se puedan entregar de extremo a extremo.

Nota: Se abrió una mejora de bug para explorar opciones para que la respuesta de resolución se enviara a través del túnel directo incluso sin una ruta estática explícita. Cisco bug ID CSCvo02022 - Mejora: NHRP debe enviar la respuesta de resolución sobre el túnel spoke a spoke para la DMVPN de subred múltiple.

Nota: Solo los clientes registrados de Cisco pueden acceder a la información y las herramientas internas de errores de Cisco.

Información Relacionada

• Asistencia técnica y descargas de Cisco