| 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
| ||
|
Message-ID: <AANLkTimnKRDY8QLiJMMLqNzCA_-6UJmUDHKf-i1Yt3V5@mail.gmail.com> Date: Thu, 24 Mar 2011 13:58:19 +0100 From: Seblu <seblu@...lu.net> To: Jesse Gross <jesse@...ira.com> Cc: netdev <netdev@...r.kernel.org> Subject: Re: bnx2 vlan issue On Wed, Mar 23, 2011 at 12:19 AM, Jesse Gross <jesse@...ira.com> wrote: > 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. Speaking of that, i've tryed 2.6.38 on my station (dell opitplex 980) to use the new bridging schema and it doesn't work. Exactly the case previously described: ip on br0 (eth0+eth1) and ip on br0.42. eth0 driver is e1000e and eth1 is tg3. br0.42 don't receive traffic. I have to open a bug report? > 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. Agree it's going in the right direction, but it's sad that breaks basic network concept. Therefore hope in future versions. Regards, -- Sébastien Luttringer www.seblu.net -- 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