cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
449
Views
0
Helpful
4
Replies

Changing the AD of a route to a subnet in EIGRP and failover.

Chris Izatt
Level 1
Level 1

If I run the commands below to force traffic that path and a link goes down will the traffic still failover to the next FC in the EIGRP topo? Is there a better way to force a route in EIGRP when the metric is higher? I am open for suggestions on proper ways to do this. 

 

 

access-list 99 permit 10.1.3.0 0.0.0.255

router eigrp 1
distance 89 10.1.2.4 0.0.0.0 99

Thanks

1 Accepted Solution

Accepted Solutions

John Blakley
VIP Alumni
VIP Alumni

If you're learning this route from another host, you can lower the metric with an offset list instead of changing the AD of the route. If you get it lower than the current successor, it should be put into the routing table for you and leave the other successor as an FS. (I haven't labbed this up yet...)

Actually, I labbed this up and doesn't work the way I intended. You would have to increase the metric of every other route for this method to work. Let me play around with some other ideas...

HTH,

John

HTH, John *** Please rate all useful posts ***

View solution in original post

4 Replies 4

John Blakley
VIP Alumni
VIP Alumni

If you're learning this route from another host, you can lower the metric with an offset list instead of changing the AD of the route. If you get it lower than the current successor, it should be put into the routing table for you and leave the other successor as an FS. (I haven't labbed this up yet...)

Actually, I labbed this up and doesn't work the way I intended. You would have to increase the metric of every other route for this method to work. Let me play around with some other ideas...

HTH,

John

HTH, John *** Please rate all useful posts ***

I thought you could only add to the metric not subtract?

 

I am going to try this or something like it to see if i can get the current path metric high enough for that subnet to work:

access-list 1 permit 10.1.1.0 0.0.0.255
router eigrp 1
offset-list 1 out 5 Ethernet7/1

 

I am also fighting split horizon based on the network layout

Yep, you're correct....that's why I said you'd have to affect all other routes. If you can add from the other side, like it seems like you're doing, you may be able to affect it that way.

HTH, John *** Please rate all useful posts ***

I did get it to work, but in complex networks this takes some logic planning and testing. 

 

I was able to get traffic to and from the the two points to follow the same path, but not super simple. I had six routers in a ring, because my laptop sucks couldn't get any more. R1 has a short path to 10.2.0.0 one way a much longer the other. I modified the BW and delay to try to make this closer to the prod i am testing for. R1 and r2 are directly connected. 10.1.7.0 is the subnet I am sending from on r1. These commands got it done for me. 

 

r1-core

access-list 1 permit 10.2.0.0 0.0.0.255  
access-list 2 permit 10.1.7.0 0.0.0.255  

router eigrp 170
 offset-list 1 in 4000 FastEthernet1/10
 offset-list 2 out 300000 FastEthernet1/10
 network 10.0.0.0

r2-core

access-list 1 permit 10.1.7.0 0.0.0.255

router eigrp 170
 offset-list 1 in 70000 FastEthernet1/1
 network 10.0.0.0

Review Cisco Networking for a $25 gift card