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: <530E7FE1.5060705@mojatatu.com>
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