Re: [c-nsp] EIGRP reality check
Eigrp default metric = 256*(1000/path-minBW + sum(delays/10)) BW is in Kbps -so the formula does work for up to 10G links However when comparing 10G an 1G int on me3600 I see following delay sh int g0/2 .. DLY 10 usec, sh int te0/1 .. DLY 1000 usec Say what? Hahaha :) Do your interfaces have similar delay discrepancies please :) ? So in my case it would be: 1G: 256*(1000/100 + sum(delays/10)) = 256*(10+1) -best path 10G: 256*(1000/1000+ sum(delays/10))= 256*(1+100) adam ___ 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/
Re: [c-nsp] EIGRP reality check
On Monday, November 25, 2013 04:55:08 AM Jeff Kell wrote: 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. I'm guessing you meant unequal cost :-). Have you seen this: http://www.cisco.com/en/US/docs/routers/crs/software/crs_r4.3/routing/configuration/guide/b_routing_cg43xcrs_chapter_0101.html#concept_6F7168EEB2D343CCBA82BB223B311E7B I haven't tried it, so don't know if it actually does what it says on the tin. Anyone? Oli? Mark. signature.asc Description: This is a digitally signed message part. ___ 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/
Re: [c-nsp] EIGRP reality check
Actually, I would have entertained equal cost even without the unequal variance options, but the latter would be even better. To answer some other questions others have asked... back to the original diagram... +--A-\ | | \ | B---D | | / +--C-/ These are layer-2 paths. We have a rather unusual network topology that would take too long to explain without sounding like a raving lunatic :) Which still may be the case, but doesn't help :) There are three layer-3 backbone rings in play here... A-B-C-D is on one common /22 subnet. B-D-others are on another. And C-D-others are on a third. From the perspective of D there are three paths to B, each one layer-3 hop away (same /22 subnet). Each of the three somehow works out to equivalent EIGRP paths in topology... despite A-D and B-D being 10G and D-C and C-A being gigabit channels. This I suspect is due to not using wide EIGRP metrics. These are all Catalysts (6500 at A, various 3750 models at B-C-D) so nothing new and bleeding edge here. Jeff On 11/26/2013 10:10 PM, Mark Tinka wrote: On Monday, November 25, 2013 04:55:08 AM Jeff Kell wrote: 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. I'm guessing you meant unequal cost :-). Have you seen this: http://www.cisco.com/en/US/docs/routers/crs/software/crs_r4.3/routing/configuration/guide/b_routing_cg43xcrs_chapter_0101.html#concept_6F7168EEB2D343CCBA82BB223B311E7B I haven't tried it, so don't know if it actually does what it says on the tin. Anyone? Oli? Mark. ___ 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/
Re: [c-nsp] EIGRP reality check
On Wednesday, November 27, 2013 05:21:45 AM Jeff Kell wrote: These are all Catalysts (6500 at A, various 3750 models at B-C-D) so nothing new and bleeding edge here. I'll admit my EIGRP skills here suck a little; well, a lot, sorry :-). Maybe Gert or other Cisco EIGRP experts lurking can help. Mark. signature.asc Description: This is a digitally signed message part. ___ 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/
Re: [c-nsp] EIGRP reality check
Hi, On Sun, Nov 24, 2013 at 09:55:08PM -0500, Jeff Kell wrote: 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. It should not do that. Even if the bandwidth is equal, the interface delay should be added in, so the 1-hop path should be preferred. Could you show show ip eigrp topology prefix mask for a network sitting behind D? 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). In our deployment, we never had issues with 1G/10G links, so without looking up the specifics, I think that should still be fine - 40G/100G might have issues then. [..] So... has anyone been through at least the wide metrics adjustments for 10G? Or changed their K-values? Any shortcuts, war stories, suggestions, etc? We fiddle with delay on interfaces to force traffic away from certain paths (like, A-B-C and A-Z-C where the physical delay on the links to Z is much higher, so it really shouldn't go there to reach C), and in extreme cases we have fiddled with offset-list and such to make certain neighbours on a multiaccess network less preferred. But usually we just go with the defaults, which normally works fine. This is why I'm wondering whether show ip ei top would have some interesting output... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpgjIPQ910CA.pgp Description: PGP signature ___ 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/
[c-nsp] EIGRP reality check
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 cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
