summaryrefslogtreecommitdiffstats
path: root/share
diff options
context:
space:
mode:
authoryar <yar@FreeBSD.org>2005-01-30 12:06:02 +0000
committeryar <yar@FreeBSD.org>2005-01-30 12:06:02 +0000
commitfa9897222f299470930d7232f8adc143cc084074 (patch)
tree34b77c58bf0460db39324bafc8a1d63189e1b930 /share
parent458021ff80d5074ca60542b02faf09e75cd2f51c (diff)
downloadFreeBSD-src-fa9897222f299470930d7232f8adc143cc084074.zip
FreeBSD-src-fa9897222f299470930d7232f8adc143cc084074.tar.gz
Revise the part on VLAN support in physical interfaces.
MFC after: 1 week
Diffstat (limited to 'share')
-rw-r--r--share/man/man4/vlan.451
1 files changed, 32 insertions, 19 deletions
diff --git a/share/man/man4/vlan.4 b/share/man/man4/vlan.4
index ab9e8eb..2b311af 100644
--- a/share/man/man4/vlan.4
+++ b/share/man/man4/vlan.4
@@ -68,19 +68,28 @@ The parent interface is likely to be an Ethernet card connected
to a properly configured switch port.
The VLAN tag should match one of those set up in the switched
network.
-.Pp
+.Sh HARDWARE
The
.Nm
-driver supports physical devices that do
-the VLAN demultiplexing in firmware.
-Devices that have hardware support for
-802.1Q VLANs are automatically recognized by their interface capabilities.
-.\"
-.Ss "Selecting the Right Network Interface Card to Run VLANs Through"
-By now, the only NICs that have both hardware support and proper
-driver hooks for the 802.1Q VLAN technology in
-.Fx
-are
+driver supports efficient operation over parent interfaces that can provide
+help in processing VLANs.
+Such interfaces are automatically recognized by their capabilities.
+Depending on the level of sophistication found in a physical
+interface, it may do full VLAN processing or just be able to
+receive and transmit frames exceeding the maximum Ethernet frame size
+by the length of a 802.1Q header.
+The capabilities may be user-controlled by the respective parameters to
+.Xr ifconfig 8 ,
+.Cm vlanhwtag
+and
+.Cm vlanmtu .
+However, a physical interface is not obliged to react to them:
+It may have either capability enabled permanently without
+a way to turn it off.
+The whole issue is very specific to a particular device and its driver.
+.Pp
+By now, the list of physical interfaces able of full VLAN processing
+in the hardware is limited to the following devices:
.Xr bge 4 ,
.Xr em 4 ,
.Xr ixgb 4 ,
@@ -91,16 +100,15 @@ are
and
.Xr vge 4 .
.Pp
-The rest of the Ethernet NICs supported by
-.Fx
-can run
+The rest of the Ethernet interfaces can run
VLANs using software emulation in the
.Nm
driver.
However, most of them lack the capability
-of transmitting and/or receiving oversized frames.
-Using such a NIC as a parent interface
-implies a reduced MTU on the corresponding
+of transmitting and receiving oversized frames.
+Assigning such an interface as the parent to
+.Nm
+will result in a reduced MTU on the corresponding
.Nm
interfaces.
In the modern Internet, this is likely to cause
@@ -109,7 +117,7 @@ connectivity problems due to massive, inadequate
.Xr icmp 4
filtering that breaks the Path MTU Discovery mechanism.
.Pp
-The NICs that support oversized frames are as follows:
+The interfaces that support oversized frames are as follows:
.Bl -tag -width ".Xr fxp 4 " -offset indent
.It Xr bfe 4
supports long frames for
@@ -160,11 +168,16 @@ supports long frames only if the card is built on a newer chip
.Pp
The
.Nm
-driver automatically recognizes devices that support oversized frames
+driver automatically recognizes devices that natively support oversized frames
for
.Nm
use and calculates the appropriate frame MTU based on the
capabilities of the parent interface.
+The other interfaces listed above can handle oversized frames,
+but they do not advertise this ability of theirs.
+The MTU setting on
+.Nm
+can be corrected manually if used in conjunction with such parent interface.
.Sh SEE ALSO
.Xr kqueue 2 ,
.Xr miibus 4 ,
OpenPOWER on IntegriCloud