Nothing should be new here for us. We've really discussed all of this already when we discussed how many routers should we have within an area, why we create areas. We've already discussed all of that. We can see here if we have a lot of routers in one area, that means we have a lot of link-state advertisements, or LSAs. And what does that mean for Dijkstra's algorithm? A lot of processing.
I want you to look at the smaller routing tables if summarization is used. We can perform summarization on the area border routers. Now what LSA type generates inter-area routing? It's Type 3. By default we have unsummarized routes. But with a command called the area range commands, we can summarize. And that's going to repackage the Type 3 routes, so it has fewer routes summarizing.
- Single-area OSPF
- Many LSAs are processed on every router
- Large routing tables
- Multiarea OSPF
- LSA processing is confined to an area
- Smaller routing tables if summarization is used
- Scalable / Best design / More complex (knowledge)
And I want you to see this. It's done on area border routers. So we don't have multiple areas, we don't have ABRs, and so we don't have that place where we can perform route summarization. So we really need to have multiple areas, if only to perform summarization at the key strategic places. That is what makes routing protocols scalable. That's the number one thing with any dynamic routing protocol, is, to make it scalable summarization first. Then areas have other benefits, compartmentalization of the Type 1 and 2 LSAs, and the Dijkstra's algorithm that is run for intra-area routing. But summarization is job number one. One of the strengths of OSPF is its ability to scale for really large environments. Can we scale OSPF in a single-area OSPF environment? No. Not at all, not at all. Area 0 – how many routers we said? 50 routers. That's not scalable. So if you want to implement a truly scalable solution for OSPF for really large environment, you're going the multi-area OSPF route.
Planning to implement OSPF
If you're planning OSPF, let's talk real world here. You're planning OSPF, you want to make sure you've got the feature set on your chassis to run it. So you're going to have to go to your router chassis, make sure if you've got some of the newer router chassis that you're licensed for OSPF; look at your multilayer switches, which are going to be running dynamic routing protocols also, and make sure OSPF runs there. That's number one. You're not going to rollout an OSPF implementation when you don't support it.
Enhanced Interior Gateway Routing Protocol, or EIGRP, is more widely supported than OSPF in a Cisco shop. You got Cisco gear, you're more likely to have EIGRP support, believe it or not. Then you have to think, "I got my addressing. OSPF is going to be advertising the subnets of those. I have to understand that where do I draw the lines between my areas. Where's the backbone which is going to tell us where the ABRs are going to live? Where do I perform redistribution or you said default information originate command which makes routers ASBRs?" and then figure out a good time to do it. How are we going to roll this out? How are you going to roll it out?
We have to think about, when we are doing a rollout, administrative distance, by the way. Because you can have two different sources running at the same time. An administrative distance, we choose for instance EIGRP over OSPF, because EIGRP is more trustworthy. So how are we going to roll this out? It should be scheduled for a time when people shouldn't be in the office - like the weekends. And then do the job of configuration, which should be quick. It should be 90% planning for OSPF and then 10% typing in a few commands, maybe even doing some copying and pasting, having all of the configurations ready to go. You can do that all ahead of time. And then test, validate, "Do I have my neighbors? Are all the routes showing up in my routing table? Are these the optimal routes? Do I have any suboptimal pathway?" That's how we would do in implementation of OSPF.