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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 30 Apr 2014 14:50:46 -0400 From: Vlad Yasevich <vyasevic@...hat.com> To: Stephen Hemminger <stephen@...workplumber.org> CC: netdev@...r.kernel.org, bridge@...ts.linux-foundation.org, shemminger@...tta.com, jhs@...atatu.com, john.r.fastabend@...el.com, mst@...hat.com Subject: Re: [RFC PATCH v2 net-next 0/7] Non-promisc bidge ports support On 04/30/2014 01:22 PM, Stephen Hemminger wrote: > On Tue, 29 Apr 2014 17:20:21 -0400 > Vlad Yasevich <vyasevic@...hat.com> wrote: > >> This patch series is a re-implementation of prior attempts to support >> non-promiscuous bridge ports. >> >> The basic concept is the same as before. The bridge keeps >> track of the ports that support learning and flooding packets >> to unknown destinations. We call these ports auto-discovery >> ports since they automatically discover who is behind them through >> learning and flooding. >> >> If flooding and learning are disabled via flags, then the port >> requires static configuration to tell it which mac addresses >> are behind it. This is accomplished through adding of fdbs. >> These fdbs should be static as dynamic fdbs can expire and systems >> will become unreachable due to lack of flooding. >> >> If the user marks all ports are needing static configuration then >> we can safely make them non-promiscuous, we will know all the >> information about them. >> >> If the user leaves only 1 port as automatic, then we can mark >> that port as not-promiscuous as well. One could think of >> this a edge relay similar to what's support by embedded switches >> in SRIOV devices. Since we have all the information about the >> other ports, we can just program the mac addresses into the >> single automatic port to receive all necessary traffic. >> >> In other cases, we keep all ports promiscuous as before. >> >> There are some other cases when promiscuous mode has to be turned >> back on. One is when the bridge itself if placed in promiscuous >> mode (use sets promisc flag). The other is if vlan filtering is >> turned off. Since this is the default configuration, the default >> bridge operation is not changed. > > I like this because it does the right thing and is transparent to > the user. You might also not want to do it if the underlying device > does not support multiple MAC addresses > ie !(dev->priv_flags & IFF_UNICAST_FLT) > > > You could even go into looking at L2 offload on lower device. > Hmm. dev_uc_add() would already take care of that, but yes, we could optimized it a bit more by looking at the flag as well and not bother with the overhead if the device will just function in promiscuous mode anyway. -vlad -- 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