cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
614
Views
0
Helpful
4
Replies

NHRP problem (Cisco 881)

mkazmierski
Level 1
Level 1

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!

4 Replies 4

Giuseppe Larosa
Hall of Fame
Hall of Fame

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

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!

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

www.cisco.com/go/fn

Hope to help

Giuseppe

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)

Getting Started

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco