CCIE Pursuit Blog

December 30, 2008

Secrets Of The EIGRP Offset-List Command

The following post is loooooong and of no interest to 99.9999999999% of the world.  I was going over EIGRP commands and had a problem with an EIGRP offset-list not altering the EIGRP metric the way that it should have.  In the process of playing with this command I think that I’ve found the method that this command uses to alter the EIGRP metric of a route.

I did warn you that this was only interesting to a handful of geeks.

Here’s the network topology.  Really basic:

r1————r2

r1 and r2 are connected by a single serial link (s0/0 on both devices).  Both routers running EIGRP on all interfaces.  There are 3 loopbacks being advertised on each device.

r1#sh ip ei int
IP-EIGRP interfaces for process 100

Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Se0/0 1 0/0        27       0/15          91           0
Lo0                0        0/0         0       0/10           0           0
Lo1                0        0/0         0       0/10           0           0
Lo2                0        0/0         0       0/10           0           0

r1#sh ip ei nei
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
(sec)         (ms)       Cnt Num
0   10.1.12.2 Se0/0 13 00:01:47   27   200  0  3

r1#sh ip route ei
D    222.222.222.0/24 [90/2297856] via 10.1.12.2, 00:01:55, Serial0/0
2.0.0.0/24 is subnetted, 1 subnets
D       2.2.2.0 [90/2297856] via 10.1.12.2, 00:01:55, Serial0/0
22.0.0.0/24 is subnetted, 1 subnets
D       22.22.22.0 [90/2297856] via 10.1.12.2, 00:01:55, Serial0/0

r2#sh ip ei int
IP-EIGRP interfaces for process 100

Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Se0/0 1 0/0        34       0/15         147           0
Lo0                0        0/0         0       0/10           0           0
Lo1                0        0/0         0       0/10           0           0
Lo2                0        0/0         0       0/10           0           0

r2#sh ip ei nei
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
(sec)         (ms)       Cnt Num
0   10.1.12.1 Se0/0 13 00:02:15   34   204  0  3

r2#sh ip route ei

1.0.0.0/24 is subnetted, 1 subnets
D       1.1.1.0 [90/2297856] via 10.1.12.1, 00:02:19, Serial0/0
111.0.0.0/24 is subnetted, 1 subnets
D       111.111.111.0 [90/2297856] via 10.1.12.1, 00:02:19, Serial0/0
11.0.0.0/24 is subnetted, 1 subnets
D       11.11.11.0 [90/2297856] via 10.1.12.1, 00:02:19, Serial0/0

Okay to start with let’s see the routing information for net 1.1.1.0/24 on r2:

r2#sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100”, distance 90, metric 2297856, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:03:17 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:03:17 ago, via Serial0/0
Route metric is 2297856, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

On r2 let’s add 100 to the EIGRP metrics of all EIGRP routes advertised in s0/0 from r1:
[NOTE: access-list 0 selects all networks]

r2(config)#router ei 100
r2(config-router)#offset-list 0 in 100 s0/0

*Mar  1 00:15:01.055: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.1 (Serial0/0) is resync: route configuration changed

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100”, distance 90, metric 2297956, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:08 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:08 ago, via Serial0/0
Route metric is 2297956, traffic share count is 1
Total delay is 25003 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

Interesting…we’ve added 100 to the EIGRP metric as expected.  The ‘total delay’ has also increased by 3 microseconds (not expected).  It seems that the EIGRP offset-list alters the EIGRP variable in order to change the overall EIGRP metric.  EIGRP uses this easy to remember 🙂 equation to calculate its metric:

If k5 equals 0, the composite 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)]

This led me to wonder what would happen if we took delay out of the EIGRP equation.  We can do that by setting the EIGRP K-Value for delay to 0 and just leaving bandwidth K-Value (we’ll need to do this on both routers):

r1(config)#  router ei 100
r1(config-router)#  metric weights 0 1 0 0 0 0

r2(config)#router ei 100
r2(config-router)#metric weights 0 1 0 0 0 0
r2(config-router)#no offset-list 0 in 100 s0/0

r2(config-router)#do sh ip proto | i EIGRP metric weight
EIGRP metric weight K1=1, K2=0, K3=0, K4=0, K5=0

Let’s see our metric before applying the offset-list:

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100”, distance 90, metric 1657856, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:32 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:32 ago, via Serial0/0
Route metric is 1657856, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

Okay, let’s reapply the offset-list:

r2(config-router)#offset-list 0 in 100 s0/0

*Mar  1 03:04:44.711: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.1 (Serial0/0) is resync: route configuration changed

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100”, distance 90, metric 1657856, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:10 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:10 ago, via Serial0/0
Route metric is 1657856, traffic share count is 1
Total delay is 25003 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

BOOYAH!  The offset-list is supposed to increase the EIGRP metric by 100.  We can see that the metric did NOT change (still 1657856), BUT the total delay increased by 3 microseconds.  It looks like we’ve discovered the mechanism used by the EIGRP offset-list to change the EIGRP metric.  We’ve also discovered that setting the delay K-Value to zero “breaks” the offset-list function.

One last experiment.  Let’s see if the offset-list is intelligent enough to handle a delay K-Value of more than 1:

r1(config-router)#metric weights 0 1 0 4 0 0

r2(config-router)#metric weights 0 1 0 4 0 0
r2(config-router)#no offset-list 0 in 100 s0/0

r2(config-router)#do sh ip proto | i EIGRP metric weight
EIGRP metric weight K1=1, K2=0, K3=4, K4=0, K5=0

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100”, distance 90, metric 4217856, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:01:09 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:01:09 ago, via Serial0/0
Route metric is 4217856, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

r2(config-router)#offset-list 0 in 100 s0/0

*Mar  1 03:11:56.439: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.1 (Serial0/0) is resync: route configuration changed

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100”, distance 90, metric 4218256, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:07 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:07 ago, via Serial0/0
Route metric is 4218256, traffic share count is 1
Total delay is 25003 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

Weird.  I would have thought that this would have worked as we have our default K-Values but have just increased the weight of delay 4 times.  We can see that the delay was once again increased by 3 microseconds, but the overall metric was unaffected.  Weird.

Thank you to reader Rich for pointing out that 4217856 and 4218256 are NOT the same value.  🙂  The EIGRP metric increased by 400 instead of the 100 that we specified in the offset-list.  That’s because the K-Value for delay is set to 4 times the default.

Hmmm…one more experiment.  Let’s set the delay K-Value back to 1 but make it the only variable used for the EIGRP metric:

r1(config-router)#metric weights 0 0 0 1 0 0

r2(config-router)#metric weights 0 0 0 1 0 0
r2(config-router)#no offset-list 0 in 100 s0/0

r2(config-router)#do sh ip proto | i EIGRP metric weight
EIGRP metric weight K1=0, K2=0, K3=1, K4=0, K5=0

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100”, distance 90, metric 640000, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:33 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:33 ago, via Serial0/0
Route metric is 640000, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

Let’s reapply the offset-list and see what happens:

r2(config-router)#offset-list 0 in 100 s0/0

*Mar  1 03:22:54.319: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.1 (Serial0/0) is resync: route configuration changed

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100”, distance 90, metric 640100, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:06 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:06 ago, via Serial0/0
Route metric is 640100, traffic share count is 1
Total delay is 25003 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

It worked.  So we don’t need to have the bandwidth K-Value “turned on” for the offset-list to work.

Last experiment…I promise.  Let’s set the delay K-Value to 4 and set the other K-Values to 0:

r1(config-router)#metric weights 0 0 0 4 0 0

r2(config-router)#metric weights 0 0 0 4 0 0
r2(config-router)#no offset-list 0 in 100 s0/0

r2(config-router)#do sh ip proto | i EIGRP metric weight
EIGRP metric weight K1=0, K2=0, K3=4, K4=0, K5=0

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100”, distance 90, metric 2560000, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:14 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:14 ago, via Serial0/0
Route metric is 2560000, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

Reapply the offset-list:

r2(config-router)#offset-list 0 in 100 s0/0

*Mar  1 03:33:52.279: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.1 (Serial0/0) is resync: route configuration changed

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100”, distance 90, metric 2560400, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:06 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:06 ago, via Serial0/0
Route metric is 2560400, traffic share count is 1
Total delay is 25003 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

Ah hah!  The metric changed by 400 instead of 100 (as we had configured it to be offset).  I think that this is pretty good evidence that the EIGRP offset-list only alters the EIGRP delay variable and is only accurate when that K-Value is set to 1.

I don’t think that this will affect you in real life (who’s changing K-Values and using offset-lists with EIGRP?) but it could possibly come up in a lab.  I could forsee a task that has you change the K-Values and then another task that has you altering EIGRP metrics (probably for some evil unequal-cost load-balancing task).  At least now you’ll know why your perfectly executed offset-list solution has failed.  🙂

Advertisements

7 Comments »

  1. I don’t know who it would be of little interest to, but thats great research you did. Who thinks about offsets manipulating metric weights as opposed to the metric directly? when you leave the ol’ metric weights 010100 default on you would never notice. Thanks for throwing that out to the community. Though, to be honest I don’t see the proctors telling you to give weight to only bandwidth, if only because so many paths could have the same minimum bandwidth. I could be dead wrong about that though.

    Comment by Luis Garcia — December 30, 2008 @ 12:53 pm | Reply

  2. Tricky little bug. Nice write-up!

    Comment by stretch — December 30, 2008 @ 1:00 pm | Reply

  3. In your you example where you set the K values to 1 0 4 0 0 you said it didnt change the overall metric but it did from “metric 4217856” to “metric 4218256” which increased by your K-value muliplier of 4. Thats was what you were looking for right?

    Comment by Rich — December 30, 2008 @ 1:36 pm | Reply

  4. @Luis Garcia – Good points.

    @stretch – Thanks.

    @Rich – Thank you! My eyes must have been buggy from looking at EIGRP metrics (and my brain switched off). This is what I expected. I’ll update the posting.

    Comment by cciepursuit — December 30, 2008 @ 2:06 pm | Reply

  5. Richard, over at configterminal.com had commented on one of my articles where I was discussing EIGRP offset lists. He referenced the document below that talks about EIGRP using the Delay value with the offset lists.

    http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a008012dac4.shtml#offset

    We were thinking that since delay was multiplied by 256 in the metric equation, that couldn’t be correct, as you can add values other than multiples of 256 to the metric. But I guess I never did the show on the route that listed the total delay of the metric. Evidently, EIGRP can manipulate the delay far more ganularly than we can on the interface. Nice post!

    Comment by jrensink78 — December 30, 2008 @ 3:49 pm | Reply

  6. Nice post, excellent research!

    Comment by Joe A — December 31, 2008 @ 12:43 pm | Reply

  7. I think this happens because delay is specified in 10’s of usecs so 100 is actually 1000 usecs. The router doesn’t do floating points so 1000/256 (the multiplier for EIGRP metrics) is actually 3. When the show route command is issued the router displays the min bandwith and delay seperatley and because the 256 multiplier comes into play the 1000 increase (which was entered as 100) only translates to a 3 microsecond increase. I guess this all stems from the offset not being subjected to the 256 multiplier.

    Comment by Nick A — August 13, 2009 @ 11:09 am | Reply


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: