On Sun, Jan 07, 2001 at 06:06:37PM +0000, Alan Cox wrote:
> > Um, what about people running their box as just a VLAN router/firewall?
> > That seems to be one of the principle uses so far. Actually, in that case
> > both VLAN and IP traffic would come through, so it would be a tie if VLAN
> > came first, but non-vlan traffic would suffer worse.
>
> Why would someone filter between vlans when any node on each vlan can happily
> ignore the vlan partitioning
VLANs are Level-2, that is SWITCHING.
They have no real meaning unless you have a switching fabric,
in which they present ways to hard-partition ports to different
switching domains without having physically separate cabling.
Normal hosts are connected on non-truncking ports, and only some
rare systems are connected to 802.1Q trunks so they can access
multiple VLANs inside the fabric.
No ordinary hosts are able to choose at which VLANs they are.
Truncking ports have ways to control which VLANs are allowed
to go thru them (at least at Cisco hardware I am familiar with).
> > So, how can I make sure that it is second in the list?
>
> Register vlan in the top level protocol hash then have that yank the header
> and feed the packets through the hash again.
That is what the two existing VLAN codes for Linux do now.
Better(?) way could be to have a way to have device specific
reception vector in addition to xmit vector. That way we could
stack "Layer-2 protocols", like 802.1Q and (to an extent) even
802 bridging.
See ftp://zmailer.org/linux/netif_rx.patch
After all, if you have a way to plumb reception to an optional
bridging layer, you propably would not need netif_rx() contained
bridging code.
> > > Question: How do devices with hardware vlan support fit into your model ?
> > I don't know of any, and I'm not sure how they would be supported.
>
> Several cards have vlan ability, but Matti reports they just lose the header
> not filter on it if I understood him
No you didn't understand.
Nothing is lost, it relates to hardware assisted received
IP frame TCP/UDP checksumming by the network cards. Some
cards support that, some support it even in presense of
802.1Q TAG header.
I don't yet see any cards which have hardware assist for
IPv6 checksumming. VLAN tags or not.
Reception must handle at first tearing off the VLAN header
when receiving the frame, then return back to netif_rx()
to see what was inside - SNAP frame, IPv4 frame, whatever.
/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jan 07 2001 - 21:00:30 EST