(Getting rid of some content as it is too big now)
Well typically the what you have shown would be used but the difference
between my blog, your first example, and the example that started this chain
is that K1 was 1. In Bilal's example K1 = 0 so the same formula is not
used, in fact the metric is not used at all.
In such a case the formula that I have given below is used for calculating
traffic share count which is different than what I did and the whitepaper,
which the whitepaper probably doesn't cover ignoring parameters either by
changing a K value to 0.
I have never seen what I show below documented I just reverse engineered it
based on looking at the numbers, not saying that is a big task, but I am
confident what I did will work in every situation where K1 = 0.
Regards,
Tyson Scott - CCIE #13513 R&S, Security, and SP
Managing Partner / Sr. Instructor - IPexpert, Inc.
Mailto: tscott_at_ipexpert.com
From: Garth Bryden [mailto:hacked.the.planet.on.28.8k.dialup_at_gmail.com]
Sent: Wednesday, September 29, 2010 9:01 AM
To: Tyson Scott
Cc: Bilal Hansrod; Paul Negron; Cisco certification
Subject: Re: EIGRP Traffic Share Count
Hey Tyson!
I have read your blog, it is fantastic, all you vendors have made my life so
much easier with your postings :-)
I should have phrased my question earlier a bit better I believe, I went
running yesterday so I was very tired this morning when I posted that!
I know how to calculate the metrics for EIGRP so that I can achieve the
traffic share ratio's that is no problems what I am getting a bit confused
about how the router calculates the traffic share (I may have missed
something obvious here! Pardon me if I did). The main reason because of this
is I always learnt is that the router will calculate the traffic share by
dividing all of the metrics for the route by the largest metric that is
going to be used as part of the load balancing algorithm and then it'll
round the result down to the nearest integer.
This is what is actually says in Cisco's EIGRP whitepaper -
http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094c
b7.shtml#loadbalancing though I know they aren't always 100% accurate in the
documentation.
This seems true enough to me, I'll take one of the examples from your blog
where you had R6 load balancing over three links at a ratio of 8:4:1..
R6#show ip route 200.0.0.2
Routing entry for 200.0.0.2/32
Known via "eigrp 1001", distance 90, metric 158720, type internal
Redistributing via eigrp 1001, eigrp 6009
Advertised by eigrp 6009
Last update from 150.100.100.2 on Serial0/1/0, 00:00:01 ago
Routing Descriptor Blocks:
150.100.221.5, from 150.100.221.5, 00:00:01 ago, via FastEthernet0/1
Route metric is 317184, traffic share count is 4
Total delay is 5200 microseconds, minimum bandwidth is 13908 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
* 150.100.220.5, from 150.100.220.5, 00:00:01 ago, via FastEthernet0/0
Route metric is 158720, traffic share count is 8
Total delay is 5200 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
150.100.100.2, from 150.100.100.2, 00:00:01 ago, via Serial0/1/0
Route metric is 1269760, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 4065 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
Okay, so performing the Math as per the Cisco White Paper we have
1269760 / 158720 = 8
1269760 / 317184 = 4.00322841
1269760 / 1269760 = 1
Great, the second path will be rounded down to four and we achieved the
traffic share ratio's as you noted in your blog. The world was happy!
Then Bilal pointed out the traffic share ratio's that we saw in their
workbooks EIGRP topology which was demonstrating unequal cost load balancing
and all of a sudden our traffic share count is now at a ratio of 103:120 as
per the below
Rack1R6#show ip route 155.1.9.9
Routing entry for <http://155.1.9.0/24> 155.1.9.0/24
Known via "eigrp 100", distance 90, metric 3072, type internal
Redistributing via eigrp 10, eigrp 100
Advertised by eigrp 10
Last update from 155.1.146.1 on FastEthernet0/0.146, 00:01:04 ago
Routing Descriptor Blocks:
155.1.146.1, from 155.1.146.1, 00:01:04 ago, via FastEthernet0/0.146
Route metric is 3584, traffic share count is 103
Total delay is 140 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 4
* 155.1.67.7, from 155.1.67.7, 00:01:04 ago, via FastEthernet0/0.67
Route metric is 3072, traffic share count is 120
Total delay is 120 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
In the above calculation only the value of delay was used as we know and as
you have pointed out it seems that the formula for working out the traffic
share has changed.. If it used the same formula as shown in the EIGRP white
paper the traffic share would be
3584 / 3072 = 1.16666
3584 / 3584 = 1
These would both be rounded down and the traffic share ratio would be
1:1....... obviously it wouldn't be perfect because the paths aren't
actually equal but the formula still made sense which is why I am assuming
Cisco Engineering decided to change the calculation when only delay has been
considered to the calculation you pointed out before-
120 / 140 * 120 = 102.85
120 / 120 * 120 = 120
I guess what I am wondering now is the following
Is there a long methematical algorithm at work here then which is doing the
calculation?
Is it part of the EIGRP sub process performing the traffic share calculation
or the actual routing process.. at the moment I'm assuming it must be EIGRP
because how would the routing process know we are only considering delay as
the value for metric calculation?
I'm also wondering why Cisco have done this and why they have not documented
it!
Does it mean the algorithm for traffic share will change again if we have
any of the other K values set to 1?
Though I am not majorly worried about my questions come exam time again,
it's really interesting to understand how things are being done behind the
scene's in IOS! :-)
Cheers
Garth
On Wed, Sep 29, 2010 at 1:28 PM, Tyson Scott <tscott_at_ipexpert.com> wrote:
Garth,
If you are using BW and Delay in your calculation attempt then you should go
thru the blog I shared.
Regards,
Tyson Scott - CCIE #13513 R&S, Security, and SP
Managing Partner / Sr. Instructor - IPexpert, Inc.
Mailto: tscott_at_ipexpert.com
From: Garth Bryden [mailto:hacked.the.planet.on.28.8k.dialup_at_gmail.com]
Sent: Tuesday, September 28, 2010 9:14 PM
To: Tyson Scott
Cc: Bilal Hansrod; Paul Negron; Cisco certification
Subject: Re: EIGRP Traffic Share Count
Hi Tyson,
Thanks heaps for your assistance!
Does this just apply when the metric is being calculated by delay only?
On Tue, Sep 28, 2010 at 12:03 PM, Tyson Scott <tscott_at_ipexpert.com> wrote:
Bilal,
I am glad it was helpful. Anything that we can do to unlock the mysteries
is what we like to do. That is why we are all on here helping you guys out.
Regards,
Tyson Scott - CCIE #13513 R&S, Security, and SP
Managing Partner / Sr. Instructor - IPexpert, Inc.
Mailto: tscott_at_ipexpert.com
From: Bilal Hansrod [mailto:bilal.hansrod_at_gmail.com]
Sent: Monday, September 27, 2010 10:29 PM
To: Tyson Scott
Cc: Paul Negron; Garth Bryden; Cisco certification
Subject: Re: EIGRP Traffic Share Count
Thank you Tyson - That was right on money, the below explanation has
releived lot of uneasy feeling from mind and heart in relation to EIGRP :)
Thanks once again and I will be reading these two blogs over and over to
understand EIGRP mystery.
Great blogs from ipexpert on EIGRP technology.
http://blog.ipexpert.com/2010/05/03/eigrp-unequal-cost-load-balancing/
http://blog.ipexpert.com/2010/03/03/eigrp-metric-k-values/
Regards,
Bilal
On Tue, Sep 28, 2010 at 1:57 AM, Tyson Scott <tscott_at_ipexpert.com> wrote:
Corrected Typos
Well metric isn't used as you have chosen to ignore BW.
With the following output
Rack1R6#show ip route 155.1.9.9
Routing entry for 155.1.9.0/24
Known via "eigrp 100", distance 90, metric 3072, type internal
Redistributing via eigrp 10, eigrp 100
Advertised by eigrp 10
Last update from 155.1.146.1 on FastEthernet0/0.146, 00:01:04 ago
Routing Descriptor Blocks:
155.1.146.1, from 155.1.146.1, 00:01:04 ago, via FastEthernet0/0.146
Route metric is 3584, traffic share count is 103
Total delay is 140 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 4
* 155.1.67.7, from 155.1.67.7, 00:01:04 ago, via FastEthernet0/0.67
Route metric is 3072, traffic share count is 120
Total delay is 120 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
We can see the metric is greater on the first entry (3584) versus 3072 but
the route via Fa0/0.67 has a higher traffic share count that proves metric
isn't used. Here we are simply looking at delay (120 & 140). So 120 is our
traffic share base value to start with.
For the second value we will use 120 as the base number and times that by
the percentage of difference
120/140*120 = 102.857...
There is no easy way to simplify 120 and 103. 103 is a prime number so we
cannot simplify it. So our traffic share count is 120 and 103
For your last output of 160 usec/120 usec. Again 120 is our primary traffic
share count because it is the lowest delay which is the best metric.
For the second value we have 120/160*120 = 90. Now 120 and 90 can be
simplified by dividing each by 30 which gives you the traffic share count of
4 and 3.
Regards,
Tyson Scott - CCIE #13513 R&S, Security, and SP
Managing Partner / Sr. Instructor - IPexpert, Inc.
Mailto: tscott_at_ipexpert.com
From: Bilal Hansrod [mailto:bilal.hansrod_at_gmail.com]
Sent: Monday, September 27, 2010 10:40 AM
To: Tyson Scott
Cc: Paul Negron; Garth Bryden; Cisco certification
Subject: Re: EIGRP Traffic Share Count
Hi Tyson,
Actually, the numbers I gave you was from workbook. The below show output is
from live routers and only K3 enabled.
R6 - R1 = 100 usec
R1 - R3 = 20 usec
R3 - SW1 = 20 usec
SW1 - SW3 = 10 usec
SW3 - VLAN9 (155.1.9.9) = 10 usec
Total 160usec, which is showed in route via
155.1.146.1 (R1)
R6 - SW1 = 100 usec
SW1 - SW3 = 10 usec
SW3 - VLAN9 (155.1.9.9) = 10 usec
Total 120 usec, which is showed in route
via 155.1.67.7 (SW1)
So the question is how is share count 3 and 4 derived
Rack1R6#show ip route 155.1.9.9
Routing entry for 155.1.9.0/24
Known via "eigrp 100", distance 90, metric 3072, type internal
Redistributing via eigrp 100
Last update from 155.1.146.1 on FastEthernet0/0.146, 00:03:33 ago
Routing Descriptor Blocks:
155.1.146.1, from 155.1.146.1, 00:03:33 ago, via FastEthernet0/0.146
Route metric is 4096, traffic share count is 3
Total delay is 160 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 4
* 155.1.67.7, from 155.1.67.7, 00:03:33 ago, via FastEthernet0/0.67
Route metric is 3072, traffic share count is 4
Total delay is 120 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
Rack1R6#show ip eigrp topology 155.1.9.0 255.255.255.0
IP-EIGRP (AS 100): Topology entry for 155.1.9.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3072
Routing Descriptor Blocks:
155.1.67.7 (FastEthernet0/0.67), from 155.1.67.7, Send flag is 0x0
Composite metric is (3072/512), Route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 120 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
155.1.146.1 (FastEthernet0/0.146), from 155.1.146.1, Send flag is 0x0
Composite metric is (4096/1536), Route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 160 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 4
Rack1R6#
Thank you Tyson for taking your time and helping us on this concept.
Regards,
Bilal
On Tue, Sep 28, 2010 at 12:15 AM, Tyson Scott <tscott_at_ipexpert.com> wrote:
I mean "show ip eigrp topology 155.1.9.9
Regards,
Tyson Scott - CCIE #13513 R&S, Security, and SP
Managing Partner / Sr. Instructor - IPexpert, Inc.
Mailto: tscott_at_ipexpert.com
From: Bilal Hansrod [mailto:bilal.hansrod_at_gmail.com]
Sent: Monday, September 27, 2010 10:00 AM
To: Tyson Scott
Cc: Paul Negron; Garth Bryden; Cisco certification
Subject: Re: EIGRP Traffic Share Count
Thanks Tyson, I was reading your article since morning and it does make
sense if you want to take Bandwidth and Delay into account. I was only
taking delay into consideration while calculating the traffic share count.
Now, I know how to change the ratio , but still unable to understand the
default traffic ratio with below snippet.
Rack1R6#show ip route 155.1.9.9
Routing entry for 155.1.9.0/24
Known via "eigrp 100", distance 90, metric 3072, type internal
Redistributing via eigrp 10, eigrp 100
Advertised by eigrp 10
Last update from 155.1.146.1 on FastEthernet0/0.146, 00:01:04 ago
Routing Descriptor Blocks:
155.1.146.1, from 155.1.146.1, 00:01:04 ago, via FastEthernet0/0.146
Route metric is 3584, traffic share count is 103
Total delay is 140 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 4
* 155.1.67.7, from 155.1.67.7, 00:01:04 ago, via FastEthernet0/0.67
Route metric is 3072, traffic share count is 120
Total delay is 120 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
How come above show ip route show traffic share of 103 and 120 respectively?
I have K3=1 and remaining K's are 0, meaning delay will be factored in. Any
suggestion as how these numbers is calculated before we change the traffic
share ratio.
Thanks,
Bilal
On Mon, Sep 27, 2010 at 11:51 PM, Tyson Scott <tscott_at_ipexpert.com> wrote:
You can change EIGRP to only take into account bandwidth if you change your
K values on the routers to ignore delay.
K1 = 1 K2-5 = 0
Without doing this you need to account for delay.
I already posted the article to our blog that will tell you how to calculate
traffic share values and the formula for calculation.
Regards,
Tyson Scott - CCIE #13513 R&S, Security, and SP
Managing Partner / Sr. Instructor - IPexpert, Inc.
Mailto: tscott_at_ipexpert.com
-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
Blogs and organic groups at http://www.ccie.net
Received on Wed Sep 29 2010 - 11:00:22 ART
This archive was generated by hypermail 2.2.0 : Fri Oct 01 2010 - 05:58:06 ART