DMVPN question

Unanswered Question
Mar 27th, 2008

A client complained that when their hub router died, all the spokes in their DMVPN hub and spoke topology all lost their tunnels.

The spokes are supposed to be leveraging NHRP to build a database of other spokes' public interface addresses so that they can bypass the hub router for spoke-to-spoke communication.

It seems that that functionality did not work.

What I am suspecting is that the NHRP database entries eventually timeout and require the hub to refresh their databases. Is that true? Do the entries in the NHRP databases timeout? If so, is this configurable?

Thanks

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
MW20082008 Fri, 03/28/2008 - 07:04

Thanks. That helps a lot.

Now, what I am doing is researching the best design deployment for a secondary hub.

Should the hub be on the same local segment? Is it OK if its not? Can they be geographically separated?

I know that the hubs have to share routing information and NHRP database information for the DMVPN network. So, I know that this can be achieved through common subnet connections, or by creating a DMVPN or p-pGRE tunnel connection bewteen both hubs.

I am wondering if these are the only ways.

MW20082008 Fri, 03/28/2008 - 09:36

J:

OK

I think when we talk about 'common subnets' in a DMVPN environemnt with OSPF, we should differentiate what we mean, right?

As for DMVPN, the common subnet/single DMVPN cloud involves having the tunnel interfaces all sitting in the same subnet.

In OSPF, the common subnet requirement for an OSPF NBMA or broadcast network addresses the requirement of having both routers share a common subnet if one is to be the DR and the other the BDR.

So, if the two DMVPN hub routers are no tsitting on the same PHYSICAL subnet, one hub will be the OSPF DR but the other will NOT be the BDR. It will, however, become the DR once the active DR dies.

Did I get this straight?

Marcin Zgola Fri, 03/28/2008 - 14:29

do this:

here is what i did. i had a client with the same problem. 25 sites, and one hub. we upgraded on of the spoke sites to 2851 with vpn card, other sites are still using 1800, 1700, 2800. anyway. each spoke has two tunnel interfaces tunnel 1 that points to main hub, and tunnel 2 that points to a 2nd hub. We run OSPF with different cost configured on each tunnel interface so tunnel 1 is always preffered, when main hub dies or goes down. all the spokes depend on 2nd hub. the only thing is we were using two different ospf process ids, and area #, so we did norry about dr,bdr and things like that.

MW20082008 Fri, 03/28/2008 - 17:36

MZ:

i could totally dig it. Thats what i was thinking.

I was just wondering if there was a requirement when deploying a dual hub DMVPN architecture that makes it necessary to have the 2 hubs on the same LAN segment. I guess the answer is simply "no."

But I will say that the spokes' tunnel interfaces MUST be in the same subnet as the hub tunnel interface because the OSPF adjacency has to be established between them for the hub to be able to exchange routing information with the spokes and also for NHRP to work.

Is this last statement in bold letters true?

Actions

This Discussion