Date: Tue, 17 Oct 2006 09:06:26 +0200 From: Jon Otterholm <jon.otterholm@ide.resurscentrum.se> To: freebsd-net@freebsd.org Subject: Re: If_bridge behaving as HUB Message-ID: <453480F2.40604@ide.resurscentrum.se> In-Reply-To: <20061016163610.GA93501@heff.fud.org.nz> References: <45335BB1.6050809@ide.resurscentrum.se> <20061016163610.GA93501@heff.fud.org.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
>>
>> From man if_bridge:
>>
>> A bridge works like a hub, forwarding traffic from one interface to
>> another. Multicast and broadcast packets are always forwarded to all
>> interfaces that are part of the bridge. For unicast traffic, the
>> bridge
>> learns which MAC addresses are associated with which interfaces and
>> will
>> forward the traffic selectively.
>>
>> Has anyone else got this problem? How do I debug this?
>>
>>
>
> You should run 'ifconfig bridge0 addr' to print out the forwarding
> table, check if the mac address is listed on the correct port.
>
>
> cheers,
> Andrew
>
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?
-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.
I would like to know how the "learn"-function works and why it doesn't
work with unicast traffic.
/Jon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?453480F2.40604>