1.\" $OpenBSD: vlan.4,v 1.34 2011/11/27 19:55:18 haesbaert Exp $ 2.\" 3.\" Copyright (c) 2000 The NetBSD Foundation, Inc. 4.\" All rights reserved. 5.\" 6.\" This code is derived from software contributed to The NetBSD Foundation 7.\" by Jason R. Thorpe of Zembu Labs, Inc. 8.\" 9.\" Redistribution and use in source and binary forms, with or without 10.\" modification, are permitted provided that the following conditions 11.\" are met: 12.\" 1. Redistributions of source code must retain the above copyright 13.\" notice, this list of conditions and the following disclaimer. 14.\" 2. Redistributions in binary form must reproduce the above copyright 15.\" notice, this list of conditions and the following disclaimer in the 16.\" documentation and/or other materials provided with the distribution. 17.\" 18.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS 19.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED 20.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 21.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS 22.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 23.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF 24.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 25.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN 26.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 27.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 28.\" POSSIBILITY OF SUCH DAMAGE. 29.\" 30.Dd $Mdocdate: November 27 2011 $ 31.Dt VLAN 4 32.Os 33.Sh NAME 34.Nm vlan , 35.Nm svlan 36.Nd IEEE 802.1Q/1AD encapsulation/decapsulation pseudo-device 37.Sh SYNOPSIS 38.Cd "pseudo-device vlan" 39.Sh DESCRIPTION 40The 41.Nm 42Ethernet interface allows construction of virtual LANs when used in 43conjunction with IEEE 802.1Q-compliant Ethernet devices. 44The 45.Nm svlan 46Ethernet interface allows construction of IEEE 802.1AD-compliant 47provider bridges. 48It is normally used for QinQ to stack 49.Nm 50interfaces on top of it. 51.Pp 52The interfaces can be created at runtime using the 53.Ic ifconfig vlan Ns Ar N Ic create 54command or by setting up a 55.Xr hostname.if 5 56configuration file for 57.Xr netstart 8 . 58The interface itself can be configured with 59.Xr ifconfig 8 ; 60see its manual page for more information. 61.Pp 62For 63.Nm 64devices, 65the 802.1Q header specifies the virtual LAN number, and thus allows an 66Ethernet switch (or other 802.1Q compliant network devices) to be aware of 67which LAN the frame is part of, and in the case of a switch, which 68port(s) the frame can go to. 69Frames transmitted through the vlan interface will be diverted to the specified 70physical interface with 802.1Q vlan encapsulation. 71Frames with 802.1Q encapsulation received by the parent interface with the 72correct vlan tag will be diverted to the associated 73.Nm 74pseudo-interface. 75.Pp 76Frame headers which normally contain the destination host, source host, and 77protocol, are altered with additional information. 78After the source host, 79a 32-bit 802.1Q header is included, 80comprising as follows: 8116 bits for the ether type (0x8100); 823 bits for the priority field; 831 bit for the canonical field (always 0); 84and 12 bits for the vlan identifier. 85The priority field may be altered via 86.Xr pf.conf 5 ; 87see the 88.Cm prio 89option for more information. 90Following the vlan header is the actual ether type for the frame and length 91information. 92.Pp 93For 94.Nm svlan 95devices, 96the configuration is identical to the 97.Nm 98interface, the only differences being that it uses a different Ethernet 99type (0x88a8) and an independent VLAN ID space on the parent 100interface. 101.Pp 102.Nm 103and 104.Nm svlan 105interfaces support the following unique 106.Xr ioctl 2 Ns s : 107.Bl -tag -width "SIOCSETVLAN" -offset 3n 108.It SIOCGETVLAN 109Get the vlan tag and parent for a given vlan interface. 110.It SIOCSETVLAN 111Set the vlan tag and parent for a given vlan interface. 112.El 113.Pp 114.Nm 115and 116.Nm svlan 117interfaces use the following interface capabilities: 118.Bl -tag -width "IFCAP_VLAN_HWTAGGING" -offset 3n 119.It IFCAP_VLAN_MTU 120The parent interface can handle full sized frames, plus the size 121of the vlan tag. 122.It IFCAP_VLAN_HWTAGGING 123The parent interface will participate in the tagging of frames. 124(This is not supported by 125.Nm svlan 126interfaces.) 127.El 128.Sh DIAGNOSTICS 129.Bl -diag 130.It "vlan%d: initialized with non-standard mtu %d (parent %s)" 131The IFCAP_VLAN_MTU capability was not set on the parent interface. 132We assume in this event that the parent interface is not capable of handling 133frames larger than its MTU. 134This will generally result in a non-compliant 802.1Q implementation. 135.Pp 136Some Ethernet chips will either discard or truncate 137Ethernet frames that are larger than 1514 bytes. 138This causes a problem as 802.1Q tagged frames can be up to 1518 bytes. 139Most controller chips can be told not to discard large frames 140and/or to increase the allowed frame size. 141Refer to the hardware manual for your chip to do this. 142.El 143.Pp 144If the IFCAP_VLAN_MTU capability is set on a vlan parent, 145.Nm 146assumes that the Ethernet chip on the parent can handle 147oversized frames. 148Either the chip allows 1518 byte frames by default (such as 149.Xr rl 4 ) , 150the driver has instructed the chip to do so (such as 151.Xr fxp 4 152and 153.Xr dc 4 ) , 154or the driver also takes advantage of a hardware tagging capability, 155and thus oversized frames are never actually sent by 156.Ox 157(such as 158.Xr txp 4 159and 160.Xr ti 4 ) . 161.Sh SEE ALSO 162.Xr bridge 4 , 163.Xr inet 4 , 164.Xr ip 4 , 165.Xr netintro 4 , 166.Xr hostname.if 5 , 167.Xr pf.conf 5 , 168.Xr ifconfig 8 , 169.Xr netstart 8 170.Rs 171.%T IEEE 802.1Q standard 172.%O http://standards.ieee.org/getieee802/802.1.html 173.Re 174.Rs 175.%T IEEE 802.1AD standard 176.%O Provider Bridges, QinQ 177.Re 178.Sh AUTHORS 179Originally wollman@freebsd.org. 180.Sh BUGS 181The 802.1Q specification allows for operation over FDDI and Token Ring 182as well as Ethernet. 183This driver only supports such operation with Ethernet devices. 184.Pp 185When the IFCAP_VLAN_HWTAGGING capability is set on the parent interface, 186.Nm 187does not participate in the actual tagging of Ethernet frames. 188It simply passes the vlan ID on to the parent interface for tagging on transmit. 189The vlan tagged packet is not actually visible to 190.Ox . 191Thus, 192.Xr bpf 4 193will show untagged packets on the parent interface, although frames 194are actually being transmitted with tags on the wire. 195