01-14-2009 03:43 AM - edited 03-04-2019 12:50 AM
Hello,
I want to build a DMVPN with the possibility of creating dynamic tunnels between spokes.
Configuration of the spoke:
interface Tunnel0
description *** MULTIPOINT GRE ***
ip address 10.0.0.40 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication LsP-DMV
ip nhrp map 10.0.0.250 x.x.x.x (//HUB)
ip nhrp map multicast 10.0.0.250
ip nhrp network-id 9999
ip nhrp holdtime 300
ip nhrp nhs 10.0.0.250
ip ospf network broadcast
ip ospf priority 0
tunnel source FastEthernet4
tunnel mode gre multipoint
tunnel key 100
tunnel protection ipsec profile DMVPN
when I traceroute another spoke the IPSec tunnel is being created, but the traceroute goes through the Hub.
Result of ip nhrp map on 10.0.0.40:
10.0.0.3/32 via 10.0.0.3
Tunnel0 created 00:02:28, expire 00:01:33
Type: dynamic, Flags: router
NBMA address: x.x.x.x (//HUB)
(Claimed NBMA address: y.y.y.y (//SPOKE))
I believe that it behaves like that because NBMA address is different from Claimed NMBA address. What is interesting that when I traceroute from 10.0.0.3 (where I have 1812 router) it goes directly to 10.0.0.40 (so behaves correctly). So I believe that the problem could be with Cisco 881 (the same configuration among 1812s is working good). Any hints how to run it on 881? Thanks!
01-14-2009 09:30 AM
Hello Mariusz,
I remember the first time I tried dynamic spoke to spoke that to trigger the setup of the dynamictunnel I needed to perform
an extended ping using as source the internal LAN and destination a remote LAN spoke
try in this way and then check with
sh crpyto ipsec sa
if you see the new entry to the spoke
as well as a new entry in the sh ip nhrp
Hope to help
Giuseppe
01-14-2009 10:27 AM
Thanks for the message Giuseppe! I am doing an extended ping from the beginning but with no success (i.e. I get !!!!! but the communication goes through the hub, no directly to the second spoke).
Still, a new tunnel between spokes is created correctly (isakmp shows QM_IDLE; ipsec inbound/outbound esp sas: ACTIVE, no packets are encapsulated/decapsulated). About NHRP I get the results presented in my first message.
In 1812 it is working correctly and I believe the problem is probably connected directly with 881(C880DATA-UNIVERSALK9-M). Anyone did such configuration on this platform? Thanks!
01-14-2009 11:34 AM
Hello Mariusz,
you mean that if you start the extended ping from the 1812 spoke the dynamic tunnel is used for carrying traffic ?
if so you may consider an IOS upgrade.
I have no direct experience with 881 as a spoke but I had seen limited support on old IOS code on a C7200 that wasn't able to act as NHRP server.
try to see
Hope to help
Giuseppe
01-14-2009 12:13 PM
Thanks!
I have checked in feature navigator (looking for NHRP) and got a result that my current image (c880data-universalk9-mz.124-20.T1.bin) supports it. Indeed, it correctly works as a spoke in nhrp-hub-spoke topology.
In addition, when I traceroute from spoke-1812 to spoke-881, direct ipsec tunnel between them is used. When I traceroute from spoke-881 to spoke-1812 it goes through the hub. It is kind of weird and I am wondering what can be a issue... maybe 881 does not fully support direct spoke-to-spoke tunnels, maybe additional configuration is needed (sh ip nhrp gives me some suspections but... really don't know what is going on)
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: