Wireless Access

We are a hospital and GE has it's own network along with ours.  They have some wireless patient monitoring devices that connect to their network via our Wifi network.  These devices work using broadcast/multicast. With these devices, anyone can poll the server for a patient's vitals signs and be able to see it while any other device can see it at the same time.  Basically, two clients can poll and see the same vitals signs at the same time.

The issue that we are seeing is that when the client is connected via our Wifi network and polls, it breaks the connection of the other client.  If the client connects wired to the controller, this issue doesn't appear, both clients can poll and see the same data on two different devices.

I've checked the VAP and we're not disabling broadcast/multicast.  Anyone have any idea what could be causing this?

Do you have IP igmp snooping turned on the actual VLAN ?

MAke sure you have DMO turned on the VAP 

Make sure that bcmc is not turned on the VLAN

IP igmp snooping is not turned on the VLAN. I would think this would become an issue if it was both wired/wireless?

Should DMO be turned on or off on the VAP? As I understand DMO will turn multicast traffic into unicast traffic.

BCMC is not turned on the VLAN, but again the wired connection works, only on wireless the issue is being seen.

IP igmp snooping is not turned on the VLAN. I would think this would become an issue if it was both wired/wireless?

You can turn IP igmp snooping on the controller , do you mean wired connected directly to the controller ?

Should DMO be turned on or off on the VAP? As I understand DMO will turn multicast traffic into unicast traffic.

I apologize I meant MRO that it allows you to send multicast at higher data rates vs the default method 

BCMC is not turned on the VLAN, but again the wired connection works, only on wireless the issue is being seen.

You need to have ip igmp snooping enabled on the SVI interface of the VLAN that those users are getting serviced on

You can confirm this by running the following command :

(controller) #show  ip igmp interface

IGMP Interface Table
--------------------
VLAN  Addr          Netmask        MAC Address        IGMP      Snooping  Querier       Querier-dest  IGMP Proxy
----  ----          -------        -----------        ----      --------  -------       ------------  ----------

Note: igmp snooping has worked well in our environment but Aruba recommends that you use igmp proxy

Yes, the client "claims" that when he has the device connected wired directly to the controller to access port on that same vlan, the issue is not present.

Ok, MRO is not turned on the SSID.

IP IGMP is not enabled on the SVI of that vlan.  It's a L2 on the controller though.

IP IGMP is not enabled on the SVI of that vlan.  It's a L2 on the controller though. 

You can still enabled it on a L2 controller :

interface vlan 410
ip igmp snooping

Will try enabling and test.  Does the SVI need to have an IP address assigned or no?

I think you do but not 100% sure because we had one assigned to the VLAN that allowed muitlcast but you may not need it 

You should probably create a test VAP/SSID and apply it to just one VLAN

So today our lead engineer went to a site after getting the proper info from the GE engineer.  He found that if the device is connected via Wifi, it will work and it can roam properly.  As soon as the device is shut down and turned back on, the device will not associate again.

He brought the device to our office, we are running a newer test code there, and it worked fine.  The only thing that we have changed in the original environment is that we enabled IP Mobility for the use of our Wifi Phones.  He did notice on the controller that the user was listed under the IP MOBILE HOST table.  

Does anyone have any dieas?  Could this be a bug?

So after speaking with the vendor GE we finally got word of what the real issue is. The device works properly and it roams fine, but as soon as you turn off/on the unit, it will not associate back to the last AP it was on.  If you roam the device back to a previous AP, it will come back up.  I've tested this with 6.1.3.1 and 6.1.3.7 and the issue is there.  We are testing 6.2.1.2 and it works flawlessly though.