Home page logo

nanog logo nanog mailing list archives

RE: jumbo frames
From: RJ Atkinson <rja () inet org>
Date: Thu, 31 May 2001 17:40:50 -0400

At 16:47 31/05/01, Lane Patterson wrote:
I have been tracking jumbo frame support trends for a while, and
am reasonably disappointed by lack of standards and vendor willingness
to support jumbos (yes there are very REAL h/w design considerations, 
so until operators demand jumbo support and folks test it in realistic
environments, it's not going to happen).  

I believe most GigE switch vendors currently support ~9180 IP MTU
over GigE interfaces.  IEEE 802 committee has repeatedly and 
deliberately declined to make that an official standard however.

A number of the host vendors (e.g. Sun) appear to be listening
to customer requests for support of that IP MTU size also.

Unfortunately, many of the folks most adamant about maintaining 4470
in their core are therefore sticking with POS everywhere, so their 
requirement is not making it to the ether vendors.

        POS could be configured at various MTUs, right ?
        4470 is just a historical choice equal to FDDI, right ?
        Folks could engineer their POS links to use ~9180, I think,
        if they wanted to do so.

There are different reasons to use several different sizing parameters:

       "Mini-jumbo": say 1518, 1540, etc.  the idea here is that you
               can handle stacked tunnels and LAN encapsulations, such
               as stacked headers of 802.1Q, MPLS, IP/GRE tunnels, etc.
               while still preserving "1500 for the edge"

               Applicability:  802.1Q, VPN, MPLS, and other encap-based 
                       or tunnel-based applications

I believe at least 802.1q support is quite commonplace these days.

       "Mid-jumbo": say 4470: the idea is to make sure a backbone can
               preserve its MTU across both ethernet, ATM, and POS links
               within its diameter, and conceivably between networks via
               IX's that support jumbos.  This in fact may be critical
               for folks running large ISIS implementations that need 
               to ration # of LSPs:

        This number derives from FDDI MTU, which was formerly
commonly used as the basis for many an exchange point.


        I believe IEEE 802 committee officially opposes the above draft,
though I could be misinformed.

       "Real jumbo": not standardized, 

        Kindly see RFC-1626, which is where this number and
rationale came from.  The correct number, btw, is 9180 bytes 
as an IP MTU.

               but somewhere between 8100-9100B,...

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]