A few weeks ago, we added OSPF areas functionality to netlab. In the next release¹, you’ll be able to configure stub areas, NSSA areas, inter-area route summarization and filtering (OSPF ranges), and summarization of NSSA type-7 prefixes for OSPFv2 and OSPFv3.

OSPFv2 (defined in RFC 2328) is 27 years old, and NSSA functionality (RFC 3101) was last touched 22 years ago. One would hope the implementations in network devices are mature and feature-complete. Yeah, keep dreaming 🤦‍♂️.

When we started developing the configuration templates for OSPF areas, I wrote a comprehensive integration test that checks:

• Configuration of stub and NSSA areas;
• Summarization of intra-area routes (OSPF ranges)
• Summarization of type-7 NSSA routes (NSSA ranges)
• Setting the default route cost for stub and NSSA areas
• Totally stubby areas (no inter-area routes are inserted into the area)

The test topology is (as always) available on GitHub, and the test results are summarized in the OSPFv2 and OSPFv3 test results (Area Parameters somewhere close to the bottom of the page; click the Device link to get more details).

As you can see from the test results, of the devices on which we implemented this functionality², only Junos and the latest FRR release³ passed all the tests with flying colors. Meanwhile:

• Arista EOS (release 4.33.1F), Cisco IOS (release 17.12), Cumulus Linux 5.10 (the last public version), and Dell OS10 (release 10.5.6.6) do not support NSSA ranges
• It’s impossible to configure the cost of the type-7 default route inserted into the NSSA area on Aruba CX and SR Linux
• There is no way to configure the range costs (for supported ranges) on ArubaCX or Dell OS10.

But wait, there’s more. Dell OS10 sometimes gets confused⁴ when facing the “complex” setup described above and forgets to set the E bit on router LSA, making the translated type-5 LSAs useless.

As you can see, it’s best not to trust vendors when they claim they support some functionality. I’m positive that all of the above vendors claim they support RFC 3101, and technically, they’re not wrong; the devil is in the details, which are often caused by the weasely “should” wording in the RFCs.