Date: Thu, 01 Oct 1998 12:22:44 +0930 From: Leigh Hart <hart@dotat.com> To: Mike Smith <mike@smith.net.au> Cc: freebsd-net@FreeBSD.ORG Subject: Re: 802.1Q VLAN support Message-ID: <199810010252.MAA17381@at.dotat.com> In-Reply-To: Your message of "Wed, 30 Sep 1998 18:05:10 MST." <199810010105.SAA04638@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Mike [:p]
Mike Smith <mike@smith.net.au> 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, <hart@dotat.com> |
| 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810010252.MAA17381>