From: Przemyslaw Karwasiecki (karwas@bellsouth.net)
Date: Wed Oct 16 2002 - 01:47:51 GMT-3
This flapping nightmare is controlled (partially) by dampening
caused by the exponentially decaying weights used to calculate load.
But, it still can cause instability. (after Alex Zinn "Cisco IP
Routing")
I think, EIGRP uses the very same algorithm used when printing
"sh int | inc load".
BTW -- its behaviour can be modified by "load-interval" knob
in the context of interface configuration.
Przemek
On Tue, 2002-10-15 at 21:42, Chuck Church wrote:
> Jason,
>
> Are you sure about the load calculation? Someone (I think it was
> Brian Dennis) mentioned a while ago that if you decided to include load, it
> was only looked at initially when the EIGRP process started up. I never
> found anything on CCO to support this, but it makes sense. If your
> preferred routes changed based on load, they'd change again soon after the
> load switched to somewhere else. It'd be a route flapping nightmare.
> Anyone seen a document on CCO about this?
>
> Chuck Church
> CCIE #8776, MCNE, MCSE
> Sr. Network Engineer
> Magnacom Technologies
> 140 N. Rt. 303
> Valley Cottage, NY 10989
> 845-267-4000
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Jason Sinclair
> Sent: Tuesday, October 15, 2002 8:14 PM
> To: 'Rick'; Ccielab (E-mail)
> Subject: RE: EIGRP metric weights Question FOR EIGRP GURUS
>
>
> Rick,
>
> A little history is in order to understand why this command was introduced.
> EIGRP was the post-IGRP routing protocol that Cisco developed utilising the
> Diffusing Update Algorithm. That said, reliability and load were included as
> configurable constants for backward compatibility with IGRP. It is not
> recommended to manipulate these settings but to manipulate the delay factor
> instead (k3 constant). If for example you were to include load as one of the
> parameters for metric, what happens when the load changes (which is
> generally calculated every 30 seconds)? Basically, a new update will be sent
> because of the change in metric for the route.
>
> If on other hand the lab should ask you to include load or reliability in
> the metric calculation you would use k2 to include load and k5 to include
> reliability.
>
> Let me know if you would like more info.
>
> Jason Sinclair CCIE #9100
> Manager, Network Control Centre
> POWERTEL
> 55 Clarence Street,
> SYDNEY NSW 2000
> AUSTRALIA
> office: + 61 2 8264 3820
> mobile: + 61 416 105 858
> email: sinclairj@powertel.com.au
>
> -----Original Message-----
> From: Rick [mailto:ccie_2003@hotmail.com]
> Sent: Wednesday, 16 October 2002 05:32
> To: Ccielab (E-mail)
> Subject: EIGRP metric weights Question FOR EIGRP GURUS
>
> I'm trying to understand Why, and how to properly use this command. Could
> someone further explain this command and give an example how to use it, or
> how
> it may be used on a lab scenario?
> Thanks,
> Rick
>
>
> To allow the tuning of the IGRP or Enhanced IGRP (EIGRP) 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 EIGRP metric vector into a scalar
> quantity.
>
>
>
>
> Defaults
>
> tos: 0
>
> k1: 1
>
> k2: 0
>
> k3: 1
>
> k4: 0
>
> k5: 0
>
> Usage Guidelines
>
> Use this command to alter the default behavior of IGRP routing and metric
> computation and allow the tuning of the IGRP metric calculation for a
> particular type of service (ToS).
>
> If k5 equals 0, the composite IGRP or EIGRP metric is computed according to
> the following formula:
>
> metric = [k1 * bandwidth + (k2 * bandwidth)/(256 - load) + k3 * delay]
>
>
> If k5 does not equal zero, an additional operation is performed:
>
> metric = metric * [k5/(reliability + k4)]
>
>
> Bandwidth is inverse minimum bandwidth of the path in bps scaled by a factor
> of 2.56 * 1012. The range is from a 1200-bps line to 10 terabits per second.
>
> Delay is in units of 10 microseconds. The range of delay is from 10
> microseconds to 168 seconds. A delay of all ones indicates that the network
> is
> unreachable.
>
> The delay parameter is stored in a 32-bit field, in increments of 39.1
> nanoseconds. The range of delay is from 1 (39.1 nanoseconds) to hexadecimal
> FFFFFFFF (decimal 4,294,967,040 nanoseconds). A delay of all ones (that is,
> a
> delay of hexadecimal FFFFFFFF) indicates that the network is unreachable.
>
> Table 19 lists the default values used for several common media.
>
>
> Table 19: Bandwidth Values by Media Type Media Type Delay Bandwidth
> Satellite
> 5120 (2 seconds)
> 5120 (500 megabits)
>
> Ethernet
> 25600 (1 ms)
> 256000 (10 megabits)
>
> 1.544 Mbps
> 512000 (20,000 ms)
> 1,657,856 bits
>
> 64 kbps
> 512000 (20,000 ms)
> 40,000,000 bits
>
> 56 kbps
> 512000 (20,000 ms)
> 45,714,176 bits
>
> 10 kbps
> 512000 (20,000 ms)
> 256,000,000 bits
>
> 1 kbps
> 512000 (20,000 ms)
> 2,560,000,000 bits
>
>
>
>
> Reliability is given as a fraction of 255. That is, 255 is 100 percent
> reliability or a perfectly stable link.
>
> Load is given as a fraction of 255. A load of 255 indicates a completely
> saturated link.
>
> Examples
>
> The following example sets the metric weights to slightly different values
> than the defaults:
>
> router igrp 109
> network 192.168.0.0
> metric weights 0 2 0 2 0 0
>
>
> **********************************************************************
> PowerTel Limited, winners of
> Best Corporate/Wholesale Broadband Initiative, Australian Telecom Awards
> 2002
> Broadband Wholesale Carrier of the year, CommsWorld Telecomms Awards 2001
> Best Emerging Telco, Australian Telecom Awards 2001
>
> **********************************************************************
> This email (including all attachments) is intended solely for the named
> addressee. It is confidential and may contain commercially sensitive
> information. If you receive it in error, please let us know by reply email,
> delete it from your system and destroy any copies.
>
> This email is also subject to copyright. No part of it should be reproduced,
> adapted or transmitted without the prior written consent of the copyright
> owner.
>
> Emails may be interfered with, may contain computer viruses or other defects
> and may not be successfully replicated on other systems. We give no
> warranties in relation to these matters. If you have any doubts about
> the authenticity of an email purportedly sent by us, please contact us
> immediately.
>
> **********************************************************************
This archive was generated by hypermail 2.1.4 : Tue Nov 05 2002 - 08:35:47 GMT-3