Please, unsubscribe me.
Regards
Amidu Sila
On 2/27/14, 03:37 AM, Vlad Yasevich wrote:
On 02/26/2014 06:59 PM, Jamal Hadi Salim wrote:
On 02/26/14 10:18, Vlad Yasevich wrote:
This patch series is a complete re-design and re-implementation of
prior attempts to support non-promiscuous bridge ports.
The basic design is as follows. The bridge keeps track of
all the ports that flood packets to unknown destinations. If
the flooding is disabled on the port, to get traffic to flow
through, user/management would need to add an fdb describing
such traffic. When such fdb is added, we save the address
to bridge private hardware address list.
Entering the addresses in the uc list on other bridgeports seems
reasonable for the scenario described.
But would it _also_ need to be added to the fdb of the bridge?
i.e how does the bridge (if the packet was to be handed to it)
know where to forward?
The fdb described here is actually added to the bridge. In the case
when we are turning promiscuous mode off on a port, we program the
address from the fdb down to the port uc list as well. This allows
the bridge to continue receiving traffic destined for this address even
though the port is not in promiscuous mode.
BTW: on the comment that flooding off implies learning off: I would like
to be able to turn off flooding on a specific bridge port but
still want to learn from it. I dont think those two are mutually
exclusive.
No they are not, but it does lead to some very interesting traffic
hang-ups that I've experienced first hand. Everything works great
in the beginning. However, if you go idle for a long enough period
that the fdb times out, re-establishing the connection take a rather
long time due to unicast ARPs being dropped by the bridge. You end
up waiting until arp fails and switches to broadcast to restore the
connection. So, this mode isn't really recommended. Nothing currently
forbids it however.
-vlad
cheers,
jamal
