Multicast traffic originating on one AP does not reliably reach a client on another AP, on the same WLAN.

  • 1
  • Question
  • Updated 3 years ago
  • Answered
Multicast traffic originating on one AP does not reliably reach a client on another AP, on the same WLAN. Sometimes it works and other times it doesn't. We have IGMP Snooping enabled on all of our Cisco SG300 switches and have ran "qos igmp-query v2 enable" on our ZoneDirector's "System Default" AP Group.

I'm not too sure what exactly I need to change to fix this issue, but it seems to me that the AP is not always forwarding multicast traffic to the switch it's attached to.
Photo of Matty Brown

Matty Brown

  • 30 Posts
  • 3 Reply Likes

Posted 3 years ago

  • 1
Photo of Keith - Pack Leader

Keith - Pack Leader

  • 860 Posts
  • 51 Reply Likes
Hi Matty - what version of ZoneFlex are you running?
Photo of Matty Brown

Matty Brown

  • 30 Posts
  • 3 Reply Likes
Hi Keith

We're on 9.6.2.0 build 13 using ZD1112 and 11x ZF7363's.

Thanks,

Matty
Photo of Keith - Pack Leader

Keith - Pack Leader

  • 860 Posts
  • 51 Reply Likes
No known issues that I'm aware of. Probably best to open a support case, but here's a few more questions that they will likely ask as well:

1) What kind of multicast traffic?
2) Have you modified any of the SmartCast settings?
3) Any VLAN's involved?
4) Any errors showing on the switchports?
5) Just "one" AP or any AP?
6) Are you tunneling?

If/when you open a case, attach these answers and a ZD debug

Working hypothesis: These packets aren't making it into a priority queue and are therefore often getting dropped. Do you have rate-limiting enabled?
Photo of Matty Brown

Matty Brown

  • 30 Posts
  • 3 Reply Likes
We don't have a Ruckus Premium Support contract - I think our Ruckus support is handled by the reseller so I guess I'll have to take it up with them.

1) We're sending UDP packets to a multicast address, 239.255.0.1. These are short messages which tell displays mounted on our order pickers (forklifts) that stock has been picked and it is necessary to update the display to show an up to date picking list.
2) SmartCast settings? :). What are they?
3) No, both senders and recipients are on the native VLAN.
4) No, no errors showing on the switchports.
5) We only have two AP's covering our warehouse. The problem seems to happen when the sender is on one AP and the receiver is on the other AP.
6) No, traffic is not tunnelled back to the ZoneDirector.

We have call admission control enabled, but no rate limiting.
Photo of Keith - Pack Leader

Keith - Pack Leader

  • 860 Posts
  • 51 Reply Likes
OK..guessing a bit but I would start with turning off directed-multicast. See https://support.ruckuswireless.com/an.... You can do this one AP at a time and I think with will be of diagnotic help. (e.g. remote_ap_cli -a )

If that doesn't work, reverse the above and then try disable QOS:


no qos classification


If neither of those works...it's going to get involved (packet capture, etc)
Photo of Matty Brown

Matty Brown

  • 30 Posts
  • 3 Reply Likes
Hi Keith

Thanks for your help - turning off directed-multicast appears to resolve the issue. :)

The commands I ran were:
ruckus> enable
ruckus# config
ruckus(config)# show wlan (to get the exact name of the WLAN I wanted to configure)
ruckus(config)# wlan MySSID
ruckus(config-wlan)# no qos directed-multicast
ruckus(config-wlan)# qos directed-threshold 0
ruckus(config-wlan)# end
ruckus(config)# end
ruckus# reboot
Photo of Keith - Pack Leader

Keith - Pack Leader

  • 860 Posts
  • 51 Reply Likes
Great! And thanks for posting your results - it will really help people in the future. What I suspect is going on is we're treating your multicast as "noise" instead of something well-known like SIP and so it's not getting into priority queues properly - it's going into the "OK to drop" bucket.