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_note09186a0080093f0d.shtml -----Original Message----- From: Justin M. Streiner [mailto:strei...@cluebyfour.org] 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 > configured differently from the MTU at the other end? How did you catch it? > > In general, do you see any need for a debugging tool to be > standardized to find such mismatches? Some routing protocols (OSPF comes to mind) will complain loudly and generally 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 something like an Ethernet transport from a metro provider to get between two locations, make absolutely certain that you find out from the provider how the circuit 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
