Home page logo

nanog logo nanog mailing list archives

Re: MTU mismatch on one link
From: Tom Taylor <tom.taylor.stds () gmail com>
Date: Fri, 31 Aug 2012 11:16:21 -0400

My question was actually prompted by an issue that comes up with multicast routing, where either the underlying RIB is static or the unicast routing protocol managed to operate successfully. In any event, in some cases the PIM messages get large enough to be lost at layer 2.

One proposal before the PIM Working Group was to negotiate MTU as part of the PIM Hello exchange, but this was considered overkill for a debugging-type problem. As some responses have pointed out, OSPF does at least detect the situation.

On 31/08/2012 10:42 AM, Andrew K. wrote:
Besides routing protocol convergence is there any service issues with
running mismatched MTU?  Assuming the packet flow does not exceed the
smallest MTU value.

On 8/31/2012 10:28 AM, Dan White wrote:
On 08/31/12 09:30 -0400, 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?

Performing a ping with a large packet size '-s', and/or with packet
fragmentation turned off '-M do' have been our primary tools for finding
MTU (layer 2 and layer 3) mismatches.

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]