ICND2 200-105

ICND2 200-105

OSPF Data Overview

This is going to be a review for you, but I want you to understand where Open Shortest Path First, or OSPF, lives in the world of dynamic routing protocols. There's Routing Information Protocol, or RIP, which is distance vector, there's Enhanced Interior Gateway Routing Protocol, or EIGRP, which is balanced hybrid or advanced distance vector, whatever you want to say there. OSPF is link state. That really means to me one thing. That means it runs Dijkstra's Shortest Path First (SPF) Algorithm; that is something that is common to all link state routing protocols. They do tend to be more scalable, although EIGRP is tremendously scalable. One thing that does separate them from all the other dynamic routing protocols is, they have a full picture of the topology inside of their own area and they have a pretty good set of details regarding networks outside of their area, but not the same level, okay. Dijkstra's algorithm really helps us get around our own area. When we do have changes we just compartmentalized a small, little change, that is a link-state advertisement.

Link-State Routing Protocols

A link-state advertisement is a piece of information, which can be contained within what is called a link-state update and we send these around the topology. We listen to these as well when we get them, we update our own routing table based on first-hand information. And we get a lot of details, things like router ID, who generated this update, the sequence number to make sure that this is new information and not stale information. But still let's not lose sight of the fact that we're still just trying to understand all of the different subnets in our autonomous system and figure out the best way to get there.

When it comes to these link-state advertisements, or LSAs, and it comes to the sending of LSAs when the topology change occurs, is there any other point in time when we might send an LSA? When you think about RIP, you think back to how it sent its update every 30 seconds by default whether a change occurred or not. Does OSPF have any functionality like that as well? It sort of does and it sort of doesn't depending on your take on the matter, but here's the deal. There is something called a paranoid update that you should all know about. The paranoid update has a really unusually long timer. Most timers in networking are very short. This one is boy, it's probably the longest timer I know about and it's 30 minutes and it just says this.

If you haven't heard anything for this duration of 30 minutes, let's just make sure everybody is still on the same sheet of music, on the same page. And this does also align with the aging time of an update, which is 60 minutes. So at about the halfway point of getting to the 60 minutes where LSA bit of information is going to expire, we just readvertise it, make sure everything is okay. So this is called the paranoid update.

OSPF Data Structures

OSPF deals with three different tables; first table being the neighbor table. You think about your neighbors, who are they? Well that's what this neighbor table is all about for OSPF. Who are your neighbors? Who have you formed a neighbor adjacency with? And this is a really important component of OSPF. Will I ever exchange information routing information that is utilizing OSPF with someone who is not my neighbor? No it is a prerequisite, so to speak, on exchanging information and in fact we need to see each other in our adjacencies to be able to do that. So this is something that's quite important, so if you're troubleshooting routing, you look at your routing cable, something is a miss, you're missing information. Well you can come back here and if you don't have any neighbors, you know that it's not something about a router isn't advertising it, it's something more fundamental; we don't even have a neighborship. So we have our neighbor table and then from there we send out our LSAs. And what do we do when we receive LSAs? We gobble them up, we take them and we put them inside of a topology table. So this topology table contains all of that information about our OSPF area. And it's important for us to gather that and then perform calculations on it to figure out what is the best way to get all these different destination networks.

Dijkstra's Algorithm

So, so far we've seen things that are really common to EIGRP as well neighbor table in EIGRP; a topology table in EIGRP. But do you remember EIGRP's algorithm? It was DUAL. Here we're talking about OSPF; OSPF has a different set of gears that are going to churn on that data called the Shortest Path First Algorithm, named by the gentleman who invented it, Dijkstra. And this SPF Algorithm is going to go destination by destination; here is the way to visualize it, not like you need to program this. You place yourself at the root of the tree. You find yourself basically in the topology database. Router does that and then it has a list of all the destination networks that it knows about. How do we know that? The topology table can easily be read to list off all of the networks and then one-by-one Dijkstra's algorithm calculates the best path to each of those destinations. So it's not like we run Dijkstra's algorithm and it answers all of the best paths. We run it each time we have to get to a unique destination network. And the way that it works is it assigns a cost to the links. And when it gets to a certain point when it says oh, I got something better, I'm going to stop running that calculation because I've already established a better pathway to that destination. And so Dijkstra's algorithm, a complex algorithm, but ultimately it just tells us here's the best way to go, and then where does that information go inside of our router? Well that path with the shortest metric to get to that destination network ends up in our routing table.

Link-state Routing Protocol Data Structures

So you can see the relationship we have here. Routing table gets populated based on the answers that Dijkstra's Shortest Path First Algorithm comes up with based on its calculations. But it does those calculations based on the information it has in its topology table and we can't have information in the topology table unless we have neighbors. So it's an important relationship here between all these tables; that is very important for us to know because when it comes to troubleshooting, we have to be able to work our way around these tables to find out what's really going on if we don't have the routes we expect inside of that routing table.

OSPF Metric

Pop quiz everyone! Can anybody tell us the name of the metric for EIGRP? I'm going to remind you folks of the other types of metrics that are out there. Let's use that as an opportunity to review. RIPs metric, not like we care about that this much these days, but RIP is hop count. It's just a number of routers to get there. EIGRP, if you remember EIGRP, bonus points for you. What would you call EIGRP's metric? Well we could say feasible distance, that's the composite metric. OSPF's metric is a 'cost'. That is the metric and it is derived from this equation: Cost = Reference Bandwidth / Interface Bandwidth, where reference bandwidth is 100 Mb/s. The equation sets up a sort of a fraction. On the top of the fraction, the numerator, if you will, we have the reference bandwidth. And the denominator beneath the slash of that fraction is the interface bandwidth, so this is accumulated. Now it's interface bandwidth. So we do this every single link, every single link gets a component cost and then we accumulate these costs to derive the entire path cost to get to that destination. So here's the deal though. Is there a good way to remember 100 Mbps? I mean, I think I know some network connection speeds or network connection types that are of that same speed.

Well Fast Ethernet connection is 100 Mbps. So if we take the reference bandwidth, which is 100 Mbps, divided by an interface bandwidth of 100 Mbps for Fast Ethernet, what is the cost for a Fast Ethernet link? If you take one number and divide that same number by itself, you're going to get a one, which is great okay. So I got a cost of one, that's my reference speed, if you will, and this is beautiful, right? I want you to think this is great, because there's never going to be a network speed, a network link, that is faster than 100 Mbps, right. There's never going to be something faster than 100 Mbps. Wait, wait a second; never be an interface being speed faster than a 100 Mbps. What year is this? Where you're living right now? Because in my world, I've seen gigabit speeds, I've seen 10 gigabit speeds, I've even seen 40 gigabit speeds. All right, do you see the problem we have here right now? The reference bandwidth by default is 100 Mbps. Let's put you on the spot here. 100 Mbps reference bandwidth divided by a 1 gigabit interface. Which would have 1000 Mbps bandwidth, what's our cost then? 0.1! Can we have 0.1 as a cost with OSPF? No. So what does that mean? We have to round up to 1.

All right, let's go at the 10 gigabit link. It's going to be less than 1. We don't have to figure out the number, but it would be less than 1. 40 gigabit link, less than 1. In all those cases, we have to round up to 1. So, Fast Ethernet cost of 1, GigabitEthernet cost of 1, 10 gigabit cost of 1, 40 gigabit cost of 1. Is that a problem? It would be. So if our routers had an option of taking a 10 gigabit link and a Fast Ethernet link, then OSPF was running in the default state on our routers or switches, it would load balance equally, it would equally load balance. And what that would mean is we would get something called pinhole congestion. Think of it like, if you've ever taken a pin, poked it through a piece of cardboard to look at the sun, you've got a really narrow slot to look through.

Well that's, kind of, like the Fast Ethernet side of the bandwidth. We're going to get just a trickle of information when we could send a deluge of information in the faster pathway. But we're devaluing it based on this measurement system. So some other chassis in Cisco, in fact, changed the reference bandwidth. They changed it to 40 Gbps. But we're in the world of routers and catalyst switches, which may be multilayer. And we still have this 100 Mbps reference bandwidth. It can be changed though, it can be changed and if you change it, you really should change it on all of the routers in your autonomous system to have a consistent measure. Because if we're not consistent, then we're going to have a hard time, doing some calculations and predictions on the right pathways. What's the command we utilize to change that reference bandwidth? Well we go into router configuration mode for OSPF:

Router(config)#router ospf 1
Router(config-router)#auto-cost reference-bandwidth ?
  <1-4294967>  The reference bandwidth in terms of Mbits per second
Router(config-router)#auto-cost reference-bandwidth 40000
% OSPF: Reference bandwidth is changed.
        Please ensure reference bandwidth is consistent across all routers.

So if you wanted to change it to 40,000, that would say 40 Gbps, for reference bandwidth. And some operating systems, in fact give you the way to say, "Instead of measuring in megabits, I want to measure in gigabits because I'm putting in a really big number for you." Folks, always remember when it comes to OSPF's metric, when it comes to cost, lower is better and that would be the path that would end up in our routing table.