Operación de DMVPN
Una Dynamic Multipoint VPN (Red privada virtual multipunto dinámica) es una iteración evolucionada de los túneles "Hub and Spoke" (Note que DMVPN por si misma no es un protocolo, mas bien un concepto de diseño).
En una topología genérica "Hub and Spoke" se implementan túneles estáticos (usando típicamente GRE o IPSEC) entre un router "hub" ubicado en el centro y sus "Spokes" o satélites, los cuales generalmente conectan oficinas sucursales a la sede central.
Cada nuevo "Spoke" requiere que se haga una configuración adicional en el router "Hub" y el tráfico entre los "Spokes" debe ser desviado a través del "HUB" para que salga de un túnel y luego ingrese en otro. Mientras que esta podría ser una solución aceptable a pequeña escala, se vuelve difícil de manejar cuando los "Spokes" van multiplicándose y creciendo en número.
DMVPN ofrece una solución elegante a este problema: Túneles GRE multipunto.
Recordemos que un túnel GRE encapsula paquetes IP con un encabezado GRE y un nuevo encabezado IP para poder transportar el paquete a través de una red no confiable.
Los túneles GRE punto a punto tienen exactamente dos extremos y cada túnel en el router requiere una interface virtual separada con su propia configuración independiente.
Contrariamente, un túnel multipunto GRE permite que existan mas de dos extremos y es tratado como una red de acceso múltiple sin broadcast (NBMA).
Usemos esta topología de ejemplo:
Formación de túneles GRE multipunto:
Mientras que una configuración típica de "Hub and Spoke" requeriría tres túneles separados expandiéndose desde el router R1 hacia cada uno de los router "Spoke", el GRE multipunto permite que los cuatro routers puedan comunicarse usando una sola única interface túnel en la misma subred IP (192.168.0.0/24). Esta configuración NBMA es habilitada por el Next Hop Resolution Protocol el cual permite que los túneles multipunto sean construidos dinámicamente.
Next Hop Resolution Protocol (NHRP)
NHRP (definido en el RFC 2332) es el "catalizador" que facilita el establecimiento del túnel dinámico, al proveer una resolución de direcciones "túnel a interface física". Los clientes NHRP (los router "Spoke") realizan una solicitud al "next hop server" (NHS) (el router HUB) para obtener la dirección física de otro router "Spoke".
Es interesante notar que, en nuestro escenario, la designación como el NHS es el único atributo que distingue al router R1 como el router "Hub".
Configuración DMVPN
Comencemos por examinar la configuración del router R1:
interface FastEthernet0/0 ip address 172.16.15.2 255.255.255.252 ! interface Tunnel0 ip address 192.168.0.1 255.255.255.0 ip nhrp map multicast dynamic ip nhrp network-id 1 tunnel source 172.16.15.2 tunnel mode gre multipoint |
La primera cosa que seguramente notaremos es que el túnel no tiene un destino especificado explícitamente. Esto es porque los túneles multipunto son construidos dinámicamente desde los "Spokes" DMVPN hacia el router "Hub"; el router "Hub" no necesita tener preconfigurada las direcciones de los "Spokes".
También note que el modo de túnel ha sido designado como "GRE multipoint".
El comando ip nhrp network-id 1 identifica de manera única la red DMVPN, los túneles no se formarán entre routers con un ID diferente de red.
El comando ip nhrp map multicast dynamic habilita el reenvío de tráfico multicast a través del túnel a los "Spoke" dinámicos (lo cual es requerido por la mayoría de los protocolos de enrutamiento dinámico).
La configuración de los router "Spoke" es muy similar a la del router "Hub". A continuación se presenta aquí la configuración tomada del router R2:
interface FastEthernet0/0 ip address 172.16.25.2 255.255.255.252 ! interface Tunnel0 ip address 192.168.0.2 255.255.255.0 ip nhrp map 192.168.0.1 172.16.15.2 ip nhrp map multicast 172.16.15.2 ip nhrp network-id 1 ip nhrp nhs 192.168.0.1 tunnel source 172.16.25.2 tunnel mode gre multipoint |
Ahora vemos dos nuevos comandos en comparación con los usados en el router "Hub". El comando ip nhrp nhs 192.168.0.1 designa a router R1 como el NHS (que es la única funcionalidad única del router "Hub"), y ip nhrp map 192.168.0.1 172.16.15.2 que mapea estáticamente la dirección NHS hacia la dirección física del router R1.
El comando ip nhrp multicast también difiere ligeramente de como está aplicado en el router "Hub" en que el tráfico de multicast está solamente permitido desde los "Spokes" hacia el "Hub", no desde un "Spoke" a otro "Spoke".
Después de completar la configuración de túnel en cada router, podemos verificar que las sesiones DMVPN se han establecido entre el router "Hub" y cada "Spoke":
R1# show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
Tunnel0, Type:Hub, NHRP Peers:3,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 172.16.25.2 192.168.0.2 UP 00:57:47 D
1 172.16.35.2 192.168.0.3 UP 00:45:56 D
1 172.16.45.2 192.168.0.4 UP 00:45:46 D
|
Tunelización Dinámica
Mientras que DMVPN sin duda provee una configuración ordenada, lo que resulta brillante es su habilidad para establecer dinámicamente túneles "Spoke" a "Spoke".
En una configuración típica de una topología "Hub and Spoke", un paquete destinado desde R2 a R4 necesitaría ser enrutado a través del router R1, salir del túnel R2 y ser re-encapsulado para ingresar en el túnel R4.
Claramente un mejor camino se encuentra a través de R5 y DMVPN nos permite tomar esta ventaja.
Vea en esta captura de paquetes el tráfico desde R2 a R4. El tráfinco inicialmente sigue el camino a través de R1 como se describió previamente, mientras un túnel dinámico se esta construyendo desde R2 a R4 usando NHRP. Luego que el nuevo túnel se ha establecido, el tráfico fluye a través de él, obviando completamente el router R1. Podemos ver que un nuevo túnel se ha establecido luego que se ha detectado tráfico destinado para R4:
R2# show dmvpn ... Tunnel0, Type:Spoke, NHRP Peers:1, # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb ----- --------------- --------------- ----- -------- ----- 1 172.16.15.2 192.168.0.1 UP 01:08:02 S R2# ping 192.168.0.4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.0.4, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 28/37/56 ms R2# show dmvpn ... Tunnel0, Type:Spoke, NHRP Peers:2, # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb ----- --------------- --------------- ----- -------- ----- 1 172.16.15.2 192.168.0.1 UP 01:08:27 S 1 172.16.45.2 192.168.0.4 UP 00:00:03 D |
Note que el túnel a R4 ha sedo marcado como dinámico, en contraste con el túnel estático hacia el Hub/NHS.
Añadiendo cifrado
Hasta este punto los túneles han sido configurados como texto plano por simplificar el ejemplo, pero en el mundo real probablemente quisiéramos incluir protección IPsec a los túneles que atraviesan rutas no confiables.
Afortunadamente, la solución es tan simple como aplicar una política de protección IPsec a la interface túnel en cada router. Aquí se presenta un perfil IPsec usando una llave ISAKMP pre-compartida para demostración:
crypto isakmp policy 10 authentication pre-share crypto isakmp key P4ssw0rd address 172.16.0.0 255.255.0.0 ! crypto ipsec transform-set MyTransformSet esp-aes esp-sha-hmac ! crypto ipsec profile MyProfile set transform-set MyTransformSet ! interface Tunnel0 tunnel protection ipsec profile MyProfile |
Después de reiniciar las interfaces de túnel, podemos ver que las sesiones DMVPN ha sido reconstruidas mostrando esta vez encriptación.
R1# show dmvpn ... Tunnel0, Type:Hub, NHRP Peers:3, # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb ----- --------------- --------------- ----- -------- ----- 1 172.16.25.2 192.168.0.2 UP 00:02:28 D 1 172.16.35.2 192.168.0.3 UP 00:02:26 D 1 172.16.45.2 192.168.0.4 UP 00:02:25 D R1# show crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id slot status 172.16.15.2 172.16.35.2 QM_IDLE 1002 0 ACTIVE 172.16.15.2 172.16.25.2 QM_IDLE 1001 0 ACTIVE 172.16.15.2 172.16.45.2 QM_IDLE 1003 0 ACTIVE |
----------------------------------------------------------
Post basado en http://packetlife.net/blog/2008/jul/23/dynamic-multipoint-vpn-dmvpn/
con aportes del editor del blog.
Traducción por: José R. Torrico Gumucio - Instructor Cisco Networking Academy- Bolivia
4 Comentarios
