On Mon, Feb 18, 2013 at 7:43 PM, Vladislav Bogdanov <bubble@xxxxxxxxxxxxx> wrote: > 18.02.2013 10:50, Andrew Beekhof wrote: >> This sounds like it might be relevant: >> https://bugzilla.redhat.com/show_bug.cgi?id=880035 > > Yes, at least partially. Although I cannot comment much on original > issue you see there, except that libvirt is not a suspect there Right. Its not a libvirt issue - except for the possibility that it could set that option by default. Beyond that, no-one seems able to really answer what on earth is going on (or why it changed recently). > - it has > nothing to multicast, it is solely to kernel and qemu. > > I've originally seen (with inter-node qemu mcast tunnels) the similar > behaviour to what David wrote in Comment 1. Processes running on > different hosts and bound to one IGMP group loose each other. > > From what I understand, to prevent false IGMP membership expiration, you > should have some device (one is at least enough) in a broadcast layer-2 > segment, which originates IGMP query requests to all its ports known to > have been joined to a IGMP groups in a past. Other igmp-snooping devices > should propagate that requests downstream, so the whole membership tree > remains consistent (that is relevant to a case when you run corosync > UDPM in VMs connected to linux-bridge ports where host side of that > bridge have ports connected to a switch). > > It you have a bunch of VMs all running on one host and connected via > internal bridge, you would enable IGMP querier on that bridge. > If you have inter-node groups, you'd better enable it on a switch. > > From cisco docs (I do not know if it is relevant to linux-bridge), you > need to have an IP address configured on a device to have querier > working, so you can't enable it on a pure bridge (where you do not have > an IP address on a host-side interface). > > If you have multicast router in a segment for all groups, you probably > do not need to care, because router should send queries. Although you > may need to mark its port as 'mrouter'. > > In my case, I have several hosts in one (hardware) broadcast segment and > have IGMP snooping enabled on a switch. IGMP joins are originated by > qemu processes running on hosts themselves. Although I use bridges on > hosts, I do not have host-side IPs on all of them, but I have switch as > a "central" device, and, as it is enough to have only one querier in a > segment, I delegated that function to it. And that helped. > > As I know that models used by corosync and qemu are very similar, I > expect that to help with corosync UDPM as well. > > >> >> On Mon, Feb 18, 2013 at 5:46 PM, Vladislav Bogdanov >> <bubble@xxxxxxxxxxxxx> wrote: >>> 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
