Do we care for how complex OSFP could be in our networks?
This type of question came up the other day while in work. While we were looking at how OSPF is deployed within our Data Centres today. We keep it simple and mostly a flat network, a few OSPF Areas and one of them been Area 0.
Do we have a need to make it complex and add multiple OSPF Areas running in Stub, Total Stub or Not So Stubby Area? We could but what are the benefits from doing this. These Area types were originally added to the OSPF protocol to keep the Link State Database small and easy to process for routers which had small amount of memory and lower end CPU many years ago. With routers and switches of today been built with 2-4Gig of memory and multi core CPU of the self do we ever worry any more that we are going to kill our network devices with overloading the OSPF LSD? That is if you are not taking/redistributing in the internet routing table into your OSPF network and not running thousands of OSPF devices within the same area, not a Service Provider!
So a bit of a background on the OSPF Area;
OSPF uses areas to reduce the adverse effects of large LSD updates flooding the network. If a link flaps within an Area every OSPF device in that area will receive the update for that link flap. In the context of OSPF, an area is a logical grouping of OSPF devices and links that effectively divide an OSPF domain into sub-domains. Routers within an area will have no detailed knowledge of the topology outside of their area. All routers within an area will share the same link-sate database. So each router will see the topology for the OSPF sub-domain and not the whole OSPF domain. Because of this each router will have a smaller link-state database which means fewer LSAs to process and therefore less impact on the CPU. This means flooding is restricted to the area and not the whole OSPF domain.
Now we have an idea of what an Area is and how these floods of LSA’s are reduced. This is where the different LSA’s come into affect. Not to go too much into the details on the different LSA’s we will focus on the three main LSA’s that help with hiding these floods. Just to recap here are the main LSA’s we have today in OSPFv2;
- 1. Router LSA
- 2. Network LSA
- 3. Network Summary LSA
- 4. ASBR Summary LSA
- 5. AS External LSA
- 7. NSSA External LSA
Along with these LSA it will also be good to recap on the different router types we will also find within a multi OSPF Area domain.
- Internal Routers – These routers have a single link-state database.
- Area Border Routers (ABRs) – Connect to one or more areas to the backbone and act as a gateway for inter-area traffic. Maintains a separate link-state database for each of its connected areas.
- Backbone Routers – Are routers with at least one interface attached to the backbone. An Internal Router whose interfaces all belong to area 0 is also a Backbone Router.
- Autonomous System Boundary Routers (ASBRs) – Are gateways for external traffic, injecting routes into the OSPF domain that were learnt (redistributed) from other routing protocols & static routes. An ASBR can be located anywhere within the OSPF domain.
Now we should have all the information we need to build a good idea of how a OSPF domain with multiple areas will function. So which of these LSA’s will be providing the most benefit for saving our memory and CPU by hiding these LSA flooding throughout the OSPF domain? That would be done mostly by LSA Type 3;
Network Summary LSAs (Type3) are originated by ABRs. They are sent into a single area to advertise destinations outside that area. These LSAs are the means by which an ABR tells the internal routers of an attached area what destinations the ABR can reach. When an ABR originates a Network Summary LSA, it includes the cost from itself to the destination the LSA is advertising. When another router receives a Network Summary LSA from an ABR, it does not run the SPF algorithm. Rather, it simply adds the cost of the route to the ABR and the cost included in the LSA. The router which receives the Type3 LSA has no knowledge of which Area this route has originated from. The ABR in short is taking the Type1 & Type2 LSA’s and even other Type3’s in some cases from one Area and translates them into Type3 LSA’s when passing them into the adjoining Area.
For routes not originated within the OSPF domain a similar approach is taken to help with masking the routes origination and saving on SPF cycles when they are redistributed into the OSPF domain, LSA Type5 found within non Stub Area types and LSA Type7 which is only found within a NSSA;
Autonomous System External LSAs or External LSAs (Type5) are originated by ASBRs. They advertise either a destination external to the OSPF domain, or a default route external to the OSPF domain. The ASBR will advertise the route into the OSPF domain either as an E1 or E2 type route. Type5 E1 LSA cost will be set by the ASBR but as with Type3 LSAs when another OSPF device receives the Type5 E1 LSA it addes the cost to the ASBR as well as the cost that the ASBR set within the LSA. As for Type5 E2 LSA the ASBR will set the cost within the LSA which will be then become a static value for the route which other OSPF devices within the domain will set as the cost to reach that route. Now within the LSD for a E2 route each OSPF device that receives this LSA will run its own SPF algorithm on how to reach the ASBR, Type4 LSA provide this information, who advertised the route into the OSFP domain but this cost is never added to the E2 route when it is populated into the route table.
NSSA External LSAs (Type7) are originated by ASBRs within not-so-stubby areas (NSSAs). An NSSA External LSA is almost identical to an AS External LSA. Unlike AS External LSAs, which are flooded throughout an OSPF domain except within a Stub Area, NSSA External LSAs are flooded only within the not-so-stubby area in which it was originated. Type7 LSA’s just like Type5 also have the function of E1 & E2 routes but for NSSA these are called N1 & N2. Both provide the same funtion but within different Area types, N1 & N2 will only be found within the NSSA are. When these routes are received by the ABR for the NSSA Area it then translates them into E1 & E2 routes and sends them into the OSPF domain which now makes that ABR the ASBR. So now my ABR just became my ASBR? Extra complexity now in my troubleshooting.
After taking in all of the above and seeing how complex our network has just gotten by breaking up our OSPF domain into multiple Areas and even making some of these Areas into a Stub or NSSA do we really realise how complex we have just made it? Are all these extra OSPF additives really needed in today’s network when they were originally added to save our precious memory & CPU on our routes?
Each network today is its own snow flake in this blizzard called the IT Industry and I am sure each one will have its own use case to how it runs OSPF across the network. Whether it is a single Area or multiple Areas utilizing Stubs, NSSA etc… It is really down to how the engineer designing the network understands the protocol. How they can get the most benefits from deploying OSPF in the manner they have within their network. Also sometimes we inherit networks which have grow organically with all the added complexity.
But do we really care for the complexity OSPF has baked in as a protocol before we start turning on these functions? Or do we want to treat our network like a CCIE lab and make it over complex just because we can?
For me today it is all about keeping the network simple and removing any unnecessary complexity from the network. Does this mean running OSPF across my data centre as a single Area0 keep it simple? Does running OSPF in this manner make it easier for other network engineers to work with and mean I wont be getting call at 2am when something goes wrong on the data centre network? It might…
I think this type of thinking could also be taken when looking at how we deploy other technologies and protocols within our networks today. Keep it simple. Would you agree?