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.

Okay to start with let’s see the routing information for net 1.1.1.0/24 on r2:
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]
*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
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:
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):
Let’s see our metric before applying the offset-list:
Okay, let’s reapply the offset-list:
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:

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:
Let’s reapply the offset-list and see what happens:
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:
Reapply the offset-list:
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.

Network Bulls
Best Institute for CCNA CCNP CCSP CCIP CCIE R&S, CCIE Security Training in India
www.networkbulls.com
M-44, Old Dlf, Sector-14
Gurgaon, Haryana, india