Problem setting DMVPN

Unanswered Question
Sep 18th, 2008

Hi,

I am Setting up in the lab DMVPN phase 3, single coud, OSPF and with two hubs and three spokes.

I am having stability issue, each time I reboot the backup hub I loss most of my spoke and they don t come back ......

Hubs are Cisco 3845 running IOS version 124-15-T1.

Spokes are Cisco 2851 running IOS version 124-15-T1.

See attachement for configs.

Thanks

Attachment: 
I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Giuseppe Larosa Thu, 09/18/2008 - 10:36

Hello Tayeb,

you want to setup a single cloud DMVPN with a primary hub and a backup hub.

You have tried to change the bandwidth on the mGRE tunnel interface but DR election is influenced by ip opsf priority command

So I would suggest:

prim_hub

int tunnel 0

ip ospf pri 10

sec_hub

int tunnel 0

ip ospf pri 8

on spokes

int tunnel 0

ip ospf priority 0

after this the roles should be the expected ones with primary-hub DR, sec-hub BDR, spokes DRother

if ospf priority is the same the highest OSPF router-id wins the election

Hope to help

Giuseppe

tmesbah Fri, 09/19/2008 - 07:56

Thans Giuseppe. I did the change this moning and here is what happened:

1. When rooting the backup hub, I dont lost any of my spokes. Was great

2. Now, when I tried the reboot the primay hub, I lost all my spokes, doesnt seems to fail over to backup hub. I was geeting this error on the backup hub:

%CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=x.x.x.x "address of outside interface of primary hub", prot=50, spi=0x29A531FA(698692090), srcad

dr=y.y.y.y "address of outside interface of backup hub",

Thanks

Giuseppe Larosa Fri, 09/19/2008 - 12:06

Hello Tayeb,

probably before it was the backup hub to be the DR on the mGRE subnet.

By giving another look at mGRE configuration a suggestion is the following to add static NHRP entries on each hub to point to the other one.

You have done this only on secondary hub I would do the same on primary hub.

on hub 1:

int tu0

ip nhrp map 10.100.106.4 172.24.2.4

ip nhrp map multicast 172.24.2.5

this could help the primary hub to recover after reload by providing an NHRP entry to the working hub router

the IPSec error is to be expected by reloading the primary backup has lost the SPI of the security association with the backup hub and they need to negotiate again.

try with this change in NHRP on primary hub.

Hope to help

Giuseppe

tmesbah Thu, 09/25/2008 - 06:42

Did the modification. Now every time

1. I power off the backup Hub I lost 6 pings "pinging the spokes".

2. I power back the backup Hub I lost 1 pings

The same result with the primary hub.

I taught if we power the backup Hub I will not lose my spokes, am I correct.

Any idea how to fix this.

Giuseppe Larosa Fri, 10/10/2008 - 12:22

Hello ,

in another thread about DMVPN Brent found a solution for the IPsec problems related to power cycle of hub or spokes routers:

Crypto isakmp keepalive seconds 40(i used 40) on-demand

Hope to help

Giuseppe

tmesbah Fri, 09/19/2008 - 12:07

Just find out that the only way to get the tunnel back is by issuing the command "clear cry session" on all spokes. Can't go with this because I we have no TECH guy on the spokes, all spokes are managed centrally.

Any idea ...

Thanks

Actions

This Discussion