OSPF Design Number of Routers in Backbone area 0

[Meddane]

n the design of the OSPF routing protocol, the number of routers in an area is widely discussed in deployments and forum, and according to recent studies and the power of modern routers, it is no longer a major concern. However, the number of routers in the backbone area 0 is still relevant. The backbone area in the OSPF world is critical and serves as the central point in a multi-area architecture, with direct connections to non-backbone areas (which is the core function of how the OSPF protocol operates) for the exchange of link-state information between non-zero areas, filtering, etc. This can lead to instability in the topology, an impact on convergence time, and potentially increased CPU utilization, as all inter-area information always passes through the backbone area.

Therefore, it is extremely prudent to consider this point and be cautious when adding routers to the backbone area. Best practices suggest reducing the number of routers and including only those that are necessary in addition to the ABRs.

Another critical point in the backbone area is the importance of redundancy to prevent partitioning of the backbone area in the event of a link failure. A good design for a backbone area ensures that no single link failure can cause a partition in area 0, which implies that a full mesh between the routers would be ideal. In the example below, if the link between R4 and R5 fails, the exchange of link-state information and communication among the internal routers of area 0 would be disrupted due to the inter-area loop prevention rule, which states that an ABR always ignores Type-3 LSA learned from another ABR through a non-backbone area.

[Martin L]

Very Interesting.... thanks for sharing!

[Joseph W. Doherty]

In the design of the OSPF routing protocol, the number of routers in an area is widely discussed in deployments and forum, and according to recent studies and the power of modern routers, it is no longer a major concern.

Well, although it's certainly true, OSPF router control plane capacity has increased over the years, allowing an increased number of OSPF routers to run well within an OSPF area, possibly downgrading the concern for the absolute number of routers per area, two factors that impact the number of routers within an area are: first, the topology complexity and second, the OSPF implementation.

Consider the old rule of thumb of (about) 50 routers per area, but consider the extreme topology difference for a star topology, where the hub router (e.g. L3 switch) has 48 downstream OSPF neighbors, all just having the single upstream hub router as their neighbor vs. the 48 routers being connected in a full mesh.

(BTW, also consider if the hub was just L2 (switch), and the 48 OSPF routers each saw the other 47 as OSPF neighbors on the same subnet.)

Keep in mind, top tier vendors like Cisco, their OSPF implementation has proprietary enhancements, above and beyond what the OSPF RFC calls for.  Such enhancements often allow more OSPF routers per area.

So, the number of OSPF routers, alone, might not be a major concern, but the combination of the number of OSPF routers, the underlying area topology, and the OSPF implementation, probably should still be a major concern, as you truly do not want to inadvertently discover how many straws it takes to break the camel's back.

Another critical point in the backbone area is the importance of redundancy to prevent partitioning of the backbone area in the event of a link failure. A good design for a backbone area ensures that no single link failure can cause a partition in area 0, which implies that a full mesh between the routers would be ideal.

Fully agree partitioning area zero is a "bad thing", which makes redundancy in area zero particularly important, but don't agree this implies a full mesh is the ideal solution, except perhaps in cases with a low number of nodes, like a handful, or your example of just 4 area zero routers. 

In your example, just adding an area zero link between R1 and R2 would avoid a single point of failure, such as your example breaking the link between R4 and R5.