Hi everyone, we have a specific configuration issue with the ZoneDirector 1100 and ZoneFlex 7372 APs.
When watching a IPTV multicast stream over Wifi, and then roaming between access points, the stream breaks. Without any configuration at all, the IPTV over multicast (VLC player) worked almost flawlessly, when staying on the same AP, but as soon as my computer switched to other AP, the stream broke up, failed to recover,
and eventually the SAP list of channels also disappeared until VLC was
Only once it happened that the stream was able to recover after the roaming (after like 4 seconds), and I suspect it was because it has reconnected to the AP it has disconnected from a while before.
This happens on all the computers we've tried. The encryption type (802.1x EAP vs WPA2 pre-shared key) does not matter, it happens on both.
As it is, we have our APs connected to multiple Cisco Catalyst 2960 switches, with IGMP snooping enabled on each of them. Each Catalyst is connected (either directly or indirectly) to our core switch, and several of the APs are also on the core. Also the ZoneDirector has IGMP snooping enabled and directed multicast is also enabled. Disabling directed multicast did not help.
We use ZoneDirector 1100 and APs are ZoneFlex 7372.
Does anyone have a clue what we could be missing here? Does Ruckus support handing over multicast group membership?
Hi Monnat Systems, first thanks for your advice. We have both 802.11r and 802.11k enabled. Usually the roaming happens in a splitsecond, and even without the tunnel, the computer gets the same IP address. (Experimentally confirmed by a ping each second, where the latency went up when the notebook was roaming, but didn't lose the packet entirely. In the same moment of roaming, the VLC lost the multicast stream, picture froze for a few seconds and then stop.)
In the meantime, we have tried to enable Tunnel Mode. This way, the multicast stream goes directly to ZoneDirector and then it is distributed for each client. This practically solved the issue, but we don't want to use it, for obvious reasons (tunnel with each client, bandwidth usage increase etc.).
So the main issue - retaining multicast sessions between APs - remains unsolved by this. Any ideas?
(we still have active Partner support with Ruckus, will the support be able to answer this when we open a case?)
For your application, you probably want to let the clients IGMP through both the wired and wireless interfaces, and disabling our directed-multicast (mcast to ucast for first 5 members) to pure multicast transmission may be your best bet. Try combining these WLAN commands with commands to your AP Ethernet interfaces (determine which for your 7372 AP or do both).
ruckus> en ruckus# config ruckus(config)# wlan ruckus(config-wlan)# no qos directed-multicast ruckus(config-wlan)# qos directed-threshold 0 ruckus(config-wlan)# no qos igmp-snooping ruckus(config-wlan)# end ruckus(config)# end ruckus# ruckus# debug ruckus(debug)# remote_ap_cli -A "set qos eth0 directed multicast disable" ruckus(debug)# remote_ap_cli -A "set qos eth0 igmp disable" ruckus(debug)# remote_ap_cli -A "set qos eth0 igmp-query disable" ruckus(debug)# quit ruckus#
Ok, so several observations after toggling these settings (and patiently testing them for the last two-three hours with my notebook):
After running "no qos igmp-snooping" on a WLAN, the whole multicasted IPTV stopped working (but not if I was already watching, btw). By enabling it, everything went back to normal. Running "set qos eth0 igmp (igmp-query) disable" on an AP had no effect.
The "stream closing" issue was caused by the VLC itself. When I ran something from the SAP playlist, and VLC suddenly decided that it couldn't find the stream anymore and deleted it from the list, then the playback got stopped, whether I had a signal or not. By running the playback in a separate window/playlist, this issue disappeared.
I was also testing playback with and without directed multicast (set up on the ZoneDirector WLAN). Result? I'm not really sure which is better. On Windows and Linux, it seemed that both perform +- the same, with occasional breaks that might have been caused by anything, really, from drivers to Windows/Ubuntu mocking me.
I ran Wireshark to further examine temporary failures to restart
the stream. In all cases when the stream restored successfully, IGMP
"Membership Report group 233.x.x.x" was sent out, and also the AP itself
sent a Membership Query to 126.96.36.199 (in most cases), while when the
stream failed to restore, no IGMP packets appeared in the capture.
That alone means that it is the client itself that sends the request to join the multicast group again after roaming... or is it? Does ZoneFlex by any means impersonate the client to speed up the transition?
I really couldn't find the exact cause of the last problem. Weird. But it seems that majority of the issues was resolved when the I made the VLC playlist to stop shrinking.