[VLAN] dropping of un-matched tagged packets?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Dear James,

>>> What Ethernet adapter are you using (chipset or linux module name)?
>> The kernel module seems to be e1000
>> occ3-devb:~# dmesg | grep eth2
>> e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection
>> e1000: eth2: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex
>> My kernel version (in the case it would be needed) is
> I think what you want to do is create a bridge containing eth2 and
> whatever else, and then create vlans on the bridge, eg create a br0.200
> interface, and therefore never invoke the bridge logic on the e1000. The
> problem is, as was suspected earlier, that the e1000 contains hardware
> vlan acceleration which does indeed appear to filter out the vlans you
> don't care about.

Well, it's a bit more complicated... The idea is to bridge the physical
interface (eth2) with some tun devices (for example, tun0, tun1, etc.) that
are connected to interfaces inside a virtual machine running in the host
(using User Mode Linux,, maybe you
know about it) (tun0 to eth0 in virtual machine, tun1 to eth1 in virtual
machine, etc.) and to create the VLANs inside the virtual machine (eth0.200
in the virtual machine, eth1.300 in the virtual methince, etc.) not in the
bridge itself. Therefore, the bridge would have to switch trunk traffic
transparently, so this traffic reach the virtual machine and the virtual
machine kernel vlan interface can deal with the tagged packet (and deliver
it untagged to eth0.200, eth1.300 or whatever).

> Unfortunately, once you turn on vlanning on the physical e1000
> interface, the hardware acceleration will come into play and you won't
> see the ones you aren't subscribing to anyway.
> Assuming there isn't already a way and I just can't see it, in order to
> work around the above problem you'd need to:
> . patch the vlan kernel module to optionally not use hw acceleration
> even if it is available, via a parameter to one of the ioctls
> . patch the vconfig code to add a command line option to make use of the
> above option
> Ben would be the best one to comment on how useful the above might be. I
> could probably put a patch together, but you'd have to test it :)

Of course, I will do! :)

Although I know I'm trying a weird UML/VLAN/bridge application :), I think
such patch could be useful in general, due to it would increase the
flexibility of the VLAN support for people using cards with hw acceleration,
like me.

Best regards,

[Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Photo]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]     [Video 4 Linux]     [Linux Resources]

Powered by Linux