DMVPN and Dynamic Routing
General
If you’re running DMVPN, you’re probably not interested in using static routing. After all, you’re using a dynamic solution.
So, we have a few options to choose from. These are EIGRP, BGP, OSPF, and ODR.
IS-IS is not an option for DMVPN, as DMVPN’s use IP for transport, while IS-IS does not. I’ve also not included RIP here, as well, it’s RIP, and if you’re serious about this, you’re probably not going to run RIP.
According to Cisco (reference at the end of the article), EIGRP is used in about 75% of DMVPN deployment that they see, with BGP accounting for 20%, and OSPF for 4%.
Why is OSPF not popular here? Well, OSPF doesn’t map to DMVPN really well, due to the strict area requirements, and the NBMA nature of the topology.
So, in this article we will look at some factors that will affect which protocol you choose, and some important configuration items for each one.
All Routing Protocols
There are a few underlying concepts to be aware for in all cases. Firstly, be aware that there will be unicast and multicast traffic involved.
Unicast traffic will travel between hub-and-spoke, as well as spoke-to-spoke. Multicast on the other hand will only travel between hub and spoke.
This is because DMVPN is an NBMA network, which doesn’t support multicast at all. The only reason we can get it working to the hub is because of the nhrp multicast command we add to the tunnel interface.
As there’s no multicast on spoke-to-spoke tunnels, there is no traditional IGP running between spokes. Routes are learned through the hub routers.
This also means that routing protocols will not look at the state of the on-demand tunnel between spokes. If the on-demand tunnel drops, there is no routing protocol re-convergence.
So, guideline number 1 is, don’t try to run a routing protocol between spokes. Leave it to NHRP to work out the routing for you.
EIGRP
EIGRP works really well with DMVPN. There are a few things to be aware of, especially with phase 2.
Split Horizon
The most important concern is split horizon. This is EIGRP’s loop prevention mechanism.
Split horizon prevents loops by never advertising a route out the interface that it was learned on.
If you look at our generic topology, you can see why that may be a problem for our hub routers.
In DMVPN, the tunnel interface is used for everything. That means that a route from Spoke-1 will be learned on the hub’s Tunnel0 interface.
The hub will then need to use Tunnel0 to advertise the route to Spoke-2. However, split-horizon will block this, and Spoke-2 will never get the route.
The simplest solution is to disable split-horizon on the tunnel interface on the hub router (but not the spokes).
If you’re using phase 1 or phase 3, you have another option. Instead of sending the learned routes back out of the tunnel interface, just send out a summary route. The summary (or default) route is generated on the hub, so split-horizon will not block it.
Unfortunately, summaries are not allowed with phase-2, so you’re stuck with disabling split-horizon in this case.
Sub-Optimal Routing
Now that split-horizon is disabled, you will find that the hub updates the route with it’s own IP as the next-hop IP.
This introduces a new problem, especially noticeable in phase 2. If the hub is the next hop for all routes, then all traffic will flow via the hub.
This effectively disables spoke-to-spoke tunnels, which is the whole point of phase 2.
To remedy this, use no ip next-hop-self eigrp {AS} on the hubs tunnel interface. This prevents the hub from making itself the next hop, allowing spoke-to-spoke tunnels once again.
Path Selection
The hub will usually connect to several spoke routers, and these spoke routers will be a different sites. Each site will likely have different speeds of internet connection.
However, the hub uses a single interface, the tunnel, to reach every spoke. So how can we configure different bandwidths, to influence path selection?
The answer is, we can’t.
Instead, we’re better off using delay at the spoke end to influence EIGRP’s metric.
BGP
BGP in general works really well with DMVPN, and it behaves much the same as it normally would. So here, we’re mostly talking about design factors you may consider.
There are two major ways to approach this; Using iBGP or using eBGP.
iBGP
iBGP may be worth considering if all the spokes are part of your organisation. That is, they’re not customer or third-party sites.
However, the general recommendation is to avoid using iBGP if you can. This is because it requires some extra tuning, as it was really designed to work with an underlying IGP, which we don’t have here.
If you are going to use iBGP, start by making your hubs Route Reflectors. This prevents the need for an iBGP full mesh, which isn’t possible in DMVPN (no peering between spokes remember?)
In phase 1 or phase 3, the hub routers will need to be the next-hop. This is simply configured with the next-hop-self command. In phase 3, even though the hub is the next hop, NHRP shortcuts still enable spoke to spoke communication.
Phase 2 is quite difficult to get working with iBGP, so try to stick to phase 1 or 3 (this is becoming a recurring theme; Generally avoid phase 2 with dynamic routing).
eBGP
eBGP is suitable whether you have a single organisation, or a multi-tenancy deployment.
Typically, your hubs will be part of your core AS. What I mean by this, is that your hubs will generally be configured with iBGP as far as the rest of your internal network is concerned, and use eBGP to peer with the spokes.
For the spoke routers, there are two approaches to take. One, as shown above, is to give each and every spoke a different AS.
The other option is to give the same ASN to every spoke router, as shown below.
By default, using the same ASN at each site will result in each spoke dropping routes originated by another spoke.
When a spoke receives a route from the hub, it will look at the AS-Path. It will see its own ASN in the path, and assume there is a loop. It will then drop the route.
There are a few ways we can deal with this. One is to use a different ASN for every spoke, which is a simple solution.
Another option is to use phase 1 or phase 3, and only send a default or summary route to each spoke. As the hub originates the route, the spoke ASN, is not in the path, and therefore the route is not dropped.
Specific routes from other spokes will still be dropped, but that won’t matter due to the summary. NHRP redirects in phase 3 will still allow for spoke to spoke communication.
Phase 2 works best if each spoke has a different ASN. If you’re determined to use phase 2, and still want each spoke to have the same ASN, you need to use additional BGP tuning.
For example, you may use allowas-in to bypass loop prevention, or use some sort of AS rewriting. However, this is all a workaround and is not recommended.
L3VPNs
An advantage of using BGP is that you can add VRFs and MPLS to create an L3VPN.
This is a topic all of its own though. Keep an eye out for a future video discussing this.
Dynamic Neighbours
The downside to BGP is statically configuring each neighbour. If you want to minimise this, you could consider dynamic neighbours.
The spoke will still need to be configured manually, but the hub can be configured with a listen range, and will automatically peer with spokes if they are part of the correct range.
If you are using eBGP with different ASN’s at each spoke, dynamic neighbours becomes more tricky, but is still possible with alternate ASN’s.
The down side is that dynamic neighbours require the use of peer-groups, which won’t work with BGP templates.
OSPF
OSPF is challenged in the DMVPN arena for one particular reason; As the hubs have a single tunnel interface, the spokes that connect to it all have to be in the same area. This will limit scalability, which may or may not be a concern to you.
If you’re going to use OSPF, make sure that your hubs are the DR and BDR. If you only have one hub, make it the DR, and don’t configure a BDR.
The key point here is that the spokes should never be elected as DR or BDR. You can enforce this with ip ospf priority 0.
If we configure OSPF normally, we will see loads of neighbour resets. This happens because we’re using a tunnel interface, which OSPF treats as a point-to-point network by default, which doesn’t work in a multi-point interface.
To resolve this, change the tunnel interface’s network type to broadcast.
If you’re using phase 3, you could also use multipoint or non-broadcast (non-broadcast requires manual neighbour definitions).
For phase 2 though, stick with the broadcast type. Other types will draw traffic through the hub, which will prevent the spoke to spoke tunnels.
ODR
ODR is quite rare, but as it’s made for hub and spoke topologies, it may be suitable for a small DMVPN deployment.
The biggest concern with ODR is the CDP timing. CDP frames are sent every 60 seconds. Dropped routes are marked as invalid after three CDP interfals (180 seconds by default), and are removed from the routing table after 4 intervals (240 seconds by default),
If there’s a fault in the network, you’re going to have really bad convergence times. So, it is recommended to tune the CDP timers down quite a bit, to something that suits your needs.
Even though ODR is very simple, we can still have dual-hubs for redundancy. To achieve this though, we need to build two DMVPN clouds; One to each hub.
traffic is load-balanced across the clouds by default. If one cloud fails, the other is used.
References
Cisco Live – Advanced Concepts of DMVPN – BRKSEC-4054
IPSpace – Scaling BGP-Based DMVPN Networks
Fry Guy – DMVPN and Routing Protocols – OSPF
Cisco – Configuring Dynamic Multipoint VPN with On-demand Routing