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: Thu, 27 Feb 2014 08:54:16 +0000 From: Amidu Sila <amidu@...itel.com> To: vyasevic@...hat.com, Jamal Hadi Salim <jhs@...atatu.com>, netdev@...r.kernel.org CC: john.r.fastabend@...el.com, shemminger@...tta.com, bridge@...ts.linux-foundation.org, mst@...hat.com Subject: Re: [Bridge] [PATCH RFC 0/7] Non-promisc bidge ports support Please, unsubscribe me. Regards Amidu Sila On 2/27/14, 03:37 AM, Vlad Yasevich wrote: > On 02/26/2014 06:59 PM, Jamal Hadi Salim wrote: >> 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? > The fdb described here is actually added to the bridge. In the case > when we are turning promiscuous mode off on a port, we program the > address from the fdb down to the port uc list as well. This allows > the bridge to continue receiving traffic destined for this address even > though the port is not in promiscuous mode. > >> 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. > No they are not, but it does lead to some very interesting traffic > hang-ups that I've experienced first hand. Everything works great > in the beginning. However, if you go idle for a long enough period > that the fdb times out, re-establishing the connection take a rather > long time due to unicast ARPs being dropped by the bridge. You end > up waiting until arp fails and switches to broadcast to restore the > connection. So, this mode isn't really recommended. Nothing currently > forbids it however. > > -vlad >> 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