Reply

Re: GS110TP IGMP snooping bug

ka9q
Aspirant

GS110TP IGMP snooping bug

I have three GS110TPs connected in a line A-B-C. All run 5.4.2.33 (latest version). I've found a subtle bug in IGMPv2 snooping. When the IGMP querier changes from C to A, as can happen during querier (re)election when one or more switches is rebooted, switch B (the middle switch) can fail to correctly forward traffic toward switch A, the new IGMP querier.

 

Looking at the MFDB (multicast forwarding database) on switch B, I do not see an entry for the link to switch A, so packets sent to the group by a member on switch C do not reach the members on switch A. Killing and restarting the multicast application on switch C (so its host operating system issues an IGMP leave and then a join) temporarily fixes the problem.

 

I think the problem comes from the rule that in IGMPv2, the link on which an IGMP query is received is an implicit member of every multicast group. I.e., all multicast traffic flows "upstream" to the active IGMP querier. I suspect that when the querier changes, your software fails to go through the list of existing multicast groups, revising the membership of each link in that group based on whether or not it was the former (or new) IGMP querier. This would explain why I can temporarily work around the problem by leaving and rejoining the group on a downstream host; this forces the IGMP snooping logic to re-execute based on the new IGMP querier.

 

Is there any hope that this switch will ever support IGMPv3? It's simpler and much more efficient than IGMPv2 in many ways; in particular it is no longer necessary to forward all multicast traffic toward the active IGMP querier since membership messages are sent to a special multicast group (224.0.0.22) rather than to each group in question. I.e., this particular bug would not be possible with IGMPv3.

Model: GS110TPv2|ProSafe 8 ports gigabit PoE smarta switch
Message 1 of 8
ka9q
Aspirant

Re: GS110TP IGMP snooping bug

I filed a similar bug report in May 2018 but never got a definitive answer. I did dig into the problem more deeply this time and think I have a better handle on the cause of the problem.

 

 

Message 2 of 8
ka9q
Aspirant

Re: GS110TP IGMP snooping bug

Another data point: the IGMP snooping tables can be rebuilt by momentarily disabling and re-enabling IGMP. If the switch is not the IGMP querier, every entry in the rebuilt table will then properly include the port going to the switch that is the querier.

 

Go into IGMP Snooping Configuration and set IGMP Snooping Status to disable. Apply it, wait a while, then select enable and hit apply again. Now go to MFDB (Multicast Forwarding Data Base) and verify that the port going to the querying switch is included in every entry, as required by IGMPv2.

 

Again, I believe the problem is that when a switch that had been the IGMP querier goes to non-querier status (because another switch with a lower IP address has won the querier election) the switch should go through its MFDB and add to each entry the port going to the new querier. It doesn't seem to be doing this.


I bet this could easily explain a lot of the problems people are having with IGMP snooping when they have more than one snooping switch.

 

Message 3 of 8
DaneA
NETGEAR Moderator

Re: GS110TP IGMP snooping bug

@ka9q,

 

Is there any hope that this switch will ever support IGMPv3? It's simpler and much more efficient than IGMPv2 in many ways; in particular it is no longer necessary to forward all multicast traffic toward the active IGMP querier since membership messages are sent to a special multicast group (224.0.0.22) rather than to each group in question. I.e., this particular bug would not be possible with IGMPv3.

As far as I have checked, there is already a feature request to have the GS110TPv2 to support IGMP snooping v3.  There is no guarantee when it will be implemented. 

 

NETGEAR released the GS110TPv3 and this supports IGMP snooping v3 on all ports.  Kindly check the data sheet here

 

 

Regards,

 

DaneA

NETGEAR Community Team

Message 4 of 8
ka9q
Aspirant

Re: GS110TP IGMP snooping bug

What's the difference between the GS110TPv2 and GS110TPv3? Is the hardware totally different?

 

Note that besides not implementing IGMPv3 at all, the implementation of IGMPv2 on the GS110TPv2 is simply buggy. I'm still seeing the upstream link to the IGMP querier drop out of multicast forwarding database entries in downstream switches, with the result that packets sent to the group from computers on downstream switches do not reach group members on computers attached to upstream switches. This happens even when I haven't explicitly changed the IGMP querier, though it's possible that it has happened spontaneously due to the querier election algorithm.

 

I will disable querier election on the downstream switches, thus forcing the querier to remain the same, and see if it still happens.

Message 5 of 8
ka9q
Aspirant

Re: GS110TP IGMP snooping bug

Is there any progress on resolving this problem? To summarize, the multicast forwarding databases on non-querying switches frequently drops the links to upstream switches (i.e., switches closer to the querying switch) even when there are group members on those switches. The symptom is that not every multicast group member's packets are received by every other member. That's definitely a bug separate from the lack of support for IGMPv3.

 

Another serious IGMP bug I haven't mentioned yet: when the option is selected to drop unknown multicast groups, all IPv6 groups are also dropped. I understand that the switch doesn't support MLD (the IPv6 counterpart to IGMP for IPv4) but in this case it should continue to flood IPv6 multicasts even when unknown IPv4 multicasts are dropped. IPv6 multicast is now very heavily used on virtually every LAN for service discovery (especially by Apple devices) so breaking it is not acceptable even though the lack of MLD support makes IPv6 multicast unusable for high speed data streams.

 

Working around this bug requires turning off the switch option to drop unknown multicast groups, which in turn creates *another* problem: unless a transmit-only multicast application joins the group to which it is transmitting (which is not required by the specs), the switch will treat that as an "unknown" group and flood all traffic to it out every switch port. Having a transmit-only application join the group to which it is transmitting isn't difficult if you control the source code to the application, but this isn't always possible.


I've run into so many bugs with this switch that I am not inclined to buy any more Netgear switch products. I might as well spend a little more on Cisco and get something I know will work correctly, or at least get engineering support when it doesn't.

Message 6 of 8
schumaku
Guru

Re: GS110TP IGMP snooping bug

Keep dreaming - the consumer/SOHO and SMB products come from the same ODMs. This is a level the brand name engineering can't do much - except to escalate to the ODM (most working very thight to the switch core maker). Otherwise you have to buy Cisco IOS or NX...

Message 7 of 8
ka9q
Aspirant

Re: GS110TP IGMP snooping bug

Yeah, you're probably right.

Message 8 of 8
Top Contributors
Discussion stats
  • 7 replies
  • 763 views
  • 0 kudos
  • 3 in conversation
Announcements