Cisco Knowledge Suite Cisco SystemsCisco Press
   

   
Home
MyCKS
Cutting Edge
Certification
Core Reference
Guided Learning
   
Networking Architecture
LAN
WAN
Switching
Internet Protocols (IP)
Network Protocols
Transport and Application Protocols
Desktop Protocols
Security and Troubleshooting
Network Resources and Management
Integrated Services
 

Routing Metrics and Distances

   

Contents Next >

Routing Metrics and Distances

  

 

Primary Activities of Convergence

  

 

Understanding Convergence

  

 

Process Switching Versus Fast Switching

  

 

Understanding the Role of Split Horizon

  

 

Poison Reverse and Triggered Updates

  

 

IGRP Routing Metrics (Variables) and Cisco Administrative Distances

  

 

Summary

Save to MyCKS

 
IP Routing Primer

From: IP Routing Primer
Author: Robert Wright
Publisher: Cisco Press (53)
More Information

2. Routing Metrics and Distances

This chapter focuses on convergence and parallel paths, primarily discussing their interaction with routing metrics and distances.

Convergence is the process routers go through when a route (network) or group of routes has become unavailable due to a link going down in the network or extreme packet loss on a link. This loss results in the routers flushing the lost routes and listening to see whether other routes are available. Routers usually store only the best route to a network in their routing tables. Other, higher-cost, routes may exist, but the router ignores them if it believes that the better route still exists.

In the example in Figure 2-1, RouterA converges on a new path to 168.71.8.1 because the link between RouterA and RouterC has failed.

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#

Table 2-1. Primary Activities of Convergence

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.

   

Contents Next >

Save to MyCKS

 

Breaking News

One of the primary architects of OpenCable, Michael Adams, explains the key concepts of this initiative in his book OpenCable Architecture.

Expert Advice

Ralph Droms, Ph.D., author of The DHCP Handbook and chair of the IETF Dynamic Host Configuration Working Group, guides you to his top picks for reliable DHCP-related information.

Just Published

Residential Broadband, Second Edition
by George Abe

Introduces the topics surrounding high-speed networks to the home. It is written for anyone seeking a broad-based familiarity with the issues of residential broadband (RBB) including product developers, engineers, network designers, business people, professionals in legal and regulatory positions, and industry analysts.

             
     

From the Brains at InformIT

|

Contact Us

|

Copyright, Terms & Conditions

|

Privacy Policy

 

© Copyright 2000 InformIT. All rights reserved.