IGRP Routing Metrics (Variables) and Cisco Administrative Distances
This section covers two of the five possible variables of IGRP (Interior Gateway Routing Protocol) routing metrics— bandwidth and delay. It explains why only two are used and why it is usually best to accept the defaults for these two variables based on the type of link in use and its speed. It also discusses the concept of administrative distances.
IGRP Metrics (Variables)
IGRP can be configured to take the following variables into account when determining which routes to use:
Bandwidth: This is a measure of the speed of the physical network connected to an interface. A 64K serial connection has a bandwidth of 64,000 bits per second. Cisco uses a factor of 1000 in the bandwidth command. Therefore, entering the command bandwidth 64 on a serial interface results in a configured bandwidth of 64K.
Delay: This is an arbitrary measurement of how long it takes an interface to serialize the maximum size of a packet that an interface can accept onto the physical media. Slower links have higher delays, and faster links have lower delays. The number used on the interface is not determined dynamically; it is configured to a static value by a network administrator or left at the Cisco default.
Load: In Cisco terms, this is a measurement that is taken over a period of time and averaged. It doesn't reflect an exact instant in time but is meant to reflect the utilization of a link.
Reliability: In Cisco terms, this is a measurement that is taken over a period of time and averaged. It doesn't reflect an exact instant in time but is meant to reflect the condition of a link. It can incorporate how often the link transitions from an up state to a down state, as well as the error rate of frames arriving on the link.
MTU (maximum transmission unit): This represents the largest frame a link can accept.
Cisco recommends that only bandwidth and delay be used due to the following factors:
Reliability is another transient condition; error conditions can come and go quickly. If a link is really so unreliable that it needs to be rerouted around, it should be shut down on the router until it can be repaired.
In addition to both of the points just made, convergence itself can take several minutes. In the meantime, the routers in the network may have paths that are really loops or black holes. Packets get forwarded to routers that do not have information sufficient to forward them further and consequently drop them.
Very few end systems constantly generate frames at the largest size a link is capable (MTU) of on a constant basis. Many applications, such as Telnet and HTTP Web traffic, generate many more smaller frames than maximum-sized frames. These applications tend to have asymmetric traffic patterns; larger frames travel in one direction while smaller frames travel in the other direction. Including the MTU in the equation complicates the decision of which route to use, and this problem isn't offset by the benefit it would provide.
Administrative Distances
The term metric has already been explained as describing the overall desirability of a route to a remote (not locally attached) network.
With Cisco routers, there is another concept called administrative distance, which is a subjective analysis of the believability of a routing protocol. In other words, if a router running two different routing protocols learns about the same network from both protocols, the protocol that has the lower distance associated with it will be the one whose entry is installed in the router's routing table. The types of distances used in the next scenario, which is on running multiple routing protocols concurrently, are as follows:
Connected interface Distance 0
A subnet that is assigned to an interface in the router takes precedence over an advertised route for the same subnet. If RouterB advertised a route to 168.71.5.0, RouterA would ignore it because it has a connected route to this subnet already.
Static route Distance 1
A route that has been manually configured into a router. If RouterA had a static route indicating that 168.71.8.0 was reachable via the next hop of 168.71.6.2 (RouterB), this route would override any dynamic route RouterA received from RouterC, even though the RouterA-to- RouterC path is actually shorter in terms of hops.
IGRP Distance 100
Cisco's proprietary Interior Gateway Routing Protocol.
RIP Distance 120
An IETF standard routing protocol.
There are several other types of routing protocols and associated distances. When using a combination of routing protocols, keep in mind that the default distance values may cause a router to use a path that you did not intend it to use.
Running Multiple Routing Protocols Concurrently
Two routers have been reconfigured for this scenario (see Figure 2-11). RouterA and RouterC are running both RIP and IGRP. RouterB is only running IGRP in order to demonstrate that when RouterC receives a one-hop route to 168.71.5.0 from RouterA via RIP, it will ignore it in lieu of the two hop IGRP route it receives from RouterB.
Note
Running multiple routing protocols is fairly common. Companies that have a lot of UNIX systems that use RIP but want to run IGRP on the routers use the RIP/IGRP combination. Distance will always play a part in configurations with more than one routing protocol running, regardless of the routing protocol combination used.
Figure 2-11. The network now has two routing protocols running.
In order to make this scenario work, RouterA and RouterC only send RIP advertisements over the link between them, which is accomplished by applying access lists to the RIP and IGRP sections of each router's configuration.
RouterA's new configuration is as follows:
!
interface ethernet0
ip address 168.71.5.1 255.255.255.0
!
interface serial0
ip address 168.71.6.1 255.255.255.0
bandwidth 128
!
interface serial1
ip address 168.71.9.1 255.255.255.0
!
router igrp 109
network 168.71.0.0
distribute-list 1 out serial1
router rip
network 168.71.0.0
distribute-list 1 out serial0
!
access-list 1 deny 0.0.0.0 255.255.255.255
!
RouterB's new configuration is as follows:
!
interface serial0
ip address 168.71.6.2 255.255.255.0
bandwidth 128
!
interface serial1
ip address 168.71.7.2 255.255.255.0
bandwidth 128
!
router igrp 109
network 168.71.0.0
!
RouterC's new configuration 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 128
!
interface serial1
ip address 168.71.9.2 255.255.255.0
!
router igrp 109
network 168.71.0.0
distribute-list 1 out serial1
router rip
network 168.71.0.0
distribute-list 1 out serial0
!
access-list 1 deny 0.0.0.0 255.255.255.255
!
In the following output from the debug ip rip and debug ip igrp transactionscommands, you can see the debug messages from both routing protocols as they arrive at RouterC.
RouterC#debug ip rip
Oct 7 22:33:10: RIP: received update from 168.71.9.1 on Serial1
Oct 7 22:33:10: 168.71.6.0 in 1 hops
Oct 7 22:33:10: 168.71.5.0 in 1 hops
RouterC#deb ip igrp transactions
Oct 7 22:35:59: IGRP: received update from 168.71.7.2 on Serial0
Oct 7 22:35:59: subnet 168.71.6.0, metric 82125 (neighbor 80125)
Oct 7 22:35:59: subnet 168.71.5.0, metric 10004001 (neighbor 10002001)
Note
The debug ip rip and the debug ip igrp transactions commands perform the same function for their respective routing protocols. See the Cisco IOS documentation for more details on these two commands.
Notice in the following routing table from RouterC that the route to 168.71.5.0 is via serial 0 through RouterB even though the connection via serial 1 is only one hop. This is because, as previously explained, IGRP has a distance of 100, whereas RIP has a distance of 120. The smaller distance value overrides what appears to be a physically shorter route.
RouterC#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
Gateway of last resort is 168.71.7.2 to network 10.0.0.0
I* 10.0.0.0 [100/180250] via 168.71.7.2, 00:00:47, Serial0
168.71.0.0 255.255.255.0 is subnetted, 5 subnets
C 168.71.9.0 is directly connected, Serial1
C 168.71.8.0 is directly connected, TokenRing0
C 168.71.7.0 is directly connected, Serial0
I 168.71.6.0 [100/82125] via 168.71.7.2, 00:00:47, Serial0
I 168.71.5.0 [100/10004001] via 168.71.7.2, 00:00:47, Serial0
R* 0.0.0.0 0.0.0.0 [120/1] via 168.71.9.1, 00:00:18, Serial1
RouterC#
If the links connecting RouterA to RouterB and RouterB to RouterC were both T1s (1.54MB), and the link between RouterA and RouterC were 256K (a fractional T1), the best path from a bandwidth perspective would be the one that IGRP selected in this instance. RIP lacks the capability to take into account the speed of the links it is being used over. If all of the routers in Figure 2-11 were running IGRP, the path from RouterA to 168.71.8.0 would be via RouterB.
Altering IGRP's Bandwidth and Delay Variables
This section further explains the functionality of the two IGRP metrics normally used: bandwidth and delay.
RIP will no longer be mentioned because Cisco routers do not have a function for manipulating RIP tables to make them override RIP's default hop-based metric. This means that if all of the routers in Figure 2-11 were running RIP, the links connecting RouterA to RouterB and RouterB to RouterC were both T1s (1.54MB), and the link between RouterA and RouterC was 256K (a fractional T1), RIP would still use the less desirable (slower) one-hop route.
RouterB would have to introduce significant latency (delay in switching a packet from one interface to another) to negate the speed benefit of sending a packet over the two hop routes.
As previously stated, IGRP is capable of using five metrics: bandwidth, delay, load, reliability, and MTU. Normally, only bandwidth and delay are considered. The overall IGRP metric for any path between a router and a remote network is based on the minimum bandwidth of any link in the path and the sum of all delays in the path.
This scenario proves this concept by configuring RouterC to load share traffic destined to 168.71.5.0 over its links to both RouterA and RouterB. In other words, RouterC still has two equal-cost routes to 168.71.5.0. All three routers are now running IGRP, as shown in Figure 2-12.
In the following routing table from RouterC, only one route is installed to 168.71.5.0. This is the normal condition before any manipulation of the IGRP variables has taken place.
Figure 2-12. Review of the basic network topology—all routers are now running IGRP.
RouterC#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
Gateway of last resort is not set
I* 10.0.0.0 [100/180250] via 168.71.7.2, 00:00:42, Serial0
168.71.0.0 255.255.255.0 is subnetted, 5 subnets
C 168.71.9.0 is directly connected, Serial1
C 168.71.8.0 is directly connected, TokenRing0
C 168.71.7.0 is directly connected, Serial0
I 168.71.6.0 [100/82125] via 168.71.9.1, 00:00:21, Serial1
[100/82125] via 168.71.7.2, 00:00:42, Serial0
I 168.71.5.0 [100/10002001] via 168.71.9.1, 00:00:21, Serial1
RouterC#
It is possible to convince RouterC to install the other path to 168.71.5.0 via RouterB by manipulating the delay command on RouterC's serial 1 interface. RouterC needs to believe that the total delay to 168.71.5.0 over its link to RouterA is equal to the total delay of the link to 168.71.5.0 over its link to RouterB. Remember from the earlier discussions that RouterC does not know that RouterB is not connected to 168.71.5.0 and has to forward packets destined to 168.71.5.0 to RouterA. All RouterC needs to believe is that RouterB is the next hop in the path to 168.71.5.0. Figure 2-13 shows where the increased delay is required.
Figure 2-13. The decay is cumulative across all links in a path.
The following text shows how to configure the delay variable on an interface. This process is the same for all types of interfaces.
RouterC#conf term
RouterC(config)#int s 1
RouterC(config-if)#delay 4000
RouterC(config-if)#^Z
RouterC#
The following section of RouterC's configuration shows the result of increasing the delay on serial 1 to 40,000. The units are 10s, so 4000=40,000.
hostname RouterC
!
interface serial1
ip address 168.71.9.2 255.0.0.0
bandwidth 128
delay 4000
!
To view the results of the delay command on the interface itself, use the show interface command, as shown here:
RouterC#show interface serial 1
Serial1 is up, line protocol is up
Hardware is HD64570
Internet address is 168.71.9.2 255.255.255.0
MTU 1500 bytes, BW 128 Kbit, DLY 40000 usec, rely 255/255, load 1/255
Now that the delay on RouterC's serial 1 interface has been changed to 40,000 usecs, the two paths to 168.71.5.0 should be installed in RouterC's routing table.
Using the show ip route command, followed by a subnet—in this case, 168.71.5.0—the router limits the output of the routing table to information relevant to the requested subnet. This can be very useful when a router has a large routing table. The output of this command shows that RouterC now has two equal-cost paths (parallel routes) to 168.71.5.0.
RouterC#show ip route 168.71.5.0
Routing entry for 168.71.5.0 255.255.255.0
Known via "igrp 109", distance 100, metric 10004001
Redistributing via igrp 109
Advertised by igrp 109 (self originated)
Last update from 168.71.7.2 on Serial0, 00:00:54 ago
Routing Descriptor Blocks:
* 168.71.9.1, from 168.71.9.1, 00:01:01 ago, via Serial1
Route metric is 10004001, traffic share count is 1
Total delay is 40010 microseconds, minimum bandwidth is 128 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0
168.71.7.2, from 168.71.7.2, 00:00:54 ago, via Serial0
Route metric is 10004001, traffic share count is 1
Total delay is 40010 microseconds, minimum bandwidth is 128 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
RouterC#
The following output of debug ip igrp transactions from RouterC shows both routes to 168.71.5.0 being advertised to RouterC with the same metric. The first message is from RouterA; the second is from RouterB. This is why the previous routing table has both routes in it.
RouterC#debug ip igrp transactions
Oct 8 16:57:59: IGRP: received update from 168.71.9.1 on Serial1
Oct 8 16:57:59: subnet 168.71.6.0, metric 84125 (neighbor 80125)
Oct 8 16:57:59: subnet 168.71.5.0, metric 10004001 (neighbor 10000001)
Oct 8 16:58:24: IGRP: received update from 168.71.7.2 on Serial0
Oct 8 16:58:24: subnet 168.71.9.0, metric 84125 (neighbor 82125)
Oct 8 16:58:24: subnet 168.71.6.0, metric 82125 (neighbor 80125)
Oct 8 16:58:24: subnet 168.71.5.0, metric 10004001 (neighbor 10002001)
RouterC#
Note
A key point to understand is that a router uses the delay on an interface it receives a routing advertisement over to determine the metrics for the routes being advertised. In other words, delay is applied on inbound advertisements, not outbound. The delay variable was not changed on RouterA. Instead, it was changed on RouterC in order to force RouterC to accept RouterA's advertisement for 168.71.5.0.
RouterC now load balances over the two links in either a session-by-session basis or a packet-by-packet basis. This may result in better utilization of the links between RouterC and RouterA. However, if RouterB is already sending enough traffic to RouterA to keep the link nearly full, the extra traffic from RouterC may cause it to be oversubscribed. Care should always be used when manipulating routing tables to make them behave in a way that is different from their default behavior. The end results may not be what you expected.
Problems with Manipulating the Delay Variable
It is not possible to have both RouterB and RouterC load balance their traffic to 168.71.5.0. Figure 2-14 shows where the increased delay is required for RouterB to load balance.
Figure 2-14. The decay is still cumulative across all links in a path,which prevents load balancing.
In order for RouterB to accept RouterC's and RouterA's advertisements for 168.71.5.0, the total delay on both paths from RouterB's perspective have to be equal. Because the delay on RouterC's serial 1 interface was changed to 40,000 usecs to force RouterC to load share, RouterB's serial 0 interface delay would have to be changed to 60,000 usecs—20,000 for the link to RouterC and an additional 40,000 for the link between RouterC and RouterA. This would affect the total delay that RouterC's path to 168.71.5.0 via RouterB encounters. RouterC would now have a path to 168.71.5.0 via RouterA with a delay of 40,000 usecs and a path to 168.71.5.0 via RouterB with a total delay of 80,000 usecs—20,000 for the link to RouterB and the additional 60,000 for RouterB's link to RouterA.
The next section illustrates what happens to the metrics advertised with routes when the delay variable is altered.
Understanding the Effects of Manipulating theDelay Variable
Increasing the delay on an interface causes the router to alter the metric it uses to advertise routes learned over the link to other routers. The delay on RouterB's serial 0 interface was changed to 40,000 usecs, which will cause RouterB to alter the metrics it uses for routes learned from RouterA when advertising them to RouterC. Figure 2-15 shows where the increased delay is applied.
Figure 2-15. The delay parameter has been increased as shown.
The following output of the show interface command on RouterB shows that the delay on its serial 0 has been increased to 40,000:
RouterB#show interface serial 0
Serial0 is up, line protocol is up
Hardware is HD64570
Internet address is 168.71.6.2 255.255.255.0
MTU 1500 bytes, BW 128 Kbit, DLY 40000 usec, rely 255/255, load 1/255
The following code is RouterC's entry for 168.71.5.0 now that RouterB has had the delay on serial 0 increased to 40,000 usecs. Note that the metric for this route is the same as before for serial 1: 10004001. The other route via serial 0 is not installed because the metric has increased from RouterB. The combined delay that RouterC sees for the path to 168.71.5.0 via RouterB is now 60,000 usecs—20,000 usecs for the link to RouterB and 40,000 usecs for the link between RouterB and RouterA.
The following output of debug ip igrp transactions from RouterC shows the advertisements for 168.71.5.0 arriving from RouterA and RouterB with different metrics. The first message is from RouterA and the second is from RouterB.
RouterC#debug ip igrp transactions
Oct 8 16:55:09: IGRP: received update from 168.71.9.1 on Serial1
Oct 8 16:55:09: subnet 168.71.6.0, metric 84125 (neighbor 80125)
Oct 8 16:55:09: subnet 168.71.5.0, metric 10004001 (neighbor 10000001)
Oct 8 16:55:29: IGRP: received update from 168.71.7.2 on Serial0
Oct 8 16:55:29: subnet 168.71.6.0, metric 84125 (neighbor 82125)
Oct 8 16:55:29: subnet 168.71.5.0, metric 10006001 (neighbor 10004001)
The difference in the metrics is why the routing table from RouterC has only one route to 168.71.5.0 in it.
RouterC#show ip route 168.71.5.0
Routing entry for 168.71.5.0 255.255.255.0
Known via "igrp 109", distance 100, metric 10004001
Redistributing via igrp 109
Advertised by igrp 109 (self originated)
Last update from 168.71.9.1 on Serial1, 00:00:20 ago
Routing Descriptor Blocks:
*168.71.9.1, from 168.71.9.1, 00:00:20 ago, via Serial1
Route metric is 10004001, traffic share count is 1
Total delay is 40010 microseconds, minimum bandwidth is 128 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0
RouterC#
Compare the previous routing table, which was observed after RouterB's delay on serial 0 was increased to 40,000 usecs as shown in Figure 2-15, with the routing table and debug messages observed while RouterB's delay on serial 0 was still 20,000 usecs as shown in Figure 2-13:
RouterC#show ip route 168.71.5.0
Routing entry for 168.71.5.0 255.255.255.0
Known via "igrp 109", distance 100, metric 10004001
Redistributing via igrp 109
Advertised by igrp 109 (self originated)
Last update from 168.71.7.2 on Serial0, 00:00:54 ago
Routing Descriptor Blocks:
* 168.71.9.1, from 168.71.9.1, 00:01:01 ago, via Serial1
Route metric is 10004001, traffic share count is 1
Total delay is 40010 microseconds, minimum bandwidth is 128 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0
168.71.7.2, from 168.71.7.2, 00:00:54 ago, via Serial0
Route metric is 10004001, traffic share count is 1
Total delay is 40010 microseconds, minimum bandwidth is 128 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
RouterC#
The following output of debug ip igrp transactions from RouterC shows both routes to 168.71.5.0 being advertised to RouterC with the same metric. The first message is from RouterA; the second is from RouterB, which is why the previous routing table has both routes in it.
RouterC#debug ip igrp transactions
Oct 8 16:57:59: IGRP: received update from 168.71.9.1 on Serial1
Oct 8 16:57:59: subnet 168.71.6.0, metric 84125 (neighbor 80125)
Oct 8 16:57:59: subnet 168.71.5.0, metric 10004001 (neighbor 10000001)
Oct 8 16:58:24: IGRP: received update from 168.71.7.2 on Serial0
Oct 8 16:58:24: subnet 168.71.9.0, metric 84125 (neighbor 82125)
Oct 8 16:58:24: subnet 168.71.6.0, metric 82125 (neighbor 80125)
Oct 8 16:58:24: subnet 168.71.5.0, metric 10004001 (neighbor 10002001)
RouterC#
This section has explained how manipulating the delay variable affects routing metrics and some of its limitations. The next section explains the role of the bandwidth variable in more detail.
Understanding the Effects of Manipulating the Bandwidth Variable
This scenario illustrates that the bandwidth variable is not cumulative. Only the lowest bandwidth in a path is taken into account when determining a metric for a route. This is illustrated by observing how changing the bandwidth on RouterB's serial 0 interface affects the metric RouterB advertises to serial 0's subnet—168.71.6.0—but does not affect the metric RouterC uses for its route to 168.71.6.0.
Figure 2-16 shows that the bandwidth on RouterB's serial 0 interface has been changed to that of a T1 connection— 1.54MB.
Figure 2-16. Changing the bandwidth on routerB's serial 0 to a higher speed has no effect on routerC.
The following output from RouterB shows how to change the bandwidth variable and how to tell whether the change has taken effect.
RouterB#config term
RouterB(config)#interface serial 0
RouterB(config-if)#bandwidth 1544
RouterB(config-if)#^Z
RouterB#show interface serial0
Serial0 is up, line protocol is up
Hardware is HD64570
Internet address is 168.71.6.2 255.255.255.0
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
The following output of the debug ip igrp transactions command on RouterC shows the metric advertised by RouterB to RouterC for 168.71.6.0 before the bandwidth on RouterB's serial 0 was changed.
RouterC#debug ip igrp transactions
Oct 8 16:58:24: IGRP: received update from 168.71.7.2 on Serial0
Oct 8 16:58:24: subnet 168.71.6.0, metric 82125 (neighbor 80125)
RouterC#
In the previous debug output from RouterC, the bandwidth was 128, as indicated in the show interface command on RouterB provided here:
RouterB#show interface serial 0
Serial0 is up, line protocol is up
Hardware is HD64570
Internet address is 168.71.6.2 255.255.255.0
MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec, rely 255/255, load 1/255
The following output of the debug ip igrp transactions command on RouterC, which was taken after changing the bandwidth on RouterB's serial 0, shows that the change affects the advertised metric that RouterC receives from RouterB for 168.71.6.0 but does not affect the metric RouterC installs.
The installed metric is still 82125, even though the neighbor— RouterB—indicated that its metric was 8476. This is because the bandwidth on RouterC's serial 0 interface remained the same: 64K.
RouterC#deb ip igrp transactions
Oct 8 17:10:37: IGRP: received update from 168.71.7.2 on Serial0
Oct 8 17:10:37: subnet 168.71.6.0, metric 82125 (neighbor 8476)
RouterC#
In the previous debug output from RouterC, the bandwidth on RouterB's serial 0 interface was 1544, as indicated in the output of the show interface command on RouterB provided here:
RouterB#show interface serial 0
Serial0 is up, line protocol is up
Hardware is HD64570
Internet address is 168.71.6.2 255.255.255.0
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Experimenting with the delay and bandwidth parameters in a small network, such as the one used in this example, will probably not create major problems. However, experimenting with bandwidth and delay in a 1,000-router network in an attempt to achieve load balancing on some paths will almost certainly lead to more problems than it solves.
Calculating IGRP Metrics
In this book, only two of the five IGRP metrics are considered, which is the default behavior. The other three variables are set to 1.
The following text from Cisco's technical tips section on Cisco Connection Online (CCO) www.cisco.com explains in detail the formula for calculating IGRP metrics.
IGRP calculates the metric by adding together weighted values of different characteristics of the link to the network in question. These values (bandwidth, bandwidth divided by load, and delay) are weighted with the constants K1, K2, and K3. Here's the formula (BandW=bandwidth):
Metric = K1 * BandW + (K2 * BandW)/(256-load) + K3*Delay
The default constant values are K1=K3=1 and K2=K4=K5=0, so: Metric = BandW + Delay.
If K5 does not equal 0, an additional operation is done: Metric = Metric * [K5/(reliability + K4)]
To find BandW, find the smallest of all the bandwidths from outgoing interfaces and divide 10,000,000 by that number. (The bandwidth is scaled by 10,000,000 in kilobits per second.)
To find Delay, add all the delays from the outgoing interfaces and divide this number by 10. (The delay is in tens of microseconds.)
When the bandwidth was 128 and the delay was 20,000 usecs on RouterB's serial 0 interface, RouterB's advertised metric for the subnet assigned to serial 0 was 80125. This is shown by the [neighbor 80125] statement in bold taken from RouterC's debug messages. Following is RouterC receiving an update from RouterB:
RouterC#debug ip igrp transactions
Oct 8 16:58:24: IGRP: received update from 168.71.7.2 on Serial0
Oct 8 16:58:24: subnet 168.71.6.0, metric 82125 (neighbor 80125)
RouterC#
The following output of the show interface command on RouterB shows that RouterB's serial 0 interface has the bandwidth set to 128K:
RouterB#show interface serial 0
Serial0 is up, line protocol is up
Hardware is HD64570
Internet address is 168.71.6.2 255.255.255.0
MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec, rely 255/255, load 1/255
The formula for determining the metric RouterB will use when advertising its connected route to 168.71.6.0 is as follows:
Bandwidth = 10,000,000/128,000 or 78125
Delay = 20,000/10 or 2000
= 80125
When the bandwidth was 1544 and the delay was 20,000 usecs on RouterB's serial 0 interface, RouterB's advertised metric for the subnet assigned to serial 0 was 8476. This is shown by the [neighbor 8476] statement in bold taken from RouterC's debug messages. Following is RouterC receiving an update from RouterB:
RouterC#deb ip igrp transactions
Oct 8 17:10:37: IGRP: received update from 168.71.7.2 on Serial0
Oct 8 17:10:37: subnet 168.71.6.0, metric 82125 (neighbor 8476)
RouterC#
The following output of the show interface command on RouterB shows that RouterB's serial 0 interface has the bandwidth set to 1544K:
RouterB#show interface serial 0
Serial0 is up, line protocol is up
Hardware is HD64570
Internet address is 168.71.6.2 255.255.255.0
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
The formula for determining the metric RouterB will use when advertising its connected route to 168.71.6.0 is as follows:
Bandwidth = 10,000,000/1,544,000 or 6476
Delay = 20,000/10 or 2000
8476
When the bandwidth was 128 and the delay was 20,000 usecs on RouterB's serial 0 interface, RouterC's installed metric for 168.71.6.0 was 82125. This is shown by the [metric 82125] statement in bold taken from RouterC's debug messages. Following is RouterC receiving an update from RouterB:
RouterC#debug ip igrp transactions
Oct 8 16:58:24: IGRP: received update from 168.71.7.2 on Serial0
Oct 8 16:58:24: subnet 168.71.6.0, metric 82125 (neighbor 80125)
RouterC#
The following output of the show interface command on RouterC shows that RouterC's serial 0 interface has the bandwidth set to 128K:
RouterC#show interface serial 0
Serial0 is up, line protocol is up
Hardware is HD64570
Internet address is 168.71.7.1 255.255.255.0
MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec, rely 255/255, load 1/255
The formula for determining the metric RouterC will use for 168.71.6.0 is as follows:
Bandwidth = 10,000,000/128 or 78125
Delay = 40,000/10 or 4000
= 82125
When the bandwidth was 1544 and the delay was 20,000 usecs on RouterB's serial 0 interface, RouterC's installed metric for 168.71.6.0 was still 82125. This is shown by the [metric 82125] statement in bold taken from RouterC's debug messages. This is RouterC receiving an update from RouterB:
RouterC#deb ip igrp transactions
Oct 8 17:10:37: IGRP: received update from 168.71.7.2 on Serial0
Oct 8 17:10:37: subnet 168.71.6.0, metric 82125 (neighbor 8476)
RouterC#
The following output of the show interface command on RouterC shows that RouterC's serial 0 interface has the bandwidth set to 128K:
RouterC#show interface serial 0
Serial0 is up, line protocol is up
Hardware is HD64570
Internet address is 168.71.7.1 255.255.255.0
MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec, rely 255/255, load 1/255
The formula for determining the metric RouterC will use for 168.71.6.0 is the same because the lowest bandwidth in the path is still 128K.
Bandwidth = 10,000,000/128 or 78125
Delay = 40,000/10 or 4000
= 82125