We have been using EIGRP in the most recent generation of our campus network, a choice that was largely made on the fact that it could load-share across equal-cost paths, and take the path of "least resistance" to the target.
Recently we upgraded some core links to 10Gbps, with a couple remaining gig backup links across them. As a result, we ended up with a grouping: +--A-\ | | \ | B---D | | / +--C-/ A-B, A-D, and B-D are 10Gbps. A-C and C-D are multi 1G channels. "D" hosts our backup server, so we tried to optimize the data paths from A, B, and C. Making things a bit more non-standard, these are not point-to-points, they're on a small broadcast subnet. A-B, A-C, and A-D are one, B-C and C-D are another, and B-D is the third. >From B to D there are three routes... direct to D (10G), via A to D (10G), and via C to D (gig channel). And vice versa. EIGRP shows the three paths as equal weight (Catalyst 3750s and 6500s on current code) despite the bandwidth difference. Some early Googling indicates that newer EIGRP versions support "wide" metrics, to accomodate higher bandwidth link metrics, but I'm not sure if they are even supported on all our platforms and code versions (appears to be router-IOS 15.2 and higher). Further investigation into the EIGRP topology for these links indicates they come up with equal metrics, and they do NOT appear to be load sharing (always using the same path... and not the direct path in both cases, which lead to this investigation). Then I discover in the K-values lookups that the default K-values (1 0 1 0 0) don't include bandwidth as I originally thought... Aaargh... and changing K-values will drop all your adjacencies? So... has anyone been through at least the "wide metrics" adjustments for 10G? Or changed their K-values? Any shortcuts, war stories, suggestions, etc? Jeff _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
