cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
2764
Views
0
Helpful
32
Replies

DMVPN Tunnel down

Hello All,

 

We have configured two Tunnels in single ISP link for dual connectivity.

 

Data center1 router <-------------> Edge Router(Tunnel1)

Data center2 router <-------------> Edge Router(Tunnel2)

 

Above is the setup of DMVPN Tunnel.

 

Edge Router#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface: Tunnel2, IPv4 NHRP Details
Type:Spoke, NHRP Peers:2,

# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 Public IP DC1 10.XX.XX.1 UP 13:21:24 S
1 Public IP DC2 10.XX.XX.2 NHRP 07:37:04 S

 

neighbor 10.XX.XX.1 remote-as 13567
neighbor 10.XX.XX.1 description DC1 Router
neighbor 10.XX.XX.1 password 7 password
neighbor 10.XX.XX.1 update-source Tunnel2
neighbor 10.XX.XX.1 timers 180 540
neighbor 10.XX.XX.1 send-community both
neighbor 10.XX.XX.1 soft-reconfiguration inbound
neighbor 10.XX.XX.1 route-map BGP_INBOUND_3GDMVPN in
neighbor 10.XX.XX.1 route-map BGP_OUTBOUND_3GDMVPN out
neighbor 10.XX.XX.2 remote-as 13567
neighbor 10.XX.XX.2 description DC2 Router
neighbor 10.XX.XX.2 password 7 password
neighbor 10.XX.XX.2 update-source Tunnel2
neighbor 10.XX.XX.2 timers 180 540
neighbor 10.XX.XX.2 send-community both
neighbor 10.XX.XX.2 soft-reconfiguration inbound
neighbor 10.XX.XX.2 route-map BGP_INBOUND_3GDMVPN in
neighbor 10.XX.XX.2 route-map BGP_OUTBOUND_3GDMVPN out

 

DC2 Router#sh dmv 

0 UNKNOWN 10.XX.XX.104 NHRP never IX

 

Could you please let us know what would be the reason? and i am sure, it is not issue with ISP since one tunnel is up.

 

Thanks in advance.

 

Regards,

Chandhuru

Thanks and regards, Chandhuru.M
32 REPLIES 32

Hello Georg,
 
Thanks for your reply.
 
I guess DMVPN will not support keep alive right ???
 
Correct me if am wrong and also I read one article from cisco stated that keepalive will not be effect when there is a vrf in place. 
 
Could you please clarify me???
 
Regards,
Chandhuru
Thanks and regards, Chandhuru.M

Hello,

 

since it is only 1 particular site and only one tunnel, and since the BGP goes down as well, you might as well just configure the EEM script below, which automatically bounces your tunnel interface in case the BGP adjacency is reestablished. Replace the 'x.x.x.x' wth the real IP address of the BGP neighbor:

 

event manager applet EEM_BGP_TUNNEL_BOUNCE
event syslog pattern "%BGP-5-ADJCHANGE: neighbor x.x.x.x Up"
action 1.0 cli command "enable"
action 2.0 cli command "configure term"
action 3.0 cli command "interface Tunnel2"
action 4.0 cli command "shut"
action 4.0 cli command "no shut"

Hello Georg,

 

Thanks for the solution.

 

This is temporary solution right? Is there any other particular reason for this issue?

Because we are seeing this issue in few more spoke as well.

 

Thanks in advance.

 

Regards,

Chandhuru

Chandhuru

Thanks and regards, Chandhuru.M

Hello,

 

the only real and permanent solution would be stop your ISP from having these outages. The tunnel will go down no matter what when the ISP link goes down, the script just brings it back up.

 

So there are sites where this never occurs ? Are all sites running the same hardware and IOS ?

Hello Georg,

 

Solution is appreciated but we cannot stop ISP outages.

 

Anyways i came to know that IOS currently running in Spoke is 15.2(1)T2.1 - 3925 router.

 

Whether it would be the issue? Any known bug in this version?

Thanks and regards, Chandhuru.M

Hello,

 

there is a bug in 15.2 where 'if-state nhrp' configured on the tunnel interface keeps the NHRP registration to never finish.

 

You might want to try and remove 'if-state nhrp' from the tunnel interfaces and check if that makes a difference...

It didn't helped. I have already tried. Thanks!

Thanks and regards, Chandhuru.M

Hello,

 

try and remove ' ip nhrp map multicast dynamic' from the spoke, it is only needed on the hub anyway. Not sure if this has any effect...

Ok Sure.

 

Thanks for prompt reply Geaorg.

Thanks and regards, Chandhuru.M

Hello Georg,

 

Could you please confirm Bug ID for the below statement:

 

"there is a bug in 15.2 where 'if-state nhrp' configured on the tunnel interface keeps the NHRP registration to never finish"

Thanks and regards, Chandhuru.M

Hello,

 

CSCug76750 - NHRP registration fails when if-state nhrp is configured
Symptom: No encrypted/decrypted packets are seen after phase1/phase2
comes up because NHRP registration never finishes.
Tunnel interface stays in up/down status.

Hello Georg,

 

Looks like this Bug ID is different issue. Can you cross check the Bug ID. Thanks!

Thanks and regards, Chandhuru.M

Hello,

 

The bug ID is correct, it is linked to another one, but that seems to be a mistake in the database, as the linked ID is unrelated...

Yes. As I said earlier, this problem occurs only when ISP goes down and coming back. 
 
Post ISP came back online only one tunnel become live another one is down. Second one also will come online unless until bounce the tunnel interface. 
 
Please suggest your comments.
 
Regards,
Chandhuru
Thanks and regards, Chandhuru.M

Looking at this config, I only see Tunnel2, and this is marked as your edge router.

 

If you want to have two tunnels built to each DMVPN router, I thought you need to have two separate tunnel interfaces. I'm not sure if I'm missing Tunnel1 or confusing this with another devices config, but if you're making an IPSEC tunnel the SA needs to have it's own SPI. GRE can have multiple endpoints on the same network if you're using point-to-multipoint, but a spoke connecting to a hub would need separate interfaces.

 

I don't have any solid evidence to support this other than studies I'm drawing from memory. I could be wrong.