From owner-freebsd-net Wed Sep 30 19:51:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA24911 for freebsd-net-outgoing; Wed, 30 Sep 1998 19:51:36 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from at.dotat.com (zed.dotat.com [203.38.154.39]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA24893 for ; Wed, 30 Sep 1998 19:51:31 -0700 (PDT) (envelope-from hart@at.dotat.com) Received: from at.dotat.com (localhost.dotat.com [127.0.0.1]) by at.dotat.com (8.8.7/8.8.5) with ESMTP id MAA17381; Thu, 1 Oct 1998 12:22:46 +0930 (CST) Message-Id: <199810010252.MAA17381@at.dotat.com> To: Mike Smith cc: freebsd-net@FreeBSD.ORG Subject: Re: 802.1Q VLAN support In-reply-to: Your message of "Wed, 30 Sep 1998 18:05:10 MST." <199810010105.SAA04638@dingo.cdrom.com> Date: Thu, 01 Oct 1998 12:22:44 +0930 From: Leigh Hart Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Mike [:p] Mike Smith wrote: > > > I'm developing some single board computer applications that require > > 802.1Q vlan support (of the simplest kind) and in trawling through > > these list archives I found mention of if_vlan.c ...: > > 'pseudo-device vlan X' Ooer - Thanks :) > will get it into the kernel. However it seems that there's a missing > userland application required for the 'SIOC[GS]ETVLAN' ioctls. I can work that bit out easy enough once the code is in the kernel! > > PS - my work with 802.1Q has found that, despite the current draft > > spec suggesting that each vendor should decide on their own what > > to do about the problem of having a larger frame size due to the > > extra 4 byte VLAN header, most vendors have opted to support an > > increas by four bytes in the frame size... > > > > It should be noted that if FreeBSD is going to support this in > > any sensible manner, it should start including an option for > > changing ETHER_MAX_LEN in the kernel, either real time or at > > compile time... > > Ick. How does this impact hardware with frame size limitations? Some hardware can't physically cope with larger frame sizes, so you don't use that hardware - I've found SMC, NE2000 and some WD cards (ie: the ed driver set) have no problems supporting the larger frames (just by tweaking the value in the system includes and rebuilding the kernel, then using ifconfig to set a larger mtu) - but I havn't tried any others yet... Normally, if you try and set the MTU of an interface above 1500 using ifconfig, the ioctl (set mtu): will fail with "Invalid argument". The SIOCSIFMTU ioctl call which ifconfig uses eventually ends up in one place or another inside the driver code which does something not unlike this: /* * Set the interface MTU. */ if (ifr->ifr_mtu > ETHERMTU) { error = EINVAL; } else { ifp->if_mtu = ifr->ifr_mtu; } So regardless of hardware, it enforces ETHERMTU as the maximum possible MTU on any interface of any type. If you change ETHERMTU to reflect the fact you want an extra four bytes in the frame, certainly the SMC and NE2k's work - you can (a) set the MTU to 1504 using ifconfig, and (b) large packets do make it across the wire (eg: ping -s 2000 desthost splits into 1504 and 496 byte packets). > You'll need to differentiate between "how big a frame is allowed to be" > and "how big we will normally make a frame". The real problem with the draft dot1q standard is that they don't address this issue - they leave it up to the vendor to choose between growing the frame size by four bytes for the VLAN header and forcing a lower MTU for the network - to date, no switch vendors have chosen to do the latter because it isn't possible, practically, to force everyone to change their MTU before using this vendor's switch - would you do that?? The only other option is to fragment the frames across the trunk port (vlan tagged port) but *ouch* that hurts the throughput... > Diffs would be good. 8) Miffs are better ;] Cheers Leigh -- | "By the time they had diminished | Leigh Hart, | | from 50 to 8, the other dwarves | Dotat Communications Pty Ltd | | began to suspect 'Hungry' ..." | GPO Box 487 Adelaide SA 5001 | | -- Gary Larson, "The Far Side" | http://www.dotat.com/hart/ | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message