From: ibuprofin@painkiller.example.tld.invalid   
      
   On Wed, 12 Jun 2013, in the Usenet newsgroup comp.protocols.tcp-ip, in article   
   , Rick Jones wrote:   
      
   >Moe Trin  wrote:   
      
   >>>   All stations in the same broadcast domain MUST have the same MTU.   
      
   >> Wrong   
      
   >Are we arguing about my conflating MTU and frame size together?   
      
   Perhaps - normally I don't see a (software) knob to diddle with level   
   2 packet lengths, much less a level 2 variable called MTU.  But as   
   mentioned, mucking with the (level 3) MTU is quite common - because of   
   tunneling for example.   
      
   >> Rick, what are you smoking?   Can I get some?   ;-)   
      
   >JumboFrames I suspect.   
      
   My doctor says they're fattening and tells me to avoid them.   Yes, I   
   can see what you're referring to in that regard.   
      
   >Starting point - two systems, back-to-back cable 1500 byte MTU at both   
   >ends:   
      
   Looks fine   
      
   >Now up the MTU on the sender to 9000 bytes:   
      
   Don't have GigE here (I'm assuming this be the case), and at work   
   where we did, we left the MTU at 1500 to avoid some confusion as some   
   systems were 100BaseT on slower ports off the network switches,  It   
   says here that's costing efficiency, but it wasn't that big of a deal   
   considering that those were slower systems anyway.   
      
   >As it happens, ethtool -S eth0 on the destination shows   
   >"rx_long_length_errors: 2" and that incremented to 4 when I ran the   
   >ping test again.   
      
   You said they're back-to-back, so the only thing I can think of is this   
   is a artifact of the receiving system not being aware that jumbos were   
   in use.   I don't know.   
      
   >Now, perhaps in your situation when you shrank the MTU to < 1500   
   >bytes, the ethernet controller and NIC were still willing to take-in a   
   >frame larger and IP accept it.   
      
   That's part of what I meant in my reply to Jorgen (via Barry) by O/S   
   dependent.  A quick scan through RFC1122 doesn't find it, but I recall   
   a bit where the a minimum "maximum" packet is 576 bytes, but I think   
   most Ethernet stacks are built to expect 1500 or so.  For that matter,   
   the MTU on the loopback is 16436 on my Linux boxes.   
      
   >In my setup, I have reset my sender to a 1500 byte MTU, and then set   
   >the MTU to 1280 on my receiver.  In that case the 8000 byte ping   
   >still worked, but I am not sure it would be good to rely on that.   
      
   The reason the 8k ping works is that the stack is fragmenting it, as   
   shown by all those extra packets in the tcpdump.  The "transmitting"   
   system is sending at it's MTU, and the "receiving" system is accepting   
   that - possibly up to the nominal 1500 or so bytes.  What might be   
   interesting to try is beeping up the MTU to something like 1550 or so,   
   rather than the giant leap to 9k.   
      
   >I could see, and have some vague recollections about, systems whereon   
   >if one dropped the MTU/frame size below 1500 bytes, it would not   
   >accept packets above the new MTU and still below 1500.   
      
   Might this be related to PMTU black-holes?   There's certainly plenty   
   of evidence for that with PPPo? where the user is also running a   
   firewall blocking those ICMP Type 3 Code 4 mal-ware packets rather   
   than relying on RFC3514.   
      
           Old guy   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)