1.\" $OpenBSD: vlan.4,v 1.40 2014/04/23 11:42:14 naddy 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: April 23 2014 $ 31.Dt VLAN 4 32.Os 33.Sh NAME 34.Nm vlan , 35.Nm svlan 36.Nd IEEE 802.1Q/1AD 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 a 802.1Q vlan tag added. 71802.1Q frames 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, comprising as follows: 7816 bits for the ether type (0x8100); 793 bits for the priority field; 801 bit for the canonical field (always 0); 81and 12 bits for the vlan identifier. 82The priority field may be altered via 83.Xr pf.conf 5 ; 84see the 85.Cm prio 86option for more information. 87Following the vlan header is the actual ether type for the frame and length 88information. 89.Pp 90For 91.Nm svlan 92devices, 93the configuration is identical to the 94.Nm 95interface, the only differences being that it uses a different Ethernet 96type (0x88a8) and an independent VLAN ID space on the parent 97interface. 98.Pp 99.Nm 100and 101.Nm svlan 102interfaces support the following unique 103.Xr ioctl 2 Ns s : 104.Bl -tag -width "SIOCSETVLAN" -offset 3n 105.It SIOCGETVLAN 106Get the vlan tag and parent for a given vlan interface. 107.It SIOCSETVLAN 108Set the vlan tag and parent for a given vlan interface. 109.El 110.Pp 111.Nm 112and 113.Nm svlan 114interfaces use the following interface capabilities: 115.Bl -tag -width "IFCAP_VLAN_HWTAGGING" -offset 3n 116.It IFCAP_VLAN_MTU 117The parent interface can handle full sized frames, plus the size 118of the vlan tag. 119.It IFCAP_VLAN_HWTAGGING 120The parent interface will participate in the tagging of frames. 121(This is not supported by 122.Nm svlan 123interfaces.) 124.El 125.Sh DIAGNOSTICS 126.Bl -diag 127.It "vlan0: initialized with non-standard mtu N (parent ...)" 128The IFCAP_VLAN_MTU capability was not set on the parent interface. 129We assume in this event that the parent interface is not capable of handling 130frames larger than its MTU. 131This will generally result in a non-compliant 802.1Q implementation. 132.Pp 133Some Ethernet chips will either discard or truncate 134Ethernet frames that are larger than 1514 bytes. 135This causes a problem as 802.1Q tagged frames can be up to 1518 bytes. 136Most controller chips can be told not to discard large frames 137and/or to increase the allowed frame size. 138Refer to the hardware manual for your chip to do this. 139.El 140.Pp 141If the IFCAP_VLAN_MTU capability is set on a vlan parent, 142.Nm 143assumes that the Ethernet chip on the parent can handle 144oversized frames. 145Either the chip allows 1518 byte frames by default (such as 146.Xr rl 4 ) , 147the driver has instructed the chip to do so (such as 148.Xr fxp 4 149and 150.Xr dc 4 ) , 151or the driver also takes advantage of a hardware tagging capability, 152and thus oversized frames are never actually sent by 153.Ox 154(such as 155.Xr txp 4 156and 157.Xr ti 4 ) . 158.Sh SEE ALSO 159.Xr bridge 4 , 160.Xr inet 4 , 161.Xr ip 4 , 162.Xr netintro 4 , 163.Xr hostname.if 5 , 164.Xr pf.conf 5 , 165.Xr ifconfig 8 , 166.Xr netstart 8 167.Rs 168.%T IEEE 802.1Q standard 169.%U http://standards.ieee.org/getieee802/802.1.html 170.Re 171.Rs 172.%Q Provider Bridges, QinQ 173.%T IEEE 802.1AD standard 174.Re 175.Sh AUTHORS 176Originally wollman@freebsd.org. 177