Hi, On Sun, Dec 21, 2014 at 08:38:00PM +1100, CiscoNSP List wrote: > > This hints at a MTU problem in your network, and the proper fix is to > > fix the MTU problem, not add config to the RR to work around it. > > > Thanks Gert - It's because we are purchasing inter-pop links from > other carriers(And there supported MTU's varies dramatically)...in > this instance our PE's "agreed" on 1900'odd MSS, but we were only > able to get ~1544.....On the links we control, it's all 9100.....and > we tweak as needed with carrier supplied links.
Yeah. Fun with providers with not clearly defined MTU on such a link
(we have one that changes MTU whenever they move between primary and
backup path... but the difference is much larger than "just 1 or 2
labels"...).
Even more important to actually ensure that the devices connected to that
link are configured with the correct MTU so everything else can rely
on maximum-sized packets to either go through, or get back an ICMP error
(and adjust).
What we do in our network: we ping (from a FreeBSD host) all devices that
sit behind "interesting" links with 10000 byte packets - knowing that the
packets will be fragmented on the way *to* the device, and same for the
response packets. If the MTU setting for a link is right, the fragments
will make it. If the router has a too-high IP MTU, the fragments will
get lost, and the monitoring system will tell us.
Somewhat of a hack, but works.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]
fax: +49-89-35655025 [email protected]
pgpp1tWmCI358.pgp
Description: PGP signature
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
