Link to home
Start Free TrialLog in
Avatar of mykeeikenga
mykeeikengaFlag for Nigeria

asked on

Can EIGRP determine link quality

Hi guys,

I'm a WAN administrator running EIGRP acroos a network of over 200 nodes. I have redundancy on these locations i.e. two WAN links to every location. At some point the quality of the primary link to some of these locations get very bad e.g. extremely high latency, very epileptic replies etc. Is there any way to make EIGRP determine link quality and switch to the backup link until the primary link gets better? I know i can achieved this with IPSLA monitor but what i dont know is how it will work with EIGRP.
Avatar of Don Johnston
Don Johnston
Flag of United States of America image

EIGRP can use bandwidth, delay, load and reliability in building the cost of a path. By default, only bandwidth and delay are used.  If memory serves, the reliability K-value is K4. So to use bandwidth, delay and reliability use this command from the EIGRP router config mode:

metric weights 0 1 0 1 1 0 !(TOS, K1, K2, K3, K4, k5)

This will set bandwidth, delay and reliability  multiplier to 1. If you want reliability to have a greater impact, increase the K4 multiplier.

Avatar of JFrederick29
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I'd try to use cisco SLA monitoring.
This is from EE knowledge base. input from "wingatesl"
The configuration I posted was to get to a point where he could pull the plug and work from the other connection. Then we would put in !
! Define and start the IP SLA probe
ip sla 53
 timeout 500
 frequency 3
ip sla schedule 53 life forever start-time now
! Define an object that tracks the SLA probe
track 13 rtr 53 reachability
ip route 1 track 13
! This is the default route. It is REMOVED when the ping fails
Ip route 2
! This route is left behind and therefore becomes the default

The interface status makes no difference. The SLA is based off of reachability not link state. The T1 could remain up and have a failure a couple of hops down and the system will still fail over. In fact some of the solutions that we have installed have had a switch in between the ISPs and the router. If that ping fails the route is changed.  I wanted to focus on getting the NAT functional and tested before we move forward. Quoted from above "Once that is proven then we can go into the balancing of the connections"

P.S. You will need to redistribute static to EIGRP.