jumbo frames

Richard A. Steenbergen ras at e-gerbil.net
Fri Apr 27 20:38:05 UTC 2001


On Fri, 27 Apr 2001, John Fraizer wrote:

> On Fri, 27 Apr 2001, Richard A. Steenbergen wrote:
> 
> > 
> > On Fri, Apr 27, 2001 at 02:10:48PM -0500, Stephen Sprunk wrote:
> > >
> > > Or unless you actually have >1500 MTU to the hosts, which is quite
> > > possible.  A traffic study from MCI's backbone (obviously years ago)
> > > showed nearly 40% (byte-wise) of their traffic was in packets >1500
> > > bytes.  With the death of FDDI, this has probably come down, but
> > > GE-attached servers in colos should push it back up.
> > 
> > Probably not since GigE defaults to 1500 bytes and there is no agreed upon
> > standard for jumbo frames. Right now it doesn't make much sense to attempt
> > jumbo frames for packets headed outside of your administrative control,
> > because of PMTU-D problems.
> 
> Not trying to start flame-wars again but: If we didn't have weirdos
> using RFC1918 space on WAN links, the PMTU problem wouldn't be such a
> problem.

*groan* not again please... At any rate, there are any number of things
which break PMTU-D, for example boneheads who filter all ICMP including
needfrag.

It can even be more benign, for example networks which rate limit ICMP on
their borders thinking they are doing the "right thing". All it takes is
one smurf and that rate limit has effectively become a deny all ICMP.
Another example is that most routers don't support ICMP type and code
filtering granularity, which means if you think you are doing a good thing
by filtering or rate limiting ICMP Unreach (does anyone remember the days
of ICMP Unreach scans which attempted to reset established connections)
you've probably broken PMTU-D as well.

If you are pushing jumbo frames out to the internet and relying upon
PMTU-D to bring it back down to 1500 for ordinary ethernet users, you are
now DOWN for the majority of users who are not optimized. Noone wants to
deploy something like that on a wide scale, for packets heading outside of
their administrative control...

> If you're using anything beyond ethernet on your LAN/WAN, the
> likelihood is that you already have links with MTUs of 4470, etc.  I
> don't understand why people are treating GigE any different than any
> other layer2 media capable of MTU larger than 1500.  The fact that
> there is no standard "jumbo" size is moot.  You should verify like MTU
> on the ends of any link.  Am I mistaken?  Are there folks out there
> who are setting their ATM OC-3/12/48 links to 1500 MTUs?

The fact that it is not standardized is key, because it is very unlikely
to be deployed correctly on both ends (especially across a switched fabric
like a NAP) without extra human interaction and equiment which supports
the agreed upon minimium... Not even the big router vendors get it right
(ex: Cisco GSR 3-port gige linecards), so most people are not going to
deploy it outside of their administrative control.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)





More information about the NANOG mailing list