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:

OSPF + EIGRP redistribuir rutas

Vamos a ver un caso muy particular para redistribución de rutas, en este ejemplo partimos del supuesto que tenemos un Router R4 en un sitio remoto que tiene configurado OSPF, tenemos en otro extremo Routers R1, R2 y R3 con enrutamiento EIGRP configurado entre ellos, se habilitan 2 interfaces en R4 para interconectar con el AS EIGRP entre R3 y R2 por cuestiones de contar con redundancia y requerimos lo siguiente:

1. Habilitar enrutamiento entre los Routers sin eliminar las configuraciones previas, podemos agregar y cambiar valores por defecto.
2. Permitir que la ruta por defecto de todos los Routers sea por medio de R4
3. Establecer como ruta preferida para comunicar ambos sistemas mediante R3 y R4 quedando como ruta secundaria R2 y R4.

El esquema de interconexión y direccionamiento utilizado es el siguiente.

Funcion y ejemplo del BFD

El Bidirectional Forwarding Detection (BFD) es un protocolo que provee un mecanismo de keep alive  de detección que puede ser utilizado por otros componentes de de red para los cuales el mecanismo es muy lento y/o inapropiado o inexistente, tal puede ser el caso de los protocolos de rute IGP tipo OSPF o EGP tipo BGP.

Usando BFD y OSPF el escenario propuesto para esta práctica es el siguiente:

Con este esquema el DR es R2 y la mejor ruta elegida hacia R4 es a traves de R1, cuando el enlace entre R1 y R4 falla el tiempo de convergencia es menor que sin el uso de BFD.

La configuración es muy simple, basta con habilitar en todos los router BFD dentro de la sección para OSPF

VRF lite

El uso de VRF es la capacidad que nos provee un router para dividir a este router y su tabla de enrutamiento en múltiples; de ahí su nombre VRF (Virtual Routing and Forwarding).

Una aplicación para esto podría ser en el caso de un proveedor de servicios (ISP) con múltiples clientes.

Es de esperar que los diferentes clientes no deben de ser accesados por otros clientes, ni deben compartir el medio.

VRF Lite nos permitiría esto ya que cada VRF tendrá su propia tabla de enrutamiento y los clientes en diferentes VRF's no podrán accesar otros clientes en diferentes VRFs.

El escenario planteado es el siguiente:

Bajo este esquema de conectividad propuesto los clientes deben tener acceso uno a uno y no tener visibilidad de ninguno otro cliente, la correspondencia debe ser uno a uno de la siguiente forma.

R1←→R4
R2←→R5
R3←→R6

Características OSPF

Este es un Laboratorio de OSPF que pretende comprender el uso de las aréas y los tipos de LSA que maneja en la configuración.

Está es la topología de red que he usado.

Configuraciones para OSPF sobre Frame Relay

Este tema nos permite entender como opera el protocolo OSPF sobre redes non-broadcast permitiendo el envío de mensajes tipo hello a diferencia del entorno ethernet (broadcast) por medio de mensajes unicast, podemos ver como debemos configurarla en un esquema Hub-and-spoke, está técnica fue creada para redes legacy que no soportan transmisión broadcast (HDLC/PPP).

Entrando de lleno en el ejemplo vemos que tenemos una red Frame-Relay donde existen 2 PVC uno entre R1 y R2 y otro entre R2 y R3 pero no tenemos un circuito entre R1 y R3 lo cual puede impedir el intercambio de información de la red cuando R1 y R3 es elegido como DR (o Router designado) por que no hay forma de que envíen paquetes directamente R1 y R3 por que deben pasar por el PVC hacía R2 respectivamente.

Para resolver el problema usaremos ip ospf network point-to-point con lo cual no hay elección de DR/BDR router y esto se sustituye por un proceso especial para determinar next-hop como se puede ver en R2 con el comando show ip ospf neightbor.

R2#show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface

1.1.1.1           0   FULL/  -        00:00:31    10.10.10.1      Serial2/0

3.3.3.3           0   FULL/  -        00:00:38    10.10.10.6      Serial2/1

El estado de los PVC

R2#SHOW FRAMe-relay PVC SUMMary    

Frame-Relay VC Summary

              Active     Inactive      Deleted       Static

  Local          2            0            0            0

  Switched       0            0            0            0

  Unused         0            0            0            0

NAT ON STICK

La técnica de Nat on Stick consiste en combinar policy-map y NAT con la finalidad de enviar y recibir datos de diferente segmento por la misma interface, a decir de la documentación oficial de CISCO son pocas las ocasiones en que se utiliza esta técnica en la imagen 1 tenemos el caso básico en el cual aplica y sirve para entender el funcionamiento, en este caso los paquetes entrantes a R1 que procedan la dirección ip 192.168.1.2 serán siempre redirecciovados a la interface Loopback 0 y se hará NAT.

Para comprender como son tratados los paquete habilitamos los debug:
debug ip policy
debug ip nat

En la prueba inicial el R2 manda un traceroute a una ip fuera de su red en este caso 8.8.8.8

R2#traceroute 8.8.8.8

Type escape sequence to abort.

Tracing the route to 8.8.8.8

  1 192.168.1.1 40 msec 40 msec 48 msec

  2 2.2.2.2 !H  !H  * 

Y el debug muestra que se aplica el policy route-map y el NAT correctamente obviamente no encontramos el destino.

*Dec 27 11:41:20.931: IP: s=192.168.1.2 (FastEthernet0/0), d=8.8.8.8, len 28, policy match

*Dec 27 11:41:20.931: IP: route map LOOP, item 10, permit

*Dec 27 11:41:20.931: IP: s=192.168.1.2 (FastEthernet0/0), d=8.8.8.8 (Loopback0), len 28, policy routed

*Dec 27 11:41:20.935: IP: FastEthernet0/0 to Loopback0 0.0.130.158

*Dec 27 11:41:20.935: NAT: s=192.168.1.2->2.2.2.2, d=8.8.8.8 [298]

*Dec 27 11:41:20.939: NAT: s=2.2.2.2, d=2.2.2.2->192.168.1.2 [64]

Vemos el que el fue NAT aplicado correctamente.

R1#show ip nat translations 

Pro Inside global      Inside local       Outside local      Outside global

udp 2.2.2.2:49211      192.168.1.2:49211  8.8.8.8:33437      8.8.8.8:33437

udp 2.2.2.2:49212      192.168.1.2:49212  8.8.8.8:33438      8.8.8.8:33438

Generic Routing Encapsulation (GRE)

Generic Routing Encapsulation (GRE) es un protocolo de túnel que puede encapsular una amplia variedad de protocolo de capa de red tipos de paquetes dentro de un túnel IP , creando un virtual punto de enlace a varios routers en puntos remotos a través de un Protocolo de Internet ( IP) de redes.

En este ejemplo esta es la topología que aplicaré para generar el túnel GRE simulando las redes LAN de los sitios remotos que se van a comunicar con las interfaces Loopback 1 en los routers R1 y R3 y siendo las interfaces Loopback 0 primero los ID del enrolamiento OSPF y después el orígenes y destino para generar el túnel GRE.

En las adyacencias tenemos que el protocolo principal de ruteo es OSPF e interiormente EIGRP para la comunicación del las redes que van por el túnel GRE.

OSPF

R1_GRE#show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface

2.2.2.2           1   EXSTART/DR      00:00:36    192.168.20.2    GigabitEthernet1/0

R2_GRE#show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface

3.3.3.3           1   FULL/DR         00:00:35    192.168.20.6    GigabitEthernet2/0

1.1.1.1           1   FULL/BDR        00:00:38    192.168.20.1    GigabitEthernet1/0

R3_GRE#show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface

2.2.2.2           1   FULL/BDR        00:00:32    192.168.20.5    GigabitEthernet0/0

EIGRP

R1_GRE#show ip eigrp neighbors 

EIGRP-IPv4 Neighbors for AS(100)

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

0   192.168.0.2             Tu0               11 00:00:58   44  1434  0  3

EIGRP-IPv4 Neighbors for AS(100)

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

0   192.168.0.1             Tu0               11 00:01:27   48  1434  0  3