[ previous ] [ next ] [ threads ]
 
 From:  =?ISO-8859-1?Q?Thomas_Kolst=F8?= <thomas at kolsto dot no>
 To:  Adam Lawson <alawson at calhost dot com>, m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Ditching Cisco - Is m0n0wall router/firewall combo good for production use?
 Date:  Mon, 06 Jun 2005 16:53:16 +0200
Adam Lawson wrote:

>Is there a scenario where a NIC works with m0n0wall but does not support
>VLAN/802.11q? I tried using m0n0 last Friday night and the card sort of
>worked (some traffic passed) but all in all traffic was being stopped
>somewhere and I couldnt tell if it was the card or the configuration.
>
>I mean, I added an optional int just to test, added rules to 'pass * traffic
>from src * to dest *' on all int's and everyone who was simply subnetted saw
>in/out traffic. People on a VLAN didn't.
>
>Is there a special VLAN hardware compatability list different than those
>that just work generically without doing anything special?
>
>Adam
>
>  
>
 From the FreeBSD man page (man 4 vlan):

     " The vlan driver supports physical devices that do the VLAN 
demultiplexing
     in firmware.  The link0 flag should be set on a vlan interface (not on
     its parent) using ifconfig(8) in that case to indicate that 
hardware sup-
     port for the 802.1Q VLANs is present in its parent.

     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 FreeBSD are bge(4), em(4), 
gx(4),
     nge(4), ti(4), and txp(4).

     The rest of the ethernet NICs supported by FreeBSD can run VLANs using
     software emulation in the vlan 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
     vlan interfaces.  In the modern Internet, this is likely to cause 
tcp(4)
     connectivity problems due to massive, inadequate icmp(4) filtering that
     breaks the Path MTU Discovery mechanism.

     The NICs that support oversized frames are as follows:

           dc(4)   supports long frames for vlan natively.

           de(4)   requires defining BIG_PACKET in the
                   /usr/src/sys/pci/if_de.c source file and rebuilding the
                   kernel.  The hack works only for the 21041, 21140, and
                   21140A chips.

           fxp(4)  supports long frames for vlan natively.

           sis(4)  supports long frames for vlan natively.

           ste(4)  supports long frames for vlan natively.

           tl(4)   has support for long frames.

           tx(4)   supports long frames for vlan natively.

           xl(4)   supports long frames only if the card is built on a newer
                   chip (Cyclone and above).

     Note: Unless marked as having native support for vlan, the above 
drivers
     don't inform the vlan driver about their long frame handling 
capability.
     Just increase the MTU of a vlan interface if it appears to be lower 
than
     1500 bytes after attaching to a parent known to support long frames."

Personally I tend to opt for ti or em based cards if there is vlans 
involved -

Best regards,

- thomas at kolsto dot no