Re: If_bridge behaving as HUB

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
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: If_bridge behaving as HUB
    ... 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. ... A bridge works like a hub, forwarding traffic from one interface to ... Multicast and broadcast packets are always forwarded to all ...
    (freebsd-net)
  • Re: kern/102607: [if_bridge] dont generate random L2 address
    ... The MTU of the first member interface to be added is used as the ... +The bridge can be used as a regular host interface at the same time as ...
    (freebsd-net)
  • Re: kern/102607: [if_bridge] dont generate random L2 address
    ... The MTU of the first member interface to be added is used as the bridge MTU. ...
    (freebsd-net)
  • Re: tap devices and DHCP.
    ... The other end runs linux as DHCP server on LAN. ... >> member of the same bridge. ... > bridge interface. ... is a member of an if_bridge bridge. ...
    (freebsd-net)
  • Re: bridge issues with pf rules on OpenBSD/Sparc
    ... confused as to which physical interface traffic goes in and out on ... for the bridge, I was hoping to have the bridge tell it. ... >> router always appears to match rules for le2 outbound traffic from ... I want to be functional between the LAN and AP. ...
    (comp.unix.bsd.openbsd.misc)