DMVPN - Dynamic Multipoint Virtual Private Network
DMVPN
es una tecnología que nos permite tener una configuración HUB-SPOKE con
túneles VPN. La idea es que cuando dos Spokes quieren hablar entre
ellos, será el hub el que les dará los datos para montar el túnel entre
ellos. Simplifica las comunicaciones y ahorra costes. Los túneles se
levantan bajo demanda.
No tenemos que montar obligatoriamente IPSEC para que funcione mGRE, pero en los tiempos que estamos, lo mejor es encriptar nuestras comunicaciones. Por ello,hay que tener en cuenta que el equipo que hace de HUB tendrá que mantener una sesión IPSEC con cada spoke y, eso conlleva mucha capacidad de procesamiento si tenemos muchos spokes.
Esta tecnología se basa en mGRE (Multi GRE), NHRP (Next Hop Resolution Protocol) y IPSEC.
Tenemos 3 tipos o fases para implementar dmvpn:
- Fase 1(obsoleta): Hub and Spoke - mGRE en el Hub y p2p GRE spokes . NHRP se necesita para que los spokes se registren en el hub. No hay túneles spoke-spoke. El "next-hop" de los spokes lo cambia el hub. Se permite sumarización y generación de ruta por defecto en el hub.
- Fase 2(obsoleta): Hub and Spoke con Spoke-to-spoke tunnels - mGRE en el Hub y en spokes. NHRP para se necesita que los spokes se registren en el hub y para la resolucion spoke-spoke. Hay túneles spoke-spoke iniciados por los propios spokes. No se permite sumrización y generación de ruta por defecto en el hub.
- Fase 3: Igual que Fase 2 pero ahora los Spoke pueden también responder a los NHRP
Requests.
mGRE en el Hub y en spokes. NHRP se necesita para que los spokes se registren en el hub
y para la resolucion spoke-spoke. Cuando el spoke le pregunta con NHRP que quiere montar un túnel con otro spoke, el hub le responde con un mensaje NHRP redirect para decirle que dirección ip debería ser su siguiente salto y se instala en la tabla de rutas. Se permite sumarización y generación de ruta por defecto en el hub.
El "next-hop" de los spokes lo cambia el hub
Tenemos 2 roles:
- DMVPN Hub o NHRP Server (NHS)
- DMVPN Spokes o NHRP Clients (NHC)
En los Spokes configuramos la direccion del Hub para que se registren enviando un NHRP Registration Request. Los Hub aprenden las direcciones públicas y del túnel.
mGRE
puede transportar unicast, multicast, y broadcast. El hub puede montar
muchos túneles en el mismo interface físico. Es gracias a NHRP, que
ejecuta el ARP pàra descubrir y mapear los destinos de los túneles. NHRP
es un protocolo de capa 2.
Vamos a confgurar un laboratorio DMVPN.
Vamos a usar la topología y configuraciones básicas del laboratorio de VPN del curso CCNP.
Lo primero que vamos a crear son túneles GRE+IPSEC, que es la solución previa a DMVPN.
Usaremos el protocolo EIGRP para la comunicación entre equipos a través de los túneles. Esta es la configuración básica para hacer una arquitectura Point-To-Multipoint con túneles GRE+IPSEC donde GRE nos aporta la capacidad de transportar unicast, broadcast, multicast y protocolos de enrutamiento y, IPSEC la seguridad e integridad de los datos:
CONFIGURACIÓN BÁSICA GRE+IPSEC POINT-TO-MULTIPPOINT
Antes de que hagáis un copy-paste de todo, os propongo que solo configuréis EIGRP, los túneles, la ruta estática y la configuración básica de las interfaces, claro. Una vez montado podéis ver EIGRP sobre GRE, es decir mGRE sin IPSEC.
Usaremos el protocolo EIGRP para la comunicación entre equipos a través de los túneles. Esta es la configuración básica para hacer una arquitectura Point-To-Multipoint con túneles GRE+IPSEC donde GRE nos aporta la capacidad de transportar unicast, broadcast, multicast y protocolos de enrutamiento y, IPSEC la seguridad e integridad de los datos:
CONFIGURACIÓN BÁSICA GRE+IPSEC POINT-TO-MULTIPPOINT
Antes de que hagáis un copy-paste de todo, os propongo que solo configuréis EIGRP, los túneles, la ruta estática y la configuración básica de las interfaces, claro. Una vez montado podéis ver EIGRP sobre GRE, es decir mGRE sin IPSEC.
| R1# interface Ethernet0/0 ip address 10.0.0.1 255.255.255.252 full-duplex no sh ! interface Ethernet0/1 ip address 192.168.0.1 255.255.255.0 full-duplex no sh ! interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! Creamos los túneles: interface Tunnel1 ip address 100.100.100.1 255.255.255.252 ip mtu 1400 ip tcp adjust-mss 1360 delay 1000 tunnel source Ethernet0/0 tunnel destination 172.16.1.2 ! interface Tunnel2 ip address 100.100.100.5 255.255.255.252 ip mtu 1400 ip tcp adjust-mss 1360 delay 1000 tunnel source Ethernet0/0 tunnel destination 172.16.2.2 ! interface Tunnel3 ip address 100.100.100.9 255.255.255.252 ip mtu 1400 ip tcp adjust-mss 1360 delay 1000 tunnel source Ethernet0/0 tunnel destination 172.16.3.2 Ruta estática por defecto: ip route 0.0.0.0 0.0.0.0 10.0.0.2 EIGRP router eigrp 1 net 192.168.0.0 0.0.0.255 net 100.100.100.0 0.0.0.15 no auto FASE I de IPSEC: crypto isakmp enable crypto isakmp policy 1 authentication pre-share encryption aes 128 group 2 hash sha lifetime 86400 crypto isakmp identity address crypto isakmp key 0 IPSEC-GRE address 0.0.0.0 FASE 2 de IPSEC: crypto ipsec transform-set IPSEC-GRE-TRANSFORM esp-aes 128 esp-sha-hmac mode transport crypto ipsec security-association lifetime seconds 86400 Creamos un access-list: access-list 103 permit gre host 10.0.0.1 host 172.16.1.2 access-list 104 permit gre host 10.0.0.1 host 172.16.2.2 access-list 105 permit gre host 10.0.0.1 host 172.16.3.2 Y ahora el crypto map: crypto map VPN-IPSEC-GRE local-address e0/0 crypto map VPN-IPSEC-GRE 10 ipsec-isakmp match address 103 set peer 172.16.1.2 set transform-set IPSEC-GRE-TRANSFORM crypto map VPN-IPSEC-GRE 20 ipsec-isakmp match address 104 set peer 172.16.2.2 set transform-set IPSEC-GRE-TRANSFORM crypto map VPN-IPSEC-GRE 30 ipsec-isakmp match address 105 set peer 172.16.3.2 set transform-set IPSEC-GRE-TRANSFORM Aplicamos el crypto map en la interfaz: interface e0/0 crypto map VPN-IPSEC-GRE -------------------------------------------------------- R3#
interface Ethernet0/0
ip address 172.16.1.2 255.255.255.252
full-duplex
no sh
!
interface Ethernet0/1
ip address 192.168.10.1 255.255.255.0
full-duplex
no sh
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255 !
interface Tunnel0
ip address 100.100.100.2 255.255.255.252 ip mtu 1400 ip tcp adjust-mss 1360 delay 1000 tunnel source Ethernet0/0 tunnel destination 10.0.0.1 !
ip route 0.0.0.0 0.0.0.0 172.16.1.1
!
net 192.168.10.0 0.0.0.255 net 100.100.100.0 0.0.0.3 no auto ! crypto isakmp enable crypto isakmp policy 1 authentication pre-share encryption aes 128 group 2 hash sha lifetime 86400 ! crypto isakmp identity address ! crypto isakmp key 0 IPSEC-GRE address 0.0.0.0 ! crypto ipsec transform-set IPSEC-GRE-TRANSFORM esp-aes 128 esp-sha-hmac mode transport ! crypto ipsec security-association lifetime seconds 86400 ! access-list 103 permit gre host 172.16.1.2 host 10.0.0.1 ! crypto map VPN-IPSEC-GRE local-address e0/0 ! crypto map VPN-IPSEC-GRE 10 ipsec-isakmp match address 103 set peer 10.0.0.1 set transform-set IPSEC-GRE-TRANSFORM ! interface e0/0 crypto map VPN-IPSEC-GRE ! ------------------------------------------------------------- R4#
interface Ethernet0/0
ip address 172.16.2.2 255.255.255.252
full-duplex
no sh
!
interface Ethernet0/1
ip address 192.168.20.1 255.255.255.0
full-duplex
no sh
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255 !
interface Tunnel0
ip address 100.100.100.6 255.255.255.252 ip mtu 1400 ip tcp adjust-mss 1360 delay 1000 tunnel source Ethernet0/0 tunnel destination 10.0.0.1 !
ip route 0.0.0.0 0.0.0.0 172.16.2.1
!
router eigrp 1net 192.168.20.0 0.0.0.255 net 100.100.100.4 0.0.0.3 no auto ! crypto isakmp enable crypto isakmp policy 1 authentication pre-share encryption aes 128 group 2 hash sha lifetime 86400 ! crypto isakmp identity address ! crypto isakmp key 0 IPSEC-GRE address 0.0.0.0 ! crypto ipsec transform-set IPSEC-GRE-TRANSFORM esp-aes 128 esp-sha-hmac mode transport ! crypto ipsec security-association lifetime seconds 86400 ! access-list 104 permit gre host 172.16.2.2 host 10.0.0.1 ! crypto map VPN-IPSEC-GRE local-address e0/0 ! crypto map VPN-IPSEC-GRE 10 ipsec-isakmp match address 104 set peer 10.0.0.1 set transform-set IPSEC-GRE-TRANSFORM ! interface e0/0 crypto map VPN-IPSEC-GRE ! ------------------------------------------------------------- R5#
interface Ethernet0/0
ip address 172.16.3.2 255.255.255.252
full-duplex
no sh
!
interface Ethernet0/1
ip address 192.168.30.1 255.255.255.0
full-duplex
no sh
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255 !
interface Tunnel0
ip address 100.100.100.10 255.255.255.252 ip mtu 1400 ip tcp adjust-mss 1360 delay 1000 tunnel source Ethernet0/0 tunnel destination 10.0.0.1 !
ip route 0.0.0.0 0.0.0.0 172.16.3.1
!
net 192.168.30.0 0.0.0.255 net 100.100.100.8 0.0.0.3 no auto ! crypto isakmp enable crypto isakmp policy 1 authentication pre-share encryption aes 128 group 2 hash sha lifetime 86400 crypto isakmp identity address ! crypto isakmp key 0 IPSEC-GRE address 0.0.0.0 ! crypto ipsec transform-set IPSEC-GRE-TRANSFORM esp-aes 128 esp-sha-hmac mode transport ! crypto ipsec security-association lifetime seconds 86400 ! access-list 105 permit gre host 172.16.3.2 host 10.0.0.1 ! crypto map VPN-IPSEC-GRE local-address e0/0 ! crypto map VPN-IPSEC-GRE 10 ipsec-isakmp match address 105 set peer 10.0.0.1 set transform-set IPSEC-GRE-TRANSFORM ! interface e0/0 crypto map VPN-IPSEC-GRE !
R2#
ip routing
interface Ethernet0/0
ip address 10.0.0.2 255.255.255.252
full-duplex
no sh
!
interface Ethernet0/1
ip address 172.16.1.1 255.255.255.252
full-duplex
no sh
!
interface Ethernet0/2
ip address 172.16.2.1 255.255.255.252
full-duplex
no sh
!
interface Ethernet0/3
ip address 172.16.3.1 255.255.255.252
full-duplex
no sh
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255 ! |
Ahora, con toda esta configuración tenemos montado mGRE+IPSEC, que en realidad es un conjunto de enlaces P2P GRE+IPSEC.
Comprobamos haciendo ping de PC4 a todos los demás y comprobamos con trace los saltos que nos da para llegar a los PC. El tráfico enre PC's tiene que ir por los túneles.
EIGRP está funcionando por los túneles y nuestras comunicaciones están encriptadas.
Para saber que tenemos un túnel GRE+IPSEC:
Ahora, si en nuestra empresa tuviéramos muchos túneles, la configuración del equipo se agrandaría, lo que conlleva un rendimiento pobre además de ser más difícil la visión de la configuración ante tantas líneas.
He subrayado en negro los comandos importantes que han cambiado respecto al túnel. Como vemos, en el HUB se reduce la configuración. Os dejo los equipos R4 y R5 para que los configuréis fijándoos en la configuración de R3. Comprobad con ping y trace. También podéis ver las asociaciones que hace el protocolo NHRP:
En R1, el HUB, no hay que modificar nada, solo en los Spokes:
Observad que el access list ahora permite cualquier ip de origen ya que no sabemos cuál nos va a proporcionar nuestro ISP. Haced lo mismo en los otros dos Spokes.
FASE 2
Aquí lo que conseguimos es que dinámicamente los spokes monten túneles entre ellos sin tener que pasar por el HUB. Quitamos EIGRP (hace cosas raras, quizás no ip split horizon y no ip next-hop-self lo resuelvan) e implementamos OSPF, así os muestro un detalle (ip ospf network broadcast) Cuando un spoke inicie la comunicación con otro spoke se montará un túnel entre ellos. Los equipos quedarían así:
Si no le ponemos el comando ip ospf network broadcast no levanta la vecindad.
Si miramos la tabla de rutas y la tabla NHRP vemos todo como antes, aunque ahora con OSPF. Es cuando lanzamos un ping desde el PC de uno de los spokes hasta otro PC en otro de los spokes. Veremos en las tablas como la dirección para llegar al PC ya no es la .1, sino la .3,4 o 5 dependiendo a donde queramos llegar. Ya no se pasa por R1.
Aquí conseguimos que el hub le diga a los spokes que cuando quieran comunicarse entre ellos, para resolver los next hop deben hablar entre ellos mismos y no preguntarle al HUB, de manera que este último no tiene ni que resolver ip y ni consumir recursos del router.
Por ejemplo, un spoke (R3) quiere comunicarse con otro (R5). Para ello hace un lookup de su tabla de rutas y le dice que su next hop para llegar a R5 es R1. Este hace un lookup y se lo manda a R5. Aquí se da cuenta que tanto la entrada como la salida de esa petición han sido por la interface tunnel 0. Se da cuenta de que forman parte de una misma DMVPN.
Entonces el HUB (R1) le manda un mensaje NHRP Traffic Indication al spoke (R3), este lo procesa y hace un NHRP Resolution Request, que es una petición de la direccion ip de la red del spoke R5 que viaja hasta R5.
Cuando llega el NHRP Resolution Request a R5 y este se da cuenta de que es el final del camino de la red DMVPN, monta un túnel IPSEC con R3 y le envía por el propio túnel un NHRP Resolution reply que contiene las direcciones ip.
Cuando este NHRP Resolution reply llega a R3, este crea el mapeo en la tabla y a partir de ese momento se envían los apqeutes directamente.
Esto reduce la tabla de rutas en los spokes y las preguntas al hub. Es lo más usado actualmente.
En el hub:
(config)#interface tunnel 0
(config-if)#ip nhrp redirect
En los spokes:
(config)#interface tunnel 0
(config)#ip nhrp shortcut
Para verificar:
show crypto session
show ip nhrp show ip nhrp nhs detail
show dmvpn
show ip route - las rutas de NHRP se marcan con una H y con 250 de AD.
También se puede configurar DMVPN con BGP para grandes infraestructuras. Los HUB actuaría como Routers Reflector (RR) y los SPOKES como ROuter Reflector Clients. Es fácil montar la política de enrutmiento y además, si hay un cambio en la red solo se manda un update y no el montón de query de EIGRP o la inundación de LSA de OSPF.
Comprobamos haciendo ping de PC4 a todos los demás y comprobamos con trace los saltos que nos da para llegar a los PC. El tráfico enre PC's tiene que ir por los túneles.
 |
| Hay comunicación entre PC's y el trace nos muestra lo saltos a través de los túneles |
EIGRP está funcionando por los túneles y nuestras comunicaciones están encriptadas.
Para saber que tenemos un túnel GRE+IPSEC:
 |
| 47 - protcolo Ip para GRE |
Ahora, si en nuestra empresa tuviéramos muchos túneles, la configuración del equipo se agrandaría, lo que conlleva un rendimiento pobre además de ser más difícil la visión de la configuración ante tantas líneas.
Con DMVPN reducimos considerablemente la configuración en el HUB introduciendo nuevos comandos:
- crypto ipsec profile
- tunnel protection ipsec profile
- ip nhrp map multicast dynamic
Para configurar DMVPN vamos a R1 (HUB) y solo configuramos un túnel y el crypto map no hay que aplicarlo en la interfaz de salida. esto sería la "FASE I", . Con DMVPN la configuración de R1 que hace de HUB y R3 quedarían así:
| R1# crypto isakmp policy 1 encryption aes authentication pre-share group 2 crypto isakmp key IPSEC-GRE address 0.0.0.0 0.0.0.0 ! crypto ipsec security-association lifetime seconds 86400 ! crypto ipsec transform-set IPSEC-GRE-TRANSFORM esp-aes esp-sha-hmac mode transport ! crypto ipsec profile DMVPN set transform-set IPSEC-GRE-TRANSFORM ! interface Tunnel0 ip address 100.100.100.1 255.255.255.0 no ip redirects ip mtu 1400 ip tcp adjust-mss 1360 ip nhrp authentication FASEI ip nhrp map multicast dynamic ip nhrp network-id 100 ip nhrp holdtime 600 no ip split-horizon eigrp 1 delay 1000 tunnel source Ethernet0/0 tunnel mode gre multipoint tunnel key 1234 tunnel protection ipsec profile DMVPN ! router eigrp 1 network 100.100.100.0 0.0.0.15 network 192.168.0.0 no auto-summary ! ip route 0.0.0.0 0.0.0.0 10.0.0.2 --------------------------------------------------------- R3# crypto isakmp policy 1 encryption aes authentication pre-share group 2 hash sha lifetime 86400 ! crypto isakmp identity address crypto isakmp key IPSEC-GRE address 0.0.0.0 0.0.0.0 ! crypto ipsec security-association lifetime seconds 86400 ! crypto ipsec transform-set IPSEC-GRE-TRANSFORM esp-aes esp-sha-hmac mode transport ! crypto map VPN-IPSEC-GRE 10 ipsec-isakmp set peer 10.0.0.1 set transform-set IPSEC-GRE-TRANSFORM match address 103 ! interface Tunnel0 ip address 100.100.100.3 255.255.255.0 ip mtu 1400 ip tcp adjust-mss 1360 ip nhrp authentication FASEI ip nhrp map 100.100.100.1 10.0.0.1 ip nhrp network-id 100 ip nhrp holdtime 300 ip nhrp nhs 100.100.100.1 delay 1000 tunnel source Ethernet0/0 tunnel destination 10.0.0.1 tunnel key 1234 ! interface Ethernet0/0 crypto map VPN-IPSEC-GRE ! router eigrp 1 network 100.100.100.0 0.0.0.255 network 192.168.10.0 no auto-summary ! ip route 0.0.0.0 0.0.0.0 172.16.1.1 ! access-list 103 permit gre host 172.16.1.2 host 10.0.0.1 |
He subrayado en negro los comandos importantes que han cambiado respecto al túnel. Como vemos, en el HUB se reduce la configuración. Os dejo los equipos R4 y R5 para que los configuréis fijándoos en la configuración de R3. Comprobad con ping y trace. También podéis ver las asociaciones que hace el protocolo NHRP:
 |
| SHOW IP NHRP |
Si hacéis un ping de spoke a spoke, veréis en los saltos de los túneles que pasa por R1. No hay túneles de spoke a spoke.
En los Spokes también podemos reducir la configuración aplicando un perfil como en el HUB:
En los Spokes también podemos reducir la configuración aplicando un perfil como en el HUB:
| R3# no crypto map VPN-IPSEC-GRE 10 ! interface Ethernet0/0 no crypto map VPN-IPSEC-GRE ! crypto ipsec profile DMVPN set transform-set IPSEC-GRE-TRANSFORM ! interface tunnel 0 tunnel protection ipsec profile DMVPN |
Ahora, si tenemos el caso de que nuestro equipo Spoke no tiene una dirección ip fija (ADSL o Cable) tenemos que hacer una pequeña modificación solo en el Spoke, el HUB se queda igual.
Para mostrar este ejemplo, configuro un servidor DHCP en R2 para que asigne direcciones ip a los equipos R3, R4 y R5. Esto no es un ejemplo real, pero para ver como funciona el protocolo lo hacemos así, emulamos que tenemos un ISP que nos da una dirección dinámica:
| R2# ip dhcp excluded-address 172.16.1.1 ip dhcp excluded-address 172.16.2.1 ip dhcp excluded-address 172.16.3.1 ! ip dhcp pool R3 network 172.16.1.0 255.255.255.252 default-router 172.16.1.1 ! ip dhcp pool R4 network 172.16.2.0 255.255.255.252 default-router 172.16.2.1 ! ip dhcp pool R5 network 172.16.3.0 255.255.255.252 default-router 172.16.3.1 |
En R1, el HUB, no hay que modificar nada, solo en los Spokes:
| R3# crypto map VPN-IPSEC-GRE 10 ipsec-isakmp set peer 10.0.0.1 set security-association level per-host set transform-set IPSEC-GRE-TRANSFORM match address 103 ! interface Ethernet0/0 ip address dhcp full-duplex crypto map VPN-IPSEC-GRE ! access-list 103 permit gre any host 10.0.0.1 |
Observad que el access list ahora permite cualquier ip de origen ya que no sabemos cuál nos va a proporcionar nuestro ISP. Haced lo mismo en los otros dos Spokes.
FASE 2
Aquí lo que conseguimos es que dinámicamente los spokes monten túneles entre ellos sin tener que pasar por el HUB. Quitamos EIGRP (hace cosas raras, quizás no ip split horizon y no ip next-hop-self lo resuelvan) e implementamos OSPF, así os muestro un detalle (ip ospf network broadcast) Cuando un spoke inicie la comunicación con otro spoke se montará un túnel entre ellos. Los equipos quedarían así:
| R1# No hay que configurar en el HUB nada relativo a NHRP. Solo OSPF interface Tunnel0 ip address 100.100.100.1 255.255.255.0 no ip redirects ip mtu 1400 ip tcp adjust-mss 1360 ip nhrp authentication FASEI ip nhrp map multicast dynamic ip nhrp network-id 100 ip nhrp holdtime 600 ip ospf network broadcast ip ospf priority 2 delay 1000 tunnel source Ethernet0/0 tunnel mode gre multipoint tunnel key 1234 tunnel protection ipsec profile DMVPN ! no router eigrp 1 router ospf 1 log-adjacency-changes network 100.100.100.0 0.0.0.255 area 0 network 192.168.0.0 0.0.0.255 area 0 R3-R4-R5 Si no lo hemos hecho antes en los spokes, lo hacemos ahora para crear el DMVPN Profile y aplicarlo al interface tunnel: no crypto map VPN-IPSEC-GRE 10 ! interface Ethernet0/0 no crypto map VPN-IPSEC-GRE ! crypto ipsec profile DMVPN set transform-set IPSEC-GRE-TRANSFORM ! interface tunnel 0 tunnel protection ipsec profile DMVPN Ojo que la dirección ip del túnel es diferente para cada uno. interface Tunnel0 ip address 100.100.100.3 255.255.255.0 no ip redirects ip mtu 1400 ip tcp adjust-mss 1360 ip nhrp authentication FASEI ip nhrp map 100.100.100.1 10.0.0.1 ip nhrp map multicast 10.0.0.1 ip nhrp network-id 100 ip nhrp holdtime 300 ip nhrp nhs 100.100.100.1 ip ospf network broadcast ip ospf priority 0 delay 1000 tunnel source Ethernet0/0 no tunnel destination 10.0.0.1 tunnel mode gre multipoint tunnel key 1234 tunnel protection ipsec profile DMVPN ! no router eigrp 1 router ospf 1 log-adjacency-changes network 100.100.100.0 0.0.0.255 area 0 network 192.168.10.0 0.0.0.255 area 0 |
Si miramos la tabla de rutas y la tabla NHRP vemos todo como antes, aunque ahora con OSPF. Es cuando lanzamos un ping desde el PC de uno de los spokes hasta otro PC en otro de los spokes. Veremos en las tablas como la dirección para llegar al PC ya no es la .1, sino la .3,4 o 5 dependiendo a donde queramos llegar. Ya no se pasa por R1.
 |
| ping desde PC1 a PC2 |
 |
| Ahora para llegar a 192.168.20.0 se hace directamente a través de la 100.100.100.4 |
También podéis ver que en los spokes se crear una sesión IPSEC entre los propios spokes con elcomando show crypto session.
FASE 3 Aquí conseguimos que el hub le diga a los spokes que cuando quieran comunicarse entre ellos, para resolver los next hop deben hablar entre ellos mismos y no preguntarle al HUB, de manera que este último no tiene ni que resolver ip y ni consumir recursos del router.
Por ejemplo, un spoke (R3) quiere comunicarse con otro (R5). Para ello hace un lookup de su tabla de rutas y le dice que su next hop para llegar a R5 es R1. Este hace un lookup y se lo manda a R5. Aquí se da cuenta que tanto la entrada como la salida de esa petición han sido por la interface tunnel 0. Se da cuenta de que forman parte de una misma DMVPN.
Entonces el HUB (R1) le manda un mensaje NHRP Traffic Indication al spoke (R3), este lo procesa y hace un NHRP Resolution Request, que es una petición de la direccion ip de la red del spoke R5 que viaja hasta R5.
Cuando llega el NHRP Resolution Request a R5 y este se da cuenta de que es el final del camino de la red DMVPN, monta un túnel IPSEC con R3 y le envía por el propio túnel un NHRP Resolution reply que contiene las direcciones ip.
Cuando este NHRP Resolution reply llega a R3, este crea el mapeo en la tabla y a partir de ese momento se envían los apqeutes directamente.
Esto reduce la tabla de rutas en los spokes y las preguntas al hub. Es lo más usado actualmente.
En el hub:
(config)#interface tunnel 0
(config-if)#ip nhrp redirect
En los spokes:
(config)#interface tunnel 0
(config)#ip nhrp shortcut
Para verificar:
show crypto session
show ip nhrp show ip nhrp nhs detail
show dmvpn
show ip route - las rutas de NHRP se marcan con una H y con 250 de AD.
También se puede configurar DMVPN con BGP para grandes infraestructuras. Los HUB actuaría como Routers Reflector (RR) y los SPOKES como ROuter Reflector Clients. Es fácil montar la política de enrutmiento y además, si hay un cambio en la red solo se manda un update y no el montón de query de EIGRP o la inundación de LSA de OSPF.
Aquí os dejo un par de documentos de Cisco sobre DMVPN.
http://www.cisco.com/c/dam/en/us/products/collateral/security/dynamic-multipoint-vpn-dmvpn/DMVPN_Overview.pdf
http://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/41940-dmvpn.html
http://www.cisco.com/c/dam/en/us/products/collateral/security/dynamic-multipoint-vpn-dmvpn/DMVPN_Overview.pdf
http://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/41940-dmvpn.html
Este comentario ha sido eliminado por el autor.
ResponderEliminarEra algo planeado desde hace tiempo pero me cuesta sacarle horas a esta actividad "no remunerada". ¿Has montado el laboratorio con las 3 fases para EIGRP y OSPF? Estoy pensando en abrir el blog a colaboradores porque no me da la vida. Gracias por tu comentario. Un saludo.
EliminarHola paco , tengo duda si DMVPN ospf en Fase 3 , el type de network broadcast or point-to-multipoint ? , parece q olvidan mucho ese detalle
ResponderEliminarDebería ser Point-to-Multipoint para la fase 3.
Eliminar