NAME
vlan
, svlan
— IEEE 802.1Q/1AD
encapsulation/decapsulation pseudo-device
SYNOPSIS
pseudo-device vlan
DESCRIPTION
The vlan
Ethernet interface allows
construction of virtual LANs when used in conjunction with IEEE
802.1Q-compliant Ethernet devices. The svlan
Ethernet interface allows construction of IEEE 802.1AD-compliant provider
bridges. It is normally used for QinQ to stack vlan
interfaces on top of it.
The interfaces can be created at runtime using the
ifconfig vlan
N
create
command or by setting up a
hostname.if(5) configuration file for
netstart(8). The interface itself can be configured with
ifconfig(8); see its manual page for more information.
For vlan
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 vlan
pseudo-interface.
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
pf.conf(5); see the prio
option for more
information. Following the vlan header is the actual ether type for the
frame and length information.
For svlan
devices, the configuration is
identical to the vlan
interface, the only
differences being that it uses a different Ethernet type (0x88a8) and an
independent VLAN ID space on the parent interface.
vlan
and svlan
interfaces support the following unique
ioctl(2)s:
- SIOCGETVLAN
- Get the vlan tag and parent for a given vlan interface.
- SIOCSETVLAN
- Set the vlan tag and parent for a given vlan interface.
vlan
and svlan
interfaces use the following interface capabilities:
- IFCAP_VLAN_MTU
- The parent interface can handle full sized frames, plus the size of the vlan tag.
- IFCAP_VLAN_HWTAGGING
- The parent interface will participate in the tagging of frames. (This is
not supported by
svlan
interfaces.)
DIAGNOSTICS
- vlan%d: initialized with non-standard mtu %d (parent %s)
- 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.
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.
If the IFCAP_VLAN_MTU capability is set on a vlan parent,
vlan
assumes that the Ethernet chip on the parent
can handle oversized frames. Either the chip allows 1518 byte frames by
default (such as rl(4)), the driver has instructed the chip to do so (such as
fxp(4) and dc(4)), or the driver also takes advantage of a hardware
tagging capability, and thus oversized frames are never actually sent by
OpenBSD (such as
txp(4) and ti(4)).
SEE ALSO
bridge(4), inet(4), ip(4), netintro(4), hostname.if(5), pf.conf(5), ifconfig(8), netstart(8)
IEEE 802.1Q standard, http://standards.ieee.org/getieee802/802.1.html.
IEEE 802.1AD standard, Provider Bridges, QinQ.
AUTHORS
Originally wollman@freebsd.org.
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.
When the IFCAP_VLAN_HWTAGGING capability is set on the parent
interface, vlan
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 OpenBSD. Thus,
bpf(4) will show untagged packets on the parent interface, although
frames are actually being transmitted with tags on the wire.