Running OSPF in a Single Non-Backbone Area

One of my subscribers sent me an interesting puzzle:

One of my colleagues configured a single-area OSPF process in a customer VRF customer, but instead of using area 0, he used area 123 nssa. Obviously it works, but I was thinking: “What the heck, a single OSPF area MUST be in Area 0

Not really. OSPF behaves identically within an area (modulo stub/NSSA behavior) regardless of the area number. Even there, you could argue that the only difference between area 0 and other areas is that the standard (and all compliant implementations) doesn’t allow you to set stub or NSSA bit in area 0.

The fundamental difference between area 0 and other areas arises when you connect multiple areas. OSPF behaves like a distance-vector protocol across area boundaries, and the area number serves as a split-horizon mechanism; inter-area routes are not propagated across non-backbone areas.

I explained that a long time ago in an article that’s probably long gone from the face of the Internet. I will try to find the source text and republish it.

So yes, running OSPF in a single area is perfectly fine. Using area# 123 and making it an NSSA area is also okay. Does it make sense? There might be some other design requirement we’re not aware of, but all other things being equal, I’d always prefer area 0 over anything else to keep things obvious.


  1. Maybe this is the missing reference from the old times you mention here? It also still has the PDF there.

    1. Wow. It's still there after 11 years. Thank you!
  2. Interesting thanks. Another classic "It works but why would you do that?" The worst example of that I've ever seen in my career was a NATed BGP session. Sure it works but why would you do that to yourself and worse still the next person along who has to learn your environment and maintain it...
  3. Your subscriber mentioned "customer VRF" so maybe MP-BGP MPLS VPN is used. The network topology works even with area 0 and non-zero areas at different sites (MPLS backbone is a super backbone/super area 0). OSPF routes within an area which are redistributed to BGP should be treated as type 3 summary LSA. A potential problem one could face is when you redistribute within the NSSA area: those OSPF routes are treated as type 7 NSSA external LSAs (converted to type 5 LSA by the ABR) and will be redistributed back to OSPF as type 5 LSAs at a different site. They would be blocked there if it's a NSSA. With NSSA you may need to configure an explicit default route.
    I'm wondering what business problem your subscriber wants to solve with a NSSA. I'm also wondering why the customer uses OSPF for interconneting sites to begin with. But I'm wondering the most who's the service provider which is supporting OSPF for peering.
    Maybe Ivan could quickly verify my statements with his highly automated CI/CD pipeline in his virutal lab ;)
    1. There could be several reasons for doing such a design, maybe the customer could be having connections to multiple business partners or maybe they want some routes from RIPv1 domain or it could be even for some political reason ;) I agree that it may not be a a best practice, but the point here is, it worked and met the customer requirement. Whether they keep it temporary or as a fixed design depends on the maturity of the organization.
Add comment