lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 22 Mar 2011 16:19:03 -0700
From:	Jesse Gross <jesse@...ira.com>
To:	Seblu <seblu@...lu.net>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: bnx2 vlan issue

On Tue, Mar 22, 2011 at 3:59 AM, Seblu <seblu@...lu.net> wrote:
> On Tue, Mar 22, 2011 at 3:05 AM, Jesse Gross <jesse@...ira.com> wrote:
>> On Thu, Mar 17, 2011 at 4:22 PM, Seblu <seblu@...lu.net> wrote:
>>> On Thu, Mar 17, 2011 at 8:16 PM, Jesse Gross <jesse@...ira.com> wrote:
>>>> On Thu, Mar 17, 2011 at 11:02 AM, Seblu <seblu@...lu.net> wrote:
>>>>> On Thu, Mar 17, 2011 at 3:51 PM, Seblu <seblu@...lu.net> wrote:
>>> How can I create a bridge with the untagged vlan from an interface?
>>>
>>>> * bridge on interface, vlans on bridge device.  This gives you a
>>>> bridge with all packets and vlan devices can give you specific vlans.
>>> I cannot use this schema, i used bridge to bring together vnet
>>> interface and vlan interface.
>>
>> I'm not sure I understand why you say you can't use this.  You can
>> combine vlans and bridging pretty much arbitrarily, including stacking
>> multiple layers.
> I don't see _how I can bridge an interface with an untagged vlan from
> another interface_.
>
> I little example is maybe more clear:
> My dekstop have 2 NIC (eth0, eth1). I receive from network admin 2
> vlans. 20 untag and 21 tagged. My laptop is plugged to eth1.
> I want "export" untagged vlan 20 to eth1.
> Before 2.6.37, i do something like br0 = (eth0 + eth1). I put an ip on
> br0 and on eth0.21. And br0 just have untagged frame from eth0 which
> was transmitted to eth1. eth0.21 have only tagged frame from vlan 21.
> eth1 did not receive tagged vlan 21.
> After 2.6.37, i can do a bridge like before (br0 = eth0 + eth1) but i
> must use br0.21 to have access to vlan 21 network in my desktop. But,
> my laptop can also access to tagged vlan 21, and i don't want this.
>
> A lot of old xen based setup use this behaviour.
> About my kvm test, I'm looking to the pci passtrough and macvtap, but
> this requires configuration that supports it.
> Why cannot have a eth0.U with only untagged frames?
>
>>
>>>
>>>> * Use ebtables rules in the bridge to accept/reject certain packets as desired.
>>> I don't see how use ebtables to push untagged frame to a dedicated
>>> iface which can be added in a bridge.
>>
>> You could have a bridge on the raw interface and connect all of the
>> VMs that need untagged traffic.  If you add an ebtables rule to reject
>> tagged traffic then vlan devices on the interface will continue to
>> work as before.
>>
> If I ignores the fact that the name of the card is not fixed, i see.
> But performance will follow? I don't believe this kind of config will
> allow ~7/8Gbit/s of traffic.
> Traversing ebtables rules is not free. And starting filtering traffic
> is a really different job than just bridge cards together.

I don't necessarily disagree that there should be a better way to do
this, though as of the moment the above is probably your best bet.

To me, the most important thing is to have consistent behavior across
different cards.  In 2.6.37 that behavior was standardized on the way
non-accelerated NICs used to do but the other way is more common and
perhaps better.  Eric B. posted a patch yesterday that better unifies
the code paths.  This would be the first step to such a change because
it would make it easier to move the handling logic for both at the
same time.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ