Primary Activities of Convergence
Convergence involves four primary activities: update, invalid, holddown, and flush, which are explained in Table 2-1. The following example, which uses the show ip protocol command at the command prompt of RouterA, shows the default timers used by RIP. These are the timers that a Cisco router uses to control the way RIP reacts to changes in its routing table. It is possible to override these defaults by using the timers basic command. See the Cisco command reference for the version of IOS you are using for more information on this command.
Figure 2-1. RouterA has to converge on a new path because the link to RouterC has gone down.
Note
The timers basic command should be used with caution. Inappropriate use of this command can have a catastrophic effect on the IP routing functionality of your router.
RouterA#show ip protocol
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 27 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
.
.
output deleted
.
RouterA#
| Activity | Description |
|---|---|
| Update | The time between routing updates sent by a router. |
| Invalid | A term used to describe both a particular state that a route may be in and a timer that is used to monitor a route's status. The term invalid is used for routes that have not been heard from for the period of time that the invalid timer is set for. For example, if the invalid timer is for 60 seconds and an advertisement for a route from the router it is learned from has not been received for 61 seconds, the invalid timer expires and the route is considered invalid. |
| Hold down | A term used to describe both a particular state that a route may be in and a timer used to monitor the status of a route. The term hold down is used to refer to routes that have been marked as invalid (expired) but are not yet capable of being replaced with a new route of a higher metric. The hold down timer determines how long a route remains in hold down (unless the flush timer fires before the hold down timer finishes running). |
| Flush | A term for both a timer and the act of removing a route from the routing table. The flush timer restarts every time an update is received for a route from the router that it is learned from. It is important to note that the flush timer and the invalid timer restart at the same time and run concurrently. When the flush timer has expired for a route, the route is removed from the routing table. For RIP, the flush timer expires before the hold down timer, so hold down never runs for its complete cycle. |
Viewing the Invalid Timers in a Routing Table
The following routing table from RouterA shows that the invalid timer for 168.71.8.0 from 168.71.9.2 (RouterC) was restarted 39 seconds ago.
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 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 Gateway of last resort is 0.0.0.0 to network 0.0.0.0 168.71.0.0/16 is subnetted, 5 subnets C 168.71.9.0 is directly connected, Serial1 R 168.71.8.0 [120/1] via 168.71.9.2, 00:00:39, Serial1 R 168.71.7.0 [120/1] via 168.71.6.2, 00:00:11, Serial0 [120/1] via 168.71.9.2, 00:00:39, Serial1 C 168.71.6.0 is directly connected, Serial0 C 168.71.5.0 is directly connected, Ethernet0 S* 0.0.0.0/0 is directly connected, Ethernet0 RouterA#
The information immediately after the next hop IP address is the timer information. 00:00:00 is hh:mm:ss—hours, minutes, and seconds. The timer is reset to all 0s every time an update for the route is received.
Viewing an Expired Invalid Timer in a Routing Table
This scenario shows how to determine when a route—in this case, 168.71.8.0—is in hold down. For this example to work properly, the serial link between RouterA and RouterC has to remain up and RouterC has to stop advertising 168.81.8.0 to RouterA. If the serial link between the two routers were to fail, RouterA would immediately remove any routes from its routing table that it was using RouterC to reach without waiting for the hold down timer to expire.
In order to show what happens when a route is lost for a reason other than a directly attached link failing, it's necessary to stop RouterC from advertising 168.71.8.0 to RouterA. To do this, an access list is applied to the router rip section of RouterC's configuration. The new configuration for RouterC is as follows:
!
interface tokenring0
ip address 168.71.8.1 255.255.255.0
!
interface serial0
ip address 168.71.7.1 255.255.255.0
bandwidth 64
!
interface serial1
ip address 168.71.9.2 255.0.0.0
bandwidth 128
!
router rip
network 168.71.0.0
distribute-list 1 out serial1
!
access-list 1 deny 168.71.8.0 0.0.0.0
access-list 1 permit 0.0.0.0 255.255.255.255
!
Note
Refer to your Cisco IOS documentation for an explanation of access list configuration and use. The concept of using access lists to filter routing updates is explained in more detail in Chapter 5, "Default Routing."
In the following routing table from RouterA, you can see that RouterA's invalid timer has expired for 168.71.8.0 and that the route is marked "possibly down, routing via 168.71.9.2, Serial1." At this point, the route is considered to be in holddown, and the 180-second holddown is now running.
There is another path via RouterB by which RouterA can reach 168.71.8.0. RouterA should converge on this path after it finally gives up on the original route via RouterC. In the meantime, RouterA will continue to use this route to reach 168.71.8.0.
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 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 Gateway of last resort is 0.0.0.0 to network 0.0.0.0 168.71.0.0/16 is subnetted, 5 subnets C 168.71.9.0 is directly connected, Serial1 R 168.71.8.0/24 is possibly down, routing via 168.71.9.2, Serial1 R 168.71.7.0 [120/1] via 168.71.6.2, 00:00:24, Serial0 C 168.71.6.0 is directly connected, Serial0 C 168.71.5.0 is directly connected, Ethernet0 S* 0.0.0.0/0 is directly connected, Ethernet0 RouterA#
RouterA will continue to use this route to forward packets destined for subnet 168.71.8.0. This concept is explained in the next scenario.
HINT
If a network administrator discovers that a route is in holddown, he or she can attempt to clear the route manually to speed up convergence if a different path is available. If no other path is available, this command will probably not help resolve the connectivity loss problem created by the route going into holddown. The syntax for this command, using the route from this scenario, is as follows:
RouterA#clear ip route 168.71.8.0
This command was not used in this section because it would have invalidated the scenario being presented. This command can be used on routes that are in holddown with no negative effect. If it is used on an active route (one that is not in holddown), temporary connectivity loss can occur. It is best to experiment with this command in a lab environment to understand how it will affect IP connectivity before using it in a live environment.
The administrator can also use the traceroute command to find a router that has a connection to the network that is in holddown. Depending on the topology of the network and the status of the routing tables in the routers that the traceroute command encounters, it may actually end up at the router that was advertising the route that has gone into holddown. However, it is not really necessary to find the exact router that was sending the original route. Any router connected to the same network can be used to investigate what the problem is and possibly resolve it. It could be something like an Ethernet segment with excessive collisions that is constantly resetting or a beaconing Token Ring segment. The traceroute command is available on Cisco routers and most other hosts that use TCP/IP. The syntax of this command on a Cisco router's command prompt is as follows:
RouterA#traceroute 168.71.8.0
In Figure 2-1, the traceroute 168.71.8.0 command from RouterA would end up at RouterC using the path via RouterB after RouterA had converged on the new path. An investigation of RouterC would have turned up the fact that someone had configured an access list against RIP. The TraceRoute utility is described in more detail in Chapter 6, "IP Troubleshooting Scenarios." More information on TraceRoute can be found in RFC 1393 as well (see Appendix A, "RFCs").
Router Still Uses a Path
During the time RouterA has its route to 168.71.8.0 in holddown, it continues to forward any packets it receives that are destined for subnet 168.71.8.0 to RouterC. This is standard behavior for a router running RIP, as well as for many other IP routing protocols.
One of the reasons for having routing protocols behave this way is based on the following assumption:
Temporary packet loss due to using routes to networks that might not be viable is better than immediately accepting a less desirable route to the destination network.
In this scenario, the less desirable path would be for RouterA to reach 168.71.8.0 via RouterB. If 168.71.8.0 went into holddown in RouterA because of congestion on the link between RouterA and RouterC—which caused the packets with the routing updates to be dropped—packets from sessions between hosts on subnets 168.71.5.0 and 168.71.8.0 over the same link should be dropped as well.
By allowing these packets to be dropped instead of sending them via the less desirable path, RouterA and RouterC are giving the hosts a chance to react to the dropped packets by sending fewer packets at a time—and perhaps even sending smaller packets. This requires that either the applications in use or their underlying protocols keep track of packet loss and react in a network-friendly fashion.
HINT
In networks with very large routing tables, the updates might be split between multiple packets. If you have recently added several new routes and are having problems with these routes not being learned by other routers or other routes that were once stable suddenly disappearing—particularly over low-speed serial links—it is very probable that the same packets at the end of each update are getting lost. Routes are usually advertised in descending order: 134.67.0.0 would be sent before 120.34.0.0. If your lowest numbered routes are having problems, this is most likely what is happening.
If RouterA immediately accepted the less desirable route to 168.71.8.0 as soon as the invalid timer for 168.71.8.0 expired and forwarded all traffic to 168.71.8.0 over it, congestion on the more desirable path between RouterA and RouterC would cease to be a problem.
Note
Remember that holddown is both the name of a timer that routing protocols use and the name of a function. The holddown timer, which is 180 seconds for RIP, starts when the invalid timer expires. The holddown function is the same for all IP routing protocols. It is used to prevent a new, higher-cost (less desirable) route from being accepted for a route that has been marked invalid for the period of the holddown timer.
The routing updates that had been getting dropped due to congestion would start arriving again, and RouterA would immediately go back to using its link to RouterC to reach 168.71.8.0. At this point, the problem would start all over again.
This is referred to as route flapping, which is when a route continuously switches between two different next hop routers— RouterB and RouterC in this scenario.
If the traffic pattern that caused this problem is more than just an anomaly, it will be necessary to either increase the speed of the link between RouterA and RouterC or permanently configure the hosts to send fewer packets at a time (and possibly smaller packets as well) to prevent it from happening again.
In this scenario, Ping (Packet Internet Groper) will be used to generate IP packets to prove that a router will continue to forward packets to a network that it believes may be unreachable.
Note
Ping is a useful diagnostic tool that is available on all TCP/IP-capable systems. If you type ping, followed by an IP address, at a router console, the router attempts to send IP ping packets to the destination IP host. If the host is reachable, it should respond. The device sending the ping keeps track of the time it was sent and when a response was received so that it has a rough idea of how long it takes to send and receive IP packets with a remote host.
Cisco routers, as well as many other hosts using TCP/IP, run the Ping application as a very low priority task on the CPU. This can cause the round-trip times to appear longer than they really are. A better way to measure round-trip time is to analyze traffic from an actual application flow perspective. Most analyzers time stamp the packets they decode. For applications that send data in response to queries such as databases or Web pages, the time between the request and the response is the total network delay. However, this delay also includes any time the server took to process the request before replying.
Figure 2-2 shows that RouterA will continue to use its original route to 168.71.8.0 even though it is marked as "Possibly Down." Refer to the output of the show ip route command from RouterA that was presented at the end of the previous section.
Figure 2-2. RouterA still uses the route to 168.71.8.0.
The following debug messages from RouterA show that RouterA still sends ping packets to 168.71.8.1 over the serial link to RouterC. The responses to the pings from RouterC to RouterA also show up in the debug messages. The last part of each message indicates whether the packet is being sent (sending) or received (rcvd).Refer to Figure 2-2 when reading the debug messages.
RouterA#deb ip packet RouterA#ping 168.71.8.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 168.71.8.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 20/23/24 ms RouterA# IP: s=168.71.9.1 (local), d=168.71.8.1 (Serial1), len 100, sending IP: s=168.71.8.1 (Serial1), d=168.71.9.1 (Serial1), len 104, rcvd 3 IP: s=168.71.9.1 (local), d=168.71.8.1 (Serial1), len 100, sending IP: s=168.71.8.1 (Serial1), d=168.71.9.1 (Serial1), len 104, rcvd 3 IP: s=168.71.9.1 (local), d=168.71.8.1 (Serial1), len 100, sending IP: s=168.71.8.1 (Serial1), d=168.71.9.1 (Serial1), len 104, rcvd 3 IP: s=168.71.9.1 (local), d=168.71.8.1 (Serial1), len 100, sending IP: s=168.71.8.1 (Serial1), d=168.71.9.1 (Serial1), len 104, rcvd 3 IP: s=168.71.9.1 (local), d=168.71.8.1 (Serial1), len 100, sending IP: s=168.71.8.1 (Serial1), d=168.71.9.1 (Serial1), len 104, rcvd 3 RouterA
In the previous router output, you can see that RouterA sent five pings to a host on the 168.71.8.0 subnet; in this case, the host is RouterC's Token Ring interface. The pings were successful, as indicated by the exclamation points (!). This proves that even though RouterA thought its route to 168.71.8.0 was no longer valid, it still used it to forward packets.
Note
The preceding router output also shows the use of the debug ip packet command. When the router is Process Switching IP packets, this causes the router to display debug information for every IP packet that it either sends or receives. Process Switching is explained later in this chapter in the section on Process Switching versus Fast Switching. This command should be used with extreme care. It can cause a heavily loaded router to stop functioning. It is possible to use access lists in conjunction with some debugging commands (including debug ip packet) to reduce their performance impact on a router, which is explained in Chapter 5. If you are using a Telnet connection to a router, you need to enter the terminal monitor command in order to view the output of debug commands. You must do this for every new Telnet session. Check the version of Cisco IOS you are running to find out its default behavior for sending debug messages.