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…
I was listening to very interesting Future of Networking with Fred Baker a long while ago and enjoyed Fred’s perspectives and historical insight, until unfortunately Greg Ferro couldn’t possibly resist the usual bashing of traditional routing protocols and praising of intent-based (or flow-based or SDN or…) whatever.
Here’s what I understood he said around 35:17
Here’s a question I got on one of my ancient blog posts:
How many OSPF process ID can be used in a single VRF instance?
Seriously? You have to ask that? OK, maybe the question isn’t as simple as it looks. It could be understood as:
In case you’re not familiar with RFC 1925, its Rule 5 states:
It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.
Most routing protocols are a perfect demonstration of this rule.
Rich sent me a question about temporary traffic blackholing in networks where every router is running IGP (OSPF or IS-IS) and iBGP.
He started with a very simple network diagram:
TL&DR: Don’t use OSPF areas if you can avoid them. Don’t use NSSA areas.
Angelos Vassiliou sent me an interesting lengthy email after I published my OSPF Forwarding Address series (part 1, part 2, part 3, part 4). I asked him whether it’s OK to publish his email together with my responses as a blog post and he gracefully agreed, so here it is.
Remember the kludges needed to make OSPF NSSA areas work correctly? We concluded that saga by showing how the rules of RFC 3101 force a poor ASBR to choose an IP address on one of its OSPF-enabled interfaces as a forwarding address to be used in Type-7 LSA.
What could possibly go wrong with such a “simple” concept?
In the previous blog posts I described how OSPF tries to solve some broken designs with Forwarding Address field in Type-5 LSA – a kludge that unnecessarily increases the already too-high complexity of OSPF.
NSSA areas make the whole thing worse: OSPF needs Forwarding Address in Type-5 LSAs generated from Type-7 LSAs to ensure optimal packet forwarding. Here’s why:
In my initial OSPF Forwarding Address blog post I described a common Forwarding Address (FA) use case (at least as preached on the Internet): two ASBRs connected to a single external subnet with route redistributing configured only on one of them.
That design is clearly broken from the reliability perspective, but are there other designs where OSPF FA might make sense?
One of my readers sent me an interesting NSSA question (more in a future blog post) that sent me chasing for the reasons behind the OSPF Forwarding Address (FA) field in type-5 and type-7 LSAs.
This is the typical scenario for OSPF FA I was able to find on the Internet:
Over a month ago I decided to create a lab network to figure out how to solve an interesting Inter-AS MPLS/VPN routing challenge. Instead of configuring half a dozen routers I decided to develop a fully-automated deployment because it will make my life easier.
I finally got to a point where OSPF, LDP, BGP (IPv4 and VPNv4) and MPLS/VPN configurations are created, deployed and verified automatically.
You categorically reject the use of OSPF, but we have a couple of customers using it quite happily. I'm sure you have good reasons and the reasons you list [in the presentation] are ones I agree with. OTOH, why not use totally stubby areas with the hosts being in such an area?
While most readers, commenters, and Twitterati agreed with my take on the uselessness of OSPF areas and inter-area summarization in 21st century, a few of them pointed out that in practice, the theory and practice are not the same. Unfortunately, most of those counterexamples failed due to broken implementations or vendor “optimizations”.
One of my ExpertExpress design discussions focused on WAN network design and the need for OSPF areas and summarization (the customer had random addressing and the engineers wondered whether it makes sense to renumber the network to get better summarization).
I was struggling with the question of whether we still need OSPF areas and summarization in 2016 for a long time. Here are my thoughts on the topic; please share yours in the comments.