Header Only - DO NOT REMOVE - Extreme Networks

Multicast at 1000 Mbits/s works, but 100 Mbts/s don't.

Hello community, I have a
problem while I'm uploading an image with my fog server: multicast works well with my X440 switches (1000 Mbits/s) but with my x250 (100 Mbits/s) it stops after ~5min. It resumes when I restart all my ports concerned by my deployment: (my fog server and PCs).

When it stops, my PC unsubscribe to the udpcast group and resuscribe when I restart my ports.

I have the same issue when i configure my X440 PC ports at 100Mbits/s.

There is nothing in my logs that says that's my ports are blocked or somethings...

What do you suggest me to check ?


Best regards,
Adrien, from France.

10 replies

Userlevel 6
It looks to me the multicast stream times out on the switch. take a look at igmp snooping on the X250 switch. Packet handling is not handled differently between 1 gb port or a 100 Mb port, internal it is all handled the same. However the table sizes of older and newer switches differ and multicast table size could play a role here.
Thank you for your answer, it works (1000Mb or 100Mb) when i disable igmp snooping in the concerned Vlan but only if my Fog server and my PC (to deploy) are on the same switch.
it doesn't when i go trought my network.
Userlevel 6
Hi,igmp snooping on other switches play a role also. Disabling igmp snooping is a temporary solution, better is to investigate why the snooping entry times out or if a table is full (that would be logged).
Yes it can be a temporary solution, the table is not full but is there a solution to check the snooping entry times ? is it "the age" ?
Userlevel 6
yes, show igmp snooping you will see senders and subscribers and the timers/age.
Actually it is the age of the hosts that causes the exclusion of groups (when it's higher than 260 seconds)
I do not know the risks of increasing this timeout accross of my network, what is the way for my hosts to "re-subscribe" in order to make reset this timer/age ? Is it on the switch or on my deployment server in your opinion?
Thank you for your help.
Userlevel 6
The client should subscribe to the streams and keep that subsciption alive by sending a report when a switch is asking (query) for it. The switch should do a query before removing a port from the stream, you could do a capture to see if you get that igmp query and if the client responds to it.
Userlevel 5
Out of curiosity, does the VLAN where the receiver is have an IP? IGMP snooping requires at least one querier to be present in the VLAN and the querier should have an IP. The querier will poll subscribed hosts to see if they are still interested in a stream. And if the querier doesn't receive any responses it ages the host. The default host timeout is 260 seconds (around 4 minutes). Here's an example:

# show igmp snooping v70Router Timeout : 260 secHost Timeout : 260 secIgmp Snooping Fast Leave Time : 1000 msVLAN v70 (70) Snooping=Enabled Group Sender Age 15 1 Incoming multicast streams Port Host Subscribed Age Group-Limit 21 253 0 [/code]Once the 260 seconds elapses, the host is disconnected from the stream:
# show igmp snooping v70Router Timeout : 260 sec
Host Timeout : 260 sec
Igmp Snooping Fast Leave Time : 1000 ms
VLAN v70 (70) Snooping=Enabled
Group Sender Age 5
1 Incoming multicast streams [/code]Then I disable and re-enable the host port and the stream is back:
# disable ports 20# enable ports 20
# show igmp snooping v70
Router Timeout : 260 sec
Host Timeout : 260 sec
Igmp Snooping Fast Leave Time : 1000 ms
VLAN v70 (70) Snooping=Enabled
Group Sender Age 5
1 Incoming multicast streams [/code]
Userlevel 7

the problem description hints at a missing IGMP querier.

On EXOS, the querier is configured on a VLAN that has an IP address using the following command:
enable igmp vlan VLAN_NAME IGMP_VERSION [/code]This enables IGMP queries in this VLAN, allowing IP multicast to work correctly inside this VLAN.

IGMP snooping, enabled by default, requires either bidirectional multicast traffic or regular IGMP messages to keep the cache entries current. The relevant messages are created when an end system joins the group, thus multicast initially works, but this time out if there is no querier in the VLAN to trigger recurring group membership messages from the end systems.

To transport multicast from one VLAN to another needs additional mechanisms, e.g. multicast routing using PIM.

Thanks for your help, it is actually a problem of IGMP snooping, i will fix this problem.

Best regards,
Adrien, from France.