Yeah, what you're looking for is PfR
On Thu, Mar 6, 2014 at 12:53 AM, quinn snyder <snyd...@gmail.com> wrote: > something like pfr[0] may be useful in this instance, assuming the kit can > run it. > on newer kit, pfr-v2 is much less sucky than the pfr of old. > > q. > > [0] > http://docwiki.cisco.com/wiki/PfR:Solutions:BasicLoadBalancing#PfR_Features_that_Enable_Load_Balancing > > -= sent via ipad. please excuse brevity, spelling, and grammar =- > > > On Mar 5, 2014, at 22:14, Alex Pressé <alex.pre...@gmail.com> wrote: > > > > You could create a second EIGRP process with a value for K2 > > > > router eigrp 2 > > metric weights 0 1 1 1 0 0 > > > > Any identical routes in this second "new" instance of EIGRP will have a > > higher metric than the original EIGRP process. And thusly will NOT be > > installed in the routing table - provided they are *identical*. > > > > This would allow you to build out the entire second EIGRP process without > > it coming live uncontrolled. > > Then you could selectively remove networks from the original EIGRP (or > > manually increase them via offset lists). As they get removed from old > > EIGRP the new EIGRP routes would automatically take over. > > > > You're still left with the unfortunate part about the metric never > actually > > changing unless DUAL is triggered. And in my little bit of labbing this > > past hour it appears that just because one side updated the metric; the > > other side will *not* under certain circumstances.... So you can have two > > routers having different loading values for the same link(s). Resulting > in > > asymmetric flows. > > > > I bet somebody has made an EEM script to do "clear ip eigrp neighbors > soft" > > on an interval or interface loading thresholds. This would at least get > it > > to work "as intended". > > > > All in all; fucking ugly. I just use default K values and a variance > value > > of 2 with some simple offset lists or bandwidth statements. Much easier > to > > support and troubleshoot at 03:15 during a vacation. > > > > > >> On Wed, Mar 5, 2014 at 8:22 PM, Jeff Kell <jeff-k...@utc.edu> wrote: > >> > >> After a deployment of EIGRP with the intent of providing "link > >> utilization based load-sharing" as opposed to round robin, I get the > >> rude awakening that the default k-values for EIGRP do NOT include link > >> utilization. > >> > >> Any shortcuts / workarounds / etc to resetting k-values site-wide > >> without breaking each individual peering as the values are changed? > >> (EIGRP won't peer with mismatched k-values...) > >> > >> Jeff > >> > >> _______________________________________________ > >> cisco-nsp mailing list cisco-nsp@puck.nether.net > >> https://puck.nether.net/mailman/listinfo/cisco-nsp > >> archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > > > > > -- > > Alex Presse > > "How much net work could a network work if a network could net work?" > > _______________________________________________ > > cisco-nsp mailing list cisco-nsp@puck.nether.net > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > _______________________________________________ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/