Showing results for 
Search instead for 
Did you mean: 

Influencing Path Selection in EIGRP

Hi Sir,

I have a network of 4 routers (see attached network diagram). All the links between the routers have the same bandwidth and delay values. EIGRP is enabled on all the routers' interfaces.

Thus, R1 has two equal-cost paths to (loopback address of R4) via R2 ( and R3 (

I'd like R1 to prefer the path R2>R4 to reach My way of accomplishing this is by modifying the AD at R1, as follows:

R1 router



router eigrp 1

distance 91 1


access-list 1 permit


The above config works; R1 has only a single path to, via R2 (

I'd like to get some second opinions from you all whether this method is the most ideal for this case. If you know of other recommended methods, please suggest to me.

Thank you.


Lim TS


"It is with some trepidation that I disagree with you, but in this case I do."

Oh, no! I only know the code so well, and no better. I certainly don't know everything! :-) In fact, I'm glad you tested this, and contradicted me, because I had to go back in the code and lab, and rework through how this works. The complete answer (and this time it's right!):

When you configure an offset-list, we take the offset you configure, divide it by 255, and add the result to the delay on the route. To see this, examine these outputs, from the lab:

72M#sho ip eigrp topo

Composite metric is (307200/281600),

Vector metric:

Minimum bandwidth is 10000 Kbit

Total delay is 2000 microseconds

This is with no offset lists at all. The FD is 307200, and the delay is 2000. Now, I insert the offset-list:

72M(config-router)#offset-list 10 in 1000


Let's see what the route looks like in the local topo table:

72M#sho ip eigrp topo

Composite metric is (308200/282600),

Vector metric:

Minimum bandwidth is 10000 Kbit

Total delay is 2039 microseconds

Note the total metric is increased by 1000, just what your offset list said. However, if you look at the delay metric, it's changed by 39. Where did 39 come from? Well, to get there, you have to remember one other thing about EIGRP--that we actually carry the delay with one more digit than we display. Thus, when you see a delay of 1000, it's actually 10000 (!), you have to add another 0 to make things work right. You can see this, as well, when you enter the delay on an interface, and then look at the delay in the topo table--they are one digit off.

So, taking 1000, the entered offset, adding one 0, so we have 10000, and dividing by 255, what do we get?

10000/255 == 29

Oh, I almost forgot--why divide by 255? Because in the "normal" eigrp metric calculation, we multiply delay by 255 when we calculate the total metric from the vector metrics....

So, what we actually do is to add enough delay to offset the total metric by the amount you specified in the offset-list command, to the local router.






What am I missing here? Why don't you just modify your delay parameters on your interfaces to achieve te desired metrics to preferred routes? I have hundreds of interfaces in my highly meshed enterprise and I use the delay statement exclusively to implement successors and FSs.



Hi Ron,

I think the problem with altering the metric is that it will affect all of the routes - he only wants to adjust a single route. If he uses an offset list, he can do this without affecting the other routes.


I didn't take enough time to study his actual intent. This is a very interesting problem. It appears that the offset behavior is not behaving as expected among our peers. Perhaps differing code trains/versions have subtle differences which result in small but significant behavioral differences.

I wish I had more time to devote to this kind of thing but I'm usually working to keep a couple of steps ahead on my network. I do find the Network Professionals forum valuable.