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
