Túnel Dynamic Multipoint VPN (DMVPN) Fase II

La fase II consiste en establecer el modelo de túneles pero de forma dinámicos tanto en el Hub como en los Spoke, el esquema de interconexión es el siguiente:

Los estados de DMVPN son:

R1:

Túnel Dynamic Multipoint VPN (DMVPN)

Una de las principales preocupaciones y desafíos que pertenecen a la implementación de VPN sitio a sitio usando la topología Hub & Spoke con un gran número de sitios es la escalabilidad. Con el hecho de que la implementación de muchos túneles GRE sobre IPSec con un protocolo de ruteo dinámico pueda escalar bien. Sin embargo el número de listas de acceso y de túneles punto a punto será difícil de administrar cuando hay un gran número de sitios remotos usando completa o parcialmente la topología mallada. Además de los problemas de escalabilidad, la implementación de un gran número de VPN sitio a sitio usando la topología Hub & Spoke con un gran número de comunicaciones spoke to spoke, dará lugar a una sobrecarga alta en el CPU y a la memoria del hub router porque todo el tráfico spoke to spoke debe transitar por el hub

En este modelo el tráfico de Spoke a Spoke no necesariamente debe pasar por el Spoke para ello Next Hop Resolution Protocol NBMA (NHRP) definido en el RFC 2332 es usado para el registro de dirección de los spokes en las implementaciones DMVPN. Con DMVPN cualquier flujo de tráfico entre los routers se envía vía un túnel GRE, pero la característica interesante que distingue a DMVP entre otras implementaciones de VPN es que este túnel GRE es un túnel multipunto GRE. Es decir el hub y los spokes requerirán un túnel cada uno para alcanzar una conectividad DMVPN completamente mallada.

De la información dada es obvio que DMVPN puede proporcionar las siguientes ventajas:

• Simplificar la porción de la configuración del hub router eliminando la necesidad de configurar crypto maps, las interfaces de túnel, y ACL de cada spoke.

• Los spoke routers  pueden obtener sus direcciones IP dinámicamente, por ejemplo un router de borde de Internet conectado con un enlace ADSL puede obtener su IP automáticamente del ISP y entonces el túnel se registrará con el hub usando NHRP.

Basado en el esquema de Hub & Spoke el siguiente tipo de GRE utiliza un NHS como HUB el cual establece un túnel dinámico DMVPN de forma dinámica con los SPOKE utilizando el protocolo NHRP, este ejemplo es básico y no ocupa seguridad, más adelante voy a subir el ejemplo con seguridad.


Para este ejemplo el esquema de interconexión es el mismo que en el ejempo Túnel GRE VPN Punto-a-Punto pero esta vez consideramos que podemos tener más sitios remotos los cuales serán agregados de manera dinámica.

Los túneles se establecen de manera dinámica en el Hub y de forma estática en los Spoke:

Túnel GRE VPN Punto-a-Punto

La popularidad de las VPNs ha crecido durante los últimos años derivado del costo beneficio que puede proporcionar a las empresas el utilizar la infraestructura de Internet para interconectar sus redes y a flexibilidad que esto conlleva.

La implementación tradicional de GRE involucra la configuración de tunel punto a punto entre dos sitios, este tipo de solución funciona bien cuando son pocos sitios a interconectar y por consiguiente se tiene un bajo número de tuneles, el esquema de interconexión clasico de esta solución se muestra a continuación:

OSFP Virtual LInk

Tenemos a continuación un problema típico de enrutamiento OSPF inter Area donde se hizo un mal diseño y el Area 0 no esta configurada adyacente al resto por lo cual se aísla el area que no hace el intercambio de paquetes directamente conectada al area de intercambio.

El esquema de interconexión es el siguiente.

EIGRP sumarización de rutas

EIGRP con sumarización de rutas.

El esquema de interconexión es el siguiente:


 Las rutas sin sumarización en R1 se muestran a continuación:

 

OSPF Stub area

Un ejemplo simple de área stub se muestra en el siguiente ejemplo, el hecho de hacer un área stub significa que no recibe rutas inter-area o externas excepto la ruta por defecto.

El escenario es de 3 Routers interconectados entre si en Seattle, Chicago y New York respectivamente, el esquema de configuración debe cumplir con los siguientes requisitos:

• El identificador del proceso de OSPF debe ser el mismo
• El protocolo de ruteo no debe ser habilitado en la configuración de cada interface.
• El área OSPF entre Seattle y Chicago no debe permitir rutas internas o externas.
• Todo el sistema debe estar interconectado mediante el mismo protocolo. 
• El direccionamiento de las interfaces ha sido previamente asignado.

Partiendo de estas premisas y del direccionamiento establecido el esquema de interconexión es el siguiente:

NAT-PT para IPv6

Network Address Translation (NAT)—Protocol Translation (PT).

NAT64 es un mecanismo que permite que hosts que solamente tienen conectividad IPv6 puedan comunicarse con hosts que solamente tienen conectividad IPv4.

Para lograr este objetivo se debe contar con un equipo de red que sea capaz de realizar una traslación de protocolos IPv4 <-> IPv6. Entre otras cosas, este mapeo debe incluir el mapeo de las direcciones de capa de red de uno y otro protocolo.

Del lado de la red solo-IPv6, las direcciones IPv4 se mapean dentro de un prefijo IPv6 el cual debe tener suficientes bits de host para mapear todo el espacio IPv4. Normalmente se utiliza el prefijo 64::ff9b/96.

Para que los hosts solo-IPv6 puedan comunicarse con los hosts solo IPv4 hace falta un componente adicional que es una traducción a nivel de DNS. Este es el rol del DNS64, el cual se encarga de recibir las consultas DNS de los hosts solo-IPv6 y modificar las respuestas de tal manera de incluir registros AAAA que mapean las direcciones IPv4 dentro del prefijo NAT64.

Ambos procesos están definidos en [RFC6146] y [RFC6147].

El diagrama general es: