North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Strange public traceroutes return private RFC1918 addresses

  • From: Richard A Steenbergen
  • Date: Tue Feb 03 19:06:42 2004

On Tue, Feb 03, 2004 at 11:02:16AM -0500, Leo Bicknell wrote:
> While the rate of request is still very low, I would say we get
> more and more requests for jumbo frames everyday.  The pressing
> application today is "larger" frames; that is don't think two hosts
> talking 9000 MTU frames to each other, but rather think IPSec or
> other tunneling boxes talking 1600 byte packets to each other so
> they don't have to split 1500 byte Ethernet packets in half.  Since
> most POS is 4470, adding a jumbo frame GigE edge makes this application
> work much more efficiently, even if it doesn't enable jumbo (9k)
> frames end to end.  The interesting thing here is it means there 
> absolutely is a PMTU issue, a 9K edge with a 4470 core.

9k isn't an absolutely necessity, especially for x86. I believe the
original reason for 9k as picked by Alteon was to support the 8192 byte
page size on the Alpha. As long as there is enough to squeeze an x86
memory page (4096 bytes of payload) plus some room for headers, the
important goal of jumbo frames (which is NOT to lower the packet/sec
count, this is only a mild by-product for those who are still doing things
wrong) is achieved. This would also eliminate the problems of IPSec, GRE, 
and other forms of tunneling which may or may not be applied breaking 
things where PMTUD is blocked, since the "standard" payload packet for TCP 
would only be 4136 octets (leaving plenty for other "stuff").

The 4470 MTU of POS meets this requirement perfectly, and the world of end
to end connectivity would be an infinitely better place if everyone could
expect to pass 4470 through the Internet. But alas, there are probably too
many people people running GigE in the core which doesn't support jumbo
frames let alone a standardized size of jumbo frame, due to various vendor
hijinks to truly make use of POS's MTU these days.

Richard A Steenbergen <[email protected]>
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)