If you’re a regular reader of this blog, you know I always prefer knowledge over recipes. Unfortunately, it’s pretty hard to build that knowledge using the widely available training materials, which often just blast you with a barrage of facts that you’re supposed to memorize and deliver at the certification exam.

How about turning your training into a South Park episode?

A bit of a background first: I’m an avid follower of Presentation Zen blog, and recently read the Key to Story Structure: Therefore & But post focusing on how the South Park writers get their stories: they replace every AND with THEREFORE and BUT, turning a list of irrelevant facts into a sequence of consequences and complications.

Now imagine applying the same trick to OSPF 101 lesson, which usually goes like this:

We have OSPF routers that build adjacencies and exchange LSAs – type-1 LSAs for routers, type-2 LSAs for networks, type-3 LSAs for inter-area routes, type-4 LSAs for ASBRs and type-5 LSAs for external routes. Then they run a shortest-path algorithm to compute the best topology.

It’s crystal clear what’s going on and WHY we need all these different LSA types, right?

How about rephrasing that paragraph as a story:

We want to build a network in which the routers automatically figure out the network topology and compute the best paths to use, BUT we cannot do that unless the routers know what the topology of the network is, BUT we cannot get there unless the routers discover who their neighbors are first, THEREFORE we need a mechanism that will allow the routers to discover their neighbors, THEREFORE there’s a hello protocol in OSPF.

Now we know who the OSPF neighbors are, BUT we still can’t do anything useful because we don’t know what’s beyond those neighbors, THEREFORE we need a mechanism that allows the routers to exchange information about their view of the network, THEREFORE we have Link State Advertisements in OSPF.

The easiest LSA we can have is the router LSA in which a router tells everyone who the adjacent routers are, BUT that would be way too cumbersome for subnets with many routers, THEREFORE we need a network LSA, BUT there might still be a problem if we get too many routers in an area, THEREFORE we need multiple areas, BUT a router inside one area wouldn’t see what’s in other areas, THEREFORE we need inter-area LSAs to propagate information between areas, BUT it might not make sense to propagate all intra-area information verbatim, THEREFORE we might want to summarize information at the area boundary.

MEANWHILE AT THE RANCH (yeah, you really should read that blog post) we might be running another routing protocol in combination with OSPF, THEREFORE we need to insert the information from that routing protocol into OSPF, THEREFORE we need another LSA type to transport external routes in OSPF, BUT we might not want to see every single external route in our OSPF domain, THEREFORE we should be able to summarize the external routes before injecting them in OSPF.

Got the idea? The next time you’re preparing a presentation or a training session, make sure it’s a story and not a list of irrelevant facts.