If_bridge behaving as HUB

[Andrew Thompson]

On Tue, Oct 17, 2006 at 09:06:26AM +0200, Jon Otterholm wrote:
> Andrew Thompson wrote:
> >On Mon, Oct 16, 2006 at 12:15:13PM +0200, Jon Otterholm wrote:
> >  
> >>Hi.
> >>
> >>I have a bridge setup with a number of vlan IF's as members. After a 
> >>while traffic destined for one member IF are sent to all member IF's.
> >You should run 'ifconfig bridge0 addr' to print out the forwarding
> >table, check if the mac address is listed on the correct port.
> >  
> They are listed on the correct port but when I read man if_bridge I get
> confused:
> 
> From man if_bridge:
> 
> discover interface
>      Mark an interface as a ``discovering'' interface.  When the
>      bridge has no address cache entry (either dynamic or static) for
>      the destination address of a packet, the bridge will forward the
>      packet to all member interfaces marked as ``discovering''.  This
>      is the default for all interfaces added to a bridge.
> 
> Ie if my router doesnt know where to send the traffic all IF's with
> discover enabled gets the traffic?

Yes, thats correct.

> 
>     -discover interface
>       Clear the ``discovering'' attribute on a member interface.  For
>       packets without the ``discovering'' attribute, the only packets
>       forwarded on the interface are broadcast or multicast packets
>       and packets for which the destination address is known to be on
>       the interface's segment.
> 
> If i set this on customer IF's it allmost works.
> 
>     learn interface
>       Mark an interface as a ``learning'' interface.  When a packet
>       arrives on such an interface, the source address of the packet
>       is entered into the address cache as being a destination address
>       on the interface's segment.  This is the default for all
>       interfaces added to a bridge.
> 
>     -learn interface
>             Clear the ``learning'' attribute on a member interface.
> 
> As I understand this: I would be able to set "-discover" and "learn" on
> all member IF's and everything would work. Unicast traffic with non
> known destination would not travel to wrong IF's and the bridge fdb
> would be updated with new customer mac's. This is almost the case - but
> sometimes customers connection fails because the bridge fdb doesn't get
> updated.
> 
> It seems that when a customer connects (ie starts his computer) with no
> active DHCP-lease and the client sends out a DHCPREQUEST (broadcast) it
> works like a charm until the bridge fdb entry expires. This could be
> solved by setting timeout to 0 - but then I would get a polluted fdb.
> For most customers it works all the time but for some it stops working
> when the fdb entry expires.

Yes, you will either need regular packets to update the fdb, a long
timeout or no timeout at all. Its hard to tell but when you say the fdb
entry expires, is that during a period of no activity? By default the
entries will be pruged after 20 mins if not updated. Rather than no
timeout you could always set it to something greater than the DHCP ack
time (1/2 lease time IIRC) and then it should always stay active and old
entries will slowly be purged. 

Another option is when a customer as sucessfully identified themselves
to you in some way, then have a script take their fdb entry and reinsert
it as static. 

> 
> I would like to know how the "learn"-function works and why it doesn't
> work with unicast traffic.

The learn flag just controls the ability to add dynamic entries to the
fdb. When its turned off then your bridge will either behave like a hub
(with discover enabled) or you will need to maintain a static table
(with discover disabled).

I hope this helps. If your bridge is not behaving as above, like active
entries being incorrectly purged, then send in a PR.


regards,
Andrew