18.02.2013 09:46, Vladislav Bogdanov wrote: One observation in addition to this old message. Cisco switches support IGMPv2 snooping (they have something for v3, but I didn't manage to make that work). Linux kernel by default uses IGMPv3. When process on a linux host joins IGMPv3 group, my cisco switch (layer2 fw) does not see it (I tested this with fence_virtd, which uses address 225.0.0.12): sw01>show ip igmp snooping groups Vlan Group Type Version Port List ----------------------------------------------------------------------- 1 239.192.255.253 igmp v2 Po13, Po14 1 239.192.255.254 igmp v2 Po13, Po14 1 239.255.255.250 igmp v2 Gi1/0/24 But, after I set net.ipv4.conf.default.force_igmp.version = 2 net.ipv4.conf.all.force_igmp.version = 2 and restart fence_virtd (two instances on two hosts), picture is: sw01>show ip igmp snooping groups Vlan Group Type Version Port List ----------------------------------------------------------------------- 1 225.0.0.12 igmp v2 Te1/1/1, Te2/1/1 1 239.192.255.253 igmp v2 Po13, Po14 1 239.192.255.254 igmp v2 Po13, Po14 1 239.255.255.250 igmp v2 Gi1/0/24 It is also essential that firewall doesn't block igmp packets to 224.0.0.1, so host answers igmpv2 queries. Vladislav > Hi all, > > can anyone please confirm that enabling IGMP querier on a switch (stack) > instead of disabling IGMP snooping (thus making switch broadcast all > multicast packets) helps to solve node loss issue? > > I enabled that feature in order to solve packet loss over qemu mcast > tunnels, and that helped dramatically. That tunnels operate very similar > to corosync, where all relevant nodes first join IGMP group, and then > all of them send multicast packets to that group. So in both cases there > is no designated 'sender' or designated 'router port' where all > multicast traffic in a layer-2 broadcast segment originate from. > > So I think it may help to stabilize corosync multicast mode as well. > > May be somebody have hardware-based testing setup with IGMP-snooping > enabled switch(es) and IGMP querier (in cisco terms, different vendors > may call it differently) feature available and can test if this actually > helps? > > Vladislav > _______________________________________________ > discuss mailing list > discuss@xxxxxxxxxxxx > http://lists.corosync.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
