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, distance vector routers contain flat relationships with each other.

Consider the example shown in Figure 11.1, 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.

Figure 11.1. Distance vector routing initiation.

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 network 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 a 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, Routers 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 Figure 11.2. 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.

Figure 11.2. Distance vector routing converged scenario.

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, I will use the existing converged topology and introduce a link failure on Router A, as illustrated in Figure 11.3. 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 down.

Figure 11.3. Link failure scenario.

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 Figure 11.4.

Figure 11.4. Incorrect update scenario.

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 is fed false information about these networks from Router B and also has to keep adjusting its metrics as shown in Figure 11.5.

Figure 11.5. Routing loop.

With all three routers containing false information regarding those networks, any packets destined for the 172.16.0.0 and the 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.

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. Table 11.1 lists the routing protocols and their maximum hop count values.

Notice that RIP version 1 and 2 both have a maximum hop count of 15, which drastically limits the size of the allowed RIP network. EIGRP, because it is 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 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, split horizon does not advertise networks out the same interface as that from which it learned them.

Take the example shown in Figure 11.6. 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 back to Router B out Serial 0/0. In addition, because it heard Router B advertising the 192.168.1.12 network 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 the 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.

Figure 11.6. Split horizon updates.

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, refer to Figure 11.7. 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 this example, because I am using RIP, the maximum hop count is 15, so 16 is an infinite metric.

Figure 11.7. Route poisoning.

When Routers 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 network in a “possible down” state in their routing table, as illustrated in Figure 11.8. This is the work of the hold-down timer.

Figure 11.8. Hold-down timers.

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 Figure 11.8, 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 down state 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 alternate 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.

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 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.

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 router 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 change to its neighbors.

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 a subnet, it load 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 a discontiguous network design.

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

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 Table 11.2, in which N represents the network and H represents the host.

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 Figure 11.9 as an example, Routers 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:

RouterA(config)#router rip
RouterA(config-router)#network 172.16.0.0
RouterA(config-router)#network 192.168.1.0

Figure 11.9. RIP configuration scenario.

Because Router A has the 172.16.0.0 network and the 192.168.1.4 network attached to it, the classful networks that are advertised are 172.16.0.0 because it is a 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 networks in the RIP configuration; thus, you require only one statement for the 192.168.1.0 network that will, in essence, encompass all three subnets. Figure 11.10 shows the configurations for each router in this topology.

Figure 11.10. Completed RIP configuration scenario.

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:

RouterA(config)#router rip
RouterA(config-router)#maximum-paths 6

Some of you may have looked at these configurations and noticed 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 Figure 11.10 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:

RouterA(config)#router rip
RouterA(config-router)#passive-interface fastethernet 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.

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:

Objective:

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:

RouterA(config)#router rip
RouterA(config-router)#version 2
RouterA(config-router)#network 172.16.0.0
RouterA(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:

RouterA(config)#router rip
RouterA(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.

RIP configurations using SDM are relatively similar and just as easy as configuring default and static routes. Select Configuration, Routing. Focus on the bottom of the screen for our dynamic routing protocols. When you click the Edit button, you see the pop-up window shown in Figure 11.11, in which you can specify your routing protocol parameters. You can enable RIP by checking the checkbox and specifying which version you want to run. Below that, you add the networks you want to advertise. Be sure that you specify each network that is directly attached to the router. This ensures that they are included in the routing updates and that the updates are sent and received on the interfaces associated with those networks. Finally, in the bottom of the window, you can check the checkboxes for the interfaces that you want to make into passive interfaces to save bandwidth or control which routers will have updates sent to them.

Figure 11.11. SDM RIP configuration.

Objective:

To verify RIP, you can use an assortment of show commands, each equally contributing to a wealth of information about the RIP routing protocol you configured. For instance, show running-config is an easy pick to show your configuration for RIP and the networks that you have configured. It is also a useful starting point if you are troubleshooting an existing implementation of RIP and you suspect missing or misconfigured network statements.

To ensure that RIP updates are being received from neighbors, show ip route proves the network configuration is functioning, because you will see RIP entries appear in the routing table:

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, P - periodic downloaded static route
       T - traffic engineered route

Gateway of last resort is not set

R    172.17.0.0/16 [120/2] via 192.168.1.6, Serial0/0/0
C    172.16.0.0/16 is directly connected, FastEthernet0/0
R    172.18.0.0/16 [120/2] via 192.168.1.6, Serial0/0/0
     192.168.1.0/30 is subnetted, 3 subnets
R       192.168.1.8 [120/1] via 192.168.1.6, Serial0/0/0
R       192.168.1.12 [120/1] via 192.168.1.6, Serial0/0/0
C       192.168.1.4 is directly connected, Serial0/0/0

The RIP entries are identified in the routing table with the letter R followed by the administrative distance and the hop count in brackets. The IP 192.168.1.6 is the next-hop address to reach those networks out of Serial 0/0/0.

Finally, to see detailed information about all the IP routing protocols configured on a routing device, use show ip protocols to see a plethora of information:

RouterA#show ip protocols
Routing Protocol is "rip"
  Sending updates every 30 seconds, next due in 24 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Redistributing: rip
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP     Key-chain
    FastEthernet0/0       2     2
    Serial0/0/0           2     2                    luckyrabbitsfoot
  Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    172.16.0.0
    192.168.1.0
  Routing Information Sources:
    Gateway         Distance       Last Update
    192.168.1.6          120       00:00:11
  Distance: (default is 120)

In this output, you can see the timers involved with the routing protocol, including the update interval of 30 seconds and the invalid and hold-down timers. The show ip protocols output also lists the interfaces participating in RIP and the version that they are configured to send and receive (in this case, version 2). On our serial 0/0/0 interface, you can also see that we have configured RIP authentication and that the key chain luckyrabbitsfoot is assigned to this interface. In addition, you can see which networks you are routing using RIP. This is useful for administrators who do not have access to privileged EXEC mode (and who therefore cannot use the show running-config command) to verify which networks are being advertised.

Troubleshooting routing protocols always begins with verification of the routing configuration and status by using the show commands discussed in the last section. You can also test whether you have IP connectivity by pinging or you can test the route packets will take by using the traceroute command. However, if you need to get into the trenches, so to speak, and verify the updates as they are being sent and received, you need to use real-time troubleshooting tools entailing the debug command.

To actively see real-time updates as they are being sent and received for RIP, use the privileged EXEC command debug ip rip, as demonstrated here:

RouterA#debug ip rip
RIP protocol debugging is on
RouterA#
*Aug  6 22:33:21.002: RIP: received packet with MD5 authentication
*Aug  6 22:33:21.002: RIP: received v2 update from 192.168.1.6 on Serial0/0/0
*Aug  6 22:33:21.002:      172.17.0.0/16 via 0.0.0.0 in 2 hops
*Aug  6 22:33:21.002:      172.18.0.0/16 via 0.0.0.0 in 2 hops
*Aug  6 22:33:21.006:      192.168.1.8/30 via 0.0.0.0 in 1 hops
*Aug  6 22:33:21.006:      192.168.1.12/30 via 0.0.0.0 in 1 hops

In this section of the debug output, the router receives an update from a neighbor with the IP address 192.168.1.6. This update is a version 2 update and has been authenticated using MD5. If any new subnets are learned from this update, they ultimately are placed in the routing table, using 192.168.1.6 as the next-hop address and Serial 0/0/0 as the exiting interface, because that is where this information was learned. Notice in this section that subnet masks are received in the update, solidifying the fact that you are running a classless routing protocol, RIPv2.

The next bit of output that follows is the local router sending its v2 multicast (224.0.0.9) update out its Fast Ethernet 0/0 interface. Most important, notice how the router increments the hop count by 1 before sending it to any neighbors on its LAN:

*Aug  6 22:33:23.598: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (172.16.0.1)
*Aug  6 22:33:23.598: RIP: build update entries
*Aug  6 22:33:23.598:   172.17.0.0/16 via 0.0.0.0, metric 3, tag 0
*Aug  6 22:33:23.598:   172.18.0.0/16 via 0.0.0.0, metric 3, tag 0
*Aug  6 22:33:23.598:   192.168.1.0/24 via 0.0.0.0, metric 1, tag 0
*Aug  6 22:33:23.598: RIP: ignored v2 packet from 172.16.0.1 (sourced from one of our
 addresses)

Also, take note of the 192.168.1.0 entry that is being advertised out this Fast Ethernet 0/0 interface. Because the interface has an IP address of 172.16.0.1, which is not in the same major network, this router automatically summarized its subnetted entries to 192.168.1.0. Therefore, we can surmise by this debug output that we have not configured the no auto-summary on Router A. If this were the case, the entry would remain classless and look more like this:

*Aug 6 22:33:23.598: 192.168.1.4/30 via 0.0.0.0, metric 1, tag 0

The final output that follows is proof that split horizon is enabled and working on this router. This is evident because the router does not send any entries that it received on serial 0/0/0 from the first output explanation. Recall that split horizon keeps a router from advertising networks back out the interface from which it received that information. Because the 192.168.1.8, 192.168.1.12, 172.17.0.0, and 172.18.0.0 networks were received in the router’s Serial 0/0/0 interface, they cannot be sent back out that interface.

*Aug 6 22:33:23.822: RIP: sending v2 update to 224.0.0.9 via Serial0/0/0 (192.168.1.5)
*Aug 6 22:33:23.822: RIP: build update entries
*Aug 6 22:33:23.822:   172.16.0.0/16 via 0.0.0.0, metric 1, tag 0

Challenge

Given the following design in Figure 11.12, configure RIP on Router A to be able to communicate with the remainder of the preconfigured network. Figure 11.12. RIP configuration challenge. Remember to remove any existing static routes. Why? Enter the configuration process for RIP. Advertise Router A’s networks. What will Router B do with the update from Router A? What will the networks look like when Router B sends them on to Router C? Configure Router A to run RIP version 2. Configure Router A to be classless. What will the update from Router A look like now?

<division> <title>Challenge Answer</title>

You must first remove any static routes because they have a lower administrative distance than RIP. The configuration in steps 2 and 3 would look like the following: RouterA(config)#router rip RouterA(config-router)#network 172.16.0.0 RouterA(config-router)#network 10.0.0.0 Despite having subnetted the major networks in our topology, you must advertise the directly connected classful networks. When Router B receives that update, it adds the 172.16.0.0 entry into its routing table (because 10.1.1.60 is already directly connected) with a metric of 1 and uses Router A’s serial interface as the next hop. The entry is not 172.16.100.0 because Router A auto-summarizes that network when exiting its WAN interface because that is on a different major network. When Router B sends that entry to Router C, it is sent as 172.16.0.0 with a metric (hop count of 2). To configure Router A for RIPv2 and make it classless, you must add the following configurations: RouterA(config)#router rip RouterA(config-router)#version 2 RouterA(config-router)#no auto-summary With this configuration, Router A does not automatically summarize the 172.16.100.0 network and it sends the subnet mask along to Router B. If B is running RIPv2 also, it keeps the network in its subnetted form of 172.16.100.0/24.

</division>