Geek Certs Blog

RIP uses a number of timers to ensure that its routes are fresh and to avoid routing loops. A routing loop occurs when a router thinks it has a path to a destination, but it does not. In other words, if your cousin sends an invitation to you at your address in Chicago, but you don’t live there, you will never get it no matter how many times your cousin sends you the invitation.

Timers measure time in seconds and you can modify their default behavior. One of these timers, the update timer, controls how often a router sends a routing update to its neighbors. This is known as a periodic update. The default for a Cisco router is 30 seconds.

The invalid timer defines the length of time, 90 seconds by default, which must pass before a router considers a route invalid. In other words, if RouterA has a route to NetworkA, but does not receive an update from another router for the route to NetworkA for 90 seconds, RouterA considers its route to NetworkA to be non-existent.

Once a router determines a route to be non-existent, it begins a countdown as to when an invalid route should be purged (or flushed) from its routing table (which will trigger the router to send a routing table update to its neighbors). The flush timer has a default length of 240 seconds. Once this timer runs out, an invalid route is removed from the routing table.

Using a typical lab scenario of four interconnected routers (in circular fashion, with each router named Left, Top, Right, and Bottom), let’s look at what happens when Right informs Top that a network to its far right is down (since this is election week, why not!). I suggest you take out a paper and pencil and then draw out this network as you would do in the lab.

When Top learns of this update, it must protect itself from a false routing update from router Left. To understand this scenario, you must consider that electricity travels at about 70% the speed of light and that routers often handle millions of routing requests per second. Therefore, we need to slow this traffic down to about 5 MPH to understand how a router can receive information about a bad route and then tell another router about what it knows.

Slowing traffic down to an understandable level, let’s next suppose that half a second after Top learns of the bad route, Top receives a routing update from router Left. Left’s update does not include the update from router Right that its far right network went down (imagine that the network’s switch lost power). When Top examines Left’s update, it notices that the update contains (what appears to be) a valid route to the far right network through router Bottom. Of course, we know that this route is down, but router Bottom does not because half a second after it sent its update to router Left, it received an update from Right with the bad news about its far right network.

What should Top do with the update it received from Left, Top could conclude that it has a valid route, put this route in its routing table, and then send it to router Right. Can you see what a mess we would now have on our hands? If this scenario played out (again, slowing the clock down to a speed we can understand), when Right next receives a request to route to the far right network, Right will send the request to Top. Next, Top sends the request to Left, and finally, Left sends the request back to Right (who starts the loop all over again). This is an example of a routing loop!

Obviously, this can’t be allowed to happen. So, here’s what happens. Once Top learns from Right that it has an invalid route, Top invokes a principal known as split horizon and starts its holddown timer, which by default runs for 180 seconds. The concept of split horizon basically solves the problem I raised in the above scenario by forbidding router Top from sending an update to router Right about the route that is down. In other words, I can’t update you about a topic you originally told me about for a specific period of time (the holddown time). Once the holddown timer expires though, all bets are off. Cisco has a very detailed explanation of these concepts here in an EIGRP tutorial.

Newer implementations of distance vector routing protocols such as RIP and EIGRP add one more element to the intrigue by implementing split horizon known with poison reverse. Using poison reverse with our example above, router Top would receive the route update from Right and then send the invalid route immediately back to Right with an unreachable metric. RIP’s metric would be 16, which is its definition of an infinite path.

Finally, to conclude this discussion for this week, when router Top receives the update from Right, Top immediately recalculates its routing table and sends a triggered update to its directly-connected neighbors. A triggered update occurs when a router learns of a route change outside of its scheduled update time, sent when the router’s update timer expires.

When routers communicate with each other they use their own language, as you would assume. You no doubt are aware that a router’s main function is to receive a packet and then figure out the best path, based on what the router knows, to get the packet to its destination.

The packet received by the router - for example an IP (Internet Protocol) packet - is a <u>routed</u> protocol. The router takes the routed protocol and encapsulates it (entirely) inside its own protocol data unit (PDU). When the router performs this process, the newly-created PDU is sent to the next router.

Before the router sends the PDU to the next router, it needs to determine to which next router the PDU should be sent. Routers learn about best paths by communicating with other routers and use routing protocols like RIP (Routing Internet Protocol), OSPF (Open Shortest Path First), and EIGRP (Cisco routers only: Enhanced Internet Gateway Routing Protocol) to accomplish this goal.

RIP and EIGRP are classified as distance vector (DV) routing protocols, whereas OSPF is classified as a link state (LS) routing protocol. DV routing protocols keep track of distances and directions (or vectors) using a simple metric called hop count. Each router through which a packet must pass is equal to one hop. It’s that easy. One catch is that a DV routing protocol such as RIP will only route a PDU 16 times. Any hop count beyond that is considered unreachable. Therefore RIP seemingly does the impossible by defining infinity.

DV routing protocols talk to each other using the logic, or algorithm, of their underlying logic, and this talk results in the shortest distance to a destination. Of course, a router should have a path to every destination (unless you specifically do not want that). RIP’s algorithm is known as the <i>Bellman-Ford</i> algorithm, named after the men who developed it. Routers record what they learn about routes in what is called a topology table but the actual routes a router will use is recorded in a routing table. In other words, the topology table might contain more than one path to one destination, but the routing table will only record the one path that has the lowest metric (which makes this route the best path to a given destination).

LS routing protocols such as OSPF utilize the more complex <i>Dijkstra</i> algorithm, again, named after the person who created it. LS routing protocols create a composite metric by learning about the bandwidth and speed of the media through which the PDU will pass. We will discuss LS routing protocols in a later discussion.

Finally,  EIGRP, which, again, is a Cisco proprietary routing protocol, is referred to by Cisco as a hybrid routing protocol. A hybrid routing protocol (according to Cisco) takes the best features from the DV and LS routing protocols and uses them all. As with LS routing protocols. we will reserve our comments about EIGRP to a later discussion, when we can cover it fully.

If you noticed that I didn’t even mention IGRP, then you are ahead of the pack! Since IGRP and RIP (version 1) are no longer supported, I’m not going to discuss them in much detail. However, many features of RIP are common to IGRP with the exception of using only hop count to calculate its metric.

When a router boots up, like any other computer (or sentient being for my Star Trek fans), it first does an internal awareness check known as POST (power-on, self test). Once the router knows its internals are functioning as expected, the router next loads its operating system (OS). Cisco named its router (and switch) OS the Internetwork Operating System or IOS. Once the router loads its IOS, it next looks to see if it possesses a specific configuration file.

When a Windows computer reaches this stage of its boot process, it applies a specific configuration from its database known as the registry. The registry is stored on a computer’s hard drive, which means that it can be changed - such as when a user changes her desktop background - and then saved so that the next time the user logs in the new desktop color is applied. A router does not have an internal hard drive, however, it does have memory that is very similar to another type of memory found in computers - EPROM (erasible programmable read-only memory). Cisco refers to this memory as NVRAM (non-volatile random-access memory). Think of NVRAM as RAM that does <u>not</u> lose its contents when the router loses power. The configuration file stored in NVRAM contains router-specific information such as the router’s name, its IP addresses, security settings, and more.

Once the router applies its startup configuration file settings, it is now, finally, ready to talk to its neighbors. On Cisco routers, a router talks to its directly-connected neighbors using another special language via CDP (Cisco Discovery Protocol). Note that whenever you encounter a protocol with a vendor’s name in it, this protocol will only be installed and available if your equipment was manufactured by that vendor. In other words, a Juniper router will not run CDP and it won’t be able to use EIGRP. 

When Cisco routers communicate using CDP, they only tell each other about the network that directly connects them to each other. So, if Router1 is connected to another network, which is usually the case, Router2 will not learn of that network’s existance, meaning that if Router2 receives a packet addressed to the other network, Router2 just might drop the packet (not route it). Of course, the the Router2 human administrator can program a (static) route to the other network, but this is a lot of work and outside of a small network, this would not work!

After reading the above, you no doubt are thinking that if the router could communicate directly with other routers, without much human intervention, this process would work in small and large networks. If you are thinking along those lines, then you understand why RIP, EIGRP, OSPF, and other routing protocols were created. When a router is provided with a basic routing protocol configuration, the router is able to dynamically talk to other routers, learn about routes, send requests for information and answer such requests, all without human intervention. When routers operate in this fashion, the network is said to be <i>scalable</i>, meaning that regardless of the network’s size, the process still functions with little or no human intervention required.

So, after a Cisco router learns all it can via CDP, it needs a dynamic routing protocol, such as RIP, to learn about paths to networks beyond its directly-connected neighbors. The router’s next step, after completing the CDP process, is to send its entire routing table to each of its directly-connected neighbors. Once the neighbors receive this routing table, they recalculate their routing table using RIP’s algorithm and then send out their entire routing table to each of their directly-connected neighbors. This process continues until all of the routers in the network have no new routes to learn. In other words, when a router receives its neighbors routing table and learns nothing new, the process is complete. At this stage, the routers have reached agreement on how to reach known destinations. This stage of agreement is known as <i>convergence</i>.

In our next discussion, we will address timers, triggered updates, routing loops, split horizon, and route poisoning. Stay tuned for next week’s continuation!