netdev - Re: [PATCH RFC 0/7] Non-promisc bidge ports support

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]

Message-ID: <20140227072006.GD16484@redhat.com>
Date:	Thu, 27 Feb 2014 09:20:06 +0200
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	Jamal Hadi Salim <jhs@...atatu.com>
Cc:	Vlad Yasevich <vyasevic@...hat.com>, netdev@...r.kernel.org,
	bridge@...ts.linux-foundation.org, shemminger@...tta.com,
	john.r.fastabend@...el.com
Subject: Re: [PATCH RFC 0/7] Non-promisc bidge ports support

On Wed, Feb 26, 2014 at 06:59:29PM -0500, 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?
> 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

I agree.

It seems a reasonable tradeoff to limit any specific
optimization to !flood && !learn if this simplifies the
implementation significantly and if everything works
as it did before even with learning on.


-- 
MST
--
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