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@xxxxxxxxxxxxxx> 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.
_______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge
