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… and 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 real difference between area 0 and other areas arises when you connect multiple areas together. OSPF is really a distance-vector protocol across multiple areas, and the area number serves as a split-horizon mechanism - inter-area routes are not propagated across non-backbone areas.
So yes, it’s perfectly fine to run OSPF in a single area, use area# 123, and make it an NSSA area. 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.
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 ;)