mirror/freebsd
1
0
Fork 0
mirror of https://git.FreeBSD.org/src.git synced 2024-12-24 11:29:10 +00:00
Code Issues Releases Activity

Revise the part on VLAN support in physical interfaces.

Browse Source 
MFC after:	1 week
This commit is contained in:
Yaroslav Tykhiy 2005-01-30 12:06:02 +00:00
parent ffc8a3046c
commit f41b145cf2
Notes: svn2git 2020-12-20 02:59:44 +00:00 
svn path=/head/; revision=141043
1 changed files with 32 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
share/man/man4/vlan.4
View File

@ -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 ,