[c-nsp] Ethernet debugging...MTU?

[Andy Dills]

On Sat, 27 Oct 2007, Pekka Savola wrote:

> On Fri, 26 Oct 2007, Andy Dills wrote:
> > Cliff notes:
> > 
> > Is the inability to get ping replies with datagrams of larger than 9216
> > bytes across a 100mbps ethernet circuit an indication that the far end is
> > setup with an MTU consistent with jumbo frames?
> > 
> > What to do if the far end swears it's set for 1500?
> 
> (Note that 100mbit/s FE interfaces may also support jumbo frames so the fact
> that it's FE interfaces isn't a guarantee that it won't be using 9216 MTU.)
> 
> When you ping with 9216 bytes, most likely your router fragments the ping
> packets to multiple datagrams (maximum at 1500 bytes; verify this).  When the
> target responds, how are the response datagram(s) fragmented?  You should be
> able to figure out the path MTU by checking the largest size of the fragments
> received.
>
> You may need to ping from a unix host in order to more easily diagnose this
> issue (e.g., run tcpdump to see the fragment offsets).

When I start up a ping and trap the responses with tcpdump, I find that 
the responses are indeed fragmented at 1500 bytes. That said, I don't get 
any reply packets once the 9216 byte barrier is surpassed.

> Based on that you should be able to figure out what IP mtu the remote end is
> using.
> 
> If it's set to 1500 but ping (with > 9216) still fails the reason might have
> more to do with the fragmentation capabilities/policies of fragmenting devices
> (routers or the hosts at each end).

This appears to be the case. I'll focus on this. It's just so odd that the 
fragmentation problem occurs at the boundary size for jumbo packets.

The original reason I discovered this is, when we try to pass a couple of 
mbps across the link, we start getting significant packet loss...with no 
incrementing error counters anywhere on any layer. So I started trying 
different things and discovered the issue I mentioned in the email, as I 
have to assume once we resolve that issue the overall issue of packet loss 
will be fixed.

Thanks,
Andy

---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---