Hi and thanks for your reply! On Fri, Dec 14, 2018 at 10:32:16AM +0800, Ying Xu wrote: > I think the scenario mentioned above is abnormal. Can we agree, that this scenario, if switch A and B were using the current bridge code, has issues right now which it did not have before that patch? I also do not quite understand what you mean with "abnormal". Do you think that it is unlikely to have two snooping switches and general queries with a 0.0.0.0 source? Note that with the current bridge code and according to RFC3376 and RFC2236, as soon as a query with a 0.0.0.0 source is sent somewhere in the broadcast domain, it will become the selected querier [*]. > The source of query indicats that is a real router or only a switch.(0.0.0.0 > means switch,non-zero means router). > In the scenario above,the switch A was selected to be a querier that means A > performs as a router, > so switch A should config its query source address to non-zero,and then Host A > can recieve the traffic from B. Even if in the described scenario switch A were configured to use a a non-zero source address to become a router, so that switch B would mark the port to switch A as a multicast router port, switch A would still loose in the querier election right now, as 0.0.0.0 is lower (RFC3376, RFC2236). So switch B would then become the selected querier with its 0.0.0.0 source and switch A would become silent even though it had a non-zero source address. And then we would have the same issue again, only swapped between host+switch A and host+switch B. Would you agree, does that make sense? Regards, Linus [*]: Looking at br_ip4_multicast_select_querier(): If previously selected querier were 0.0.0.0, it would accept any source as a new querier ("!br->ip4_querier.addr.u.ip4"). However, if the previously selected querier were non-zero, a query with 0.0.0.0 would win, too ("ntohl(saddr) <= ntohl(br->ip4_querier.addr.u.ip4)").