diff options
author | yar <yar@FreeBSD.org> | 2005-01-30 12:06:02 +0000 |
---|---|---|
committer | yar <yar@FreeBSD.org> | 2005-01-30 12:06:02 +0000 |
commit | fa9897222f299470930d7232f8adc143cc084074 (patch) | |
tree | 34b77c58bf0460db39324bafc8a1d63189e1b930 /share | |
parent | 458021ff80d5074ca60542b02faf09e75cd2f51c (diff) | |
download | FreeBSD-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.4 | 51 |
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 , |