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? Tom Taylor
You need to raise your MTU above that on the other side and do a ping size sweep. Unlike at Layer-3 when you can use set a DF bit and get back an ICMP error, at Layer-2 when you exceed the far side's MTU, the packets are silently dropped. Paul Vinciguerra CCIE# 10291 120 W Park Avenue, Suite 308 Long Beach, NY 11561 P: 516-977-2095 . F: 516-977-2482 . TF: 866-998-4624 vinciconsulting.com -----Original Message----- From: Tom Taylor [mailto:tom.taylor.stds@gmail.com] Sent: Friday, August 31, 2012 9:30 AM To: NANOG list Subject: MTU mismatch on one link 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? Tom Taylor
On Fri, Aug 31, 2012 at 01:52:09PM +0000, Paul Vinciguerra wrote:
You need to raise your MTU above that on the other side and do a ping size sweep. Unlike at Layer-3 when you can use set a DF bit and get back an ICMP error, at Layer-2 when you exceed the far side's MTU, the packets are silently dropped.
In the past, I've found a binary search on ping size to be very efficient. YMMV, of course. -- Mike Andrews, W5EGO mikea@mikea.ath.cx Tired old sysadmin
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
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... -----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
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. -- Dan White
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.
On Fri, 31 Aug 2012, 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.
Not really, but given the bursty nature of IP traffic, that's a very dubious assumption. In other words, you _can_ do it, but it's not a good idea, and can end up making lots of extra headaches for you/whoever supports this setup. jms
mturoute.exe works great http://www.elifulkerson.com/projects/mturoute.php On Fri, Aug 31, 2012 at 9:47 AM, Justin M. Streiner <streiner@cluebyfour.org
wrote:
On Fri, 31 Aug 2012, 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.
Not really, but given the bursty nature of IP traffic, that's a very dubious assumption.
In other words, you _can_ do it, but it's not a good idea, and can end up making lots of extra headaches for you/whoever supports this setup.
jms
Looks good. On 31/08/2012 11:13 AM, Ben Bartsch wrote:
mturoute.exe works great
...
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.
If you don't exceed the MTU ever then it shouldn't matter, but unless the MTUs are above what the protocol can handle on a specific link you probably will. Most commonly this happens on DSL links using PPPoE (the MTU needs to be at 1492 for the overhead) and it causes all kinds of odd behavior for clients. On 8/31/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.
-- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
On Fri, Aug 31, 2012 at 7:30 AM, Tom Taylor <tom.taylor.stds@gmail.com> 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?
Tom Taylor
I've seen several cases where BGP would not come back up after a link flap. In every case, this was when we had 7600 on one end and a CRS on the other and we had the MTU configured exactly the same on each side. The MTU value on the CRS should be 14 bytes higher than an IOS device because the XR device includes the Ethernet header size. Whenever I see a BGP session that does not come back up after a link flap, I immediate check MTU size on both sides. John
participants (10)
-
Andrew K. -
Ben Bartsch -
Blake Pfankuch -
Dan White -
John Neiberger -
Justin M. Streiner -
Mike A -
Paul Vinciguerra -
Scott Helms -
Tom Taylor