From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [RFC] net/bridge: port based vlan filtering for bridges Date: Wed, 11 Apr 2012 08:38:35 -0700 Message-ID: <20120411083835.39fed750@nehalam.linuxnetplumber.net> References: <20120411151002.GA17739@kvack.org> <20120411083052.1ca6a6ef@nehalam.linuxnetplumber.net> <20120411153629.GC17739@kvack.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org To: Benjamin LaHaise Return-path: Received: from mail.vyatta.com ([76.74.103.46]:56149 "EHLO mail.vyatta.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759269Ab2DKPii (ORCPT ); Wed, 11 Apr 2012 11:38:38 -0400 In-Reply-To: <20120411153629.GC17739@kvack.org> Sender: netdev-owner@vger.kernel.org List-ID: On Wed, 11 Apr 2012 11:36:29 -0400 Benjamin LaHaise wrote: > On Wed, Apr 11, 2012 at 08:30:52AM -0700, Stephen Hemminger wrote: > > On Wed, 11 Apr 2012 11:10:02 -0400 > > Benjamin LaHaise wrote: > > > > > Hello folks, > > > > > > Attached is the first stab at a patch to make it possible to filter packets > > > received from other bridge ports based on the port number. This can be used > > > to emulate port based VLANs that some switches support. > > > > > > The justification for this is a bit interesting. Initially, I had been > > > filtering packets using firewall rules. Unfortunately, the number of > > > filter rules becomes impossible to manage when trying to filter traffic > > > between 100 different ports. CPU overhead of the filters is also a major > > > problem. > > > > > > The particular use-case I'm dealing with is simulating wireless networks > > > on a system using LXC containers. Each guest has a veth device that is a > > > member of the bridge, but the topology of which nodes can "hear" each other > > > changes at runtime. > > > > > > Comments/thoughts? > > > > > > > Nak. If firewall doesn't work then implement a better netfilter > > module. > > That still results in the CPU overhead of packet duplication for each and > every bridge port regardless of the port receiving the packet or not. > Hmmmm, would a NF_HOOK in should_deliver be okay? Sure. Having better way to do policy would be great. Just don't want to have implementations of specific policies in generic code.