[c-nsp] EIGRP reality check

Gert Doering gert at greenie.muc.de
Mon Nov 25 03:44:22 EST 2013


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                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20131125/773508ce/attachment.sig>


More information about the cisco-nsp mailing list