[155936] in North American Network Operators' Group
RE: MTU mismatch on one link
daemon@ATHENA.MIT.EDU (Blake Pfankuch)
Fri Aug 31 10:05:20 2012
From: Blake Pfankuch <blake@pfankuch.me>
To: "Justin M. Streiner" <streiner@cluebyfour.org>, NANOG list
<nanog@nanog.org>
Date: Fri, 31 Aug 2012 14:04:26 +0000
In-Reply-To: <Pine.LNX.4.64.1208310949520.1333@whammy.cluebyfour.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
I was actually typing an email about this as well when this one showed up. =
I ran into this with a customer about 2 weeks back with a single are ospf =
implementation. They had one of their routers configured at MTU 1492 and I=
completely spaced this. Lost about a half an hour of my life to this.
This Cisco article gives a good bit of information about it as well.
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f0=
d.shtml
-----Original Message-----
From: Justin M. Streiner [mailto:streiner@cluebyfour.org]=20
Sent: Friday, August 31, 2012 7:59 AM
To: NANOG list
Subject: Re: MTU mismatch on one link
On Fri, 31 Aug 2012, Tom Taylor wrote:
> Has anyone run into a situation where the MTU at one end of a link was=20
> configured differently from the MTU at the other end? How did you catch i=
t?
>=20
> In general, do you see any need for a debugging tool to be=20
> standardized to find such mismatches?
Some routing protocols (OSPF comes to mind) will complain loudly and genera=
lly refuse to come up if configured on a link with mismatched MTUs.
As far as a debugging tool, I don't know if one is specifically needed for =
that, but another thing to watch out for is in cases where you use somethin=
g like an Ethernet transport from a metro provider to get between two locat=
ions, make absolutely certain that you find out from the provider how the c=
ircuit is engineered, including what the MTU is for the link, and how they =
encapsulate your traffic to transport it across their network (MPLS, QinQ, =
etc).
jms
