RFC: ported NetBSD if_bridge

[Julian Elischer]

On Fri, 16 Apr 2004, Bruce A. Mah wrote:

> If memory serves me right, Andrew Thompson wrote:
> > On Sat, Apr 17, 2004 at 08:55:49AM +0300, Ruslan Ermilov wrote:
> > > On Sat, Apr 17, 2004 at 03:57:58PM +1200, Andrew Thompson wrote:
> > > > Hi,
> > > > 
> > > > 
> > > > I have ported over the bridging code from NetBSD and am looking for feedb
> > ack.
> > > > My main question is, 'do people want this in the tree?'
> > > > 
> > > > 
> > > > The benefits over the current bridge are:
> > > >  * ability to manage the bridge table
> > > >  * spanning tree support
> > > >  * the snazzy brconfig utility
> > > >  * clonable pseudo-interface (is that a benefit?)
> > > > 
> > > What advantages does it offer compared to the ng_bridge(4) functionality?
> > > 
> > 
> > I didnt know about that one, I guess the main advantage is that all three
> > *BSDs would have the same code and interface. While I imported it from NetBSD
> > ,
> > it originated in OpenBSD. Thats assuming anyone cares about that sort of
> > thing.
> 
> 1.  ng_bridge(4) doesn't do spanning tree.  Neither does bridge(4).

WHICH spanning tree? Spanning tree is a generic term..
Are you refering to a particular implimentation of something that uses
spanning tree algorythms?

> 
> 2.  A problem that I saw was that ng_bridge(4) didn't interact very well
> with IPFilter...specifically, I recall that IPFilter rules had no effect
> on bridged packets.  This was a problem when I was trying to add
> filtered bridging to m0n0wall...the maintainer and I eventually switched
> to using bridge(4)-style bridging after resolving a few other problems.

There is a ipfw type netgraph module floating around somewhere that you
can link in with ng_bridge to get a much more flexible arangement
should that be needed. Of course it could do with some work....


> 
> Don't know how important those are in the grand scheme of things, but 
> those are a couple of real, functional differences.
> 
> Cheers,
> 
> Bruce.
> 
> 
>