Dynamic Multipoint VPN (DMVPN)
Agenda
Los puntos explicados en el siguiente documento serán:
- Configuración básica de DMVPN
- DMVPN – EIGRP- FASES I – II – III
- Redundancia DMVPN (Dual-Hub)
- Cifrado con IPsec
- Comandos de Verificación
- Recomendaciones generales
Introducción
Para industrias como las entidades bancarias, empresas petroleras, compañías de seguros, entre muchas otras, que cuentan con un gran número de localidades (Sites) remotas que requieren estar conectadas con la oficina principal (Headquarter), la tecnología Dynamic Multipoint VPN (DMVPN) les proporciona la capacidad de establecer estas conexiones a través de Internet creando una red de túneles VPN entre las oficinas remotas y la sede principal, así como también, creando túneles VPN de manera dinámica cuando se requiera que dos o más localidades remotas se comuniquen de manera directa.
Esta tecnología permite también establecer enlaces de respaldo (backup) a través de Internet para las comunicaciones WAN de empresas que cuentan con infraestructura propia (ATM, Fibra óptica, etc.) para comunicar su sede principal y sus sedes remotas.
Ventajas de DMVPN
Algunas de las principales ventajas que ofrece el uso de DMVPN son:
- Elimina los costos asociados a los enlaces WAN rentados a Proveedores de Servicio (ISP) entre los que encontrábamos muy comúnmente enlaces Frame Relay.
- Reduce la complejidad de la configuración: Pensemos en una entidad bancaria que cuenta con 50 sucursales en todo el país que deben conectarse con la oficina principal. Haciendo uso de otras tecnologías de túnel point-to-point deberíamos crear 50 interfaces en el Router principal (Hub) donde cada interfaz requiere al menos siete líneas de de código para configurarla; estaríamos hablando de al menos 350 líneas de código solo en este Router Hub para esta configuración. Cada vez que exista el requerimiento de anexar una nueva oficina remota tendríamos que crear una nueva interfaz túnel en el Router Hub. Con DMVPN solo se configuraría una interfaz túnel con unas 15 líneas de código, la cual no cambia en caso de tener que adicionar una nueva oficina remota en la topología.
- Permite el uso de protocolos de enrutamiento (EIGRP, OSFP, BGP)
- Permite el uso de QoS y IP Multicast.
- Permite configurar IPSec para proporcionar cifrado y confidencialidad de los datos.
- Permite diseñar una solución robusta y confiable adicionando un segundo Router (Hub) en la topología (Dual-Hub).
- Reduce la latencia y el consumo de ancho de banda al permitir conexiones directas entre las localidades remotas sin pasar necesariamente por la sede principal.
- Permite anexar localidades remotas (sites) sin realizar ningún tipo de cambio en la configuración del Router Hub.
Tomando en cuenta que DMVPN no es un protocolo sino un diseño que integra varias tecnologías, veremos a continuación cuales son las principales:
1.- Multipoint GRE (mGRE):
2.- Next-Hop Resolution Protocol (NHRP)
3.- Protocolos de enrutamiento dinámico (EIGRP, OSPF, BGP)
4.- Cifrado de datos con IPsec dinámico.
5.- Cisco Express Forwarding
Multipoint GRE (Mgre): Generic Routing Encapsulation (GRE) es un protocolo para la configuración de túneles VPN punto a punto que pueden encapsular una gran variedad de protocolos de capa 3. mGRE nos permite configurar túneles VPN punto-multipunto (Hub & Spokes).
Next Hop Resolution Protocol (NHRP): De manera muy general, el protocolo NHRP (RFC 2332) se encarga de crear una base de datos donde se mapea o asocia la dirección IP asignada a la interfaz túnel de cada localidad (dirección IP privada) con la dirección IP asignada a la interfaz física que conecta cada uno de los Routers en cada localidad a la red Non-Broadcast Multi-Access (dirección IP pública).
Este mapeo o asociación puede configurarse de manera estática o de manera dinámica. El protocolo NHRP para su funcionamiento define dentro de la topología un rol de servidor (Next Hop Server - NHS) y un rol de cliente (Next Hop Client – NHC).
Internet Protocol security (IPsec): Configurando este protocolo se cifra la data que es transmitida a través de mGRE para proveer confidencialidad e integridad de la misma.
Configurando DMVPN
Comenzaremos mostrando la configuración básica para la topología de la siguiente figura, donde R1 será el (Next Hop Server - NHS) y R2, R3 Y R4 serán (Next Hop Client – NHC).
Configuramos R1 (Hub)
- ip nhrp network-id 1 : Identifica la red DMVPN, es un valor que tiene significado a nivel local solamente, es recomendable tener el mismo nhrp network-id en todos los Routers.
- tunnel mode gre multipoint : Designa el túnel como un túnel GRE multipunto (mGRE). Se observa la ausencia del comando (tunnel destination <ip address>) que es obligatorio al establecer un túnel GRE punto a punto
Configuramos R2, R3 & R4 (Spokes)
- ip nhrp map 192.168.1.1 190.1.1.1 : Hace la asociación o mapeo de la dirección IP privada o dirección IP de la interfaz túnel (192.168.1.1) con la dirección IP NBMA o dirección IP del ISP (190.1.1.1).
- ip nhrp nhs 192.168.1.1: Indica al Router Spoke donde enviar la solicitud de registro al Router Hub, es decir, indica al Router Spoke quien es el Next Hop Server – NHS.
La configuración que se muestra para R2 es la misma que se aplica en cada uno de los Routers Spokes (R3, R3,…Rn) teniendo presente que solo cambia la dirección IP de la interfaz túnel y la dirección IP de origen (tunnel source).
- tunnel source Ethernet0/0: Cuando el ISP no proporciona una dirección IP NBMA estática se debe establecer la relación de la interfaz física (en este caso Ethernet0/0) con la interface origen del túnel (tunnel source). De esta manera cuando esta dirección IP cambie el Router podrá actualizar la información en el NHS con la nueva dirección IP NBMA.
DMVPN – EIGRP – FASES I – II – III
Generalmente escuchamos hablar de DMVPN descrito en diferentes fases, en el siguiente segmento utilizaremos el protocolo EIGRP para explicar las diferencias en cada de una estas fases.
FASE I
En esta Fase, todo el tráfico entre un Router Spoke y otro Router Spoke debe pasar por el Router Hub. La configuración en el Router Hub es un poco menos compleja y tiene como ventaja que podemos controlar cual tráfico debería ir de un Spoke a otro Spoke.
Configuramos R1 (Hub)
En esta configuración es importante reconocer los siguientes comandos que se aplican en la interfaz túnel 1del Router que actúa como server (NHS):
- no ip split-horizon eigrp 1 : Todas las rutas que son aprendidas por los Routers Spokes (R2, R3, R4) vía EIGRP desde el Router Hub R1 tienen como origen la interfaz túnel de este Router (R1). Si obviamos este comando los Routers Spokes solamente aprenderán vía EIGRP las rutas de R1:
R2#sh ip route eigrp
…
Gateway of last resort is 190.1.2.5 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
D 10.1.1.0/24 [90/27008000] via 192.168.1.1, 00:21:07, Tunnel1
Al habilitar este comando tendríamos entonces:
R2#sh ip route eigrp
…
Gateway of last resort is 190.1.2.5 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D 10.1.1.0/24 [90/27008000] via 192.168.1.1, 00:02:06, Tunnel1
D 10.1.3.0/24 [90/28288000] via 192.168.1.1, 00:00:13, Tunnel1
D 10.1.4.0/24 [90/28288000] via 192.168.1.1, 00:00:13, Tunnel1
Es importante recordar que la funcionalidad de split-horizon está habilitada por defecto en EIGRP, y la misma previene que las rutas que son aprendidas por una interfaz sean propagadas por esa misma interfaz, en consecuencia, mientras esté habilitada esta función, evitará que las rutas de los Routers Spokes sean propagadas entre ellos.
- ip nhrp map multicast dynamic : Este comando habilita al Router para que soporte el trafico de IP Muliticast, lo que permite a su vez soportar protocolos de enrutamiento dinámico sobre DMVPN. Por ejemplo permite el tráfico a la dirección IP multicast usada por EIGRP (224.0.0.10).
Configuramos R2, R3 & R4 (Spokes)
- ip nhrp map multicast 190.1.1.1 : Este comando indica al Router Spoke la dirección IP NBMA donde enviar/recibir paquetes broadcast y multicast.
FASE II
En esta fase deseamos que el tráfico de un Router Spoke desde/hacia otro Router Spoke sea transmitido directamente sin necesidad de pasar por el Router Hub. Para esto, es necesario que el Router Hub advierta las rutas aprendidas indicando el próximo salto al Router Spoke que generó originalmente esta ruta.
En la Fase I el Router Hub era el próximo salto (Next-hop) para todas las rutas EIGRP en la tabla de enrutamiento de los Router Spokes:
R2#sh ip route eigrp
Gateway of last resort is 190.1.2.5 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D 10.1.1.0/24 [90/27008000] via 192.168.1.1, 00:02:06, Tunnel1
D 10.1.3.0/24 [90/28288000] via 192.168.1.1, 00:00:13, Tunnel1
D 10.1.4.0/24 [90/28288000] via 192.168.1.1, 00:00:13, Tunnel1
Para lograr esto cambiaremos el comportamiento del protocolo de enrutamiento EIGRP como se muestra a continuación haciendo uso del siguiente comando: no ip next-hop-self eigrp 1 el cual será aplicado en el modo de configuración de la interfaz túnel del Router Hub:
Ahora verificamos la tabla de enrutamiento en cualquier Router Spoke y tenemos lo siguiente:
R2#sh ip route eigrp
…
Gateway of last resort is 190.1.2.5 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D 10.1.1.0/24 [90/27008000] via 192.168.1.1, 00:00:11, Tunnel1
D 10.1.3.0/24 [90/28288000] via 192.168.1.3, 00:00:11, Tunnel1
D 10.1.4.0/24 [90/28288000] via 192.168.1.4, 00:00:11, Tunnel1
R3#sh ip route eigrp
…
Gateway of last resort is 190.1.3.5 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D 10.1.1.0/24 [90/27008000] via 192.168.1.1, 00:05:07, Tunnel1
D 10.1.2.0/24 [90/28288000] via 192.168.1.2, 00:05:07, Tunnel1
D 10.1.4.0/24 [90/28288000] via 192.168.1.4, 00:05:07, Tunnel1
FASE III
En esta Fase al igual que en la Fase II, deseamos que el intercambio de tráfico entre Routers Spokes se haga directamente sin necesidad de pasar por el Router Hub, no obstante, en la Fase III no se modificará el comportamiento del protocolo de enrutamiento EIGRP, sino que nos serviremos del Protocolo NHRP como se muestra a continuación:
- ip nhrp redirect : De manera resumida un mensaje ip nhrp redirect indica que la ruta actual al destino no es la mejor o la óptima, por lo que el receptor del mensaje (Router Spoke) debería encontrar una mejor ruta para ese destino.
- ip nhrp shoortcut : Indica al Router que acepte los mensajes ip nhrp redirect y a su vez reescribe la nueva entrada CEF. (Cisco Express Forwarding entry).
Si observamos la tabla de enrutamiento en un Router Spoke notaremos que el próximo salto para todas las rutas será el Router Hub, no obstante, se creara un NHRP Cache que le indica a los Routers Hub una mejor ruta para cada destino. Veamos en el siguiente ejemplo:
R2#sh ip route eigrp
Gateway of last resort is 190.1.2.5 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D 10.1.1.0/24 [90/27008000] via 192.168.1.1, 01:03:01, Tunnel1
D 10.1.3.0/24 [90/28288000] via 192.168.1.1, 01:03:01, Tunnel1
D 10.1.4.0/24 [90/28288000] via 192.168.1.1, 01:03:01, Tunnel1
Ahora veremos la siguiente información:
R2#sh ip nhrp
10.1.3.0/24 via 192.168.1.3
Tunnel1 created 00:00:01, expire 01:59:58
Type: dynamic, Flags: router rib nho
NBMA address: 190.1.3.3
10.1.4.0/24 via 192.168.1.4
Tunnel1 created 00:00:12, expire 01:59:47
Type: dynamic, Flags: router rib nho
NBMA address: 190.1.4.4
….
Si hacemos un traceroute desde el R2 (Spoke) hacia R4(Spoke) veremos que R2 a pesar de tener en la tabla de enrutamiento como próximo salto para la ruta 10.1.4.0/24 a R1(Hub) la comunicación se establece de manera directa.
R2#traceroute 10.1.4.4
Type escape sequence to abort.
Tracing the route to 10.1.4.4
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.1.4 0 msec 1 msec 0 msec
Además de disminuir la latencia, otra de las ventajas que puede ofrecer la Fase III es que se puede sumarizar, cosa que no podemos hacer en la Fase II.
Si observamos la tabla de enrutamiento en el R2 – R3 o R4 (Spokes):
R2#sh ip route eigrp
…
10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
D 10.0.0.0/8 [90/27008000] via 192.168.1.1, 00:00:52, Tunnel1
Si hacemos un traceroute desde el R2 (Spoke) hacia R4(Spoke) veremos que la comunicación directa entre los Router Spokes se mantiene sin pasar por el Router Hub.
R2#traceroute 10.1.4.4
Type escape sequence to abort.
Tracing the route to 10.1.4.4
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.1.4 2 msec 6 msec 5 msec
Redundancia (Dual-Hub DMVPN)
A fin de brindar mayor disponibilidad, confiabilidad y robustez al diseño de DMVPN, podemos integrar un segundo Hub a la arquitectura como se muestra a continuación:
Utilizaremos la misma topología pero esta vez tanto R1 como R4 serán Next Hop Server - NHS y R2, R3 serán Next Hop Client – NHC.
Configuramos R4 (Hub II) :
En R1 agregamos los siguientes comandos:
En los R2 & R3 (Spokes) configuramos el nuevo NHS:
Verificamos:
R2#sh ip nhrp nhs
Legend: E=Expecting replies, R=Responding, W=Waiting
Tunnel1:
192.168.1.1 RE priority = 0 cluster = 0
190.168.1.4 E priority = 0 cluster = 0
Cifrado con IPsec
En un túnel GRE no se cifra o asegura la información que viaja a través de él, para esto utilizaremos IPsec a fin de garantizar la integridad y la confidencialidad de la data aplicando la siguiente configuración en cada uno de los Routers.
Comandos de verificación para todas las fases
A continuación una lista de comandos que pueden ser utilizados para verificar la configuración en todas las fases de DMVPN.
Recomendaciones para un óptimo funcionamiento:
Al momento de configurar DMVPN en un ambiente real existen algunas recomendaciones que deberían ser tomadas en consideración:
Utilizado para autenticar las actualizaciones y consultas de NHRP, se configura en el modo de configuración de la interfaz túnel.
R2(config)# interface Tunnel1
ip nhrp authentication <contraseña> :
A fin de evitar problemas de fragmentación de paquetes podemos utilizar los siguientes comandos:
R2(config)# interface Tunnel1
ip mtu 1400
ip tcp adjust-mss 1360
Para cambiar el intervalo de tiempo en segundos en el que un Router NHC envían solicitudes de registro a los Router NHS:
R1(config)# interface Tunnel1
ip nhrp registration timeout 100