Migrating a sprawling hub-spoke network from static routes to OSPF requires a solid strategy. The best practice is to stabilize the core by enabling OSPF between hubs first, then incrementally connect the spokes to create a scalable and resilient network.

Static Route Hell to OSPF Heaven: A DevOps Guide to Untangling Your Network

I still get a cold sweat thinking about it. It was 2 AM, and the on-call pager was screaming. Our primary e-commerce database, prod-db-01, was unreachable from our web frontends. The weird part? The DB was up, the web servers were up, but they couldn’t talk. After an hour of frantic SSHing, we found it: a junior admin, trying to add a route for a new monitoring subnet, had added a conflicting static route on one of our three core hub routers. A single typo created a black hole for our most critical traffic. That’s the tax you pay for a network held together by static routes. It’s not a matter of if it will break, but when, and who gets the blame.

So when I saw a post from an engineer staring down this exact beast—a three-hub-spoke topology drowning in static routes—I felt a kinship. They asked the million-dollar question: where do you start untangling this mess? Do you configure OSPF between the hubs first, or between the hubs and their spokes? It’s a classic infrastructure problem, and doing it in the wrong order can make a bad situation much, much worse.

The “Why”: Why Static Routes Become a House of Cards

Let’s be clear: static routes aren’t inherently evil. For a simple network with one router and a default gateway, they’re perfect. The problem is that they don’t scale. In a hub-spoke model, every time you add a new spoke, or even a new VLAN in an existing spoke, you have to manually update the routing tables on every single hub router. And if you want spokes to talk to each other (via the hubs), you have to add routes for them, too.

This creates an exponential growth in administrative overhead and, more importantly, a massive surface area for human error. The network has no self-awareness. It can’t automatically re-route around a dead link. It just follows the static instructions you gave it, even if they lead off a cliff. OSPF, a dynamic routing protocol, solves this by letting routers talk to each other, share information about the network’s topology, and calculate the best paths automatically. It’s self-healing and scalable.

So, how do we get there from here? Here are three paths, from the quick-and-dirty to the architecturally sound.

Solution 1: The “Band-Aid First” Approach (Hub-to-Spoke First)

In this scenario, you leave the static routes between your hubs (`atl-hub-rtr-01`, `chi-hub-rtr-01`, `sea-hub-rtr-01`) in place and start by configuring OSPF between each hub and its direct spokes.

The Logic

The thinking here is to get some quick wins. You immediately reduce the administrative burden for the “leaf” nodes of your network. Each spoke learns about the hub dynamically, and the hub learns about the spoke’s local subnets. It feels like progress.

The Harsh Reality

This is, in my opinion, the wrong order. Your core network—the critical link between your hubs—is still brittle and dumb. You’re building a modern house on a crumbling foundation. Worse, you now have to deal with route redistribution (injecting OSPF-learned routes into the static routing table, and vice-versa). This is complex, prone to error, and can easily create routing loops if you’re not extremely careful. You’re trading one kind of complexity for another, more dangerous kind.

Darian’s Warning: I only recommend this approach if you’re under immense pressure to connect a new spoke right now and absolutely cannot get a maintenance window to touch the core. Know that you’re incurring technical debt that you’ll have to pay back later.

Solution 2: The Architect’s Choice (Hub-to-Hub First)

This is the way. You treat the connection between your hubs as the network’s backbone. Your first priority is to make that backbone stable, resilient, and intelligent. Only then do you start connecting the spokes to it.

The Step-by-Step Plan

1. Stabilize the Core: Schedule a maintenance window. On each of your hub routers, remove the static routes that point to the other hubs. Enable OSPF on the interfaces that connect the hubs to each other.
2. Verify, Verify, Verify: Ensure all three hubs have formed OSPF adjacencies and are sharing routes. The routing tables on the hubs should now be populated with routes to each other’s networks learned via OSPF. Your core is now dynamic.
3. Connect the Spokes, One by One: Now, you can move to the spokes. Pick a spoke, like den-spoke-01 connected to atl-hub-rtr-01. On both devices, remove the static routes pointing to each other and enable OSPF on the connecting interface. The spoke will learn about the hub, and through the hub, it will learn about the entire core network and the other hubs.
4. Rinse and Repeat: Systematically repeat step 3 for every spoke in your network. The process is clean, incremental, and dramatically lower risk than the first approach.

Here’s a simplified config snippet for what this might look like on a Cisco-like device for atl-hub-rtr-01:

! Step 1: Configure OSPF between hubs
router ospf 100
 router-id 1.1.1.1
 ! Announce the networks connecting to other hubs
 network 10.100.1.0 0.0.0.255 area 0
 network 10.100.2.0 0.0.0.255 area 0
 !
! (Wait for hub-to-hub adjacencies to form and verify)
!
! Step 3: Later, bring a spoke online
! Add the spoke's connecting network to OSPF
 network 10.20.5.0 0.0.0.255 area 0
!
! Don't forget to remove the old static routes!
! no ip route 192.168.30.0 255.255.255.0 10.100.1.2 ! Old static route to chi-hub
! no ip route 172.16.10.0 255.255.255.0 10.20.5.2 ! Old static route to den-spoke

Pro Tip: Use OSPF areas! For a hub-spoke topology, putting the core hub-to-hub links in `area 0` (the backbone area) and placing each spoke in its own separate area is a fantastic design pattern for scalability and stability.

Solution 3: The “Greenfield” Option (Build a Parallel Network)

Sometimes, the existing network is so critical and so messy that you can’t risk performing surgery on it while it’s live. If you have the budget and the resources, the safest option is to build the new network alongside the old one and then migrate.

The Logic

You essentially build your ideal OSPF-powered network from scratch on parallel infrastructure. This could be new VLANs on existing switches, a new set of GRE tunnels, or even separate physical hardware. You get everything working perfectly—all hubs talking via OSPF, all spokes connected—in a non-production environment. Then, during a planned outage, you simply swing the gateway IPs or application traffic over to the new, fully-tested network.

Pros and Cons

My Final Take

For 95% of situations, Solution 2 (Hub-to-Hub First) is the right call. It’s a pragmatic, logical, and safe way to incrementally upgrade your network from a brittle liability into a resilient asset. It balances risk and effort perfectly. Fix the foundation before you remodel the house. Your future self, and the next engineer on call at 2 AM, will thank you for it.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions