📄 configuration notes for the enhanced igrp.htm
字号:
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=gb_2312-80">
<meta name="date" content="Tue Apr 29 11:38:05 1997">
<meta name="author" content="bretzlaf">
<meta name="FileType" content="SampConfig">
<meta name="GENERATOR" content="Microsoft FrontPage Express 2.0">
<title>Cisco - Configuration Notes for the Enhanced Implementation of EIGRP</title>
</head>
<body bgcolor="#FFFFFF">
<h1>Configuration Notes for the Enhanced Implementation of EIGRP</h1>
<hr>
<h2>Introduction</h2>
<p>EIGRP was significantly enhanced in releases 10.3(11),
11.0(8), 11.1(3) and later. The implementation was changed to
improve the performance on low-speed networks (including Frame
Relay) and in configurations with many neighbors. </p>
<p>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. </p>
<p>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. </p>
<h2>Bandwidth Control</h2>
<p>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 available 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 line can absorb it. This is of particular benefit on
Frame Relay networks, where the access line 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. </p>
<h2>Configuration Commands</h2>
<p>The amount of bandwidth is controlled by two interface
subcommands: </p>
<pre>
bandwidth <nnn>
</pre>
<p>and one of the following: </p>
<pre>
ip bandwidth-percent eigrp <AS-number> <ppp>
appletalk eigrp-bandwidth-percent <ppp>
ipx bandwidth-percent eigrp <AS-number> <ppp>
</pre>
<p>for IP, AppleTalk, and IPX EIGRP, respectively. </p>
<p>The <b>bandwidth-percent</b> command tells EIGRP what
percentage of the configured bandwidth it may use. The default is
50%. Since the <b>bandwidth</b> command is also used to set the
routing protocol metric, it may be set to a particular value for
policy reasons. The <b>bandwidth-percent</b> command can have
values greater than 100 if the bandwidth is configured
artificially low due to such policy reasons. </p>
<p>For example, the configuration: </p>
<pre>
interface Serial 0
bandwidth 56
ip bandwidth-percent eigrp 109 75
</pre>
<p>allows IP-EIGRP 109 to use 42Kbps (75% of 56Kbps) on Serial 0.
</p>
<p>The configuration: </p>
<pre>
interface Serial 1
bandwidth 128
ipx bandwidth-percent eigrp 210 200
</pre>
<p>allows IPX-EIGRP 210 to use 256Kbps (200% of 128Kbps) on
Serial 1. </p>
<p><b>Note:</b> This assumes that Serial 1 is actually operating
at a speed of at least 256Kbps. </p>
<h2>Configuration Problems</h2>
<p>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: </p>
<pre>
%DUAL-3-SIA: Route XXX stuck-in-active state in IP-EIGRP YY. Cleaning up
</pre>
<p>The workaround for this problem is to raise the value of the
"active" timer for EIGRP by configuring: </p>
<pre>
router eigrp
timers active-time
</pre>
<p>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. </p>
<p>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. </p>
<h2>Configuration Guidelines</h2>
<p>Thse recommendations are described in terms of configuring the
interface "bandwidth" parameter (with EIGRP being able
to use 50% of that bandwidth by default). If the interface
bandwidth configuration cannot be changed because of routing
policy considerations, or for any other reason, the <b>bandwidth-percent</b>
command should be used to control the EIGRP bandwidth. On
low-speed interfaces, raising the available bandwidth for EIGRP
above the default of 50% is advisable in order to improve
convergence. </p>
<h3>LAN Interfaces (Ethernet, Token Ring, FDDI)</h3>
<p>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. </p>
<h3>Point-to-Point Serial Interfaces (HDLC, PPP)</h3>
<p>The bandwidth parameter defaults to T1 speed (1.544 Mbps) on
serial interfaces. It should be set to the actual link speed. </p>
<h3>NBMA Interfaces (Frame Relay, X.25, ATM)</h3>
<p>It is particularly critical to configure NBMA interfaces
correctly, because otherwise many EIGRP packets may be lost in
the switched network. There are three basic rules: </p>
<ol>
<li>The traffic that EIGRP is allowed to send on a single
virtual circuit (VC) cannot exceed the capacity of that
virtual circuit. </li>
<li>The total EIGRP traffic for all virtual circuits cannot
exceed the access line speed of the interface. </li>
<li>The bandwidth allowed for EIGRP on each virtual circuit
must be the same in each direction. </li>
</ol>
<p>There are three different scenarios for NBMA interfaces. </p>
<p>Pure Multipoint Configuration (no subinterfaces) Pure
Point-to-Point Configuration (each VC on a separate subinterface)
Hybrid Configuration (point-to-point and multipoint
subinterfaces) </p>
<p>Each is examined separately. </p>
<h3>Pure Multipoint Configuration (no subinterfaces)</h3>
<p>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 * 56K) 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. </p>
<p>For instance, if a T1 access line has three 256K VCs and one
56K VC, the bandwidth should be set to 224Kbps (4 * 56K). 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). </p>
<h3>Pure Point-to-Point Configuration (each VC on a separate
subinterface)</h3>
<p>This configuration allows maximum 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
virtual circuit, 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). </p>
<h3>Hybrid Configuration (point-to-point and multipoint
subinterfaces)</h3>
<p>Hybrid configurations should use combinations of the two
individual strategies, while ensuring that the three basic rules
are followed. </p>
<h2>Examples</h2>
<p>The following examples illustrate the relationship between
topology and configuration. Only the configuration commands
pertaining to EIGRP's bandwidth usage are given. </p>
<h3>Oversubscribed Hub-and-Spoke Frame Relay Configuration
(Subinterfaces)</h3>
<p>A fairly common configuration in networks with light amounts
of transaction traffic is a hub-and-spoke configuration on 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. IP EIGRP process
123 is configured. </p>
<p>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. </p>
<p>The hub configuration would look like: </p>
<pre>
interface Serial 0
encapsulation frame-relay
</pre>
<p>interface Serial 0.1 point-to-point bandwidth 25 ip
bandwidth-percent eigrp 123 90 </p>
<p>interface Serial 0.2 point-to-point bandwidth 25 ip
bandwidth-percent eigrp 123 90 </p>
<p>... </p>
<p>Each spoke router 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: </p>
<pre>
interface Serial 0
encapsulation frame-relay
</pre>
<p>interface Serial 0.1 point-to-point bandwidth 25 ip
bandwidth-percent eigrp 123 90 </p>
<p>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. </p>
<p>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: </p>
<pre>
interface Serial 0.1 point-to-point
bandwidth 56
ip bandwidth-percent eigrp 123 41
</pre>
<h3>Full-mesh Frame Relay Configuration with Differing Access
Line Speeds</h3>
<p>In this configuration there is a fully-meshed Frame Relay
network of four routers running IPX EIGRP process 456, configured
as a multipoint network. 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: </p>
<pre>
interface Serial 0
encapsulation frame-relay
bandwidth 56
</pre>
<p>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 making all of router D's connections
point-to-point subinterfaces instead. The configuration on
routers A through C would look like: </p>
<pre>
interface Serial 0
encapsulation frame-relay
</pre>
<p>interface Serial 0.1 multipoint bandwidth 238 </p>
<p>interface Serial 0.2 point-to-point bandwidth 18 description
PVC to Router D </p>
<p>Router D's configuration would look like: </p>
<pre>
interface Serial 0
encapsulation frame-relay
</pre>
<p>interface Serial 0.1 point-to-point bandwidth 18 description
PVC to Router A </p>
<p>interface Serial 0.2 point-to-point bandwidth 18 description
PVC to Router B </p>
<p>interface Serial 0.2 point-to-point bandwidth 18 description
PVC to Router C </p>
<p>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). </p>
<p>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:
</p>
<pre>
interface Serial 0.1 multipoint
bandwidth 256
ipx bandwidth-percent eigrp 456 46
</pre>
<p>interface Serial 0.2 point-to-point bandwidth 56 description
PVC to Router D ipx bandwidth-percent eigrp 456 16 </p>
<hr>
</body>
</html>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -