In this post I’m going to look at the characteristics of OSPF and EIGRP when used in a Dynamic Multipoint VPN (DMVPN). I will do my best not to play favorites and instead stick to the facts (yes, I do have a preference :-). To that end I will back everything up with data from my lab. The focus areas of the comparison will be:

  • Scalability of the hub router’s control plane
  • Overall control plane stability
  • Traffic engineering

This post won’t go into any background on how DMVPN works. If you’re not yet familiar with DMVPN, I recommend watching these introductory videos by Brian McGahan. This post also does not do a deep dive on OSPF or EIGRP. I’m making the assumption that you’re already familiar with the different LSA types in OSPF and general functions of EIGRP.

After reading this post you should be able to describe the pros and cons of OSPF and EIGRP in the three areas listed above and incorporate this knowlege into a DMVPN design.



OSPF and EIGRP perform the same function — advertising network reachability information — but they perform this function in very different ways.

OSPF is a link state protocol which means it creates a “link state database” which is replicated to each OSPF speaker within an OSPF area. OSPF update messages — called Link State Updates (LSUs) — are actually how this database is synchronized from one speaker to another. OSPF does not directly exchange routes between intra-area neighbors! Think of these messages instead as database replication messages. The routing table entries are generated by running the Shortest Path First (SPF) algorithm against the local copy of the database. I’m calling out this intra-area behavior specifically because it will be relevant further on.

The important part to remember here is: all routers in an OSPF area must have the same copy of the database. Put another way: an OSPF update advertised into an area must be seen and processed by every router in that area in order to ensure that all routers in the area have a synchronized copy of the database.

EIGRP is based on distance vector routing principles which means it doesn’t exchange database updates but instead exchanges routing information directly. An EIGRP speaker puts these routing updates into a data structure called the EIGRP topology table and then runs the Diffusing Update Algorithm (DUAL) over the table in order to generate the routing table entries. The topology table is its own unique entity on each EIGRP speaker and does not need to be synchronized amongst them in any way.

These characteristics of the protocols are very important to understand when reviewing the details below because they form the basis for why each protocol scales the way it does.

Lab Topology

This is the example network I’ll be using throughout this post:


OSPF Design Choice: Where Does Area 0 Go?

When using OSPF on a DMVPN a choice has to be made about where to place area 0. There are three options:

  1. Area 0 behind the hub; a non-zero area across the DMVPN and at the sites
  2. Area 0 on the DMVPN; a unique non-zero area at each spoke site
  3. Area 0 everywhere

I’m going to discount the third option right off the bat because it has the worst scaling properties and the highest change of control plane instability. It’s not recommended.

Topology 1

Topology 1 looks like this:

OSPF area 0 behind the hub

Because OSPF uses a two-level hierarchy where area 0 is the backbone and all non-zero areas are attached to the backbone, placing area 0 behind the hub means that everything below the hub in the diagram must belong to the same non-zero area. What’s that you say? Virtual-links? I’ll pretend I didn’t hear that :-) With this design the DMVPN cloud itself as well as every spoke site LAN are part of the same area.

The natural question is: why can’t each spoke be part of its own area? And the answer is: because the hub uses a single, multipoint tunnel interface to connect to every site in the DMVPN cloud and an interface cannot belong to more than one OSPF area. In order for the spoke sites to be part of the same DMVPN, they must terminate on the same tunnel interface on the hub which means they must be part of the same OSPF area.

R4#show ip ospf neighbor

Neighbor ID     Pri   State        Dead Time   Address         Interface        0   FULL/  -     00:00:38     Tunnel0        0   FULL/  -     00:00:31     Tunnel0        0   FULL/  -     00:00:32     Tunnel0

In this topology, R4, R21, R22 and R23 all have the same OSPF database in area 1 and R4 is the Area Border Router (ABR) between area 1 and the backbone. When any one of those routers sends an LSU into area 1, all of the other routers process that LSU and update their database and then also perform an SPF run.

Topology 2

Topology 2 looks like this:

OSPF area 0 across the DMVPN cloud

In this topology area 0 is extended across the DMVPN to the spoke routers. The spoke routers are the ABRs this time and each connect their own unique area to the backbone. The databases on R4, R21, R22 and R23 are still all the same but this time it’s for area 0. And, since area 0 extends up above R4 and into the data center, all of the OSPF speakers in the datacenter also share the same area 0 database with R4, R21, R22 and R23. Any LSU sent into area 0 now has to be processed by those four routers as well as all of the OSPF devices attached to area 0 in the datacenter.

Filtering Routing Updates

One way to design stability into a network is to limit the scope of control plane messages such as routing updates. When a router receives a routing update, it’s a signal that it must rebuild its protocol-specific tables, send its own copy of the update out to its neighbors, rebuild the routing table and then program the forwarding table. It’s a lot of work and does place some burden on the device so it’s best to scope routing updates so that only the devices that really need to know about the update perform the reconvergence steps and the rest just continue on, blissfully unaware.

Below is a description of the capabilities that OSPF and EIGRP have for scoping routing updates.

Filtering in OSPF Topology 1

OSPF has a hard rule that update messages cannot be filtered within an area. This ties back to the rule above that all routers within an area must have the same copy of the database. In order for this to happen, all routers must receive all updates. So no filtering.

Yes, you can apply a distribute-list inbound under the OSPF process however that only filters OSPF routes from entering the routing table. It does not filter OSPF Link State Update messages. Even if a distribute-list is applied, OSPF still processes LSUs, updates the database and runs SPF.

The practical impact of this is that if there is a topology change at Site 1 — eg, an interface goes down on an OSPF speaker, be it R21 or some other router at the site — that triggers an update to that device’s OSPF database and the generation of at least one LSU to announce that change to the rest of the network.

OSPF intra-area LSUs

That small topology change in Site 1 causes LSUs to propagate throughout the area and causes each OSPF speaker to update its database and run SPF. This small change in Site 1 causes control plane churn in all of the other sites. This is no big deal in a network that resembles the sample topology but imagine a network with hundreds or even thousands of spoke sites. Now it’s a big deal because there’s hundreds/thousands of networks where links can be going up and down, all causing LSUs to be flooded across the whole DMVPN which in turn causes every OSPF speaker in every site to reconverge.

There is no way to scope routing updates within an OSPF area and therefore no way to prevent control plane churn within the area when a link in a site flaps.

Example: When manually dropping the link to the network on R21:

R21(config-if)#do show clock
*20:27:03.750 MST Mon Jun 15 2015

Router R22 receives an LSU from R21 and performs a full SPF run:

R22#show ip ospf events

            OSPF Router with ID ( (Process ID 1)

1    *Jun 15 20:27:16.566: Timer Exp:  if_ack_delayed  0x3A02E98
2    *Jun 15 20:27:14.065: Rcv Changed Type-1 LSA, LSID, Adv-Rtr, Seq# 80000003, Age 2, Area 1
3    *Jun 15 20:27:14.065: Schedule SPF, Topo Base, Area 1, spf-type Full, Change in LSA Type RLSID, Adv-Rtr

The one place routing updates can be scoped is between area 1 and area 0. R4 can be configured to advertise a summary route(s) into area 0 that represents the subnets at the DMVPN sites. The act of having a summary route in place prevents the advertisement of specific subnet routes which means there are no routing updates sent into area 0 when a link flaps in a DMVPN site. The practical impact of this is that none of the OSPF speakers in area 0 — or any other areas attached to area 0 — experience any control plane churn.

Filtering in OSPF Topology 2

Topology 2 has the same constraints but things have just moved around a bit. R21, R22 and R23 are now the ABRs and they can advertise summary routes that represent their respective sites into area 0. This isolates area 0 from any topology changes within the sites. The challenge now is that any instability on the DMVPN cloud itself will be felt by OSPF speakers up in the datacenter. For example, if R21 has an unreliable connection to the service provider which causes its DMVPN interface to flap, that will trigger LSU flooding on R4 which will be flooded up into the datacenter to the rest of area 0.

Example: The WAN interface on R21 goes down:

R21(config-if)#do show clock
*20:43:53.807 MST Mon Jun 15 2015

After the OSPF dead timer reaches zero on R4, the adjacency is brought down and R4 floods LSUs into area 0. These LSUs reach R22 and R23 and also R5 in the data center:

R22#show ip ospf events

 OSPF Router with ID ( (Process ID 1)

32 *Jun 15 20:44:35.613: RIB Delete, Topo Base, dest, mask, gw, via Tunnel0, source, type Intra
34 *Jun 15 20:44:35.613: Schedule SPF, Topo Base, Area 0, spf-type Prefix Recalculation, Change in LSA Type SN
38 *Jun 15 20:44:35.614: Starting Intra-Area SPF, Topo Base, Area 0, spf_type Full
39 *Jun 15 20:44:35.614: Starting SPF, Topo Base, wait-interval 5000ms
R5#show ip ospf events

            OSPF Router with ID ( (Process ID 1)

22   *Jun 15 20:44:35.601: RIB Delete, Topo Base, dest, mask, gw, via Ethernet0/0, source, type Intra
24   *Jun 15 20:44:35.601: Schedule SPF, Topo Base, Area 0, spf-type Prefix Recalculation, Change in LSA Type SN
29   *Jun 15 20:44:35.601: Starting Intra-Area SPF, Topo Base, Area 0, spf_type Full
30   *Jun 15 20:44:35.601: Starting SPF, Topo Base, wait-interval 5000ms

Again, this might not be a big deal in a small network, but with hundreds or thousands of spokes, the risk is high. The stability of the control plane in the datacenter is now tied to the overall stability of the underlying service provider. And once again, because they’re in the same area, there is no way to insulate the datacenter from topology changes on the DMVPN cloud.

Filtering with EIGRP

EIGRP routing updates will be advertised throughout the entire EIGRP AS, very similarly to how OSPF advertises updates throughout an area. Without scoping the updates, every EIGRP speaker in the AS will reconverge when a link flaps in a site.

By default, EIGRP follows the split-horizon rule so in this topology, updates from R21 would actually not be received by R22 or R23 because they come in and would go out the same tunnel interface on R4. I’m overlooking that here and assuming the worst-case scenario that split-horizon has been disabled on R4’s multipoint tunnel interface.

EIGRP allows any router, anywhere in the network to create a summary route and just like with OSPF, a summary route will block advertisement of the component subnets. Summary routes can be created at both levels of the network:

  • At routers R21, R22 and R23 to summarize their respective sites into the DMVPN cloud
  • At R4 to summarize the DMVPN cloud and possibly even summarize the summaries from the spoke routers into the datacenter

With this configuration, there’s a high degree of isolation between all points of the network which will prevent control plane churn when a link flaps anywhere in the network.

Example without summarization: the interface to the network on R21 goes down:

R21(config-if)#do show clock
*20:58:20.703 MST Mon Jun 15 2015

This causes a routing update to hit every EIGRP router in the AS:

R22#show ip eigrp events
Event information for AS 123:
1    20:58:21.764 NDB delete: 1
2    20:58:21.764 RDB delete:
R4#show ip eigrp events
Event information for AS 123:
1    20:58:21.823 NDB delete: 1
2    20:58:21.823 RDB delete:

When a summary route is configured on R21’s tunnel interface and the interface to goes down, R21 no longer propogates a routing update.

interface Tunnel0
 !Configure a summary route of
 ip summary-address eigrp 123

Filtering Routing Updates: Summary

Every routing update within an area is processed by every device in that area Every routing update within an area is processed by every device in that area
Routing updates within an area cannot be filtered Routing updates within an EIGRP AS can be filtered at any point via summarization
Topology changes always cause a routing reconvergence on every router in the area The impact of topology changes can be scoped by using summarization and route filtering
OSPF routing updates can only be scoped at area boundaries; there can only be 1 area boundary anywhere near the DMVPN EIGRP routing updates can be scoped at any place in the network and even at multiple places simultaneously

Periodic Routing Updates

One further thing to note about OSPF with respect to routing updates is that it refreshes every Link State Advertisement (LSA) at 30 minute intervals from the time the LSA was first advertised. So even in a very stable network with few link flaps, there is still overhead on the control plane caused by these regularly occurring updates.

The 30 minute refresh time is a constant and cannot be adjusted.

EIGRP does not send periodic routing updates.

Traffic Engineering

I’m going to change the topology a little bit for this section by adding a second hub router at the data center. Each spoke router now has two viable paths to reach the two subnets in the datacenter. The sections below will look at how traffic engineering can be performed with OSPF and then with EIGRP.

DMVPN dual-hub topology

TE with OSPF

The allocation of OSPF areas isn’t relevant for this topic which is why the diagram doesn’t show them.

OSPF assigns a metric to a route by adding up the costs of all the links along the path between the local router and the destination. A cost is assigned to a link; costs are not assigned to routes themselves. For example, if R4 advertises the prefixes and to R21 and R21 receives both OSPF updates on its tunnel interface, then OSPF on R21 will add the same cost value to the metric of both routes. OSPF will not — and cannot — add 100 to the metric of and 200 to the metric of (for example).

R21#show ip ospf interface tunnel0 | begin Cost
  Process ID 1, Router ID, Network Type POINT_TO_MULTIPOINT, Cost: 1000

As another example, let’s say R21 receives an update for the network from both R4 and R7. Since these updates come into R21 on the same tunnel interface (because all three routers are part of the same DMVPN cloud), OSPF on R21 will still add the same cost value to the metric of both routes. Even in this case, OSPF will not — and cannot — add a smaller cost to the route received from one hub and a larger cost to the route received from the other hub.

There are two traffic engineering scenarios I’m going to explore:

  1. Active/standby hubs – where spoke routers send all of their traffic to R4 and only route to R7 if R4 goes away
  2. Per-prefix active/standby hubs – where spoke routers send traffic for certain prefixes to R4 and use R7 as a backup and where they send other prefixes to R7 and use R4 as a backup

OSPF with Active/Standby Hubs

As I established above, OSPF on the spoke routers cannot increment the metric of a route by a little bit when it’s received from R4 and by a lot when it’s received from R7. Because of this the traffic engineering cannot be configured on the spokes.

What can be done instead is to modify R7’s OSPF interface cost towards the two data center subnets so that it’s advertising a higher metric out to the spokes.

Before adjusting R7’s metric, R21 has two equal cost routes via R4 and R7:

R21#show ip route
Routing entry for
  Known via "ospf 1", distance 110, metric 1021, type inter area
  Last update from on Tunnel0, 00:04:41 ago
  Routing Descriptor Blocks:, from, 00:04:41 ago, via Tunnel0
      Route metric is 1021, traffic share count is 1
  *, from, 00:06:02 ago, via Tunnel0
      Route metric is 1021, traffic share count is 1

After increasing the OSPF cost on R7’s LAN interface:

R7(config-if)#int e0/0
R7(config-if)#ip ospf cost 100
R21#show ip route
Routing entry for
  Known via "ospf 1", distance 110, metric 1021, type inter area
  Last update from on Tunnel0, 00:09:48 ago
  Routing Descriptor Blocks:
  *, from, 00:11:09 ago, via Tunnel0
      Route metric is 1021, traffic share count is 1

R21 now prefers the path via R4 because it has the lowest overall metric. As a side effect though, all of the data center prefixes are now preferred via the path to R4 not just

OSPF with Per-prefix Active/Standby Hubs

Changing the OSPF cost on the interface of R7 had the effect of changing the metric for both and Since the metric of a route is tied to the cost of the links along the path, there is no way for R7 to advertise a higher metric for one prefix and a lower metric for the other. The net result is that there is no way to do per-prefix load sharing with OSPF.

You could play some tricks and use an inbound distribute-list to block the route from the standby hub from entering the routing table. That would be cool in a lab scenario but not cool in a live network. If the active hub became unreachable, the route would be pulled and the standby route would not be installed in the routing table resulting in an outage.


Metrics in EIGRP are associated directly with the route and are advertised between neighbors along with the prefix information. EIGRP has a tool for manipulating the metric of a sent or received route that’s called an offset-list. An offset-list is just an additional value that is added to the calculated metric for a particular route.

  • An offset-list can be used to achieve active/standby hubs by adding a large value to the metric of every route advertised by R7
  • An offset-list can also be used to achieve per-prefix active/standby hubs by adding a large value to the metric of specific routes advertised by R4 and a different set of routes advertised by R7. Example:

On R7:

ip access-list standard PFX_WHERE_R7_IS_BACKUP
router eigrp 123
 offset-list PFX_WHERE_R7_IS_BACKUP out 2000 Tunnel0

On R4:

ip access-list standard PFX_WHERE_R4_IS_BACKUP
router eigrp 123
 offset-list PFX_WHERE_R4_IS_BACKUP out 2000 Tunnel0

Now on R21:

R21#show ip route eigrp
D EX [170/26880256] via, 00:02:19, Tunnel0
D EX [170/26880256] via, 00:02:19, Tunnel0

R21 is using R4 to reach one prefix and R7 to reach the other. However, both prefixes are in the EIGRP topology table from both hub routers so in the event that one hub goes away, the route learned from that hub will be flushed from the RIB and then EIGRP will install the route learned via the remaining hub.

R21#show ip eigrp topo | include Tunnel (Tunnel0), from, Send flag is 0x0 (Tunnel0), from, Send flag is 0x0
R21#show ip eigrp topo | include Tunnel (Tunnel0), from, Send flag is 0x0 (Tunnel0), from, Send flag is 0x0

OSPF Tuning

OSPF has a number of knobs for tweaking and tuning it. Do any of them help overcome some of the challenges above and achieve the goals of scale, stability, and traffic engineering?

Stub Areas

No impact on scale or control plane stability. Stub areas prevent external (Type 4 & 5) LSAs from being advertised into the area and totally stubby areas additionally prevent inter-area (Type 3) LSAs from being advertised into the area. The routing updates that I wrote about above all have to do with intra-area LSAs which stub, totally stubby, or not-so-totally stubby areas do not deal with.

Prefix Suppression

Little-to-no impact on control plane stability and scale. Prefix suppression limits the number of IP prefixes that are advertised in intra-area LSAs. Enabling this feature on the spoke routers and other OSPF speakers at the spoke sites might lessen the control plane load but it does not eliminate the fact that LSAs are still flooded throughout the area. Prefix suppression also cannot be enabled on interfaces that connect to subnets that need to be reachable from across the network (eg, the interface on R21 connected to

LSA Filtering

Not practical. LSA filtering is a feature which causes an OSPF speaker to suppress all LSA advertisements out a particular interface. For what should be obvious reasons, this has a rather negative affect on reachability of subnets that sit behind that OSPF speaker :-)

EIGRP Tuning

One of the best practices when deploying EIGRP — in a DMVPN or otherwise — is to make use of the stub feature. When the stub feature is configured on an EIGRP speaker, it causes EIGRP to only advertise routes of a certain type. For example, to only advertise routes that are directly connected or only summary routes. Above and beyond that though, the fact that stub has been configured is carried in the messages sent to each EIGRP neighbor. This tells the neighbors that if they need to “go active” on a route to not bother sending a query to the speaker that’s configured for stub. This is one of the ways that the old “stuck in active” condition is avoided in modern EIGRP networks.

R4#show ip eigrp neighbors detail
EIGRP-IPv4 Neighbors for AS(123)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
1             Tu0                      10 00:00:13   15  1584  0  21
   Version 14.0/2.0, Retrans: 0, Retries: 0, Prefixes: 2
   Topology-ids from peer - 0
   Stub Peer Advertising (CONNECTED SUMMARY ) Routes
   Suppressing queries


I’ve demonstrated the characteristics of OSPF, a link state protocol, and EIGRP, a distance-vector protocol, in a DMVPN environment and shown that there are a number of advantages when using a distance-vector protocol.

  • Control plane churn can be better managed which makes for a more stable control plane and promotes a healthier network overall.
  • Due to less control plane churn, the control plane load on the hub router(s) is greatly reduced because the hub(s) no longer has to replicate frequent control plane updates to all spoke routers.
  • There are more options for performing traffic engineering in a distance-vector network which provide more flexibility for IT to meet business requirements.
  • Distance-vector protocols don’t have a concept of areas so there are no “tough decisions” to make when designing the network about how the areas should be laid out and the pros/cons of the different options.
Disclaimer: The opinions and information expressed in this blog article are my own and not those of Cisco Systems.

14 thoughts on “OSPF vs EIGRP for DMVPN”

  1. Hey mate,
    great summary. One other thing that makes eigrp stub useful is that it prevents it from becoming a transit in dual-hub topologies, i.e. re-advertising prefixes it received over tunnel 1 over to tunnel 2

    1. Hi Michael,

      That’s a great point! I actually wasn’t thinking about that scenario so thanks for commenting.

    1. Hey Wahib :-)

      This post is already super long so I chose to leave BGP out.

      BGP has very good scaling properties though since it’s designed for Internet-sized networks. BGP will also handle more neighbors/peers than either OSPF or EIGRP. You can also summarize anywhere and there are many methods for doing traffic engineering.

      The recommendation is to use internal BGP and then use the MED attribute for doing traffic engineering. One of the nice things about using the MED is you can copy your IGP metric into the MED on your hubs so the BGP bestpath will be reflective of the IGP bestpath as well.

      If you require spoke-to-spoke traffic, use of iBGP will require route reflectors. It makes the most sense to have the hubs do the RR duty.

      A nice side benefit of iBGP is that it addresses Michael’s comment above about spokes becoming a transit point between the hubs: iBGP will automatically prevent routes learned from one hub being advertised up to the other hub.

      Hope that helps!

  2. Is there a particular reason Cisco is recommending iBGP vs eBGP for DMVPN deployments? The iWAN docs are also recommending iBGP. I’ve worked in a network where the iWAN deployment would not be “supported” by Cisco if it did not run iBGP.

    The only thing I can think of is perhaps ease of config on the spokes – as they can all share the same ASN. But one could also share the same ASN with eBGP on the spokes, and rely on aggregate routes from the hubs (or just allow-as in =) ). Last time I checked, the dynamic neighbor BGP feature was supported on both iBGP and eBGP as well. Would love you hear your insight on this!


    1. Hi Pablo,

      This is how it was explained to me: iBGP is preferred because it enables use of the MED attribute between neighbors. MED is nice because
      a) It works a lot like an IGP metric and allows for similar kind of logic between the IGP in the DC and iBGP across the WAN. it’s a minor thing that will make operations easier.
      b) There’s automatic support for stuffing the IGP metric into the iBGP MED so from a traffic engineering perspective, iBGP can automatically carry over the IGP metrics across the WAN which means the spokes, without any special config, can choose the hub that’s closest to the destination.

      As far as iWAN, I actually didn’t know the requirement for iBGP was so strict. I would assume that’s because maybe MED is being used under the covers (or maybe something else that’s iBGP-specific) that would break if eBGP was used.

      1. I would highly recommend iBGP over DMVPN for the similar reasons. It makes route decision and traffic engineering as well as troubleshoot and operations so much easy. The LAN DC perimeter devices can actually carry on the WAN preferences with similar numbers. Network Operational staff can easily manage routing preference across multiple data centers and multiple service providers networks End to End. We have implemented iBGP over DMVPN in a large scale and critical network. It has been proved as the most scalable and stable routing protocol across multiple service providers networks with full vendor independences.

        The other key benefit with iBGP in comparison with OSPF or EIGRP, you can actually manage the routing preference on a peer by peer basis. Unlike IGP protocol, you can change the routing metric for each peer in BGP. With OSPF and EIGRP, the routing preference is controlled on interface level. Therefore by changing the interface ospf cost or EIGRP delay (or any other K values) on the hub devices, you could impacts routing preference on all the remote spoke sites. iBGP works on layer 4, you have all the flexibility you need in BGP world without having to manage multiple ASNs across your organization (in comparison with eBGP).

  3. I spent too much time to figure out the limitation of OSPF over DMVPN and finally I got very handy post about both EIGRP and OSPF over DMVPN.

    Many thanks and your post is life saver

  4. Nice article, I found it very informative. I have a question though in regards to OSPF
    For Topology 2, what is the reason to extend the Area 0 into the DC in the HUB?
    Why can’t you have the HUB as an ABR with Area 0 only for the DMVPN cloud side and put the LAN network behind the HUB also in a non-zero area. e.g. Area 41?

    1. Hi Jorge, thanks for the feedback :-) I think what you’re describing is basically topology #1 but with area 0 on the bottom and area 41 on the top, yes? In that scenario, you’d have the same problems as topology #1 but in a worse way. Because area 41–a non-backbone area–is on the LAN side, by definition, *everything* on the LAN side of the DMVPN hub router would have to also be in area 41. That means your data center, any other data centers, your campus(es), any WAN clouds that aren’t part of this DMVPN. All of it. This is definitely not recommended and the reason that such a design is highly discouraged.

Leave a Reply

Your email address will not be published. Required fields are marked *

Would you like to subscribe to email notification of new comments? You can also subscribe without commenting.