OSPF between locations

Static routes are predictable, and that is their great advantage. They are also dim: a route stays in place when the path underneath it has gone. As long as there is exactly one path to every site, that is not a problem. The moment there are two, something has to choose, and that something is a routing protocol.

When you need it

• Two paths to the same site. A fibre link with a tunnel over the internet as a spare, or a ring of tunnels between three or more locations.
• Sites that have to reach each other through a third one. With a handful of branches you can do that by hand; from about ten onwards, keeping routes up to date on every router has become the actual job.
• Networks that change. Otherwise every new subnet at one site means another route on every other router.

And when you do not need it: a head office with five branches, each arriving over one tunnel. One path, one route. A protocol only adds moving parts there. See A head office with five branches.

Where it lives in the tool

The section is called Routing (OSPF, BGP, policy). It is off by default and only the Core router role switches it on, so inside a site you enable it per router through Configure on that device.

What you fill in:

• Loopback/router-id. Put a /32 address here, 10.255.0.1 for example. The tool makes a bridge called lo with protocol-mode=none and puts that address on it. That is the address by which you recognise this router in every log line and neighbour table, and it survives an interface going down. Give every router one, counting up.
• OSPFv2 switched on.
• Areas. One is already there: backbone with area id 0.0.0.0. Per area you can set the type to default, stub or nssa.
• Interface templates. Per row: which area, which interface (the list includes your tunnels), or a network instead of an interface, the cost, whether the interface is passive, and whether MD5 authentication is on.
• Redistribute, set to connected by default, and whether this router originates a default route.

What the script produces

/routing ospf instance
add name=ospf-v2 version=2 router-id=10.255.0.1 redistribute=connected disabled=no
/routing ospf area
add name=backbone area-id=0.0.0.0 instance=ospf-v2 disabled=no
/routing ospf interface-template
add area=backbone interfaces=wg1 cost=10 type=broadcast auth=md5 auth-key=... auth-id=1 disabled=no

That is all. One instance, the areas you entered, and a template per row.

Areas, without ceremony

Areas exist to stop every router hearing everything about every other router. With ten routers that is not a problem, so:

• Up to roughly fifty routers: everything in area 0. One area, done. That is not laziness, it is the right answer for a network of this size.
• If a site has several routers inside it, give that site its own area (0.0.0.1, 0.0.0.2) and let only the site router take part in area 0. The rest of the network then hears one summary instead of every internal network.
• Stub is useful for a site that only needs a default route and nothing about the outside world. The tool sets the type, but offers no field for the default route's cost or for summarising an area. You do that by hand.

The honest part

The tool generates OSPF, but it does not design OSPF. This is what it does not do:

That second row is the most important line in this chapter. WireGuard only forwards what is in the allowed address, and OSPF hellos go to multicast address 224.0.0.5. The tunnel the tool builds puts the far end's address and the networks behind it in the allowed address, but no multicast. The result: the tunnel works, ping works, and OSPF never gets past Down. Add 224.0.0.5/32 on both sides, or use a GRE tunnel for the OSPF link, which carries multicast without help.

MTU, the second silent cause

When building a neighbour relationship, OSPF exchanges a description of its database, and both ends compare their MTU while doing so. If it differs, the neighbours stall in Exstart or Exchange and never reach Full. That is exactly the fault the tool's MTU checks report for cabled links: the two ends of a cable have a different MTU. For tunnels the tool does not run that check, so verify there yourself that the MTU matches at both ends.

A workable setup

1. Give every router a loopback: 10.255.0.1, .2, .3, and so on. That becomes its router id at the same time.
2. Lay the tunnels you need and leave Routes to the other location off: OSPF is going to provide those routes, and a static route alongside is a route that stays when OSPF withdraws its own.
3. Switch the routing section on on every router, with one area, backbone.
4. Add an interface template per tunnel on each router, in area backbone, with MD5 authentication on and the same key everywhere.
5. Add a template for the internal networks too, with passive on. Passive means the network is advertised but no neighbours are looked for. You do not want OSPF hellos on a workstation VLAN.
6. Leave redistribute on connected, but think about what that publishes. On a router with a WAN interface, your provider's transfer network is part of it.
7. Let one router, usually the head office, originate the default route with if-installed. That route then disappears by itself when that office loses its internet.

Checking it

• /routing ospf neighbor print: every neighbour should be in Full. One stuck at Exstart points at the MTU. Nothing at all points at multicast in the allowed address.
• /ip route print where ospf: are the other sites' networks there, with the right tunnel interface as their gateway?
• Unplug the primary path and watch whether traffic moves to the spare within a few seconds. A second path you never tested is not a second path.

Further reading: OSPF, Static routes and A head office with five branches.