# EIGRP Unequal Cost Load Balancing (maths)

the SG has

```interface GigabitEthernet1.67
delay 25
!
interface GigabitEthernet1.146
delay 131
!
router eigrp 100
variance 5```

This question's mathmatics baffles me.  I have not done algebra since 1997.

I understand what needs to be done - but I do not underderstand the maths.

The solution guide goes from here (relavtive to this topic - dont worry about equal cost on R1)

The total delay of this path is 40 microseconds, or 4 tens of microseconds. Scaled by 256, R1 would be advertising 1024. Because R3's Feasible Distance of 1024 is equal to R6’s Feasible Distance, this path cannot be considered a Feasible Successor.

is this a typo?

to here:

Because the minimum configurable delay value is 10 microseconds, which is already the default for all Ethernet links, and based on task requirements, we need to modify R6's delay values on its VLAN 67 and VLAN 146 interfaces, so that metric through R1 is five times bigger than metric through R7.

then the formuale - which I do not know how to solve.  - was the 250 arbitary?

```5 * [Delay(Gi1.9) + Delay(Gi1.79) + Delay(Gi1.67)] = [Delay(Gi1.9) + Delay(Gi1.79) + Delay(Gi1.37) + Delay(Gi1.13) + Delay(Gi1.146)].
5 * [10 + 10 +Delay(Gi1.67)] = [10 + 10 + 10 + 10 + Delay(Gi1.146)]].```

I understand that the second line is a simplification of the first - but then how do you get the actual values for the delay on the interface? - It then suggests 250 - but I do not see the algebra workings:

If, for example, we configure delay on R6's VLAN 67 interface to be 250, in simple math we need to configure a delay value of 1310 on R6's VLAN 146 interface. This also means that configuring a variance of 5 will be enough so that both routes for VLAN 9 are installed in the routing table of R6 with the requested load distribution.

- was the 250 arbitary? - or does it have a direct correlation with the feasability condition - and if so how was it calculated? - I dont mean its obviously 25 x 10s of microseconds - I mean was this pulled out of a hat - could we have used. 500 and 2620 ?

250 + 20 = 270 * 5 which correlates to 1310 + 40 = 1350

But how was this worked out using maths to satisfy both the feasability condition and the 5 X load balancing ? guess work - or real algebra?

Thanks !

• Does anyone have some input on this one? I'm confused on this lab also and how the delay calculations were reached.

Thanks

• The trick is that you don't have to worry about the mathematics - working with the formula will cause you to have a bad day! The way to approach these problems is to use EIGRP topology table.  For each path you are able to see the metric for a path and also what values of delay and bandwidth have been used.  Note the delay values.

Following on from this the simplest way to get the required load balancing is to manipulate the metric for a particular path directly using an offset list inbound on the required interface for the path you want to influence.

Then take a look at the delay value post this change! After removing the offset list you can then find the difference in delay and apply at an interface level.

• Don't forget the delay will be configured in tens of microseconds, while the topology table shows microseconds.

• I need a better way that "trial and error" with delay to get the required ratios!!!

Could you possible point us in a direction for this method?  Alternatively, run through an example on here?

It sounds too easy (from initial view) and I've been banging my head against a wall for days now... I have the same issue with the OP - where did this 250 come from??!  Random??!

• It sounds too easy (from initial view) and I've been banging my head against a wall for days now... I have the same issue with the OP - where did this 250 come from??!  Random??!

The thing is it is!  I take no credit about this technique - Brain Dennis demonstrated it on the boot camp I did back in 2013!

Using the formula works how it's very long winded - while with the method the router does all of the work for you!

Also unless the question explicitly states that only delay values may be changed then an offset list is the quickest way. To get the result.  In addition it also allows you to be selective about which prefixes load balance and which do not!

I have not tried this scenario out so I don't know where 250 came from - I talking generically about configuring unequal cost load balancing.

• ✭✭✭

The trick is that you don't have to worry about the mathematics - working with the formula will cause you to have a bad day! The way to approach these problems is to use EIGRP topology table.  For each path you are able to see the metric for a path and also what values of delay and bandwidth have been used.  Note the delay values.

Following on from this the simplest way to get the required load balancing is to manipulate the metric for a particular path directly using an offset list inbound on the required interface for the path you want to influence.

Then take a look at the delay value post this change! After removing the offset list you can then find the difference in delay and apply at an interface level.

I really like reading this.  I have to admit that the long route of eigrp formulas gives me a headache when thinking about the lab clock (tick tock).  It always feels like a time-slow-down waiting for one little error in the calcualation, similar to redistribution tasks.

I wonder how many other CCIE's think this is sufficient.  EDIT: I see that it came directly from BrianD.  That is a good sign.  ;-)

Thanks WELSHY for posting this method again.

Lets see if I have this method correct?  ;-)

1. change EIGRP variation and calculate desired metrics.
example: 6 to 1 metrics    calculator    6*(lowest metric) = desired total metric

2. (the cheat) manually adjust the metric with offset for this calculated change.

3. ....and note the total delay: EIGRP automatically reverse-engineeers the delay factor. ;-)

Router#sh ip eigrp topology x.x.x.x

x.x.x.x (Ethernet0/1), from y.y.y.y, Send flag is 0x0
Composite metric is (196608000/66191360), route is External
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 2000000000 picoseconds
Reliability is 255/255
Minimum MTU is 1500
Hop count is 1
Originating router is z.z.z.z

4. subtract the original total delay from this number (200000000) = final interface delay

5. adjust interface delay to above result (in 10's)

6. VERIFY final variation 6 to 1.
show ip route x.x.x.x    or   show ip cef x.x.x.x

• I think I am getting there and getting a little excited at the thought of a simple method without the internal screaming in my head!

Is there a Brian M video for this?  Or someone doing it live with a real example?

• I think I am getting there and getting a little excited at the thought of a simple method without the internal screaming in my head!

Here is an example not even needing a look in the EIGRP table- assumes variance is correct to get unequal load balancing

We have

Rack1R7#show ip route 192.168.179.32
Routing entry for 192.168.179.32/29
Known via "eigrp 179", distance 90, metric 33536, type internal
Redistributing via eigrp 179
Last update from 192.168.179.9 on FastEthernet0/1, 00:04:11 ago
Routing Descriptor Blocks:
192.168.179.9, from 192.168.179.9, 00:04:11 ago, via FastEthernet0/1
Route metric is 33536, traffic share count is 1
Total delay is 310 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
* 192.168.179.2, from 192.168.179.2, 00:04:11 ago, via FastEthernet0/0
Route metric is 33536, traffic share count is 1
Total delay is 310 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes

We have ECMP path - let make the load share 5 to 2 by using an offset list

The above is represented by the ratio 5:2

Now the metric is inversely proportionate to the metric.  What I mean by this is for higher load share value I need a lowever metric and vice versa.

This means that the ratio of the metrics will be 1/5 : 1/2 or equivalently 2/10 : 5/10 (what I have done here change the common demoninator so it common on each side of the ratio - the lowest denominator in this case is 10 - 2 time 5)

From the above output we can see the metric is 33536 now let this be equivalent to 2/10

Thus 1/10 is 16768

So 5/10 is 83840

This means that I would need to increase the metric inbound into f0/0 to 83840 to get the required loadshare!  As the metric is 33536 the offset needs to be 83840-33536 = 50304

Applying offset-list 0 in 50304 f0/0 under to EIGRP process we get -

Rack1R7#show ip route 192.168.179.32
Routing entry for 192.168.179.32/29
Known via "eigrp 179", distance 90, metric 33536, type internal
Redistributing via eigrp 179
Last update from 192.168.179.9 on FastEthernet0/1, 00:00:02 ago
Routing Descriptor Blocks:
192.168.179.9, from 192.168.179.9, 00:00:02 ago, via FastEthernet0/1
Route metric is 33536, traffic share count is 5
Total delay is 310 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
* 192.168.179.2, from 192.168.179.2, 00:00:02 ago, via FastEthernet0/0
Route metric is 83840, traffic share count is 2
Total delay is 2275 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes

Although I haven't done this here - if we looked at the eigrp topology table for 192.168.179.32/29 we could look at the delay on for each path. Remember the delay via f0/1 hasn't changed by this process so will be same as the original delay for the path through f0/0.

UPDATE - why is the delay influenced and not other component of the EIGRP metric.  By default the metric is generated as a composite of the bandwidth and delay - via the formula.  Changing the bandwidth wouldn't make sense - as it's the minimum BW found along a path from the advertising router, whereas delay is additive (like OSPF cost and RIP hop count) - it increases hop by hop.  Thus the offset list only affects the delay part of the metric.

So 2275-310 = 1965 microseconds - so if we removed the offset list we would need to increase the interface delay fo f0/0 by 1964 microseconds or 196 tens of microseconds

This case is more complex due the load sharing ratio - so needed to find the common denominator - where whis share of 1 to 5 the metrics would be 1 : 1/5 or 5 : 1 (multiply both sides by 5) So the metric on one side needs to be 5 times larger

• EDIT: I see that it came directly from BrianD

This almost falls in the catergory - "why keep a dog and bark yourself" - http://idioms.thefreedictionary.com/Why+keep+a+dog+and+bark+yourself? let the router do the heavy lifting for you!

Anyway you method is right.  In the exam (I know only too well :-() is to use the simplest method to implement a solution. offset in my mind is better as we can link to an ACL and make it more specific whereas changing delay will affect all prefixes learned via that interface.

I have also added a more complex example where the load share is 5 to 2 - which need an undertanding of fractions and common denominator calculation.

Also noted that you are using named eigrp process so delay is in pico seconds - 1 micro second = 1000 nano seconds = 1000000 pico seconds - so you need to strip the first 7 digits to get tens of microseconds!

PS: still practicing to be a CCIE - an expensive process when you fail :-(

• Thank you

This was the one of many questions that suprsied me when doing the version 4 EIGRP  labs 2-3 years ago.

Now im doing version 5, this was the ONLY section that suprised me - again.  Im off to do IPSEC now. then back to ospf.  Thanks !

• You sir, have made my week!  I am going to test (and practice) a whole load of these.

Again, many thanks for taking the time to give such a clear explanation...  much appreciated by all.

Thanks, neil.

• Nope - still can't do it!  I start with 2 equal cost paths, trying to replicate your example.

Every time I set an "offset-list in", the route immediately fails the feasibility criteria and drops out of the routing table, leaving only the best route in place.

Variance is set to 128, but never gets chance to kick in.

Also, changed the EIGRP metrics to only use DELAY too.

Any ideas?  Using IOL images, but tried a few with no luck.

• ✭✭✭

Nope - still can't do it!  I start with 2 equal cost paths, trying to replicate your example.

Every time I set an "offset-list in", the route immediately fails the feasibility criteria and drops out of the routing table, leaving only the best route in place.

Variance is set to 128, but never gets chance to kick in.

If you are doing it on the final destination router, then I do not see how this could be possible.  However, it could happen, if the metric is added on another router in the path before it reaches the final destination.

On the destination router, the offset-list is added for the final metric (not part of the incoming Feasibility test).

To see this, can you give us the metrics for the two routes in the eigrp topology table?   Thanks.

show ip eigrp topology x.x.x.x/y  | in Composite metric|Successor

• Using INE topology, I am on R1 and want to unequal cost load balance 3:1 to destination 155.1.9.0/24 (hanging off R9).

Initially, costs via R6 and R3 are equal:

R1#sh ip rout 155.1.9.0

Routing entry for 155.1.9.0/24

Known via "eigrp 100", distance 90, metric 358400, type internal

Redistributing via eigrp 100

Last update from 155.1.146.6 on Ethernet0/1.146, 00:00:40 ago

Routing Descriptor Blocks:

155.1.146.6, from 155.1.146.6, 00:00:40 ago, via Ethernet0/1.146

Route metric is 358400, traffic share count is 1

Total delay is 4000 microseconds, minimum bandwidth is 10000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

* 155.1.13.3, from 155.1.13.3, 00:00:40 ago, via Ethernet0/1.13

Route metric is 358400, traffic share count is 1

Total delay is 4000 microseconds, minimum bandwidth is 10000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

R1#sh ip eigrp topology 155.1.9.0/24

EIGRP-IPv4 Topology Entry for AS(100)/ID(150.1.1.1) for 155.1.9.0/24

State is Passive, Query origin flag is 1, 2 Successor(s), FD is 358400

Descriptor Blocks:

155.1.13.3 (Ethernet0/1.13), from 155.1.13.3, Send flag is 0x0

Composite metric is (358400/332800), route is Internal

Vector metric:

Minimum bandwidth is 10000 Kbit

Total delay is 4000 microseconds

Reliability is 255/255

Minimum MTU is 1500

Hop count is 3

Originating router is 150.1.9.9

155.1.146.6 (Ethernet0/1.146), from 155.1.146.6, Send flag is 0x0

Composite metric is (358400/332800), route is Internal

Vector metric:

Minimum bandwidth is 10000 Kbit

Total delay is 4000 microseconds

Reliability is 255/255

Minimum MTU is 1500

Hop count is 3

Originating router is 150.1.9.9

I create an ACL to only change the metric from 155.1.9.0/24:

access-list 1 permit 155.1.9.0 0.0.0.255

I then make sure the variance is high (128 max), then add the "offset-list in" on the interface facing R6.

router eigrp 100

variance 128

offset-list 1 in 716800 ethernet 0/1.146 !choosing 716800 as it will make this path 3x higher than via R3 (eth0/1.13)

Immediately, I lose the route via R6, only giving the route via R3:

R1#sh ip route 155.1.9.0

Routing entry for 155.1.9.0/24

Known via "eigrp 100", distance 90, metric 358400, type internal

Redistributing via eigrp 100

Last update from 155.1.13.3 on Ethernet0/1.13, 00:00:29 ago

Routing Descriptor Blocks:

* 155.1.13.3, from 155.1.13.3, 00:00:29 ago, via Ethernet0/1.13

Route metric is 358400, traffic share count is 1

Total delay is 4000 microseconds, minimum bandwidth is 10000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

R1#

It's still in the EIGRP topology table, but failing the feasibility rule.

R1#sh ip eigrp topology 155.1.9.0/24

EIGRP-IPv4 Topology Entry for AS(100)/ID(150.1.1.1) for 155.1.9.0/24

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 358400

Descriptor Blocks:

155.1.13.3 (Ethernet0/1.13), from 155.1.13.3, Send flag is 0x0

Composite metric is (358400/332800), route is Internal

Vector metric:

Minimum bandwidth is 10000 Kbit

Total delay is 4000 microseconds

Reliability is 255/255

Minimum MTU is 1500

Hop count is 3

Originating router is 150.1.9.9

155.1.146.6 (Ethernet0/1.146), from 155.1.146.6, Send flag is 0x0

Composite metric is (1075200/1049600), route is Internal

Vector metric:

Minimum bandwidth is 10000 Kbit

Total delay is 32000 microseconds

Reliability is 255/255

Minimum MTU is 1500

Hop count is 3

Originating router is 150.1.9.9

And I doing something fundamentally wrong here??!

• ✭✭✭

Using INE topology, I am on R1 and want to unequal cost load balance 3:1 to destination 155.1.9.0/24 (hanging off R9).

R1#sh ip eigrp topology 155.1.9.0/24

EIGRP-IPv4 Topology Entry for AS(100)/ID(150.1.1.1) for 155.1.9.0/24

State is Passive, Query origin flag is 1, 2 Successor(s), FD is 358400

155.1.13.3 (Ethernet0/1.13), from 155.1.13.3, Send flag is 0x0

Composite metric is (358400/332800), route is Internal

155.1.146.6 (Ethernet0/1.146), from 155.1.146.6, Send flag is 0x0

Composite metric is (358400/332800), route is Internal

OK.  We can see that the (final metric/received advertised metric) are equal.

(358400/332800)

I create an ACL to only change the metric from 155.1.9.0/24:

access-list 1 permit 155.1.9.0 0.0.0.255

I then make sure the variance is high (128 max), then add the "offset-list in" on the interface facing R6.

router eigrp 100

variance 128

offset-list 1 in 716800 ethernet 0/1.146 !choosing 716800 as it will make this path 3x higher than via R3 (eth0/1.13)

Which router is this done on?   It should be done on R1, where you are looking for the final result.

It's still in the EIGRP topology table, but failing the feasibility rule.

R1#sh ip eigrp topology 155.1.9.0/24

EIGRP-IPv4 Topology Entry for AS(100)/ID(150.1.1.1) for 155.1.9.0/24

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 358400

Descriptor Blocks:

155.1.13.3 (Ethernet0/1.13), from 155.1.13.3, Send flag is 0x0

Composite metric is (358400/332800), route is Internal

155.1.146.6 (Ethernet0/1.146), from 155.1.146.6, Send flag is 0x0

Composite metric is (1075200/1049600), route is Internal

It seems to me that maybe you have changed the offset on R6.  Wrong router.

1075200-1049600=only 25,600 added by R1, which is the same as before.

1,049,600(new) - 332,800(original) = 716,800   received on R1????

Clear your neighbors and look at it again, but I believe you may have configured the wrong router.

• No, I am only doing configuration on R1, nothing else.  Checked the other routers for "delay" under interface or any other offset-list and nothing there.  I am using the basic-eigrp configs.

R1#sh run | s router

router eigrp 100

network 150.1.0.0

network 155.1.0.0

offset-list 1 in 716800 Ethernet0/1.146

R1#

here is R6:

R6#sh run | s router

router eigrp 100

network 150.1.0.0

network 155.1.0.0

R6#

here is R3:

R3#sh run | s router

router eigrp 100

network 150.1.0.0

network 155.1.0.0

R3#

here is R7:

R7#sh run | s router

router eigrp 100

network 150.1.0.0

network 155.1.0.0

R7#

I am glad something looks odd - I have been at this for hours and going slightly mad!!
• And I doing something fundamentally wrong here??!

This doesn't seem correct - the offset list  or applying a different delay to e0/1.146 would not change the reported distance (RD).

From your output this has tripled - breaking the feasability condition.

The offset list should change the what metric that is assigned to the interface.

You could try this - remove the offset list

Your change in delay is 32000 - 4000 = 28000 microseconds.

Look at the delay configured on e0/1.146 from show interface e0/1.146

Then increase the delay by 2800 tens of microseconds.

Of course this will affect all routes

• ✭✭✭

I just did a mini-lab sanity test on gns3 15.2(4)M5, and the offset did change the Reported Distance.  Back to the books for me.  arrrgh

May be a bug in this IOS-- or I have to relearn something.    double-arrrrggghhhh

BEFORE:=================

R1(config-router)#do sh ip eigrp topolog  2.2.2.2/32
EIGRP-IPv4 Topology Entry for AS(100)/ID(111.111.111.111) for 2.2.2.2/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 156160
Descriptor Blocks:
12.12.12.2 (FastEthernet0/1), from 12.12.12.2, Send flag is 0x0
Composite metric is (156160/128256), route is Internal

156160-127256=28,904

AFTER:=================

R1(config-router)#offset-list 0 in 111111 f0/1

R1(config-router)#do sh ip eigrp topolog  2.2.2.2/32
EIGRP-IPv4 Topology Entry for AS(100)/ID(111.111.111.111) for 2.2.2.2/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 267271
Descriptor Blocks:
12.12.12.2 (FastEthernet0/1), from 12.12.12.2, Send flag is 0x0
Composite metric is (267271/239360), route is Internal

267271-239360=27,911  ???

239360(new reported) - 128256 (original reported) = 111,104

router eigrp 100
network 1.1.1.1 0.0.0.0
network 12.12.12.1 0.0.0.0
offset-list 0 in 111111 FastEthernet0/1

• ✭✭✭

Walked away..........came back and tested in another IOS.  What a relief.

Huge BUG ALERT in gns3 15.2(4)M5

But I did learn something today (lol).   Offset is added to the original FD.

Retested in different IOS.

BEFORE=========================

R1(config-router)#do sh ip eigrp topol 2.2.2.2/32
IP-EIGRP (AS 100): Topology entry for 2.2.2.2/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 409600
Routing Descriptor Blocks:
12.12.12.2 (FastEthernet0/0), from 12.12.12.2, Send flag is 0x0
Composite metric is (409600/128256), Route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 6000 microseconds
Reliability is 255/255
Minimum MTU is 1500
Hop count is 1

AFTER========================

R1(config-router)#offset-list 0 in 111111 f0/0

R1(config-router)#do sh ip eigrp topol 2.2.2.2/32
IP-EIGRP (AS 100): Topology entry for 2.2.2.2/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 409600
Routing Descriptor Blocks:
12.12.12.2 (FastEthernet0/0), from 12.12.12.2, Send flag is 0x0
Composite metric is (520711/128256), Route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 10340 microseconds
Reliability is 255/255
Minimum MTU is 1500
Hop count is 1

409600(original FD) + 111111(offset = 520,711

(example) needed delay = 10340 - 6000 = 4340u + original interface delay

• In fairness when I used this feature it was in 12.4T and not in 15 - the offset list acts like it is adding delay to interface!

• ✭✭✭

Thanks again Welshy for comfirming this.

I retested it in 12.4 and 15.4(1)T, and it works as it should.   For all of the time spent with the issue, I guess that I will chalk-it-up to good practice with the EIGRP variance/offset trick.  ;-)

• So the solution worked on R1, however the requirements on the INE site call for the delay to be adjusted on R6, not R1.

• Configure unequal cost load balancing so that traffic from R6 going to VLAN 9 is load balanced between R1 and R7.
• Traffic share should be configured so that the link to R7 is used five times as much as the link to R1.
• Modify delay on R6 as required.

Are we barking up the wrong tree here using R1? Or are you making the offset-list changes on R1, checking the delay amounts, removing the offset-list on R1 and then making those delay adjustments on R6?

Thanks

• I was simply using the INE topology and coming up with my own scenario using the BASIC-EIGRP configurations.

My scenario was getting UCLB to work from R1 to 155.1.9.0/24 (a subnet hanging off R9).

I have checked all of my IOSes and every single on adds the metric in the offset-list to the AD *and* FD, therefore, something must be wrong with my IOSes or the platform I am using (WEB-IOU)... I fully expect the metric in the offset-list to only add to FD and the AD remains as is.

Will keep investigating...

• ✭✭✭

I retested it in 12.4 and 15.4(1)T, and it works as it should.

Just to reassure you.....I tested the above successfully.   12.4 in GNS3  and 15.4(1)T in IOU.

• Could you please verify the IOU filename you have for 15.4(1)T?

I am using i86bi_linux-adventerprisek9-ms.154-1.T_A to no avail.

I will not let this lie!!! I must see this with my own eyes!! [:D]

• ✭✭✭

In the above posts, I have already verified the three different IOS's.

Maybe try it in a different IOS that you have, or maybe try it in 12.4T.

• I did notice that your total delay on interface Ethernet0/1.146 went from 4000 microseconds to 32000 microseconds, and it could be impacting your advertised distance. It is 1049600

Remember that the advertised distance MUST be less than the feasible distance of the successor before it can be considered for load-balancing.

• Hi,

My approach:

Path Delay 1 = R6 - R7 - R9 = 30

Path Delay 2 = R6 - R1 - R3 - R7 - R9 = 50

30/10 = 3 * 256 = Metric 1 768 (Gi1.67)

50/10 = 5 * 256 = Metric 2 1280 (Gi1.146)

Now first thing I did was to equalize metrics(by adding to the lowest one link). This will get me an equal starting point on both links, so it will be easier later.

showed as 1280.  So,

1280 - 768 = 512  ,   Now, let's see how much delay we need to add to equalize the metric.

If Metric = delay * 256, that means the equation for Delay will be:

Delay = Metric / 256  ---> 512 / 256 = 2 <  We need to add this amount of delay on G1.67 Link.

R6(iconfig-if)# delay 3**  (Is 3 because we add to the current delay value of the link) This value is the delay from the show ip int G1.146 | i DLY:

MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec.      -   10 / 10 = Delay of 1  So we add to this value. And Since we are overriding the default value, we must take this into account as well.)

Okay now R6's routing table should be something like this:

R6#sh ip route 155.1.9.0
Routing entry for 155.1.9.0/24
Known via "eigrp 100", distance 90, metric 1280, type internal
Redistributing via eigrp 100
Last update from 155.1.146.1 on GigabitEthernet1.146, 00:32:40 ago
Routing Descriptor Blocks:
155.1.146.1, from 155.1.146.1, 00:32:40 ago, via GigabitEthernet1.146
Route metric is 1280, traffic share count is 1 <<<<<<<<<<<<<<<<<<< Share Count is 1
Total delay is 50 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
* 155.1.67.7, from 155.1.67.7, 00:32:40 ago, via GigabitEthernet1.67
Route metric is 1280, traffic share count is 1 <<<<<<<<<<<<<<<<<<< Share Count is 1
Total delay is 50 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes

Now that the metrics are equal is easier to compute what is request by the task.

1. Configure unequal cost load balancing so that traffic from R6 going to VLAN 9 is load balanced between R1 and R7.
• Traffic share should be configured so that the link to R7 is used five times as

much as the link to R1.  <--------- 5:1 Ratio

• Modify delay on R6 as required.

Next step is to add a value on one of the links so the end metric is 5 times higher than the other one.  In this case that would be G1.146.

Actual metric is 1280 and that * 5 = 6400. That's the metric we need to get.

Now, keep in mind that we are adding to the actual value of the metric, so to get to 6400 we just need to add the difference between 6400 (final metricl) and 1280 (actual metric) which is :  6400 - 1280 = 5120 < ----

Now that have the metric value were adding, we need to convert it to the corresponding delay value for the interface.

Delay = Metric / 256 --> Delay = 5120 / 256 --> Delay = 20

We need to add a delay of 20 + 1*

*Again we add 1 because we add to the current delay value of the link. This value is the delay from the show ip int G1.146 | i DLY:  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec.      -   10 / 10 = Delay of 1  So we add to this value.  And Since we are overriding the default value, we must take this into account as well.

R6(config-if)#  delay 21

Now that the corresponding delay values are in place, we just add a variance value of 5 under EIGRP router config

R6(config-router)# variance 5

Then we check the route again:

Routing entry for 155.1.9.0/24
Known via "eigrp 100", distance 90, metric 1280, type internal
Redistributing via eigrp 100
Last update from 155.1.146.1 on GigabitEthernet1.146, 00:00:32 ago
Routing Descriptor Blocks:
155.1.146.1, from 155.1.146.1, 00:00:32 ago, via GigabitEthernet1.146
Route metric is 6400, traffic share count is 1 <---------------------------------------------------
Total delay is 250 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
* 155.1.67.7, from 155.1.67.7, 00:00:32 ago, via GigabitEthernet1.67
Route metric is 1280, traffic share count is 5 <---------------------------------------------------
Total delay is 50 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes

Notice the route share count now G1.146 is 1 and G1.67 is 5; we achieved a 5:1 ratio.

Now R6 will route traffic through R7 five times as much as through R1.

I'm using the CSR1000v for my lab so I can't disable CEF, which means in order to provide debugging would require a hell of a post.  But with the

show ip route 155.1.9.0 output you get how much traffic would be sent to each of the links.  HTH

Config:

router eigrp 100
metric weights 0 0 0 1 0 0
variance 5
network 150.1.0.0
network 155.1.0.0

Current configuration : 146 bytes
!
interface GigabitEthernet1.146
encapsulation dot1Q 146
delay 21 <--------------------------------
!
interface GigabitEthernet1.67
encapsulation dot1Q 67
delay 3 <-----------------------------------
end

• Thanks c1sc0m . This helped me out a lot!

• Glad to help.  I tried to explain this as best as I could, since English is not my native language.  So I apologize for any grammar mistakes.

But the key point I wanted to share is to equalize the metrics so you get an equal starting point for the calculations.