| 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
| ||
|
Date: Wed, 26 Feb 2014 18:59:29 -0500 From: Jamal Hadi Salim <jhs@...atatu.com> To: Vlad Yasevich <vyasevic@...hat.com>, netdev@...r.kernel.org CC: bridge@...ts.linux-foundation.org, shemminger@...tta.com, mst@...hat.com, john.r.fastabend@...el.com Subject: Re: [PATCH RFC 0/7] Non-promisc bidge ports support On 02/26/14 10:18, Vlad Yasevich wrote: > This patch series is a complete re-design and re-implementation of > prior attempts to support non-promiscuous bridge ports. > > The basic design is as follows. The bridge keeps track of > all the ports that flood packets to unknown destinations. If > the flooding is disabled on the port, to get traffic to flow > through, user/management would need to add an fdb describing > such traffic. When such fdb is added, we save the address > to bridge private hardware address list. Entering the addresses in the uc list on other bridgeports seems reasonable for the scenario described. But would it _also_ need to be added to the fdb of the bridge? i.e how does the bridge (if the packet was to be handed to it) know where to forward? BTW: on the comment that flooding off implies learning off: I would like to be able to turn off flooding on a specific bridge port but still want to learn from it. I dont think those two are mutually exclusive. cheers, jamal -- 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