Bug 125570 - IGMPv3 is default, there is no option for IGMPv2
IGMPv3 is default, there is no option for IGMPv2
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Neil Horman
Brian Brock
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-08 16:41 EDT by Nayden Naydenov
Modified: 2007-11-30 17:07 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-20 15:55:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
backport of 2.6 force igmp functionality (2.75 KB, patch)
2004-09-15 11:46 EDT, Neil Horman
no flags Details | Diff

  None (edit)
Description Nayden Naydenov 2004-06-08 16:41:17 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET 
CLR 1.1.4322)

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):


How reproducible:
Always

Steps to Reproduce:
1. Implement in a network that uses IGMPv2.
2. Subscribe to multicast groups other than 224.0.0.1
3. Use "tcpdump" to monitor incoming traffic.
4. You will see no multicast traffic.

Additional info:
Comment 1 David Miller 2004-06-09 01:04:09 EDT
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
next.

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.
Comment 2 Nayden Naydenov 2004-06-09 09:46:52 EDT
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.
Comment 3 David Miller 2004-06-09 12:51:09 EDT
It works with IGMPv3 clients, just some vendors don't
implement it properly.

Anyways, this is the critical piece of information I needed
thanks.
Comment 4 David Miller 2004-06-09 12:56:11 EDT
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.

Sorry.
Comment 5 Jason Smith 2004-06-17 16:42:57 EDT
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?
Comment 6 Neil Horman 2004-09-15 11:46:30 EDT
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
Comment 7 David Miller 2004-09-15 11:59:25 EDT
Feel free to put this in Neil, looks fine to me.
Comment 8 Jason Smith 2004-09-15 12:13:47 EDT
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:

sgilbert-at-nvidia wrote:

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?
Comment 9 Neil Horman 2004-09-15 13:00:24 EDT
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.
Comment 10 Ernie Petrides 2004-09-21 02:18:05 EDT
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).
Comment 11 John Flanagan 2004-12-20 15:55:19 EST
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.

http://rhn.redhat.com/errata/RHBA-2004-550.html

Note You need to log in before you can comment on or make changes to this bug.