Automate changing routes based on bandwidth

[dundient]

Good day, community.

I have a question about automate changing routes based on bandwidth.

For example, from R1's perspective we have 2 links to R2. On link#1 bandwidth usage is limited to 50mbps and link#2 is 100mbps. The main route is through link#1 and after some time, lets say, the link#1 is fully utilized. In this case, we want to automate routes through link#2. What technology we can use to reach automatic changing routes based on bandwidth utilization?

Thank you in advance  

[Joseph W. Doherty]

https://www.cisco.com/c/en/us/products/ios-nx-os-software/performance-routing-pfr/index.html

[Elliot Dierksen]

The metric in EIGRP is made up of bandwidth, delay, reliability, load, and MTU. The default K values normally exclude the use of reliability and load. In theory, the route preference for a link could change based on the load of a link if the K values are changed to include load.

Full disclaimer: I have never done this in a real network.

[Joseph W. Doherty]

EDIT

NB: Rick's later reply states K2 is only used when adding (possibly also updating) a route to the route table.  As long as an interface load change doesn't initiate a routing update, my concern for EIGRP route churn, below, is a non-existent issue.

END-EDIT

True, and I've also never used that feature.  Two problems, though.

First, I believe it's supposed to try to maintain a proportional loading, while OP desires secondary path only gets traffic when primary is fully utilized.  (Again, a feature I believe PfR supports.)

Second, I recall reading EIGRP will create much route churn, as by redirecting flows, load ratios change which causes EIGRP to move the same flows again.  (BTW, this would also be an issue for PfR which it tries to avoid by deeper analysis whether flows should be rerouted, and by "waiting" to analyze results of a flow migrations.  [Having watched PfR in action, there is a noticable delay in its LBing.  It appears to accomplish LBing across minutes, not seconds]).

Also BTW, I also recall, many years ago) one of the founding Hall of Fame members (a former Cisco project manager, I also recall) was adamant NOT to even use EIGRP's unequal multi path capability as it was very resource usage intensive.  (I have not verified this, back then, or now.)

[Richard Burts]

Interesting suggestion to change K values to use load in the path selection. It is my experience that this is done when the route is added to the routing table. Once the route parameters have been calculated load is not re-evaluated. So the load could increase but path selection would not change. So it would not accomplish what the OP desires.

[Joseph W. Doherty]

From some quick research, it appears K2 may be "constantly" being updated but changes to it, alone, do NOT trigger routing updates.  However, a routing update might incorporate a recalculated K2.

Not much to be found on this, but did find: https://learningnetwork.cisco.com/s/question/0D53i00000Kt6rFCAR/eigrp-loadreliability-metric-components.  Possibly behavior has changed between IGRP and EIGRP.

If K2 was never updated, beyond initially adding a route, it wouldn't be very useful.  Limiting it to only be revised when there's a topology change, is somewhat an improvement, or possibly not, as eventually you'll be routing on stale load info.  (Of course, not having load trigger its own route updates avoids route churn.)

 I do wonder whether K2 might have some effect on the router's own interfaces.

I agree with Rick, without it being more dynamic, it may be pretty much useless, at least across multiple routers.