Multi-Area OSPF with FRRouting: Scaling Linux Networks for the Enterprise

The Problem: The ‘Flat Network’ Performance Wall

Most network admins start their OSPF deployments by tossing every router into Area 0. In a small lab or a startup office with five routers, this works perfectly. However, the ‘flat’ design begins to struggle once you manage 50, 100, or 200 Linux-based routers acting as edge gateways.

In one 150-node production environment, I saw a single flapping 1Gbps link in a remote branch cause core router CPU utilization to jump from 10% to 95%. Because every router in a single OSPF area must maintain an identical Link State Database (LSDB), any change triggers a Shortest Path First (SPF) calculation across the entire fleet. This results in 10-15 second convergence delays and wasted cycles on hardware that should be moving packets, not recalculating maps.

Root Cause: LSDB Bloat and SPF Overload

The issue stems from how OSPF handles Link State Advertisements (LSAs). In a single-area setup, every node knows the exact state of every link in the entire autonomous system. When a subnet goes down five hops away, a Type 1 LSA floods to every single router in the organization.

As the network grows, three things happen:

• Memory Exhaustion: An LSDB with 5,000+ prefixes can consume hundreds of megabytes of RAM, taxing older Linux nodes or lightweight VMs.
• Computational Load: The Dijkstra algorithm (SPF) becomes significantly more taxing as the number of nodes and links increases.
• Instability: A single flickering fiber patch cable can create a ‘routing storm’ that destabilizes the whole network.

The Solution: Hierarchical Design

We solve this by moving from a flat topology to a hierarchical one. By breaking the network into multiple areas, you confine detailed topology information within specific boundaries. Only the backbone (Area 0) needs to know the summarized paths to other areas.

The Area Border Router (ABR) acts as the translator here. It takes detailed Type 1 and Type 2 LSAs from a local area and condenses them into a single Type 3 Summary LSA for the rest of the network.

Approach Comparison: Single Area vs. Multi-Area

Feature	Single Area (Flat)	Multi-Area (Hierarchical)
LSDB Size	Full topology (Large)	Summarized (Small)
SPF Impact	Global recalculation	Local to the area
Configuration	Simple	Moderate
Scalability	Caps at ~50-80 routers	Supports 1000+ nodes

Pros & Cons

Pros:

• Lower CPU and RAM overhead on edge routers.
• Faster convergence because SPF only runs on a subset of the map.
• Fault containment prevents a local link flap from hitting the core.

Cons:

• Requires a strict IP addressing plan for effective summarization.
• All non-backbone areas must have a physical or logical path to Area 0.

Recommended Setup

A standard enterprise hierarchy usually follows a hub-and-spoke model:

• Area 0 (Backbone): The high-speed core where all ABRs connect.
• Regular Areas (e.g., Area 10): Regional offices that require specific external routing data.
• Stub Areas (e.g., Area 20): Resource-constrained branch offices. These areas drop external (ASBR) routes and use a simple default route instead.

Implementation Guide: Multi-Area OSPF with FRRouting

We will use three Linux nodes running FRRouting (FRR) on Ubuntu 22.04. Router-ABR bridges Area 0 and Area 1. Router-Backbone sits in Area 0, and Router-Branch resides in Area 1.

1. Install FRRouting

Run these commands on all three nodes to install the routing suite:

sudo apt update
sudo apt install frr -y

Open /etc/frr/daemons, set ospfd=yes, and restart the service:

sudo systemctl restart frr

2. Configure the Backbone Router (Area 0)

Enter the FRR shell. This router only handles backbone traffic.

# vtysh
conf t
router ospf
 ospf router-id 1.1.1.1
 network 10.0.0.0/30 area 0
exit
write memory

3. Configure the Area Border Router (ABR)

The ABR is our most important node. It connects both areas and performs route summarization to keep the Area 0 routing table clean.

# vtysh
conf t
router ospf
 ospf router-id 2.2.2.2
 network 10.0.0.0/30 area 0
 network 192.168.10.0/24 area 1
 # Summarize all Area 1 subnets into one advertisement
 area 1 range 192.168.10.0/24
exit
write memory

4. Configure the Stub Area (Branch Router)

By defining Area 1 as a Stub, we prevent external LSAs from flooding the branch router. This keeps the local routing table lean.

# vtysh
conf t
router ospf
 ospf router-id 3.3.3.3
 network 192.168.10.0/24 area 1
 area 1 stub
exit
write memory

Note: You must also apply the area 1 stub command on the ABR. If the stub flags don’t match, the neighbor adjacency will never form.

Verifying the Hierarchy

Check the Router-Branch routing table to ensure the hierarchy is active.

show ip route ospf

If configured correctly, you will see a default route (0.0.0.0/0) pointing to the ABR. You won’t see 50 individual routes from other areas. On the Backbone Router, verify the summary:

show ip ospf database summary

You should see a single Type 3 LSA for 192.168.10.0/24 rather than individual link states from inside Area 1.

Optimizing SPF Timers

Standard OSPF settings can be too aggressive for large Linux-based networks. You can prevent CPU exhaustion during a link failure by adding a slight delay to the SPF calculation.

conf t
router ospf
 timers throttle spf 5000 10000 10000
exit

This tells FRR to wait 5 seconds before its first calculation. It then caps the hold time at 10 seconds. This is a critical safety net for environments with unstable wireless backhauls or flickering fiber links.

Final Thoughts

Moving to a multi-area OSPF design is the most effective way to scale Linux routing. By using ABRs for summarization and Stub areas for the edge, you reduce the computational load on your hardware. While the initial planning takes more effort, a hierarchical network is far easier to maintain than a bloated, flat Area 0.