Enhanced Interior Gateway Protocol (EIGRP) was significantly enhanced in Cisco IOS® Software releases 10.3(11), 11.0(8), 11.1(3) and later. The implementation was changed to have more control over the amount of bandwidth utilized by EIGRP and improve the performance on low-speed networks (including Frame Relay) and in configurations with many neighbors.
For the most part, the changes are transparent. Most existing configurations should continue to operate as before. However, in order to take advantage of the improvements for low speed links and Frame Relay networks, it is important to properly configure the bandwidth on each interface on which EIGRP is running.
Although the enhanced implementation will interoperate with the earlier version, the full benefits of the enhancements may not be realized until the entire network is upgraded.
Readers of this document should have the basic understanding of:
EIGRP
Frame Relay
This document is not restricted to specific software and hardware versions.
The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.
For more information on document conventions, refer to Cisco Technical Tips Conventions.
The enhanced implementation uses the configured interface bandwidth in order to determine how much EIGRP data to transmit in a given amount of time. By default, EIGRP will limit itself to using no more than 50% of the interface bandwidth. The primary benefit of controlling EIGRP's bandwidth usage is to avoid losing EIGRP packets, which could occur when EIGRP generates data faster than the interface line can absorb it. This is of particular benefit on Frame Relay networks, where the access interface bandwidth and the PVC capacity may be very different. A secondary benefit is to allow the network administrator to ensure that some bandwidth remains for passing user data, even when EIGRP is very busy.
The amount of bandwidth is controlled by two interface subcommands:
router-number percent
and one of the following for IP, AppleTalk, and IPX EIGRP, respectively:
The bandwidth-percent command tells EIGRP what percentage of the configured bandwidth it may use. The default is 50 percent. Since the bandwidth command is also used to set the routing protocol metric, it may be set to a particular value to influence route selection for policy reasons. The bandwidth-percent command can have values greater than 100 if the bandwidth is configured artificially low due to such policy reasons.
For example, the following configuration allows IP-EIGRP AS 109 to use 42Kbps (75% of 56Kbps) on Serial 0:
interface Serial 0 bandwidth 56 ip bandwidth-percent eigrp 109 75
This configuration allows IPX-EIGRP AS 210 to use 256Kbps (200% of 128Kbps) on Serial 1:
interface Serial 1 bandwidth 128 ipx bandwidth-percent eigrp 210 200
Note: This assumes that Serial 1 is actually operating at a speed of at least 256Kbps.
If the bandwidth is configured to be a small value relative to the actual link speed, the enhanced implementation may converge at a slower rate than the earlier implementation. If the value is small enough and there are enough routes in the system, convergence may be so slow that it triggers "Stuck In Active" detection, which may prevent the network from ever converging. This state is evidenced by repeated messages of the form:
%DUAL-3-SIA: Route XXX stuck-in-active state in IP-EIGRP YY. Cleaning up
The workaround for this problem is to raise the value of the "active" timer for EIGRP by configuring the following:
router eigrp as-number timers active-time
The default value in the enhanced code is three minutes; in earlier releases, the default is one minute. Raising this value would need to happen throughout the network.
If the bandwidth is configured to be too high (greater than the actual available bandwidth), the loss of EIGRP packets may occur. The packets will be retransmitted, but this may degrade convergence. The convergence in this case will be no slower than the earlier implementation, however.
These recommendations are described in terms of configuring the interface "bandwidth" parameter (with EIGRP being able to use 50 percent of that bandwidth by default). If the interface bandwidth configuration cannot be changed because of routing policy considerations, or for any other reason, the bandwidth-percent command should be used to control the EIGRP bandwidth. On low-speed interfaces, raising the available bandwidth for EIGRP above the default of 50 percent is advisable in order to improve convergence.
As a best practice Auto Summarization feature should be disabled. Configure no auto-summary command in order to disable auto summary.
The bandwidth parameter on LAN interfaces is set by default to the actual media speed, so no configuration should be necessary unless the bandwidth is explicitly configured to a very low value.
The bandwidth parameter defaults to T1 speed (1.544 Mbps) on serial interfaces. It should be set to the actual link speed.
It is particularly critical to configure nonbroadcast multi-access (NBMA) interfaces correctly, because otherwise many EIGRP packets may be lost in the switched network. There are three basic rules:
The traffic that EIGRP is allowed to send on a single virtual circuit (VC) cannot exceed the capacity of that VC.
The total EIGRP traffic for all virtual circuits cannot exceed the access line speed of the interface.
The bandwidth allowed for EIGRP on each virtual circuit must be the same in each direction.
There are three different scenarios for NBMA interfaces.
Pure Multipoint Configuration (no subinterfaces)
Pure Point-to-Point Configuration (each VC on a separate subinterface)
Hybrid Configuration (point-to-point and multipoint subinterfaces)
Each is examined separately below.
In this configuration EIGRP will divide the configured bandwidth evenly across each virtual circuit. You must ensure that this will not overload each virtual circuit. For example, if you have a T1 access line with four 56K VCs, you should configure the bandwidth to be 224Kbps (4 * 56Kbps) in order to avoid dropping packets. If the total bandwidth of the virtual circuits equals or exceeds the access line speed, configure the bandwidth to equal the access line speed. Note that if the virtual circuits are of different capacities, the bandwidth must be set to take into account the lowest capacity virtual circuit.
For instance, if a T1 access line has three 256Kbps VCs and one 56Kbps VC, the bandwidth should be set to 224Kbps (4 * 56Kbps). In such configurations, putting at least the slow virtual circuit onto a point-to-point subinterface is strongly recommended (so that the bandwidth can be raised on the others).
This configuration allows maximum bandwidth control, since the bandwidth can be configured separately on each subinterface, and is the best configuration if the virtual circuits have different capacities. Each subinterface bandwidth should be configured to be no greater than the available bandwidth on the associated VC, and the total bandwidth for all subinterfaces cannot exceed the available access line bandwidth. If the interface is oversubscribed, the access line bandwidth must be divided across each of the subinterfaces. For instance, if a T1 access line (1544 Kbps) has ten virtual circuits with a capacity of 256Kbps, the bandwidth on each subinterface should be configured to be 154Kbps (1544/10) instead of 256Kbps each.
Hybrid configurations should use combinations of the two individual strategies, while ensuring that the three basic rules are followed.
The examples in this section illustrate the relationship between topology and configuration. Only the configuration commands pertaining to EIGRP bandwidth usage are shown in these configuration examples.
A fairly common configuration in networks with light traffic is a hub-and-spoke configuration in which the access line to the hub is oversubscribed (since there is not usually enough data traffic to cause this to be a problem.) In this scenario, assume a 256Kbps access line to the hub, with 56Kbps access lines to each of ten spoke sites as shown in Figure 1. IP EIGRP process ID of 123 is configured.
Note: Each dotted line in the figures within this document corresponds to a separate PVC, and each color represents a separate IP subnet.
Figure 1
Because there is a maximum of 256Kbps available, we cannot allow any individual PVC to handle more than 25Kbps (256/10). Since this data rate is fairly low, and we don't expect very much user data traffic, we can allow EIGRP to use up to 90% of the bandwidth.
The hub configuration would look like the following configuration. Note that the configuration only shows the configuration of subinterfaces s0.1 and s0.2. We omitted the other -8 subinterfaces to make a short configuration because the configuration of all the 10 subinterfaces is the same.
Hub Router |
---|
interface Serial 0 encapsulation frame-relay !--- To enable Frame Relay encapsulation on the interface. interface Serial 0.1 point-to-point !--- The subinterface is configured to function as a point-to-point link using this command. bandwidth 25 !--- To set the bandwidth value for this interface. ip bandwidth-percent eigrp 123 90 !--- To configure the percentage of bandwidth that may be !--- used by EIGRP on this interface. interface Serial 0.2 point-to-point bandwidth 25 ip bandwidth-percent eigrp 123 90 |
Each of the ten spoke routers must be configured to limit EIGRP traffic to the same rate as that of the hub, in order to satisfy the third rule above. The spoke configuration would look like the following.
Spoke Router |
---|
interface Serial 0 encapsulation frame-relay !--- To enable Frame Relay encapsulation on this interface. interface Serial 0.1 point-to-point !--- The subinterface is configured to function as a point-to-point link !--- using this command. bandwidth 25 !--- To set the bandwidth value for this interface. ip bandwidth-percent eigrp 123 90 !--- To configure the percentage of bandwidth that may be !--- used by EIGRP on this interface. |
Note that EIGRP will not use more than 22.5Kbps (90% of 25K) on this interface, even though its capacity is 56Kbps. This configuration will not affect user data capacity, which will still be able to use the entire 56Kbps.
Alternatively, if you want to set the interface bandwidth to reflect the PVC capacity, you can adjust the bandwidth percentage for EIGRP. In this example, the desired bandwidth for EIGRP is (256K/10)*.9 = 23.04K; the bandwidth percentage would be 23.04K/56K = .41 (41%). So the same effect would be had by configuring:
interface Serial 0.1 point-to-point bandwidth 56 ip bandwidth-percent eigrp 123 41
In this configuration there is a fully-meshed Frame Relay network of four routers running IPX EIGRP process ID 456, configured as a multipoint network as shown in Figure 2.
Figure 2
Three of the four routers (routers A through C) have 256Kbps access lines, but one (router D) has only a 56Kbps access line. In this scenario, the configuration must restrict EIGRP's bandwidth in order to not overload the connection to router D. The simplest approach is to set the bandwidth to 56Kbps on all four routers:
Routers A-D |
---|
interface Serial 0 encapsulation frame-relay !--- To enable Frame Relay encapsulation on this interface. bandwidth 56 !--- To set the bandwidth value for this interface. |
EIGRP will divide the bandwidth evenly across the three PVCs. Note, however, that this is overly restrictive for the PVCs connecting routers A through C, since they have sufficient capacity to handle a lot more traffic. One way of handling this situation is to convert the network to use point-to-point subinterfaces for all PVCs, as in the example above. Another way, which would require less configuration, is to break up the network by putting routers A through C on a fully meshed multipoint subinterface, and use a point-to-point subinterface for connecting to router D, and making all of router D's connections point-to-point subinterfaces instead, as shown in Figure 3.
Figure 3
Router A-C |
---|
interface Serial 0 encapsulation frame-relay !--- To enable Frame Relay encapsulation on this interface. interface Serial 0.1 multipoint !--- The subinterface is configured to function as a point-to-point link using this command. bandwidth 238 !--- To set the bandwidth value for this interface. interface Serial 0.2 point-to-point bandwidth 18 description PVC to Router D |
Router D's configuration would look like the following.
Router D |
---|
interface Serial 0 encapsulation frame-relay !--- To enable Frame Relay encapsulation on this interface. interface Serial 0.1 point-to-point bandwidth 18 !--- To set the bandwidth value for this interface. description PVC to Router A interface Serial 0.2 point-to-point !--- The subinterface is configured to function as a point-to-point link !--- using this command. bandwidth 18 description PVC to Router B interface Serial 0.3 point-to-point bandwidth 18 description PVC to Router C |
Note that the multipoint subinterface is configured to 238 Kbps (256-18) and the point-to-point subinterfaces are configured to 18 Kbps (56/3).
Once again an alternative configuration can be used if it is desired to leave the "bandwidth" setting at its "natural" value. For the point-to-point interface, the desired bandwidth is (56K/3)*.5 = 9.33K; the percentage is 9.33K/56K = .16 (16%). For the multipoint interface the desired bandwidth is (256K-18K)*.5 = 119K, so the bandwidth percent would be (119K/256K) = .46 (46%). The resulting configuration would be:
Router A-C |
---|
interface Serial 0.1 multipoint !--- The subinterface is treated as a multipoint link. bandwidth 256 !--- To set the bandwidth value for this interface. ipx bandwidth-percent eigrp 456 46 !--- To configure the percentage of bandwidth that may be used by !--- EIGRP on this interface. interface Serial 0.2 point-to-point !--- The subinterface is configured to function as a point-to-point link !--- using this command. bandwidth 56 description PVC to Router D ipx bandwidth-percent eigrp 456 16 |
Revision | Publish Date | Comments |
---|---|---|
1.0 |
10-Aug-2005 |
Initial Release |