Home page logo
/

nanog logo nanog mailing list archives

RE: MTU mismatch on one link
From: Blake Pfankuch <blake () pfankuch me>
Date: Fri, 31 Aug 2012 14:04:26 +0000

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:streiner () 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



  By Date           By Thread  

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