Problem setting DMVPN

Unanswered Question
Sep 18th, 2008
User Badges:

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: 
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Giuseppe Larosa Thu, 09/18/2008 - 10:36
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

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
User Badges:

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
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

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
User Badges:

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
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

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
User Badges:

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