From: Jason Sinclair (sinclairj@powertel.com.au)
Date: Wed Oct 16 2002 - 01:49:14 GMT-3
Przemek,
You are correct - I recently researched a paper on EIGRP and my findings
indicated that although it is partially controlled you still get instability
from this behaviour. Also, when talking about reliability there are no such
controls that I could find.
Regards,
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: Przemyslaw Karwasiecki [mailto:karwas@bellsouth.net]
Sent: Wednesday, 16 October 2002 14:48
To: Chuck Church
Cc: 'Jason Sinclair'; 'Rick'; 'Ccielab (E-mail)'
Subject: RE: EIGRP metric weights Question FOR EIGRP GURUS
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.
>
> **********************************************************************
**********************************************************************
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