Re: [RAM] Tunnelling & GigE jumbo frame size

Iljitsch van Beijnum <> Wed, 12 September 2007 16:43 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IVVJU-0000CO-PK; Wed, 12 Sep 2007 12:43:40 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1IVVJT-00005T-R4 for; Wed, 12 Sep 2007 12:43:39 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1IVVJS-0004AV-Aq for; Wed, 12 Sep 2007 12:43:39 -0400
Received: from [] ( []) (authenticated bits=0) by (8.13.3/8.13.3) with ESMTP id l8CGdaJX036676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Sep 2007 18:39:36 +0200 (CEST) (envelope-from
In-Reply-To: <>
References: <>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <>
Content-Transfer-Encoding: 7bit
From: Iljitsch van Beijnum <>
Subject: Re: [RAM] Tunnelling & GigE jumbo frame size
Date: Wed, 12 Sep 2007 18:42:06 +0200
To: RJ Atkinson <>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

On 12-sep-2007, at 16:24, RJ Atkinson wrote:

> Dino's notes all sound correct, with one exception.

I'd like to support Pekka's point about internet exchanges, though.

> The exception is a detail and does not alter his main point,
> which is that by using Jumbo Ethernet, tunnelling
> of 1518 byte Ethernet frames ought not create any
> fragmentation issues.  However, just to be crystal clear
> to anyone who isn't tracking Ethernet closely, here
> is the summary analysis.

Please note that ethernet frame size / MTU may or may not include the  
Ethernet_II header (which doesn't conform to IEEE 802.3) and if it  
does, it may or may not include the frame check sequence. I'll use  
the IP MTU excluding ethernet headers unless otherwise specified.

> Correction:
> 	Just as "4K" MTU really means 4470 bytes, Jumbo Ethernet
> 	sizes of "9K" really mean an IP MTU of 9180 bytes.  This
> 	means the link MTU for Jumbo Ethernet is really:
>            (9180 + sizeof(Ethernet header) + sizeof(VLAN tag))

I think most people take it to mean 9000 bytes. This is the only real  
jumboframe IP MTU size I've seen implemented in hosts. However,  
routers and especially switches come with many different maximum  
frame sizes. I've looked over some product literature and compiled  
the following list: 1508, 1530, 1536, 1546, 1998, 2000, 2018, 4464,  
4470, 8092, 8192, 9000, 9176, 9180, 9216, 17976, 64000 and 65280.

> Caveats:
> 	Jumbo Ethernet is explicitly not conformant to IEEE 802.3
> 	standards.  So all implementations that I'm aware of have
> 	a default MTU (i.e. out of the box) that is IEEE 802.3
> 	compliant.  Normally, users must explicitly configure the
> 	larger MTU size on each interface before it is enabled.

> 	1 GigE standards permit deployment with CSMA/CD, although
> 	I am not personally aware of any such deployments.  A GigE
> 	CSMA/CD deployment is likely not to work properly with
> 	an Ethernet frame size above that permitted by IEEE 802.3
> 	standards.  Switched Ethernet should be fine, however,
> 	and all actual 1 GigE deployments that I am aware of are
> 	switched and do not use CSMA/CD.

When gigabit ethernet was introduced the _minimum_ frame size (not IP  
MTU size) was (sort of) increased from 64 to 512 bytes when using  
CSMA/CD to make sure a frame would fill the entire collision domain  
even at the faster bit rate. However, the _maximum_ frame size was  
never increased because it would break old stuff. Lots of gigabit  
ethernet equipment supports larger frames, but few 10 or 100 Mbps  
implementations do. So having a larger frame size for GigE would make  
interoperation with older ethernet equipment a problem.

Although the issue comes up in the IEEE 802.3 working group every few  
years, no progress has been made here because the IEEE protocols  
simply don't have the hooks that make maximum frame size negotiation  
between ethernet systems possible. However, this is much easier at  
the IP level (especially IPv6), so I'm proposing that the IETF pick  
up the slack. See the discussion about my multi-mtu draft on the  
internet area list:

RAM mailing list