559 Words. Plan about 2 minute(s) to read this.
It seems I had no end of interruptions this week. Just…stuff. All kinds of stuff getting in the way of studying. Nevertheless, I was determined to finish IEWB Vol.3 lab 2 tonight to stay on schedule, and so here I am at 1:30am, all done, plus set up for Lab 3 to commence, uh, whenever I roll out of bed tomorrow morning. I guess technically, later this morning. :)
I did learn some things on these labs. It’s killing me that I did all those DOiT labs, plus Narbik’s, and I’m still running into technical facts I managed not to learn here in the land of InternetworkExpert.com.
Here’s something I didn’t know: OSPF routers don’t have to have the same process ID to form an adjacency. I had no idea…thought that was a requirement. Man, is my face red. I’ve worked on some sizable OSPF networks (merged a couple together, in fact), and I didn’t know that. Well, knowing that fact makes for an interesting solution related to OSPF summarization. It’s late and I’m tired…but let’s see if I make enough sense as I describe this. The task is to summarize all the routes in the lab into a couple of /16’s, and advertise them to one specific OSPF neighbor, a backbone router out at the edge of the topology. Let’s say R1 is doing the summarizing, and BB1 will receive the summary routes. Here we go.
- “area range” is out, because that floods a summary LSA into the entire area. That means all the neighbors will get the summary. And it only works on ABRs.
- “summary-address” is an option, but “summary-address” only works on ASBRs. In other words, you can only summarize external routes on the originating router. OSPF may accept the command in other contexts, but it doesn’t do anything. (Narbik’s “Sure, you can have a million dollars” for you bootcampers. :P ) But it seems like a better bet than “area range”.
- Okay – so now we’ve got the more likely command to use (“summary-address”), but a lot of the routes we need to summarize aren’t external. Add to that problem multiple neighbors, and it still doesn’t seem like the right solution.
- But wait! We can get creative here to solve this problem. Here’s how. On R1, let’s create a second OSPF process on R1. Okay, cool.
- Now, peer with BB1 (the neighbor we need to send the summary to) across the new process ID. Remember that R1’s new process ID and BB1’s don’t have to match.
- So, now R1 and BB1 have an adjacency on the new process ID, let’s call it 2. R1 is exchanging LSA’s with the rest of the OSPF environment via the original process ID, let’s call it 1.
- From R1’s perspective, process ID 1 and 2 are separate worlds. If we want R1’s OSPF 1 routes to show up in OSPF 2, what do we have to do? Redistribute. And when you redistribute in OSPF, what are you creating? External routes. And what does the OSPF “summary-address” command summarize? External routes.
- So now on R1, do mutual redistribution between OSPF 1 and OSPF 2. Then in OSPF 2, run your “summary-address” commands. BB1’s only going to get the summary routes now. Slick, huh?
Okay, I’m totally wiped out now. It took me 30 minutes to knock out this feeble article…must…go…to…sleep… zzzzzzz…
Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks