Red Hat Bugzilla – Bug 125570
IGMPv3 is default, there is no option for IGMPv2
Last modified: 2007-11-30 17:07:02 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET
Description of problem:
In current 2.4.21 kernels, IGMPv3 is used by default. There is no
option to select IGMPv2. This is a problem when using multicast in
networks that do not yet support IGMPv3.
In newer kernels (2.4.25 and up), there is a way to force IGMPv2 via
sysctl. It looks like this:
/sbin/sysctl -w net.ipv4.conf.eth0.force_igmp_version=2
The problem currently exists in kernel 2.4.21-15.EL.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Implement in a network that uses IGMPv2.
2. Subscribe to multicast groups other than 184.108.40.206
3. Use "tcpdump" to monitor incoming traffic.
4. You will see no multicast traffic.
This bug report doesn't indicate that a problem actually
occurs. The way it works is that IGMPv3 is tried _first_
but if no response is received to that IGMPv2 is used
The sysctl to force IGMPv2 is only need for some broken
middleware boxes, and that is pretty rare and thus I do
not think the reporter is seeing that.
Upon doing some more research, I think the problem may be related to
the fact that we are running IGMP snooping, which doesn't work with
IGMPv3 clients (at least not in the software running on our
routers/switches). In a situation like this, having the option to
force IGMPv2 on the client is essential.
It works with IGMPv3 clients, just some vendors don't
implement it properly.
Anyways, this is the critical piece of information I needed
Actually, we cannot add this feature into the RHEL3 product
because the change requires changing a publicly visible kernel
ABI which we cannot change, namely the layout of the inetdevice
structure needs to change in order to accomodate this feature.
Are you sure the IGMP version fallback is working like you described
in comment #1? I am having problems with ganglia, which uses
multicast. I have a few computers running RHEL-3 (igmp v3) and one
computer running RedHat-7.3 (igmp v2). They are on the same subnet
and configured to use the same multicast address, but they are not
receiving eachother's multicast packets. Our network equipment does
not support igmp v3, but I still see the RHEL computers using igmp v3
(checked with tcpdump). Since our network hardware doesn't support
igmp v3 and there is another computer, on the same subnet and using
the same multicast address and using igmp v2, shouldn't they fallback
to use igmp v2 also?
Created attachment 103866 [details]
backport of 2.6 force igmp functionality
I've had a few customers mention that it would be nice to be able to force igmp
version in order to interoperate properly with their other network equipment.
I thought that this would be a good time to re-open this bug, as we're talking
about changing the ABI for RHEL3 U4 anyway. I've taken the liberty of
backporting the 2.6 functionality and attached it here
Feel free to put this in Neil, looks fine to me.
Have you looked into the version fallback behavior which doesn't
appear to be working? Someone of the ganglia mailing list recently
reported similar igmp problems and found that the kernel doesn't
appear to be advertising its igmp version correctly:
We just looked at the RedHat kernel source...sure enough...it checks
to see if it's v1, and it not, it just blindly puts "v2" in
/proc/net/igmp, even though it's really talking v3.
Could this be contributing to the problem? Are there any other igmp
versioning bugs in the kernel?
I'll post this to rhkernel-list then. Thanks dave!
Jason, in regards to your other question, If its the problem I believe
that it is, I've fixed this as well in the patch that I previously
attached. The problem is in the chunk that starts at line 2106. I've
included the 2.6 functionality there that properly reports V1,2 or 3.
Please let me know if thats not the problem you are referring to and
I'll be happy to investigate further.
A patch to facilitate forcing the igmp protocol version has just been
committed to the RHEL3 U4 patch pool (in kernel version 2.4.21-20.9.EL).
An errata has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.