Dual DMVPN with OSPF

[Xavier Lloyd]

Hi all,

I've been trying to configure this for a while now but there's one question looming. Can I have something looking like this?

Everytime I try this config, I find I can't route through the backup tunnel. If anyone can shed some more light on whether this is possible, or config caveats, etc, it would be much appreciated!

Also, can someone point me to a good document on how to configure dual hub single cloud with OSPF? I can't seem to find one...

Regards,

Xavier

[Marcin Latosiewicz]

Xavier,

My suggestion would be to open a TAC case for this.

There is no reason why you would not be able to route through any of the interfaces provided crypto and NHRP are up.

Since the amount of details to check is quite high, I think best way is via TAC case.

M.

[Mohammad Abazeed · Accepted solution]

I would second what Marcin said about this ... I was able to complish the same thing via GNS thou

For the document part, check this link, not sure if you already have it or not:

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

HTH,

Mo.

[Xavier Lloyd]

Thanks for the help guys.

Mohammad, this document really helped! I didn't see this one before and it makes it clear where my problem was. I was trying to define the static mappings for each hub on each other...so hub1 had a static nhrp mapping to hub2 and hub2 to hub1. This document shows that only hub2 (backup hub) should have a static mapping to hub1. Also the same with the nhs config...I had it on both hubs.

Last question about this though. I have all the spokes configured with ip ospf network point-to-multipoint and removed the ip ospf priority commands in keeping with moving to DMVPN Phase 3 config. Here's a redacted config:

HUB
interface Tunnel0
 bandwidth 8000
 ip address 10.x.x.12 255.255.255.0
 no ip redirects
 ip mtu 1446
 ip flow ingress
 ip nhrp authentication cisco123
 ip nhrp map multicast dynamic
 ip nhrp network-id 100
 ip nhrp holdtime 600
 ip nhrp redirect
 ip tcp adjust-mss 1446
 ip ospf network point-to-multipoint
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 tunnel key 1000
 tunnel protection ipsec profile ipsec_prof shared
 !
SPOKE
interface Tunnel0
 bandwidth 8000
 ip address 10.x.x.13 255.255.255.0
 no ip redirects
 ip mtu 1446
 ip flow ingress
 ip nhrp authentication cisco123
 ip nhrp map 10.x.x12 100.100.100.100
 ip nhrp map multicast 100.100.100.100
 ip nhrp network-id 100
 ip nhrp holdtime 600
 ip nhrp nhs 10.x.x.12
 ip nhrp shortcut
 ip nhrp redirect
 ip tcp adjust-mss 1446
 ip ospf network point-to-multipoint
 tunnel source FastEthernet0/0/1
 tunnel mode gre multipoint
 tunnel key 1000
 tunnel protection ipsec profile ipsec_prof shared

So my secondary hub should look just like a spoke and my new spoke will just add the relevant commands?

 ip nhrp map 10.x.x13 101.101.101.101
 ip nhrp map multicast 101.101.101.101
 ip nhrp nhs 10.x.x.13

And the main hub stays the same?

A document I read said that ip ospf priority doesn't have anymore use in DMVPN phase 3 so should I put on the config or leave it off? Or I guess the bandwidth commands will take care of that...I should set the bandwidth on the secondary hub to 7000 instead of 8000 and that should be ok?

Sorry for all the questions

[Mohammad Abazeed]

I think Marcin is the expert in this area ... so what do you think mate !?

[Marcin Latosiewicz]

M,X,

"ip ospf network point-to-multipoint" is something that the guys from marketing put intially in their phase2 to phase 3 migration "guide". I've seen people using it and not complaining too much, but in all honesty there is no need to enable and it's causing additional overhead. In practice we just make sure that hub will be chosed the DR (via priority) and backup hub the backup DR on tunnel interface and utilize ip ospf network broadcast.

Bandwidth and delay do not change much for DMVPN based on OSPF, they might come into play if you choose to implement QoS.

Under these circumstances, the config you point out for secondary hub seems appropriate.

M.

[Xavier Lloyd]

So I'll change it back to broadcast? In changing it back to broadcast, should I also remove the nhrp shortcut and redirect commands? (Guess I'm going back to "phase 1"?)

Since I'm back at phase 1, I'll reconfigure ospf priority as well with a 200 priority for the hub and 100 for the secondary hub (BDR?)?

Just need to make sure I have my plan set out because this was causing some headache before.

[Marcin Latosiewicz]

Xavier,

You're not going back to phase 1. Phase 1 was using point to point interfaces ;-)

You're still at phase 3 and you should leave redirect on hub interfaces and shortcut + redirect on spokes.

network type in OSPF is just modifying how OSPF works, it does not change how NHRP/resolution works - it is important to the process but it does not decide which DMVPN phase you're in.

M.

[Xavier Lloyd]

Gotchya! Thanks a lot!

[Xavier Lloyd]

Hey again!

One more question. It so happens that the backup hub has 2 Internet connections. Is there any way to get both these connections in on the DMVPN so if one goes down, it'll use the other?

The second interface currently isn't participating in the DMVPN though I would like to use it in case the primary connectino goes down.

[Marcin Latosiewicz]

Xavier,

Multiple possibilities exclue,tracking/SLA etc,

My favorite is to use VRF-lite scneario.

In essence you take advantage of the fact that you can terminate traffic on particular VRF and decepulate traffic into another.

It's something I discussed with other people already:

http://ciscosupport45.solutionset.com/thread/2106309

HTH,

M.

[Xavier Lloyd]

Thanks Marcin, I will take a look. So is it that I can have a second tunnel interface on the same router participating in the same DMVPN cloud, just using a different subnet?

Or will each spoke need to have 2 tunnel interfaces like the guy in the post asked?

[Marcin Latosiewicz]

X,

Best to use a separate netmask and separate tunnel for backup (two tunnels can be up at the same time), this can be overcome by using some unnumbered magic (AFAIU), but for clarity best leave it at two seperate tunnel subnets.

M.

[Xavier Lloyd]

I plan to use separate subnets but is it possible for tunnel1-subnet1 to be in the same gre cloud as tunnel2-subnet2 just by virtue of them having the same tunnel id, tunnel key, etc?

[Marcin Latosiewicz]

X,

Best not to mix the two, you can use une NHRP network ID if for some reason you want reoslution packets to flow between those two instances.

M.