Influencing EIGRP Path Selection

 

Being an enhanced distance vector IGP, there are several ways to influence the route and path selection of EIGRP

Administrative Distance:

Consider the topology below. We would like to prefer the link between R7 and R1 when sending traffic to the 4.4.4.4 network (R4's loopback)

Currently we have 2 equal cost routes to 4.4.4.4 as shown in the ip routing table

Also, in the EIGRP topology table, we see the 2 successor routes of equal cost

Here, we are going to use the distance command to change the AD of the route for 4.4.4.4 on R7, preferring the path towards R1s neighbor interface.

First thing is define the route in an access list 

R7(config)#access-list 1 permit host 4.4.4.4 

Next we jump into router config mode and issue the distance command, with the source interface being R1's neighbor interface (10.1.17.1) and access-list 1 on the end to define the route - 4.4.4.4

R7(config)#router eigrp 7
R7(config-router)#distance 88 10.1.17.1 0.0.0.0 1

Now we can see that the AD is 88, lower then the default of 90, so R7 will prefer this this path on the way to 4.4.4.4 only.

The EIGRP topology table remains the same as above...as we haven't changed the link metrics in any way. We'll explore that next !

Interface Bandwidth and Delay values:

If we take a look at the current values of interface gig 0/0 on R7 (the link that we want to prefer here), we see the following (truncated)

R7#show interfaces gigabitEthernet 0/0

GigabitEthernet0/0 is up, line protocol is up 

  Hardware is iGbE, address is 5254.0014.1def (bia 5254.0014.1def)

  Internet address is 10.1.17.7/24

  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec, 

     reliability 255/255, txload 1/255, rxload 1/255

To favor this link, we can increase the bandwidth or decrease the delay, which will cause EIGRP to recalculate it's route. We can also do the inverse on a link we do NOT want to favor to make the EIGRP metric WORSE - increase the delay and decrease the bandwidth. And in this case, I need to do just that since the delay and bandwidth metrics on these links are already at their optimum value as shown above, and can't be made better.

Here I decrease the bandwidth to 50000 Kbps (or 500 Mbps) and increase the delay to 20 (in 10 of miroseconds) which would be 200 usec.

interface GigabitEthernet0/1

 bandwidth 500000

 delay 20

Now we get this

GigabitEthernet0/1 is up, line protocol is up 

  Hardware is iGbE, address is 5254.000f.ef31 (bia 5254.000f.ef31)

  Internet address is 10.1.27.7/24

  MTU 1500 bytes, BW 500000 Kbit/sec, DLY 200 usec, 

     reliability 255/255, txload 1/255, rxload 1/255

show ip route - Link between R7 and R1 is now preferred.

show ip eigrp topology - metric is worse on Gig0/1 link as show shown in the topology table

Of course this affects all routes egressing from R7 towards R1, R2 and beyond.

EIGRP Offset List:

Another way to influence EIGRP routes is via an offset list. You can only make a metric WORSE with an offset list, not BETTER...so you'll need to set the offset on the link you do NOT want to favor.

Here we add the offset list to the incoming interface on R7 - (R2-R7 Link) 

offset-list <access list defining route you want to alter><in\out><off set list value><interface>

R7(config-router)#offset-list 1 in 2 gigabitEthernet 0/1

You can see below - route table favors the R1-R7 link, and only for the 4.4.4.4 route defined by access-list 1....which is nice.

And the EIGRP topology table shows the incremented metric value on the R2-R7 link - 2 above, just enough to make it fall back to a feasible successor.

If you run a show ip protocol on R7 - it will tell you that an offset list has been applied and state the additional metric.

show ip protocol

Routing Protocol is "eigrp 7"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Incoming routes in GigabitEthernet0/1 will have 2 added to metric if on list 1
Default networks flagged in outgoing updates
Default networks accepted from incoming updates

There you have it...hope this was helpful!