The preceding chapter looked at distance vector routing protocols from a sort of high altitude overview. This article brings you closer so that you can see the specific protocols that belong to this routing protocol class and explore the unique characteristics and functionality they provide. You will also learn how to configure those routing protocols to meet your administrative needs and how to verify and troubleshoot their operations.

Distance vector operations

To recap, distance vector routing protocols are legacy routing protocols that help routing devices determine the networks that are present in a topology. Using a routing algorithm, known as the Bellman-Ford algorithm, distance vector routing protocols periodically broadcast routing updates consisting of the routing table to directly connected neighbors on adjacent data links, regardless of whether a change has occurred in the topology. When those devices receive that update, they compare it with their existing routing table information.

If the distance vector metric for an entry in the routing update is greater (higher) than a current entry in the routing table, it is discarded. If the metric is equal or less, it is added to the routing table with an updated metric to include the path to the advertising neighbor. This entry eventually is passed to the next routing device where the process occurs over again.

Because these neighbors base their decisions on information that is not learned firsthand, distance vector routing protocol operations are often referred to as routing by rumor. In addition, each router in a distance vector routing topology has the same responsibility and function as the next router. In other words, the distance vector router contains a flat relationship with each other. Consider the example shown in the following picture, which uses a classful distance vector routing protocol such as RIP version 1.

Each router contains its directly connected networks in its routing table. Because the routing protocol is classful, the subnetted 192.168.1.0 network has a Fixed-Length Subnet Mask (FLSM) design. In addition, the routing table entries contain the metric (hop count for this particular example) indicated by “0” because they are all connected.

This is also followed by the interface that packets will exit to reach those networks. Without the use of static routes or routing protocols, the routers can never reach the networks that lie beyond their neighbor routers.

After you configure and enable a distance vector routing protocol, it advertises the networks in the routing table to its adjacent neighbors. For example, Router A broadcasts a routing update containing the 192.168.1.4 networks as well as the 172.16.0.0 network to Router B. As soon as Router B receives that update, it compares the entries in its routing table with the information learned from Router A. Router B already knows about 192.168.1.4 as directly connected network, so it disregards that entry because the directly connected network has a lower administrative distance than the routing protocol. Because the 172.16.0.0 network is new information, it adds that to its routing table with an updated metric of 1. The 172.16.0.0 network is one hop away through Router A. similarly when that entry is advertised to Routers C and D, the metric is updated again to 2 because it is two hops away (through Router B and then Router A).

Likewise, Router A, C, and D receive an update from Router B containing two new networks that will be added to their routing table as two hops away. This process continues until each router has an accurate depiction of all the networks in the domain, as shown in the picture below. In other words, the network will be converged. Despite having achieved full convergence, the routes will still advertise their routing table to their neighbors periodically, even if there isn’t a change in the topology.

Routing Loops

One of the major concerns with routing protocols is the possible occurrence of a routing loop. Routing loops are hard to find these days because routing protocols have implemented many measures to mitigate them, but it is still important to examine the plausible historic events that necessitated the need for such measures. Additionally, there still is a slim possibility that these loops can occur regardless of the countermeasures in place.

To demonstrate a routing loop scenario, we will use the existing converged topology and introduce a link failure on Router A, as illustrated in the following picture.

Notice that the routing table in Router A changed to reflect only the remaining connected interface left since its serial link failed. Because the next hop to the protocol learned networks is down, those entries are removed too. Likewise, Router B removes the connected interface as well as the network entry for 172.16.0.0 because that link and consequently the next hop to that network is shown.

Imagine in this scenario that Router D sends its periodic update to Router B before Router B can advertise the topology change in its update. When Router B receives the update, it compares the information with its own routing table as distance vector routing protocols typically do. The new subnet information learned in the routing update is added to the routing table. In this unfortunate case, Router B learns (again) about the 172.16.0.0 and the 192.168.1.4 networks and believes they can be reached through Router D (despite Router D originally having learned those routes via Router B). what’s more, Router B adds its metric to get to Router D to reach the networks that don’t even exist, as shown in the picture below.

Router B continues to update its neighbor routers periodically with the entries in its routing table. Unfortunately, the unreachable networks appear to be moving away because the hop count inevitably increases with each update from Router B and Router D for infinity. All the while, poor Router C also if fed false information about these networks from Router B and also has to keep adjusting its metrics as shown in the picture below.

With all three routers containing false information regarding those networks, any packets destined for the 172.16.0.0 and 192.168.1.4 network are sent to Router D, who in turn, sends them right back to Router B, and so on. These packets will continue to bounce back and forth in the routing loop until the time to live field in the IP packets expire or the link becomes so saturated, traffic cannot flow between the two routers.

Routing loop mitigation

To avoid routing loops, distance vector routing protocols have implemented several countermeasures within the routing protocol operations. The following sections describe the preventive measures that have been put in place to mitigate routing loops. For obvious reasons, the majority of these are integrated within the routing protocol and cannot be disabled.

Counting to infinity

As demonstrated earlier, when routers are continuously passing updates to unreachable networks between each other, the metric continues to increase forever, which is known as counting to infinity. The easiest way to mitigate this routing protocol side effect is to incorporate a ceiling on the maximum hop count in the design of the routing protocol. Using this tactic, routers can determine a network to be unreachable after it reaches the maximum hop count allowed for that protocol. The following table lists the routing protocols and their maximum hop count values.

Protocol	Distance vector/link state/Hybrid	Maximum Hop count
RIPv1	Distance Vector	15
RIPv2	Distance vector	15
EIGRP	Hybrid	224
OSPF	Link State	Infinite

Notice that RIP versions 1 and 2 both have a maximum hop count of 15, which drastically limits the size of the allowed RIP network. EIGRP, because it has some distance vector routing protocol features, has a maximum hop count value of 224. OSPF is a link-state routing protocol that does not use or require a maximum hop count, so it can have an infinite number of hops.

Split Horizon

Split horizon is similar to that old saying, “don’t ride out on the horse you rode in on.” After hearing this little tidbit, if you were to turn around and say back to me that split horizon is similar to that old saying. “Don’t ride out on the horse you rode in on,” it would get redundant, confusing, and annoying pretty quickly. Such is the case with routing updates.

As you saw earlier, you can get into trouble when routers advertise networks back to the router from which they learned them. Split horizon fixes this dilemma by suppressing those networks in the routing updates being sent back to the source. In other words, the split-horizon does not advertise networks out the same interface as that from which it learned them.

Take the example shown in the picture. Because Router D learned about the 192.168.1.4, 192.168.1.8, 172.16.0.0, and 172.17.0.0 subnets from Router B, it does not advertise those networks as well, it does not advertise that back out that interface either. Thus, the only network that Router D will still advertise to Router B is the 172.18.0.0 network because that subnet was not learned via serial 0/0. Now when the link fails on Router A, Router B will not receive a misleading update about 192.168.1.4 and the 172.16.0.0 networks because Router D and Router C do not advertise those networks back to Router B.

Route poison, Poison Reverse, and Hold-Down Timers

To avoid count-to-infinity routing loops, a maximum hop count is defined for a routing protocol so the metrics do not increment indefinitely in the event of a routing loop. With route poisoning, the router that recognizes the link failure poisons the affected networks by setting them to an infinite metric for that routing protocol. When that router sends this update to its neighbors, they are notified of the link failure and can update their routing table accordingly.

To illustrate the route poisoning concept, you can see the picture below. Notice in this topology that a redundant route has been added between Router D and Router A. the resultant routing table for Router D now has a route to the 172.16.0.0 network through Router A because it is only one hop count as opposed to two hops through Router B. in addition, notice that Router D has equidistant hops to reach network 192.168.1.4. in this case, Router D keeps both routes in the routing table and load balances between both links for packets destined for that network. When the link fails between Router A and Router B, Router A and Router B set the affected networks to an infinite metric. In the example, because I am using RIP, the maximum hop count is 15, so 16 is an infinite metric.

When Router C and D receive these updates from their neighbors, they can advertise the poisoned network out all their interfaces. With poison reverse, the routers override the split-horizon rule and even send the update back to the source, which proves useful as an acknowledgment that those devices are aware of the topology change. At the same time, when Routers C and D receive the poisoned update, they put that networks in a “possible down” state in their routing table, as illustrated in the picture below.

Hold-Down timers are activated when a router receives a poisoned update from a neighbor indicating that a known network is now inaccessible. To ensure that the router does not hastily listen to alternate routes causing yet another routing loop, the router ignores updates with a poorer metric than the original until the hold-down timer expires. This gives the rest of the topology ample time to react to the link change. However, if an update is received with a better metric than the original route entry, the router discontinues the hold-down timer and uses that entry in its routing table.

In the above picture, when Routers A and B poison their route entries and pass them to Routers C and D, those poisoned networks are put in a possible downstate and the hold-down timer is activated. In that time, Router B may receive updates from Router D about the 172.16.0.0 network because Router D has an alternative route. However, Router B must wait for the hold-down timer to expire before using the alternate path. For this reason, distance vector routing protocols are considered the slowest routing protocols to converge.

Triggered Updates

One way distance vector routing protocols speed up their convergence while helping avoid routing loops at the same time is something called flash or triggered updates. Because one of the contributing causes of routing loops is the lack of the update information reaching all devices quickly enough, triggered updates enable the router to send the update immediately after a link fails, as opposed to waiting for its periodic update time.

Invalid / Dead Timers

In place of a link failure, what do you suppose would happen if Router A had some operational failures or you removed or changed the routing protocol configuration or networks? Other routers in the domain would not be aware of this change because it isn’t a link failure that they can detect and react to. To ensure that these networks are not circulating indefinitely in a routing system, routing protocols have invalid, or dead, timers. If a router stops receiving updates from a router after a set amount of time, that router is considered to be dead and the networks that learned from that routers are invalid. Likewise, if a particular network stops advertising with a routing protocol, that entry becomes invalid after the dead timer ages out. This timer is reset every time an update is received from a neighbor for each network in the routing table. When the timer expires, the router poisons the route and advertises that topology changes to its neighbors.

RIP

The first distance vector routing protocol that is discussed here is coincidentally one of the oldest routing protocols that are still used today. Circa 1988, routing information protocol (RIP) for IP was defined in RFC 1058; however, its roots stem back to the 1970s at Xerox Corporations Palo Alto Research Center. The following sections look at the characteristics and configurations involved with this resolute routing protocol.

RIP characteristics

RIP is a fairly simple routing protocol in both characteristics and implementation. You already know that RIP uses hop count as its only metric, in which it can support up to 15 as a maximum. In instances where the metric is identical (for example, equal hop count) for the subnet, it loads balances up to six equal paths (four by default). Like other distance vector routing protocols, RIP sends the contents of its routing table to its directly connected neighbors, regardless of whether there is a change in the topology. Particularly, RIP’s update interval is every 30 seconds and its invalid timer is for 180 seconds. Thus, RIP (version 1) broadcasts its routing table every 30 seconds and considers a neighbor or a network to be dead after six missed updates.

Because RIP does not advertise subnet masks in its routing updates, it is also a classful routing protocol. Recall that this requires every subnet of a major network to have the same (fixed-length) subnet masks. In addition, RIP automatically summarizes subnetted networks to their default classful boundaries when sending the update over a different major network which, in turn, nullifies any support for discontiguous network design.

As with many routing protocols, RIP requires manual redistribution if you want to advertise networks from a different routing source other than connected interfaces and other RIP learned networks. This is also the case for default routes. If you configure a static default route in a router that is running RIP, you must use the default-information originate command in the routing process to redistribute that default route in its routing updates to its neighbors without any additional configuration. The neighbors receive these updates and set that router as their gateway of last resort, assuming that a static default route is not configured with a lower administrative distance. The routing table subsequently displays the learned 0.0.0.0/0 subnet as an RIP learned network.

RIP configuration

The configuration for RIP is seamless as long as you remember there two simple rules:

Advertise only your directly connected networks.
Advertise only the classful network.

The first rule is imperative to keep in mind when configuring routing protocols. Remember that the point of the routing protocols is to advertise their known networks to each other so they can build their routing tables. With that being said, do not confuse the configuration of routing protocols with static routes. You do not specify a destination network with routing protocols as you would a static route. Instead, you specify local networks and let the routing protocols advertise them to each other.

Because RIP is a classful routing protocol and does not advertise subnet masks in its updates, the second rule is self-explanatory. Regardless of whether you subnetted major networks into smaller subnets, you have to specify only the subnet to its classful boundary. In other words, you specify the network portion of the IP address and use zeros for the host bits. To recap, the classful boundaries are listed in the following table in which N represents the network and H represents the host.

Class	First Octet	Network
A	1 to 126	N.H.H.H
B	128 to 191	N.N.H.H
C	192 to 223	N.N.N.H

To configure RIP and advertise the directly connected classful networks, you must enter the configuration mode for routing protocols, using the router keyword in global configuration mode followed by the routing protocol you want to configure. After you are in the routing protocol configuration mode (signified by the (config-router)# prompt), you specify the directly connected classful networks by using the network command. If you need to remove a specific network from being advertised, you need to enter the RIP routing process again and enter no followed by the keyword network and the network number you want to remove.

Using the following picture, Router A, C, and D each have two directly connected networks while Router B has three. To configure RIP to advertise the routing protocols, the configuration for Router A would look like the following:

Router A (config)#router rip
Router A(config-router)#network 172.16.0.0
Router A(config-router)#network 192.168.1.0

Because Router A has the 172.16.0.0 network and the 192.168.1.0 network attached to it, the classful networks that are advertised are 172.16.0.0 because it is Class B, and 192.168.1.0 because that network is a Class C. you do not need to include any other network statements because the routers will advertise each others’ networks. After you define the networks with the network command, RIP begins to advertise and listen for updates on those interfaces that are contained in that classful network. For instance, if you did not configure the network 192.168.1.0 statement in Router A, you would never be able to send and receive updates on the serial interface, which would entail that Router B would never learn of the 172.16.0.0 network and Router A would never learn of the other networks in the topology.

Router B has three directly connected 192.168.1.x networks, so how many statements do you think you must configure for Router B to participate in RIP updates? Despite having three networks, you must advertise the classful network that will, in essence, encompass all three subnets. The following picture shows the configuration for each router in this topology.

If you want to change the number of allowed equal paths to load balance with RIP, you can use the maximum-paths command in the routing process. For example, if you wanted to change the maximum-paths to six equal paths, the configuration would look like the following:

Router A (config)#router rip
Router A (config-router)#maximum-paths 6

Passive Interfaces

Some of you may have looked at these configurations and notices a strange flaw in our logic. Namely, we’ve established that when we configure each network to be advertised in the routers, updates begin being sent and received on the interfaces attached to those networks. But do we really need to be sending updates on LANs that do not connect to RIP routers? For instance, the Ethernet interface on Router A from the above picture that connects to the 172.16.0.0 network does not have a router on that LAN segment. In essence, we are wasting good bandwidth and processor cycles by broadcasting these RIP update every 60 seconds to a bunch of computers who do not need to receive them. To solve this dilemma for RIP and all other routing protocols, Cisco created a handy configuration option for routing protocols called passive interface.

With this additional configuration command, you specify an interface or interfaces to the routing protocol process that will no longer send routing updates. What is interesting, however, is that the interfaces will still receive and process updates on that interface. As a result, passive interfaces are useful not only for saving bandwidth, but also can be used to manipulate our routing policies by allowing us to determine whether or not we send routing updates to certain routers. The command to achieve this marvelous feat is passive-interface interface in the routing process configuration, such as shown here for RIP:

Router A (config)#router rip
Router A (config-router)#passive-interface fast ethernet 0/0

With this command in place, updates are no longer sent out of Fast Ethernet 0/0. However, if for some reason an update was received on that interface, it would still process it and put it in its routing table.

RIPv2 characteristics

In an attempt to keep up with modern needs from a routing protocol, RIP version 2 was created in 1994 to address many of the shortcomings of its predecessor. Many of the characteristics are similar to RIPv1; nonetheless, RIPv2 had some significant improvements.

Multicast Updates: Rather than broadcast its routing updates, RIPv2 uses a reserved multicast address of 224.0.0.9 to communicate with other RIPv2 neighbors. By using a multicast address, it does not waste the processing resources of non-RIP devices because only RIPv2 devices process messages to that address.
Classful or classless support: RIPv2 is classful by default, but can be configured as a classless routing protocol, which allows for subnet masks to be sent in the routing updates. The implication of this enhancement entails that RIPv2 can support VLSM and discontiguous network design.
Authenticated updates: To ensure the origin of the routing update and protect from attackers spoofing routing updates, RIPv2 allows update authentication in which the password must match in all routers to validate the routing update.

RIPv2 configuration

The configuration for RIPv2 is practically identical to RIPv1. In other words, you still must enter the RIP routing process with the router rip command and still must advertise the directly connected classful networks. To enable RIPv2, you have to enter the command version 2 in the routing process.

Router A (config)#router rip
Router A (config-router)#version 2
Router A (config-router)#network 172.16.0.0
Router A (config-router)#network 192.168.1.0

By default, RIPv2 is classful. To configure this enhanced routing protocol to support classless routing updates, the only entry you need to configure is the no auto-summary command in the routing process:

Router A (config)#router rip
Router A (config-router)#no auto-summary

After you configure this command, the RIP version 2 updates being multicast to 224.0.0.9 are no longer be considered classful, because the subnet mask is advertised in the updates along with the network.

RIPv2 Update Authentication

As previously mentioned, RIPv2 provides update authentication to help protect from rogue devices or attackers injecting false routing information into your routing table by authenticating the routing updates. This authentication is achieved by defining a key and attaching a key string (password) to it. This key string must match on both routers, or the updates will be rejected.

To define the authentication key, use the key chain command followed by a name for the key chain in global configuration mode. After you enter that command, you are put into config-keychain sub configuration mode:

Router A (config)#key chain lucky rabbits foot
Router A (config-keychain)#

Here you can configure several keys if you want, with different key string passwords. To create a key, use the key keyword and a number identifier for that key. You are put into another sub configuration mode for that specific key, as shown by the config-keychain-key prompt:

Router A (config-keychain)#key 1
Router A (config-keychain)#

Now we finally get to define our password, using the key-string command followed by the password that will match on each side:

Router A (config-keychain-key)#key-string what a RIP off

With our key chain defined, we have to apply it to interfaces that connect to neighboring RIPv2 routers with matching authentication configurations. The command to assign the key chain to the interfaces is IP rip authentication key-chain followed by the key chain you defined a moment ago:

Router A (config-keychain-key)#exit
Router A (config-keychain)#exit
Router A (config)#interface serial 0/0/0
Router A (config-if)#ip rip authentication key-chain lucky rabbits foot

This key chain is sent over the link in clear text by default. This defeats the point of securing links because the key chain can be seen if the link is being eavesdropped. To secure the key using an MD5 hash of the password, use the following command:

Router A (config-if)#ip rip authentication mode md5