OSPF Puzzle, Part II – Analyzing OSPF Metrics, Human Style

As is the case in many parts of the computing world, computers often use different methods for coming up with an answer than we humans would use. Today, I'll take a closer look at the OSPF puzzle I began last week, today from a human perspective. Next post, I'll look at it from a router perspective, which means we'll get into some gory detail on OSPF LSAs again.

First, let me take care of most of the answers to the questions from last post. That post asked for a basic OSPF config, placing different interfaces into different areas, and to ignore the external routes for now. Depending on the wildcard masks you choose, you can configure the network commands in a variety of ways. Here's what I did for the configs. For now, I'll ignore the tuning of interface costs, and the external routes:

With this config, all five routers have OSPF enabled, in the correct areas (per the figure shown in my last post). I also added the explicit configuration of router-id's just so the LSA discussions to follow are more obvious.

Next, I asked you to figure out what configuration would be required to make the show ip route output be accurate. First, to make the right routes show up as OSPF Interarea ("IA" on the left side of the command output), all you'd have to do is make sure you put the interfaces into the right areas, per the figure. The interesting part was the metric for each route.

On R1, the metrics for the four internal OSPF routes (again ignoring the externals) were:

  • 10.1.235.0 /24:  104
  • 10.1.34.0   /24:  168
  • 12.0.0.0     /8:    154
  • 22.0.0.0     /8:    178

Now, how can you extrapolate that to OSPF costs per interface? Well, we humans process maps pretty well. All we have to do is realize that the route's cost is the sum of the OSPF costs for all outgoing interfaces in the entire route. To make sense of it, refer to this figure, which numbers the outgoing interfaces that matter in the calculation of the OSPF internal routes on R1:

So, if you take the routes one at a time, you get a few simple equations, like this:

  • Metric for 10.1.235.0/24 = 104 =  cost-link-1 + cost-link 2
  • Metric for 10.1.34.0/24 = 168 = cost-link-1 + cost-link-2 + cost-link-4
  • Metric for 12.0.0.0/8 = 154 = cost-link-1 + cost-link-2 + cost-link-3
  • Metric for 22.0.0.0/8 = 178 = cost-link-1 + cost-link-2 + cost-link-4 + cost-link-5

What I left out in the last post was that I should have at least told you R1's S0/0/0 cost, because without it, you don't have enough info to solve for all variables above. We know that the costs for links 1 and 2 added together totals 104, based on R1's route for 10.1.235.0/24. If I tell you that the cost of link 1 is 100, then a quick bit of math tells you the cost of the 5 links, as numbered in the figure, are:

  • 1: 100
  • 2:    4
  • 3:   50
  • 4:   64
  • 5:   10

With all that on the table, complete your config by choosing ALL the ways you could make the costs work out as stated here, without changing the reference bandwidth. I'll post briefly on that before the week's up, and then move on to looking at the LSAs.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Related:
Now read: Getting grounded in IoT