.\" $OpenBSD: vlan.4,v 1.37 2013/06/02 20:23:34 tedu Exp $
.\"
.\" Copyright (c) 2000 The NetBSD Foundation, Inc.
.\" All rights reserved.
.\"
.\" This code is derived from software contributed to The NetBSD Foundation
.\" by Jason R. Thorpe of Zembu Labs, Inc.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
.\" PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
.\" POSSIBILITY OF SUCH DAMAGE.
.\"
.Dd $Mdocdate: June 2 2013 $
.Dt VLAN 4
.Os
.Sh NAME
.Nm vlan ,
.Nm svlan
.Nd IEEE 802.1Q/1AD encapsulation/decapsulation pseudo-device
.Sh SYNOPSIS
.Cd "pseudo-device vlan"
.Sh DESCRIPTION
The
.Nm
Ethernet interface allows construction of virtual LANs when used in
conjunction with IEEE 802.1Q-compliant Ethernet devices.
The
.Nm svlan
Ethernet interface allows construction of IEEE 802.1AD-compliant
provider bridges.
It is normally used for QinQ to stack
.Nm
interfaces on top of it.
.Pp
The interfaces can be created at runtime using the
.Ic ifconfig vlan Ns Ar N Ic create
command or by setting up a
.Xr hostname.if 5
configuration file for
.Xr netstart 8 .
The interface itself can be configured with
.Xr ifconfig 8 ;
see its manual page for more information.
.Pp
For
.Nm
devices,
the 802.1Q header specifies the virtual LAN number, and thus allows an
Ethernet switch (or other 802.1Q compliant network devices) to be aware of
which LAN the frame is part of, and in the case of a switch, which
port(s) the frame can go to.
Frames transmitted through the vlan interface will be diverted to the specified
physical interface with 802.1Q vlan encapsulation.
Frames with 802.1Q encapsulation received by the parent interface with the
correct vlan tag will be diverted to the associated
.Nm
pseudo-interface.
.Pp
Frame headers which normally contain the destination host, source host, and
protocol, are altered with additional information.
After the source host,
a 32-bit 802.1Q header is included,
comprising as follows:
16 bits for the ether type (0x8100);
3 bits for the priority field;
1 bit for the canonical field (always 0);
and 12 bits for the vlan identifier.
The priority field may be altered via
.Xr pf.conf 5 ;
see the
.Cm prio
option for more information.
Following the vlan header is the actual ether type for the frame and length
information.
.Pp
For
.Nm svlan
devices,
the configuration is identical to the
.Nm
interface, the only differences being that it uses a different Ethernet
type (0x88a8) and an independent VLAN ID space on the parent
interface.
.Pp
.Nm
and
.Nm svlan
interfaces support the following unique
.Xr ioctl 2 Ns s :
.Bl -tag -width "SIOCSETVLAN" -offset 3n
.It SIOCGETVLAN
Get the vlan tag and parent for a given vlan interface.
.It SIOCSETVLAN
Set the vlan tag and parent for a given vlan interface.
.El
.Pp
.Nm
and
.Nm svlan
interfaces use the following interface capabilities:
.Bl -tag -width "IFCAP_VLAN_HWTAGGING" -offset 3n
.It IFCAP_VLAN_MTU
The parent interface can handle full sized frames, plus the size
of the vlan tag.
.It IFCAP_VLAN_HWTAGGING
The parent interface will participate in the tagging of frames.
(This is not supported by
.Nm svlan
interfaces.)
.El
.Sh DIAGNOSTICS
.Bl -diag
.It "vlan0: initialized with non-standard mtu N (parent ...)"
The IFCAP_VLAN_MTU capability was not set on the parent interface.
We assume in this event that the parent interface is not capable of handling
frames larger than its MTU.
This will generally result in a non-compliant 802.1Q implementation.
.Pp
Some Ethernet chips will either discard or truncate
Ethernet frames that are larger than 1514 bytes.
This causes a problem as 802.1Q tagged frames can be up to 1518 bytes.
Most controller chips can be told not to discard large frames
and/or to increase the allowed frame size.
Refer to the hardware manual for your chip to do this.
.El
.Pp
If the IFCAP_VLAN_MTU capability is set on a vlan parent,
.Nm
assumes that the Ethernet chip on the parent can handle
oversized frames.
Either the chip allows 1518 byte frames by default (such as
.Xr rl 4 ) ,
the driver has instructed the chip to do so (such as
.Xr fxp 4
and
.Xr dc 4 ) ,
or the driver also takes advantage of a hardware tagging capability,
and thus oversized frames are never actually sent by
.Ox
(such as
.Xr txp 4
and
.Xr ti 4 ) .
.Sh SEE ALSO
.Xr bridge 4 ,
.Xr inet 4 ,
.Xr ip 4 ,
.Xr netintro 4 ,
.Xr hostname.if 5 ,
.Xr pf.conf 5 ,
.Xr ifconfig 8 ,
.Xr netstart 8
.Rs
.%T IEEE 802.1Q standard
.%U http://standards.ieee.org/getieee802/802.1.html
.Re
.Rs
.%Q Provider Bridges, QinQ
.%T IEEE 802.1AD standard
.Re
.Sh AUTHORS
Originally wollman@freebsd.org.
.Sh BUGS
The 802.1Q specification allows for operation over FDDI and Token Ring
as well as Ethernet.
This driver only supports such operation with Ethernet devices.
.Pp
When the IFCAP_VLAN_HWTAGGING capability is set on the parent interface,
.Nm
does not participate in the actual tagging of Ethernet frames.
It simply passes the vlan ID on to the parent interface for tagging on transmit.
The vlan tagged packet is not actually visible to
.Ox .
Thus,
.Xr bpf 4
will show untagged packets on the parent interface, although frames
are actually being transmitted with tags on the wire.