Monitoring RIP

Once RIP is up and running, it can largely be left alone. However, there are a number of commands that you should be familiar with in order to gain information about the status of RIP, or for troubleshooting purposes.

Of these commands, the most basic and useful is the show ip protocols command. The command will provide you with information about the interfaces on which RIP is configured, the sources of routing information, and the timer values configured.

RouterA#sh ip protocols
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 26 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Redistributing: rip
Default version control: send version 1, receive any version
Interface Send Recv Key-chain
Ethernet0 1 1 2
Serial0 1 1 2
Routing for Networks:
10.0.0.0
Routing Information Sources:
Gateway Distance Last Update
10.0.20.2 120 00:00:19
Distance: (default is 120)

Notice that this router is receiving updates from address 10.0.20.2, the near interface on Router B.

In order to gain more information about the actual contents of the RIP traffic moving between systems, use the debug ip rip command. This particular command is like a toggle switch – debugging information that shows the contents of RIP updates sent and received will continue to appear on-screen until you turn it off with the no debug ip rip command.

RouterA#debug ip rip
RIP protocol debugging is on
22:48:34: RIP: received v1 update from 10.0.20.2 on Serial0
22:48:34: 10.0.30.0 in 1 hops
22:48:38: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (10.0.10.1)
22:48:38: subnet 10.0.20.0, metric 1
22:48:38: RIP: sending v1 update to 255.255.255.255 via Serial0 (10.0.20.1)
22:48:38: subnet 10.0.20.0, metric 1
RouterA#no debug ip rip

Note that the debug ip rip command shows the RIP updates both sent and received on a particular interface, along with associated subnet and metric information. Remember than a metric of 16 suggests an unreachable network in RIP.

Although you don’t need to know how to do this for the exam, it’s always nice to know how to change the default timers used by a protocol. The command to do so is timers basic, and is issued from the routing protocol configuration level. One important note here – if you do decide to change the timers on one router, you should also change the timers on every router. Otherwise, you’ll be dealing with one very unpredictable network potentially susceptible to routing loops.

RouterA(config)#router rip
RouterA(config-router)#timers basic ?
<0-4294967295> Interval between updates
RouterA(config-router)#timers basic 30 ?
<1-4294967295> Invalid
RouterA(config-router)#timers basic 30 180 ?
<0-4294967295> Holddown
RouterA(config-router)#timers basic 30 180 180 ?
<1-4294967295> Flush
RouterA(config-router)#timers basic 30 180 180 240

I used the help function to walk through the timers basic command step by step to show you the order of the entries – update, invalid, holddown, and flush. Ultimately, the same command can be used to set IGRP timers.

Configuring RIP

In this section we’re going to configure a simple network with two routers to run RIP. Our network in consists of three subnets, 10.0.10.0/24, 10.0.20.0/24, and 10.0.30.0/24, as shown in the figure below. Our goal is to ultimately have Router A learn about network 10.0.30.0 from Router B, and Router B learn about network 10.0.10.0 from Router A using RIP.

Figure: Network configuration for distance vector protocol configuration examples.

If you’re trying to configure a router to use RIP to exchange routing table information, a first important step is to remove any static routes that you may have defined. Remember those administrative distances that we looked at earlier? If you have a static route defined on Router A that provides information on how to get to network 10.0.30.0, any information that Router A receives about network 10.0.30.0 via RIP will be ignored. A static route has an administrative distance of 1, while RIP’s administrative distance is 120. When a route with a higher administrative distance is received, it is ignored, since a more trustworthy routing table entry already exists.

The command to turn on RIP routing is simple – from global configuration mode, simply issue the command router rip, as shown below.

RouterA(config)#router rip
RouterA(config-router)#

Notice how the prompt changes. At the most basic level, the router rip command makes this router capable of sending and receiving RIP updates. However, in order for this router to send out any information of use, we have to tell it which network(s) to advertise. In this case, the network we want to advertise is 10.0.0.0. You don’t need to specify either the subnet mask or specific subnet addresses – because RIP is classful, it will automatically assume that you meant all networks starting with 10. In order to make RIP announce all of the 10.0.0.0 subnets, enter the network 10.0.0.0 command, as shown below.

RouterA(config-router)#network 10.0.0.0
RouterA(config-router)#

That’s literally all it takes to set up RIP. Of course, we’ll also need RIP configured on Router B, which involves following the same steps.

RouterB(config)#router rip
RouterB(config-router)#network 10.0.0.0

In order to confirm that RIP is properly exchanging information between our routers, let’s take a look at the routing tables on Router A.

RouterA#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 3 subnets
C 10.0.10.0 is directly connected, Ethernet0
R 10.0.30.0 [120/1] via 10.0.20.2, 00:00:22, Serial0
C 10.0.20.0 is directly connected, Serial0

Notice in the routing table above that Router A learned about network 10.0.30.0 from RIP, as designated by the R at the beginning of the entry. The administrative distance is 120, and the number of hops to reach the network is 1, as designated by the entry [120/1].

Finally, the next-hop address is 10.0.20.2, which is accessible via interface Serial0.
An easy way to test whether RIP is working on both routers is a simple ping. If Router A can successfully ping IP address 10.0.30.1, it means that Router B also has a route (learned from RIP) back to network 10.0.10.0.

RouterA#ping 10.0.30.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.30.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/38/48 ms

Remember that many routing protocols are also able to load-balance across multiple paths. RIP can load balance traffic across up to 6 paths, as long as the hop counts to the network in question are equal.

Routing Information Protocol (RIP)

The Routing Information Protocol (RIP) is a simple distance-vector protocol. In order to avoid confusion, you should be aware that two versions of RIP exist – RIP version 1 (RIP), and RIP version 2 (RIPv2). For the purpose of the CCNA exam, you need to be familiar with RIP version 1, which is what we’ll look at in this section. RIPv2 will be looked at a little later in the chapter.

The first thing that needs to be made clear is that RIP is a classful protocol. What that means is that RIP will always assume the class of an address according to the standard Class A, B, and C designations. Ultimately, this means that RIP is expecting that every single host in a network is using the same subnet mask. This does not mean that RIP won’t work on a subnetted network; only that all of the subnet masks are assumed to be the same. Techniques like VLSM won’t work with RIP, mainly because when RIP sends out its routing table updates, it doesn’t include any subnet mask information.
Recall that RIP uses hop count as its metric in determining the best route to a network. Remember that RIP will always take the path with the fewest hops, regardless of factors like bandwidth, delay, or otherwise.

The maximum diameter of a RIP network is 15 hops. That means that a maximum of 15 routers can be traversed between a source and destination network before a network is considered unreachable. At the 16th hop (which RIP considers to be “infinity”), the TTL reaches 0, and a packet is discarded. Obviously this makes RIP a poor choice for very large internetworks.

RIP is also incredibly chatty. By default, a RIP router will broadcast out its complete routing table every 30 seconds, regardless of whether anything has changed. That’s not terribly efficient, and causes a great deal of unnecessary traffic. Remember that broadcasts go to all hosts in a broadcast domain, meaning that even regular computers will have to process RIP packets to some degree before discarding them. RIP may not be pretty, but it is simple.

There are a few different timers that you should be familiar with on a RIP network. There include:

Route Update Timer. The route update timer controls how often a router will broadcast routing table updates. As mentioned, a RIP router will broadcast its complete routing table every 30 seconds by default.

Route Timeout Timer. The route timeout timer specifies the amount of time that will pass before a router will mark a network as unavailable, and is set to three times the update interval (180 seconds) by default. For example, if a router doesn’t hear about network 172.16.0.0 from any other router for 180 seconds, it will mark the route as invalid. After marking a route as invalid, the information will be sent to other routers via a triggered update.

Route Holddown Timer. The route holddown timer specifies the length of the holddown timer that will be used when RIP receives information about an unreachable routing table entry. The default holddown timer is 180 seconds.

Route Flush Timer. After marking a route as invalid, a RIP router will not immediately remove the route from its routing table. Instead, it will wait until the flush timer (sometimes called the garbage collection interval) has expired. This gives the router time to let other routers know about the invalid route before removing the entry from its routing table. The default flush timer is 240 seconds.

While RIP may not be the most efficient or effective routing protocol for use on large networks, it still does the job. A big reason why RIP is so popular is because of how easy it is to set up. With as few as two commands, you can have your router fully configured for RIP.

Hybrid Routing Protocols

Some protocols can’t be so clearly defined as either distance-vector or link state. A great example is Cisco’s Enhanced IGRP (EIGRP), which is more accurately defined as a hybrid between the two. While distance vector protocols typically rely on the broadcast of complete routing tables, EIGRP instead only sends out specific updates when the metric to a route changes. Like link state protocols, EIGRP also maintains a database of neighboring routers and the network topology.

Link State Protocols

Link State Protocols work differently than distance-vector protocols. Where a distance-vector protocol periodically sends out its entire routing table to neighboring routers, a link state protocol instead builds a topology database that give it perspective on finding the best or “shortest” loop-free path to other networks. A link state protocol will usually build 3 databases. The first database is known as the neighbor or adjacency database, and keeps track of other routers on directly connected networks. The second database is the link state or “topology” database. This database keeps track of the “state” of the links on other routers on the network. Link state routers periodically send out what are known as “hello” messages, which are sent to neighboring routers as a type of keepalive message. An OSPF router will also periodically send out link state advertisements (LSAs), which are flooded across an internetwork. These messages contain information on the router’s active links, its IP address, subnet mask, and the routers it knows about. The information stored in the topology database is ultimately used to calculate the shortest path to a destination network. It is also used to create the final database, the routing table.

Although the flooding of these LSA messages sounds dangerous, in reality their scope is limited, as we’ll see when we look at OSPF. Ultimately, a link state router stores the complete topology of the internetwork in its database built on first-hand knowledge rather than the rumors passed by neighbor. Another efficiency is found in link state protocols because they don’t actually broadcast out their routing tables, or take nearly as long to converge. On the downside, link state protocols typically involve more planning to implement than their distance vector alternatives. Common examples of link state protocols include Open Shortest Path First (OSPF) and Netware Link State Protocol (NLSP).

Avoiding Routing Loops

Distance vector routing protocols use four main techniques in attempting to prevent routing loops. These include:

Defining Infinity. Instead of allowing a packet to just loop around an internetwork endlessly, distance-vector protocols define what is considered to be infinity by specifying a maximum hop count. For example, RIP considers any route that takes more than 15 hops to reach to be unreachable. Remember that TTL value that gets decremented by 1 each time a router is crossed? Once the TTL reaches 0, the packet is discarded. While this technique doesn’t eliminate routing loops on its own, it does ensure that a packet doesn’t loop around an internetwork forever.

Split Horizon. In looking at the routing loop example, you should have noticed that Router A ultimately let Router B know about a route to network 172.16.0.0, even though it originally learned that route from Router B. Split horizon is a rule that specifies that a router can never send information about a route back to the router that originally supplied the information. Had split horizon been used in our example, Router A would not have included information about network 172.16.0.0 in its update to Router B.

Route Poisoning. Usually used in conjunction with split horizon, route poisoning involves explicitly poisoning a routing table entry for an unreachable network. In our example, once Router C learned that network 172.16.0.0 was unavailable it would have immediately poisoned the route to that network by setting its hop count to the routing protocol’s infinity value. In the case of RIP, that would mean a hop count of 16.

Triggered Updates. Obviously the interval between routing table updates is part of the problem that leads to routing loops. Instead of relying on regular periodic updates, distance vector protocols will send out a triggered update when a metric to reach a network increases. In our example, Router C would immediately send out an update about network 172.16.0.0 not being available to Router B, who would then immediately send out an update to Router A. While triggered updates cause a little more network traffic in the short term, they go a long way towards faster convergence on a distance-vector network.

Holddowns. Holddowns are a technique used to ensure that a route recently removed or changed is not reinstated by a routing table update from another router. Even with the use of triggered updates, it will still take some time for the information to reach all routers on the network. As such, there is still the possibility that a not-yet-current routing table update will attempt to reinstate a route that is unreachable. Holddowns make a router wait a period of time before accepting an update for a network whose status or metric has recently changed, giving a network the opportunity to converge.

Routing Loops

One of the main issues with distance-vector routing protocols is that they are susceptible to routing loops – a direct result of their slow convergence times. A routing loop can occur in the distance vector world because of the way routers exchange information. For example, let’s say that we have a network as shown in the figure below. Three routers exist in this example, connecting a total of four networks. We’ll begin with a network that is fully converged – that is, all routers are aware of all networks, as shown in the diagram. On a fully converged network, everything works well.

Figure: Fully converged network, prior to routing loop.

Routing loops become a potential issue when our network experiences a problem. For example, imagine that network 192.168.2.0 experiences a failure – maybe the switch it was connected to malfunctioned, or somebody simply disconnected the cable. At any rate, Router C recognizes that network 192.168.2.0 is unavailable, and passes this information to Router B in its next routing table update. Once the update arrives, Router B removes the entry for network 192.168.2.0 from its routing table. So far, things are going well. However, there is one little problem – Router A is also sending out routing table updates, and is telling Router B that network 192.168.0.0 is available through it, with a hop count of two, as shown in the figure below. See a problem developing?

Figure: Update from Router A creates a routing loop between Routers A and B.

Now we have a network where Router B thinks it can get to network 192.168.2.0 via Router A. Without anything else occurring, think about what happens here. When Router B gets a packet destined for network 192.168.2.0, it will send it to Router A. Router A will look at the packet, and will send it back to Router B – that is the direction of network 192.168.2.0 as far as Router A is concerned, after all. The packet will actually end up being passed back and forth forever and ever. This is certainly not a very comforting thought.

The problem just described is a directly related to slow convergence. Router C did its job in getting information about the unavailable network to Router B, but unfortunately Router A also sent an update to Router B prior to the “correct” information arriving at Router A. On a larger network, the problem would be even worse. Remember that distance vector routing protocols are not terribly discerning – they simply trust their neighbors to provide them with correct information. Thankfully, distance vector routing protocols take a number of steps to try to avoid the routing loops just described.

Multiple Network Paths

On any internetwork, it is possible that more than one path to a destination may exist, with the same distance. For example, consider the figure below. This network consists of three networks. From Router A, network 172.16.0.0 can be reached in two possible ways – both via Router B and Router C. In both cases, the hop count to network 172.16.0.0 is identical – 1 hop. A distance vector protocol like RIP decides which route to take based on hop count, but can also load-balance over routes with the same hop-count in a round-robin fashion. In this case, some packets will be sent to network 172.16.0.0 via Router B, and some via Router C. It’s worth remembering, however, that hop count is the only metric used by RIP. For example, the link between A and C is only 64kbps, while the link between A and B is a T3 line. Even though AB is a much faster link than AC, Router A still sees both paths as equal. Such is how RIP sees the world.

Figure: Network 172.16.0.0 is available to Router A via two paths, both with a hop count of 1.

Distance Vector Routing Protocols

Distance vector routing protocols create their routing tables based on the networks to which they are directly connected, and the information passed to them by neighboring routers in the form of routing table updates. The term “distance-vector” actually describes the way in which these protocols work. The “vector” is simply a combination of two pieces of information that describe how to get to a network – the direction, and the distance.
For example, a router may find out that a previously unknown network is accessible via its E0 interface (the direction), with a metric of 2 hops (the distance). A metric is simply the piece – or pieces – of information that a router uses in determining which path is the “best” in reaching a destination network. In the case of a protocol like RIP, the metric is the number of routers that need to be crossed in getting to a destination, also called the hop count. In other distance-vector protocols, like IGRP, the default metric is a calculation based on network bandwidth and delay. While we’ll look at both shortly, for now it’s enough to say that a metric is used by a routing protocol to find the best path to reach a destination network.

Distance-vector protocols work on a principle that is sometimes called “routing by rumor”. This is because a router running a distance-vector protocol learns about other networks based on the information provided by neighboring routers. In other words, the knowledge it obtains is not first-hand. The way in which a router learns from neighboring routers is by routing table updates. At certain intervals, a router sends out its complete routing table, which will be received by other routers running the same routing protocol. These other routers look at the information contained in the routing table update, and add routes to their own tables for networks they didn’t previously know about.

Figure: RIP update broadcast from Router A.

Consider the figure above, in which Router A sends out its routing table, which is ultimately received by Router B. Router A knows about networks 192.168.1.0 and 10.0.0.0. Router B doesn’t yet have an entry for network 192.168.1.0, so it adds it to its routing table with a hop count of 1, as shown in Figure 10. When Router B needs to reach network 192.168.1.0, it will forward the packets to Router A. In the same way, Router B will also send out updates to Router A. Through these, Router A will learn that network 172.16.0.0 is available via router B with a hop count of 1. Recall that the hop count is the number of routers that need to be traversed in order to reach a network. Because Router B only needs to go through one other router to reach network 172.16.0.0, the hop count is 1. Hop count is the metric used by RIP. In other words, RIP will choose the best path to a network based on the lowest number of hops.

Figure: Routing table on Router B after RIP update.

If Router C (running the same distance vector routing protocol) were added to our network as shown in the figure above, it would also begin exchanging updates with its neighbors. In this case, it would send a routing table update to Router B, letting it know about network 192.168.2.0. Router B will add this to its routing table with a hop count of 1. In Router B’s next update to Router A, this network would also be included in the table. Router A would thus add it to its routing table, with a hop count of 2. Once all the updates were complete, and all routers knew about all networks, the network is considered to have converged. At that point, the routing tables would appear as shown in the figure below.

Figure: Router C and network 192.168.2.0 added to the existing network.

Figure: Routing tables after the network has converged.