[c-nsp] EIGRP potentially silly question...

[quinn snyder]

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.presse at 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-kell at 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 at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/