Most of the DMVPN-related questions I get are a variant of the “how many tunnels/hubs/interfaces/areas do I need for a redundant DMVPN design?” As always, the right answer is “it depends” (and I can always help you with your design if you’d like to get a second opinion), but here’s what I’ve learned so far.

Single router/single uplink on spoke site

This blog post focuses on the simplest possible design – each spoke site has a single router and a single uplink. There’s no redundancy at the spokes, which might be an acceptable tradeoff (or you could use 3G connection as a backup for DMVPN).

You’d probably want to have two hub routers (preferably with independent uplinks), which brings us to the fundamental question: “do we need one or two DMVPN clouds?”

A reader of my blog planning to migrate his network from a traditional BGP-everywhere design to a BGP-over-MPLS one wondered about potential unexpected consequences. The MTU implications of introducing MPLS in a running network are usually well understood (even though you could get some very interesting behavior); if you can, increase the MTU size by at least 16 bytes (4 labels) and check whether MTU includes L2 header. Another somewhat more mysterious beast is the interaction between IGP and LDP that can cause traffic disruptions after the physical connectivity has been reestablished.

One of my readers sent me the following question a few days ago:

Do you have a webinar that covers Dual DMVPN HUB deployment using OSPF? If so which webinar covers it?

I told him that the DMVPN: From Basics to Scalable Networks webinar covers exactly that scenario (and numerous others), describing both Phase 1 DMVPN and Phase 2 DMVPN design and implementation guidelines. Interestingly, he replied that the information on this topic seems to be very scant:

SK left a long comment to my More OSPF-over-DMVPN Questions post describing a scenario I find quite often in enterprise networks:

• Primary connectivity is provided by an MPLS/VPN service provider;
• Backup connectivity should use DMVPN;
• OSPF is used as the routing protocol;
• MPLS/VPN provider advertises inter-site routes as external OSPF routes, making it hard to properly design the backup connectivity.

If you’re familiar with the way MPLS/VPN handles OSPF-in-VRF, you’re probably already asking the question “how could the inter-site OSPF routes ever appear as E1/E2 routes?”

After weeks of waiting, perfect summer weather finally arrived … and it’s awfully hard to write blog posts that make marginal sense when being dead-tired from day-long mountain biking, so I’ll just recap the conversation I had with Brian a few days ago. He asked:

How would I set up a (dual) hub running OSPF with phase 1 spokes and prevent all spoke routes from being seen at other spokes? Think service provider environment.

If you want to have a scalable DMVPN environment, you have to put numerous spokes connected to the same hub in a single IP subnet (otherwise you’ll end with point-to-point tunnels), which also means they have to be in a single OSPF area and would thus see each other’s LSAs.

A few days ago I was discussing a data center design with a seasoned network architect and during the MPLS discussions he made an offhand remark “there are still some switches running OSPF and using network 0.0.0.0 and redistribute connected.” My first thought was “this can’t be good” but I had no idea how bad it is until I ran a lab test.

The generic dilemma along the lines of “should I make connected interfaces part of my OSPF process (and make them passive) or should I redistribute them into OSPF” has no clear-cut answer (apart from the obvious “it depends”) ... and Google will quickly find you tons of lengthy discussions.

OSPF implementation in Cisco IOS deviates slightly from OSPF/NSSA standards (RFC 2328 and RFC 3101). These are the OSPF route selection rules as implemented by Cisco IOS release 12.2(33)SRE1 (all recent releases probably behave identically):

Note: Update history is at the end of the post

Cliffs Notes version (details in DMVPN webinar):

• Configure ip nhrp multicast-map for the hub on the spoke routers, otherwise the spokes will not send OSPF hellos to the hub.
• Use dynamic NHRP multicast maps on the hub router, otherwise the spokes will not receive its OSPF hellos.
• Use broadcast network type on all routers.

This is how you configure OSPF in a Phase 1 DMVPN network (read the introductory post and Phase 1 DMVPN fundamentals first):

Remember:

• Use point-to-multipoint network type on the hub router to ensure the hub router is always the IP next hop for the DMVPN routes.
• Use point-to-multipoint network type on the spoke routers to ensure the OSPF timers match with the hub router.
• The DMVPN part of your network should be a separate OSPF area; if at all possible, make it a stub or NSSA area.
• If absolutely needed, use OSPF LSA flood filter on the hub router and a static default route on the spokes.

For more information, watch the DMVPN Technology and Configuration webinar.

A few days ago I received the following e-mail from one of my readers:

I am trying presently to put in place a DMVPN solution running OSPF. I was wondering if you ever saw a solution with dual hub dual cloud design with OSPF working in practice because since I started I have issue with asymmetric routing because of the OSPF functionality.

Actually, I did… and exactly the same setup is included in the tested router configurations you get with the DMVPN: from Basics to Scalable Networks webinar. While there are many things that can go wrong with DMVPN, I’ve never heard about asymmetric routing problems, so I started to investigate what’s actually going on.

Ian sent me a really good OSPF-over-DMVPN question after watching my DMVPN webinar:

In the DMVPN webinar you discuss OSPF design and configuration. However, Cisco design guide says you should use a different routing protocol from what you use on your LAN but you seem to suggest it is okay to extend your OSPF network out to the DMVPN edge by continuing to use OSPF albeit in a different area.

The main issue you face when running OSPF over DMVPN is scalability: OSPF does not scale as well as other routing protocols when used over DMVPN.

I’ve stumbled across a really interesting BGP/IGP problem described by Jeremy Filliben that nicely illustrates the dangers of using more than one IGP in your network. You should read the original post for details, here’s a short summary:

• The same IP prefix is received by two BGP border routers (A and D) and sent to a third IBGP-only router (E).
• E can reach A via OSPF. It can reach D via EIGRP.
• E receives two BGP paths to the target IP prefix from A and D. They are identical, so the IGP metric (taken from the IP routing table) is used as the tie-breaker.
• EIGRP and OSPF metrics are totally incomparable and thus A (reachable via OSPF) is always preferred over D (reachable via EIGRP).

Lesson learned: use a single IGP in your AS (or at least in its BGP core).

I never believed I would see this: OSPF is becoming a multi-protocol routing protocol. RFC 5838 specifies how you can redefine the instance ID field in OSPFv3 to support four address families (IPv6 and IPv4 unicast+multicast).

A month ago, I would have added CLNP and IPX to the list; unfortunately they’ve missed that particular window of opportunity ;)

It looks like this feature currently runs in PowerPoint and in a very-limited-availability image (if you’ve seen it working on an actual box, let me know).

Almost all articles describing large-scale DMVPN in combination with OSPF use the “magic” ip ospf database-filter all out command on the hub routers to minimize the OSPF traffic traversing the DMVPN part of the network.

NOTE: The same trick can be used in any hub-and-spoke network, including P2MP Carrier Ethernet networks.

What these articles usually fail to tell you is the true impact of this command: it stops all OSPF flooding from hub router. The spoke routers receive no OSPF information whatsoever; to establish connectivity to the network core, you have to use static default routes on the spoke routers.

Two years ago I wrote about the problems caused by MTU mismatch between OSPF neighbors, and warned that the ip ospf mtu-ignore interface configuration command that supposedly solves the problem could cause significant headaches. Last week’s challenge was a simple illustration of what could happen if you force OSPF neighbors to establish a session even though their interface MTUs don’t match (the very first comment correctly identified the issue).