There are routing protocols and routed protocols. Examples of the latter are HTML and SMTP; these are protocols that are routed between networks and their purpose is to facilitate the end device's purposes. Routing protocols assist with routing; they facilitate the intermediate devices that make up the infrastructure of the internetwork.
Why do we need routing protocols? Ask yourself this: if you had to tell your computer how to get a packet to Google's website, would you know the way? Of course not; there are routers between you and Google that you do not know about, you do not know what traffic conditions exist, what links are down, which links are more reliable and/or cheaper to use, which are faster, etc. Therefore, you allow the routers to make those path decisions for you.
How does a router know the best way? Well, one way is to build a routing table on each router. If you are connected to, and enabled on, a router you can type "show ip route" to display the router's known paths. This table will automatically show networks that are directly connected to it. For instance, a router may have two interfaces, and one network on each interface: 1.1.1.0 on "Ethernet 0" and 2.2.2.0 on "Ethernet 1". If the router receives a packet that has a source destination for network 1.1.1.0 or 2.2.2.0, it will know which interface to use to forward this packet since those networks are located on the router.
If you have not provided further instructions to the router and it receives a packet destined for network 3.3.3.0, it will not know what to do with the packet and will return "Network not available." If you do not tell a router about other networks or provide a means to learn about other networks on its own, it will only know about the networks that are physically, directly connected to it.
To teach your router the path to a network that is not directly connected to it you can add to the route table by programming a "static" route. In this manner, you decide how the router finds the network 3.3.3.0. You can type in "ip route x.x.x.x s.s.s.s y.y.y.y" Replace the x with the destination network, the s with the subnet mask for that network, the y with the address of the router that your router knows about (directly connected network or statically assigned) and will use to find the 3.3.3.0 network. For instance, assume that your router (Router 1) has an interface named "Ethernet 1" which is attached to the 2.2.2.0 network. In that network, Router 1's "Ethernet 1" interface is addressed as 2.2.2.1 and there is another router at address 2.2.2.2 (Router 2). Router 2 also has two interfaces: "Ethernet 0" is on the 2.2.2.0 network and "Ethernet 1" is on the 3.3.3.0 network. Therefore, if Router 1 needs to forward a packet to 3.3.3.x, it can send the packet to Router 2, which will know exactly what to do with it.
Router 1 does not intuitively know that it can send these packets to Router 2. By creating a static route statement Router 1 now knows to send all packets for network 3.3.3.0 to Router 2 using interface "Ethernet 1". Here's the rub: If you did that for every network you needed your router to know about, you would soon end up with a very long and confusing routing table.
Imagine programming statements to www.google.com, www.yahoo.com, www.thekansascitychannel.com, etc... Every time you wanted to go to a new website or send an email to a new organization, you would have to create a static route statement on every router between you and your destination. Because network conditions change often, you would need an army of people to keep that table updated.
Another method would be to tell Router 1 to send all unknown packets to Router 2. The command for this is "ip route 0.0.0.0 0.0.0.0 2.2.2.2". We call this the "Gateway of Last Resort". The zeros in the place of the address and subnet mask are wildcards that tell the router to match all values. In other words, the 0 in each octet represents any value between 0 and 255, which covers any and all scenarios.
This is a great solution for Router 1: when in doubt pass the buck. It is also a great solution for finding network 3.3.3.0 since Router 2 has it directly connected. However, what if Router 1 receives a packet addressed to a device on network 4.4.4.0? It will forward the packet to Router 2 and be done with it. However, the network 4.4.4.0 is not directly connected to Router 2; if we have not told Router 2 how to find this network, we will end up with "Network Not Available" again. If we setup a "Gateway of Last Resort" on Router 2, we will move the packet further along the Internet, but who's to say that the next router will know how to find network 4.4.4.0? Also, are you sure that you didn't set Router 3's "Gateway of Last Resort" to Router 1, which puts the packet in an endless loop?
There is a set number of routers that a packet can hit before it is discarded; this is designed into the TCP/IP routed protocol to make sure that lost packets do not traverse the Internet indefinetely, wasting time and bandwidth and eventually clogging up the links. By default, a packet can hit 29 routers; the thirtieth router will discard the packet and end its life. This is called "Hop Count" and will pop-up in later discussions.
At some point in the network, we need to have a router that can make intelligent decisions quickly and efficiently without constant human input. This is the purpose of routing protocols; they allow routers to talk to each other, sharing information about the networks that they know about, which links are up and down, how fast each link is, how many hops to the known network, how much it costs to use the link, how reliable the path is, etc. Basically, routing protocols are a method for routers to gossip.
There are two basic types of routing protocols that we are concerned with for the CCNA exam: Distance-Vector and Link-State. A Distance-Vector routing protocol focuses on how many hops it takes to get to a network. A Link-state routing protocol focuses more on the details of each link and on the whole topology of the network.
When routers are configured with a Distance Vector routing protocol, then each router is told who its neighbor routers are. They send their entire routing table to each of these configured neighbors on a set schedule.
In this case, assume that Router 2 has two interfaces. Interface "Ethernet 0" is directly connected to a network that includes Router 1. Interface "Ethernet 1" is directly connected to a network that includes Router 3. Router 1 and Router 3 do not have a direct connection; they require Router 2 to "route" the packets between its own interfaces "Ethernet 0" and "Ethernet 1".
Router 1 receives a packet for a network on Router 3. We do not want to have to program every network we will need as a static route into Router 1. We do not want to just forward the packet to Router 2 using a "Gateway of Last Resort" and hope that Router 2 makes the right decision. Instead, we program all three routers for a Distance Vector routing protocol. Router 3 sends its routing table to Router 2. Router 2 now knows about the networks that are directly connected to itself and the networks that are directly connected to Router 3. Router 2 then sends this new routing table to Router 1. In this way, Router 1 learns that, in addition to the networks that are directly connected to it, there are networks available to it through Router 2. It doesn't know that network 4.4.4.0 is on Router 3; it doesn't even know that Router 3 exists. However, due to the updates from the Distance Vector routing protocol, it does know that it can send packets destined for network 4.4.4.0 to Router 2 and they will find their way to their destination. Once they reach Router 3, and a reply packet needs to be sent back to the device on the network that is connected to Router 1, Router 3 will know that Router 2 knows how to find that network because it also has a copy of Router 2's route table.
Unfortunately, Router 2 is forced to keep a huge routing table and then transmit the whole thing over two links on a regular basis. These two links will also be consumed by the updates from Router 1 and Router 3. This means that less bandwidth is available on each link when the routing tables are being transmitted. It also means that Router 2, in order to make the best routing decision, must look at every entry in a long routing table for every single packet it routes. Routing tables consume memory and processing time, just like having programs open on your computer. If you try to do too many things at once on your PC, you will slow it down and risk crashing it. By keeping long routing tables on Router 2, you also slow it down and risk crashing it. With three routers, this is improbable. However, if we tried to connect every router on the Internet using a Distance Vector routing protocol, we would overload every link with gigabits of routing table data, we would exceed the memory of almost every router, and the processors in most routers would virtually melt down.
Even if we have unlimited resources on each router and googleplex-bits of bandwidth on every link, imagine how long it would take for your router to learn about a network that required 10 hops; in other words, a network that is 10 routers away. Each router between you and your target router would have to send their entire routing table to the next router, who would then pass that information down to the next, until it reached your router. By that time, a router may have gone down, a cable could have been unplugged, a more direct route could have been installed, etc. Distance Vector takes a long time to converge (completely learn the paths) and is inefficient at learning complex network routing.
There is another problem to consider with Distance-Vector routing protocols: what kind of link is each connection? Distance-Vector has no idea which links are better than others; it is only concerned with how many hops it would take to get from Router 1 to Router 3. If every link is equal, then this is a near-perfect philosophy. However, any two links are rarely equal.
For purposes of illustration, let us add another link between these two routers: we will directly connect the routers with a dial-up connection. I can program both routers to know that if they ever need each other, they can use interface "Analog 0" to dial each other up and talk. What they do not understand is that the connection is a sluggish phone line that transmits at 28,000 bits per second and costs me $1.50 per minute to use. They know that they can also connect through Router 2, but they do not realize that the connections through Router 2 are 100 million bits per second and do not incur additional cost for me. What the Distance-Vector neighbors know is that hop counts are bad. Therefore, Router 1 and Router 3 using a Distance-Vector routing protocol would use the connection with the least hops by default, unless I told them otherwise. If I failed to configure the shorter, "backup" link with a high metric, they would choose the 1-hop, slow, expensive route every time.
A small-ish and simple network with equal links is great for a Distance-Vector philosophy, but a larger and more complex internetwork would do better with a Link-State routing protocol. With Link-State, the philosophy is to discover each participating router in the internetwork and then send a status of your router's links to each participant. In this case, Router 2 may know about Router 1's networks but it doesn't gossip this information with Router 3. It simply minds its own business and only sends out the status of its own links. If Router 3 needs to know about Router 1's new T1 interface, or how it is always having trouble with interface "Ethernet 1", it will just have to learn that from Router 1 itself. And it will; Router 1 will send the status of its links directly to Router 3 (via Router 2, who kindly routes the packets). Once a router has this information from all of the participants (the state of convergence) it is able to build a topological database. When a routing decision is required, the router considers the various paths to that destination based on the database and uses an algorithm to determine the most efficient path. This algorithm is called Shortest Path First (SPF) based on Dijkstra's algorithm.
Now let's consider a ten-hop network. This network is all in one company, under one network administrator, spread across the United States. Bob in IT located in New York needs his PC to connect to Iggy in Accounting, located in Hawaii. There are two ways for this company's Hawaiian office to connect to the mainland: through a T1 point-to-point connection from Hawaii to the office in California, or over a dial-up connection from Hawaii directly to New York. If you use the T1 to California, you are then connected to any number of links that will get you to New York; none of which are direct but all of which include high-speed OC3 connections (OC3 = 155.52 million bits per second).
If you, as a human, had to make this decision you would probably just go with the easiest connection: the dial-up phone connection. Getting from California to New York over the various OC3 connections would require a lot of research, time, and effort. Also, the path may need to change for every packet you send in each direction, depending on changing conditions of outages and congestion. However, if you know the phone number, the connection between New York and Hawaii is easy.
If a router has an accurate database of the network's topology and uses the SPF algorithm to determine the best path from New York to Hawaii for each packet, it will probably never use the dial-up connection. SPF is looking for fast, cheap, direct, and uncongested.
Dial-up is slow and expensive (long-distance phone rates from Hawaii to New York at 56,000 bits per second). Imagine Bob's computer will be sending 500 MB in this session: 500,000,000 Bytes; a Byte = 8 bits; 500 MB multiplied by 8 bits= 4,000,000,000,000 bits per second; how long would it take to transfer this data over a 56,000 bits per second link? Then multiply that length of time by the minute-by-minute rate of the long-distance company to calculate how quickly Bob will get fired!
The SPF algorithm will prefer the T1 point-to-point connection to get from Hawaii to California because a T1 transmits at 1.544 million bits per second. However, it will also take into account if that T1 is down or is already congested with other traffic of equal or higher priority (see QoS in a future posting, or look it up for extra credit.) If the T1 is down when Bob needs to get to Hawaii, SPF will try to calculate the cheapest way to call Hawaii: perhaps the network administrator has already anticipated this scenario and programmed California's router to have a lower cost to use dial-up to Hawaii than New York's router due to reduced long-distance rates. A routing protocol will take care of most decisions for you, but it is occasionally necessary to change the settings when it suits your purposes, like when it is cheaper to call Hawaii from California than from New York.
Of course, if someone is already using the dial-up connection from California to Hawaii, SPF will resort to the slow and expensive connection from New York. However, you can see how many alternatives SPF can consider, and it hasn't even started yet! If it is going to use either connection from California to Hawaii, it will need to find a way from New York to California. This is where SPF earns its pay.
From New York, there may be three OC3's connecting to Boston, Buffalo, and Newark. From any one of these, there are OC3 connections to other cities, which are connected to each other, to California, and to New York. It resembles a spider web or a maze, and it would be easy for a human to get lost, get overwhelmed, or overlook efficient connections. However, SPF can keep up with which OC3 is unplugged, which one is overloaded, which one is up and down sporadically, etc. SPF can tell if it is quicker to take the New York-Boston-Detroit-Chicago-Kansas City-Dallas-Phoenix-Los Angeles routeOR the New York-Newark-Atlanta-Dallas-Las Vegas-Los Angeles route. In fact, it may use the first route for the first few packets, and then use the second route for next several packets, and then need an entirely different route to finish the session. Whatever the network state, if two paths exist between source and destination then SPF will determine the best one.
Therefore, Link-State routing protocols maintain a better picture of the network, they make better decisions, and they make more efficient use of the network's bandwidth by not broadcasting everything it knows on a regular basis, unlike Distance-Vector protocols (don't you wish some people would quit broadcasting everything they know all the time..yeah, everyone except me, right?).
However, Link-State protocols take up a lot of router resources. Maintaining a topological database and calculating algorithms for every packet means that the router has a lot to remember and think about. What this really means is that it is going to cost you; there may be a $50 router available with all the interfaces you need, but it will not be able to handle the demands of Link-State routing. You will have to spend more on your router, but you will end up with a more efficient network.
In the Link-State example, we never left our company's internetwork; every link and router was controlled by Ralph, the company's network administrator. Now, what if Bob wants to connect to http://larryslobodzian.blogspot.com, which is located on a separately owned/controlled network? In order to do so, he will have to leave Ralph's networks and find his way across the vast unknown of the Internet. How in the world are we going to do that?
The best design for any network that will ultimately allow Internet connectivity is to create a hierarchical model. You start with lower, smaller networks: for instance, every department at a location has its own network, and those networks are connected within the location using small, affordable, routers running a Distance-Vector routing protocol. Then, each location is connected together using dedicated links that connect to a larger, more powerful router running a Link-State routing protocol.
All of the smaller, Distance-Vector routers have a static route that tells them that if they do not know what to do with a packet, send it to the local Link-State router (The Gateway of Last Resort: Router# ip route 0.0.0.0 0.0.0.0 {insert address of the link-state router}). That Gateway router, running a Link-State protocol, will know what to do with every packet it receives. If it receives a packet destined for a remote destination within the company, it will have learned about the best paths available from its Link-State conversations with other Gateway routers within the company.
If the Gateway router receives a packet for a destination outside the company, there are three options to keep the packet moving. First of all, you can program each Gateway to have its own "Gateway of Last Resort" based on each location's details--especially if each location has its own Internet connection. Another option is to have all locations access the Internet through one location. In this case, the location with the Internet connection would have it's router that is part of the Link-State topology programmed with a "Gateway of Last Resort" that pointed the unknown traffic to the Internet (via an ISP's router.) Through Link-State routing updates, the other routers in the topology would learn that 0.0.0.0 is available through this one router. This is a solution for an organization that needs to closely monitor and control its Internet traffic for security or cost reasons. In fact, this was once necessary for reasons of cost and Internet availability; however, now that cable, DSL, wireless, and satellite is fast, affordable and widely available, this solution is less common.
The final option is to have each router run an Exterior Gateway or Border Gateway Protocol. Either of these two protocols (EGP and BGP) can be used to exchange information between two separately owned/controlled networks. Gateway Protocols are merely mentioned on the CCNA exam, and I have little experience with them, so their discussion ends here.
Routing protocols explain how the internet works. They help the network administrator makes connections quickly and more efficiently than he or she could ever do. They also help us design efficient and cost-effective networks. Understanding routing protocols not only help you pass your CCNA exam, they help you build and maintain a better network.
