09-18-2008 09:57 AM - edited 03-03-2019 11:36 PM
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
09-18-2008 10:36 AM
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
09-19-2008 07:56 AM
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
09-19-2008 12:06 PM
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
09-25-2008 06:42 AM
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.
10-10-2008 12:22 PM
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
09-19-2008 12:07 PM
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
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: