OSPF Routing over DMVPN

Setup

The setup for this blog is the same as in the DMVPN Phases in distance vector post. The hostnames will be Phase-number, where router 1 is the hub. Loopbacks will phase.phase.phase.routernumber and put in the same OSPF area as the DMVPN link. To make sure neighborships will not be affected by timers, I set the tunnel timers the OSPF fast timers:

We also have to make sure none of the spokes become DR, so we set their priority to 0:

Since the neighborships have to be in the same area, you can’t summarise on the hub. And since we are mapping multicast to the NHS servers and they will be our DR (if we have a DR), I will be ignoring non-broadcast versions of the network types. However, there is an interesting bit about non-broadcast networks that I will talk about in an upcoming post.

Phase 1

Phase 1 is a true hub-spoke topology. A broadcast network type will not work. So, we will be forced to point-to-multipoint connections. We have two options for this, all routers are point-to-multipoint or only the hubs are point-to-multipoint and the spokes are point-to-point. The last option is exactly following the topology and it is the least config, since tunnel interfaces are point-to-point by default anyway.

The timers here are important, since point-to-point uses different default timers than point-to-multipoint. However, I noticed an interesting quirk on my test-routers: when setting the interface to p-t-mp, the manually set hello timer was overridden. Reapplying the hello to the interface fixed this issue.

We have loopbacks in our routing table:

And traces work:

Phase 2

As with Phase 1, if we use point-to-multipoint, things will still be routed through the hub. Will multipoint-to-multipoint be any different? Actually no, because all spokes only build a neighborship with the spoke and all connections are represented in OSPF as point-to-point links to the hub, with the /32 networks being set to the hub:

So, all routes will still traverse the hub, negating the point-to-multipoint capability of phase 2:

###Broadcast
So, for phase 2 a broadcast network-type should work better:

We have direct routes, let’s see what happens:

Success!

Phase 3

The whole point of phase 3 is that you can set the hub as a next-hop for all routes and it will override the RIB when the need arrives. However, the router I tried this on don’t actually listen to this.

Point to Multipoint

Setting the hub as a point-to-multipoint and the spokes as point-to-point, will get us a routing table where the Hub is used as the next hop:

All routes point through the hub, and even though NHRP redirect is set, the spoke will keep sending it to the hub, even when a tunnel is set up to spoke-to-spoke. Things routed over the tunnel will go through the hub, traffic to the tunnel ip will get redirected correctly:

Multipoint-to-Multipoint

So, what happens when we make them all point-to-multipoint? We get exactly the same behaviour. The only difference is an extra /32 in the routing table for the other spoke:

A repeat of the traceroute does not change the behaviour (see below).

Broadcast

When setting the network as broadcast, we see that the next-hop will be set correctly, the first trace goes via the hub, but tracing right after that will use the straight tunnel:

Conclusion

To make use of the correct routing paradigms, we should use the following network types per phase. Please note that Phase 3 doesn’t actually add anything when using OSPF:

Phase Network type hub Network type spoke
1 Point-to-Multipoint point-to-point
2 Broadcast (DR) Broadcast
3 Broadcast (DR) Broadcast

Leave a Reply

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