cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
723
Views
0
Helpful
7
Replies

DMVPN question

MW20082008
Level 1
Level 1

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

7 Replies 7

jcoke
Level 3
Level 3

Yes, it called the holdtimer and is configurable with "ip nhrp holdtime [seconds]" Default is 7200. I'd advise configuring a second hub.

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.

Not necessarily, sure can.

Make each hub a spoke of the other.

Here's a good multiple senario DMVPN deployment doc:

http://www.cisco.com/en/US/tech/tk583/tk372/technologies_white_paper09186a008018983e.shtml

Common subnets?

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?

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.

CCIE 18676

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?

Getting Started

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco