Using link congestion to control routing updates

Fri Dec 20 16:07:47 UTC 2002

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 at xelerated.com] 
> Sent: Friday, December 20, 2002 7:58 AM
> To: Stephen Sprunk
> Cc: Ejay Hire; David Scott Olverson; nanog at 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