OSPF V: “You Have Chosen…Wisely” Path Selection Process

You Have Chosen…Wisely

In my opinion, the best movie in the Indiana Jones film franchise was Indiana Jones and the Last Crusade; aside from the pure enjoyment of the action scenes, the film gave great attention between “Indie” and his father.  One of the most-quoted lines from this movie, in pop culture at least, was the statement by the night (pictured above), “You have chosen…wisely.”  The whole concept of making the best possible choice ties in particularly well with OSPF, which puts it head-and-shoulders above Distance Vector routing protocols, since it truly can choose…wisely!  If you recall our earlier discussion about Link-State routing protocols, instead of depending on “mileage” (how far away something is”, the basis for route selection is cost, related to bandwidth.

OSPF uses cost in a cumulative manner–meaning that all of the costs of the links to a destination network are added up together.  If you have ever used a GPS for travel, this makes perfect sense, since the device would recommend the eight-lane Interstate highway (greater “bandwidth”) over the two-lane country road, regardless of the distance.  Ironically, you can even specify the route to avoid toll roads (a different spin on cost), to choose the best way to go.  If you think about it, this makes perfect sense, since you can go faster and have fewer stops on the bigger road, especially if you are tracking the route of travel from end-to-end.  In networking terms, then, OSPF devices will choose a 1.544 T1 link over the vastly inferior 56K link in choosing the best route.  What could be simpler?

Remember how strict and rule-oriented OSPF is?  Well, this applies to route preferences as well, meaning that there are additional selection criteria that will override the cost directive.  This fits into the hierarchy of OSPF areas, and creates the following list of route selection preferences:

1.  Intra-Area: Always choose the path within the area first.

2. Inter-Area: If no routes to the destination exist within the area, choose a path to another area but within the OSPF domain.

3. External Type 1: If no routes to the destination exist within the OSPF domain, choose an E1 route (remember that E1 routes count the cost to the external router in the metric)

4. External Type 2: If no E1 routes exist to the destination, choose an E2 route (remember that E2 routes do not count the cost to the external router in the metric, and redistributed routes are E2 by default)

As you can see, this can substantially change the route selection process.  Next time we will look at EIGRP, which is vastly simpler.

– Joe

OSPF IV: There is No “I” in Team: More about DR’s

DR vs. No DR

One of the unique features of OSPF concerns neighbor relationships across multiaccess networks, such as Ethernet LANs and certain types of WAN’s such as Frame-Relay and ATM (no, not the cash machines at banks).  Remember, neighbor relationships form between connected neighbors across links, so consider the diagrams above to get an idea of what this looks like. Here we have listed six routers, and the math required to calculate the number of relationships is N(N-1)/2, where N is the number of devices.  Solving for 6 in this case creates the values of 6 * 5, yielding 30, and dividing that by 2 results in 15, which is a lot between so few devices, and staggering between many.  To simplify this, OSPF has a single peer on multiaccess networks called the Designated Router, or DR.  Note in the diagram how the 15 relationships is reduced to 5 using a DR, and in reality there are 5 more with a secondary DR, called the BDR.  In keeping with the highly regimented structure of the protocol, all messages, updates, and so forth take place between peers and the DR, and NOT with one another.  The purpose of the BDR is to take over if anything happens to the DR.

As is the case with many other network protocols, there is an election process to determine the DR and BDR roles on the multiaccess networks, and seldom is this optimal.  I have personally had to deal with suboptimal DR selection in networks and labs I have worked on, especially when dealing with redistribution (the process of sharing routes between various routing sources).  Each router on the OSPF multiaccess network has a default priority of 1, which usually results in a tie in the election process, and the highest numerical Router-ID wins if that is the case.  To set the priority manually, use the ip ospf priority <0-255>  command on the interface, understanding that the higher the priority, the better (I routinely use 200 for the DR and 190 for the BDR).  To remove a router from the election process, just specify zero (0) as the priority, which is useful in hub-and-spoke topologies such as Frame-Relay (having a spoke router as the DR or BDR is not helpful at all).

Let me share a quick word on WAN topologies in OSPF because they can drive you crazy at times.  Frame-Relay and ATM do not forward broadcasts naturally, and special configuration is required is you want that functionality.  If you have to work with non-broadcast links, use the ospf neighbor command under the OSPF process.

Next time, we will wrap up our OSPF discussion by looking at route selection.

– Joe

OSPF III: DR Seeking BDR fot LTR (Neighbor Relationships, cont’d)

Is He/She a Keeper?

Few things rattle us more than the pursuit of that “special someone” in our lives, regardless of our respective cultural backgrounds.  In some cultures, marriages are arranged (often numerous years ahead of time), while others leave the process up to the individual, often found in Western cultures through the ritual of dating.  Regardless of how the process develops, how the relationship develops follows a relatively common pattern.  In cultures where dating is the accepted path, the journey begins with the often-awkward first date, when the person across the table is basically a stranger.  If things go well, conversations pass back and forth, common interests and viewpoints are discovered, and a relationship begins to form.  As things progress over time, greater trust is established, deeper conversations ensure, and at some point the two individuals become a couple in a more formal sense.  What does this have to do with OSPF?  Actually, everything!

OSPF relationships follow the same pattern just described in the whole dating/mating ritual in the previous paragraph.  They start out as strangers, with no trust, and not sharing vital, if any, information about what they know.  Using Hello Messages, the routers start the process of conversing, and over time the relationship goes from “perfect strangers” to “fully adjacent” in which Link-State information is exchanged.  Nothing about the process is instant, it takes a period of time, although the procedure is fairly rapid by human standards.  There are seven stages of states of the relationship building process, as follows:

1. Down: Not aware of one another
2. Init: Initializing, hello packets sent
3. Two-Way: Neighbor sees its own Router-Id in the hello packet
4. Exstart: Adjacency/Relationship formed, Database Description Packets created
5. Exchange: Database Description Packets sent to neighbor
6. Loading: Slave device sends Link State Requests and received Link State Advertisements
7. Full: LSDB identical, and neighbors ready to forward traffic

The next point is important because it can help you figure out when something is wrong.  Occasionally, neighbor relationships stop before reaching the Full state, indicating that some sort of problem is preventing full adjacencies from forming.  You can check the current state of any OSPF neighbor by executing the show ip ospf neighbor command from the Command Line Interface, which will list the Router-ID, state, etc., of the neighboring device.  Most commonly, this will happen at the Init, Two-Way, or Exstart stages, and requires some troubleshooting (remember that OSPF is very picky, so there are several causes that you can investigate further).

Next time we will look into the Designated Router concept.

– Joe

OSPF Part II: Wouldn’t You Like to be My Neighbor?

In my opinion, one of the most misunderstood words in modern society is the word neighbor, particularly in the United States.  The term is extraordinarily broad, and can refer to a fellow resident of a housing development or apartment, someone in the same city or county, or even country.  When you consider how loosely the word is used today, you can easily get confused when you start talking about neighbor relationships between routers, because the definition is stricter.  Incidentally, when I grew up in the 1970’s in Pennsylvania, the word neighbor meant the people living on either side of you, or across the street.  Since I don’t expect everyone that reads my writing to have that same set of experiences (either in terms of chronology, geography, or culture), let me invoke a more familiar example: the characters of Tim Taylor and Wilson on the television show Home Improvement.  Wilson and Tim lived right next door to one another, and shared both a fence and property line, meaning that their yards were literally connected.  In just about every episode, these two individuals carried on conversations, usualy with Tim asking Wilson for insight and advice, and usually heeding what was said.

Let me point out how their relationship worked as neighbors.  First, they were connected by a common property line, so there was nothing between them other than the fence, which allowed them to interact easily.  Second, they had an actual relationship, which involved a level of trust; in other words, they were not strangers.  Finally, they carried on conversations, in essence, exchanging information, which resulted in at least one of them changing something they had been thinking or doing previously.  Now let’s apply that to how OSPF defines neighbor relationships.  Neighbors have to be directly connected, without another network separating them; a link of some kind connects them (just like the property line).  Second, these relationships are not casual, the OSPF neighbor routers have a very formal relationship and know and trust one another.  Finally, they exchange information, specifically, Link State Advertisements, the pieces of data that allow for the Link State Database to be duplicated on the other device.  This is much more structured than RIP which just accepted whatever it hear as in fact being true and accurate.  In fact, OSPF routers track the state and/or availability of the neighbor device, sending messages at regular intervals called Hello Messages (more on that later), which transmit data as well as act as a keepalive mechanism.

Next time we will step through how OSPF routers build these relationships.

– Joe

OSPF Part I: The Drill Sergeant of Networking!

I have never been in any branch of the military, but I have known a number of brave men and women that have served.  For those who may not know how the military induction process works, the first step is known as Basic Training, or more affectionately, hell on earth!  This phase involves heavy physical activity, intense discipline,and hours of a drill sergeant (see graphic above) barking orders in a fierce, shrill tone that makes fire freeze!  By now you might be wondering what on earth any of this has to do with networking, which is a fair question.  Enter the Open Shortest Path First protocol, abbreviated OSPF.

Everything in OSPF is about rules, and ensures that routing takes places in an even and consistent manner across the entire autonomous system (network under a common administration).  There are rules about design, rules about information exchange, rules about the routing hierarchy, and about everything else you can think of, so to speak.  Needless to say, OSPF is also highly structured, and that is part of the appeal of this best-known link-state routing protocol.

In keeping with the military analogy, one of the first things to understand about OSPF is the “chain of command” or hierarchy.  Just as there are platoons, squads, and units of soldiers in any army, there are specific groups of devices in this protocol, which are called areas.  With a small network, you can get away with a single area and keeps things relatively simple.  In larger networks, multiple areas are a given even if just for scalability (a term meaning the ability to grow in a measured fashion), but there are often additional, design-related, reasons as well.  Areas are identified using decimal numbering, such as 0, 1, 2, and so on, although you can also use dotted decimal numbering such as 10.1.4.13; in my own experience I have only seen the digit form of numbering.

Getting back to the “rules”, an important thing to understand is that all areas must connect to a special area, called the Backbone Area, or Area 0.  In other words, any traffic leaving one area and destined for another must cross Area 0.  If you have just one area in the entire network, then you can number it just about any way you like, but in any multi-area OSPF network you simply must have an Area 0, through which traffic passes.  There is an exception process using a special connection called a Virtual-Link (which creates a direct connection to Area 0 by one that is separated by another area), but that is beyond the scope of the CCNA.

Next time we will look at formal neighbor relationships!

– Joe

What a RIP(V1/V2) Off!

The algorithms that Routing Information Protocol is based on date back to 1957, but the protocol itself was defined in RFC 1058 in 1988, with several revisions since that time.  The first version of RIP was classful, meaning that it only recognized addressing according to the Class A, B and C groups defined for the original Internet.  Subnetting was not practical since subnet masks could not be transmitted in routing updates.  If you ever want to see what this behavior is like, issue the no ip classless command on a Cisco router and specify version 1 of RIP (which is the default unless you explicitly enable version 1).  One of the more interesting things about RIP is the maximum hop-count of 15.  When I first started in networking, that seemed silly and arbitrary, but as I gained a greater grasp of binary, it made perfect sense!  You see, RIP uses a 4-Bit metric, and in binary, that maps out as follows, using the Powers of Two we talked about earlier:

8     4     2     1                Powers of Two

1       1     1     1                Binary Digits

Binary 1111 (8+4+2+1) equals a decimal value of 15!  Simply put, RIP just can’t count any higher!  In addition, because RIP is a Distance Vector Routing Protocol, it uses the loop-prevention mechanisms we talked about previously, and sends out its entire routing table every 30 seconds.  Even the newest engineer can see the glaring limitations of RIP, and due to those shortcomings, Cisco gained huge popularity by introducing its proprietary Interior Gateway Routing Protocol (IGRP).  IGRP could measure more than just hop count and thus represented a quantum leap forward in routing technology.  Unfortunately, both these protocols still used broadcasts, and new protocols such as OSPF created far more attractive update mechanisms by utilizing multicast instead.

Classless routing changed the landscape of routing in general, and in 1993 with RFC 1388, RIP was updated to support classless routing, and with the transmission of subnet masks in routing updates, subnetting was now possible.  In addition, updates using multicast became supported, and some other improvements, although the hop-limit remained at 15.  One critical thing to keep in mind is that a feature called automatic summarization is enabled on RIPV2 by default, which summarizes networks to the nearest classful boundary—in effect, making the classless protocol act classful.  Two command to almost always use when configuring RIP are: 1. Version 2 (V1 is enabled by default) and no auto-summary (disables automatic summarization).

RIP is useful in smaller networks, but in reality is as undesirable as a cheerleader being asked to the prom by the president of the chess club (see graphic above).  As we will discuss next time, there are MUCH better choices available now.

– Joe

Finding the Missing Link…

One Link to Rule them All?

When you hear the word link these days, it can conjure up all sorts of images, from the main character in Zelda to something you might find on a web page.  At some point in school you were probably taught Darwin’s theory of evolution and the term missing link (meaning some transitional form in the chain of evolution that has yet to be discovered) came up.  In the networking world, however, the term is used of a functional, active connection between devices that allows them to share information.  In addition, the operating condition of those links is referred to as a state, and when you combine the terms, you come up with Link State, a class of routing protocols that take a more global view of the network than the dysfunctional Distance Vector Protocols.  If both of these classes of protocols showed up at a party, DV would be the nerdy, socially inept guy talking to himself in the corner, and LS would be the sharp-dressed, smooth talking fellow with a crowd of people gathered around him.  Why?  Because Link State protocols are infinitely more successful and intelligent about how they operate.

Link State protocols, as the name implies, have accurate and up-to-date information about every operational link throughout the entire network.  They never have to rely on rumor, because they can figure out the entire topology themselves.  This set of information is referred to as the LSDB, or Link-State Database, and does not contain routes but link information.  LS routers unpack the data, process it using an algorithm (for example, the Dijkstra Shortest Path First Algorithm) to calculate potential routes for use by the process.  The most well-known link state protocols are OSPF (Open Shortest Path First) and ISIS (Integrated System to Integrated System), with the latter usually regarded as more popular.

Another distinct difference in the link state world is how routers interact with one another, namely, in a more structured and formal fashion.  In a way, LS routers are like a lot of business people—they only do business with people they know.  Routers actually set up formal relationships, track availability and state of those routers, and send and receive data only with devices they know.  Rumor is no longer a problem, and neither are possible routing loops, because all information is known and available.  Now the focus is not on how far away something is, but rather the cost to reach that network, with cost being the available bandwidth of the links between the source and destination points.

Now that we have talked about the types of protocols, we can discuss specific ones, starting with RIP…

– Joe

Preventing the Epic Fail…Routing by Rumor Part II

Come, on, SERIOUSLY???

In our last discussion we described Distance Vector protocols as simple, and relying on rumor, namely that a router will just take the information it receives as accurate and reliable.  For any of you that have ever believed a rumor, you probably have discovered that it was anything but accurate, or left out key details? If that it not plainly obvious, watch presidential advertising during elections in the US!  Needless to say, these protocols are not the bright bulbs so to speak, and thus need “extra help” to avoid the creation of routing loops, which are the kiss of death in networking terms.

Enter Loop Prevention Mechanisms for DV routing protocols!  These help avoid routing loops, but also introduce a great deal of delay into the convergence process (convergence is the amount of time it takes the routing process to recover from changes).  Here is a list and brief description of these mechanisms:

1. Triggered Updates: DV protocols, such as RIP, send out their entire routing table at regular intervals.  What if a route fails before the next time interval?  This feature is the essential answer, namely that in the event of a change, the advertising router sends out an update immediately even if the time for a full update has not arrived yet.

2. Poison Reverse: No, this is not an execution by a would-be assassin, but a form of route poisoning, in which the route is declared invalid and marked with an infinite metric so it will be unusable.

3. Hold-Down: While this may sound like a wrestling maneuver, it actually refers to the time during which any changes to the route are essentially ignored.  If, for example, a faulty interface keeps going up and down, the hold down process will prevent the routing table from suffering a nervous breakdown.

4. Counting to Infinity: If all else fails, Distance Vector routing protocols have a numerical value that it considers infinite, and beyond which a route is considered unreachable.  In RIP for example, the maximum hop-count is 15, beyond which a route is unusable.  It’s essentially the “last resort” loop prevention mechanism.

All of these mechanisms together keep loops from forming, and while a little on the paranoid side, they keep the network stable.  The tradeoff is a much longer convergence time, which can cause outages and delays in the networks.  At one time this was the only protocol type available, but now newer, more sophisticated ones can be used in place of that.

Next time we will talk about Link State protocols…

– Joe

Gossip Girl…Routing by RUMOR, Part I

Distance Vector Routing

If you have ever been in any social setting in your life, then you understand the concept of gossip, where one person essentially reveals something about another person (and often something negative).  You may think you outgrew this in kindergarten or high school, but even if you have never participated in it, you have known about, or even been a victim of gossip.  Sadly enough, the truthfulness of the information being shared is often dubious at best.  Usually the fastest way to break the cycle is to ask something like, “may I quote you on that?”  While certainly a life lesson, the concept of gossip also applies to network routing as well.

Distance Vector routing, the first and earliest type of routing protocols, function by gossip, sometimes called routing by rumor.  When a distance vector router receives information from a neighboring device, it simply assumes that the information is accurate, and passes it along to any other devices participating in that process.  Never once does it stop to see if the updates came from a reputable source, or if the information itself is viable in the first place.  This is but the first flaw in distance vector protocols.

A second, but related, issue is the measure by which DV protocols make routing decisions, namely, the defined metric.  As you can guess by the name, these protocols choose routes based on how far away that network is, similar to the way we choose a route of travel (based on mileage, for example).  If one road takes 43 miles to reach a specific city, and another only takes 25 miles, we will usually choose the route with the least mileage.  Routing Information Protocol (versions 1 or 2) use this same basic approach using hop count, or how many Layer 3 networks a route crosses to reach a destination network/subnet.  Simple, right?  Yes indeed, and in reality probably a little bit too simple.  Going back to the example a moment ago, what if the shorter mileage was on surface streets with stop signs, traffic lights, and low speed limits?  The mileage might be shorter, but the travel time would most likely be quite a bit longer.  Simply put, distance vector protocols have no way of knowing or judging the quality of the route, only the distance.  To make this network specific, if one route to a network was using a T1 link (1.544 Mbps) and another was using a 56 Kbps link, RIP would not know any difference, only how many hops away it is.

Distance Vector protocols also require additional mechanisms to prevent routing loops, which we will consider next time.

– Joe