On Fri, Dec 20, 2002 at 09:21:39AM -0600, Ejay Hire wrote:
Finally, I found it. If you diddle the K values for EIGRP, you can make it consider reliability, load, and delay statistics when populating a route to the route table. The default behavior is bandwidth and delay.
Yeah, but there's a subtelty here. EIGRP doesn't periodically readvertise routes based on changed reliability/load/delay; if it has to readvertise routes for some reason (link flapped, neighbor flapped, etc), the new advertisement will consider the reliability/load/delay at that time. So it may or may not do what you want, depending on what it is you really want it to do. Routing based on load has historically been unpleasant. If the load changes, the routes change, the traffic patterns change, the load changes. Lather, rinse, repeat. eric
---Quote---http://www.cisco.com/warp/customer/103/eigrp1.html EIGRP uses these scaled values to determine the total metric to the network:
metric = [K1 * bandwidth + (K2 * bandwidth) / (256 - load) + K3 * delay] * [K5 / (reliability + K4)] Note: These K values should be used after careful planning. Mismatched K values prevent a neighbor relationship from being built, which can cause your network to fail to converge. The default values for K are:
K1 = 1 K2 = 0 K3 = 1 K4 = 0 K5 = 0
---Quote---http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps18 28/products_command_reference_chapter09186a00800ca5a9.html#xtocid14
COMMAND SUMMARY. metric weights (Enhanced IGRP) To allow the tuning of the IGRP or Enhanced IGRP metric calculations, use the metric weights router configuration command. To reset the values to their defaults, use the no form of this command.
metric weights tos k1 k2 k3 k4 k5
no metric weights
Syntax Description
tos Type of service. Currently, it must always be zero.
k1-k5 Constants that convert an IGRP or enhanced IGRP metric vector into a scalar quantity.
---End Quotes---
Note: If you are going to do this and you also work with BGP, you need to take measures to prevent route-flapping. One option would be to redistribute from EIGRP to BGP and use Summary-address / aggregate-only / next hop self to force only the summary route to be propagated and sustained in the event of an IGP route change.
Here's how that works.
Internet---EdgeRouter---InternalRouters. Prefix is 192.168.0.0/16
Edgerouter is configured with Summary-address / aggregate-only / next hop selffor the whole 192.168.0.0/16 netblock. As long as it has any route in that netblock then the summary route will be advertised with edgerouter as the next-hop. Any Changes in the IGP topology will not be echoed externally.
Remember the Carpenters rule, Measure twice and cut once. For us that's test twice and then deploy.
-Ejay
-----Original Message----- From: Anders Lowinger [mailto:anders.lowinger@xelerated.com] Sent: Friday, December 20, 2002 7:58 AM To: Stephen Sprunk Cc: Ejay Hire; David Scott Olverson; nanog@merit.edu Subject: Re: Using link congestion to control routing updates
Stephen Sprunk wrote:
Opposite problem -- he wants to delay routing updates if the link is full. EIGRP by default won't use more than 25/50% (I forget) of link bw, for instance, but I'm not aware of any intentional features in other IGPs to do this.
Both OSPF and ISIS in Cisco's have pacing, ie they will not flood LSAs/LSPs over a certain configurable limit. Not sure about other platforms..
-A