Secrets of The EIGRP Offset-List Command

Secrets Of The EIGRP Offset-List
Command
Filed under: Cisco,Cisco Certification,EIGRP,IOS — cciepursuit @ 10:00 am

Tags: CCIE, CCIE Lab, Certification, Cisco, Cisco Certification, Interior Gateway Routing
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
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
D 1.1.1.0 [90/2297856] via 10.1.12.1, 00:02:19, Serial0/0
D 111.111.111.0 [90/2297856] via 10.1.12.1, 00:02:19, Serial0/0
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

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:

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.

Secrets of The EIGRP Offset-List Command

Uploaded by

Copyright:

Available Formats

You might also like

Secrets of The EIGRP Offset-List Command

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Secrets of The EIGRP Offset-List Command

Uploaded by

Copyright:

Available Formats

Secrets Of The EIGRP Offset-List

Filed under: Cisco,Cisco Certification,EIGRP,IOS — cciepursuit @ 10:00 am

Here’s the network topology. Really basic:

Xmit Queue Mean Pacing Time Multicast Pending

r2#sh ip route 1.1.1.0

*Mar 1 00:15:01.055: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.1

r2(config-router)#do sh ip route 1.1.1.0

equation to calculate its metric:

If k5 does not equal zero, an additional operation is performed:

r1(config)# router ei 100

r2(config-router)#do sh ip proto | i EIGRP metric weight

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

r2(config-router)#do sh ip route 1.1.1.0

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

r2(config-router)#do sh ip route 1.1.1.0

r2(config-router)#do sh ip proto | i EIGRP metric weight

r2(config-router)#do sh ip route 1.1.1.0

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

r2(config-router)#do sh ip route 1.1.1.0

r2(config-router)#do sh ip proto | i EIGRP metric weight

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

r2(config-router)#do sh ip route 1.1.1.0

r2(config-router)#do sh ip proto | i EIGRP metric weight

r2(config-router)#do sh ip route 1.1.1.0

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

r2(config-router)#do sh ip route 1.1.1.0

You might also like