[Bridge] Feature enhancement - Disable unicast flooding

Dylan Hall dylan at citylink.co.nz
Mon Apr 16 14:58:58 PDT 2007


I looked at ebtables initially. My first plan was to use a perl script
using pcap to listen on the interfaces and generate ebtables rules as
new hosts are detected.

I had two concerns with this approach, the first is that there are
approx 1000 hosts on the vlans I'm working with, which is a lot of
ebtables rules (linked-lists are used, and hence forwarding performance
would suffer - is this correct?). 

The second concern is that the hardware I'm using are little embedded
boxes (Soekris), so with only a 133Mhz CPU, any helper scripts I use to
maintain the ebtables rules are going to use precious CPU resources I
would rather were available for forwarding.

Given those concerns, I decided I was essentially duplicating the
learning process that already exists in the bridging code, and hence
duplicating effort rather inefficiently.

That said, a dedicated ebtables module, one that possibly references the
existing bridging database might be a plan? I have no experience writing
modules like that, how easy/hard would it be to write such a module?

Thanks,

Dylan


On Mon, 2007-04-16 at 11:11 -0700, Stephen Hemminger wrote:

> On Mon, 16 Apr 2007 10:29:31 +1200
> Dylan Hall <dylan at citylink.co.nz> wrote:
> 
> > For the project I'm working on I require that the bridging code not
> > flood unicast frames when the destination mac address is unknown,
> > similar to Cisco's "switchport block unicast" feature
> > (http://www.cisco.com/en/US/products/ps6406/products_configuration_guide_chapter09186a00805a761a.html#wp1087814).
> > 
> > I have produced a small patch (against 2.6.20.4) to control this feature
> > per bridge (rather than per port like a Cisco).
> > 
> > Have I gone about implementing this correctly?
> > 
> > Is this something other people may find useful, and hence worth
> > incorporating into the mainstream code?
> > 
> > Is it worth the effort of taking this one step further, and controlling
> > the behaviour per port rather than per bridge?
> > 
> > Thanks,
> > 
> > Dylan
> > 
> > 
> > 
> 
> Maybe. But this kind of thing is better done with a ebtables module.
> That way it can be more easily integrated with other security stuff.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/bridge/attachments/20070417/a01eac2e/attachment-0002.htm


More information about the Bridge mailing list