IEWB Vol.3 Labs 1 & 2 Done – OSPF Summarization To A Specific Neighbor Using An Alternate Process ID

560 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

5 thoughts on “IEWB Vol.3 Labs 1 & 2 Done – OSPF Summarization To A Specific Neighbor Using An Alternate Process ID

  1. Good Hard work should be appreciated!!!

    It’s very very difficult to write an article describing the Tech problems after working so late and getting totally exhausted.

    ya, but this OSPF process id thing is giving us more flexibility.

    Thanks,

  2. Process IDs being locally significant is in Doyle, but is an easy thing to forget because the fact is largely irrelevant – every place I’ve seen, worked at or even spoken to someone regarding uses the same PID for all routers. Even in labs we tend to make the PIDs the same to avoid simple mistakes. This relegates a fact to trivia.

    What pulls a fact from the realm of trivia is a useful scenario like the one you described. Good information to have, thanks. Another way to skin a cat is always good (unless you’re the cat I suppose).

  3. Hey Ethan, when you mentioned peering with a specific router, are you setting the interface to NBMA and using neighbor statements? Just wondering how you would keep that summary LSA from flooding to other routers…

    Keep up the good work man.

  4. The summaries were only set in the OSPF 2 process (not OSPF 1), so it would only get flooded to the BB1 router (the only other OSPF router on the OSPF 2 segment).

    You’re right that if there were other routers that formed an adjacency with R1 on OSPF 2, the summary LSAs would have been flooded to them as well. But there weren’t any other routers to consider in the topology. The task was to fix a specific problem, but there was no requirement to “future-proof” it.

Comments are closed.