The problem is common but not directly recreatable. AirPlay sessions will simply fail. Sometimes a simple AirPlay reconnect works, but more often than not, the user is unable to re-start the session, or there are multiple failures in a short time. Why would the connection just cease? I know that Apple and Aerohive have recently announced their partnership, so I'd expect this to work better. Has anyone else had similar instability issues?
We are actually considering moving to Airplay direct, but I'm testing it to make sure we don't see the same issues. Initially I was resistant to Airplay direct since they recommend you reserve two wifi channels for it, but we like Airplay enough we are willing to do just about anything to make it more stable for our teachers and students.
The Main issue we still see is a teacher mirroring, then all of a sudden just gets kicked off the apple tv, then has to reconnect to the apple tv mirroring.
Everyone assumes its "Aerohive" since its newly added to the network. So we are attempting to mitigate the picks and torches coming at us. We have seen this in another network with Aerohive, but different switches. - Filtering mDNS / Broadcast Storms seems to help a little.
Is your Bonjour Gateway setup to allow all, or are you allowing only the services (appletv, sleep proxy, raop). Having too many services showing up is (probably) what caused my devices to start incrementing their names.
VLAN 23 and 24 are the Student / Staff VLANs - We found there to be a bug in 6.2r1 that the first VLAN you enter in the range will be "dropped" Aerohive stated this will be fixed at a later time.
What is the AP model do you have? is the issue observed on both radios?
Could you please try to enable a Classifier Map QoS based on the services? You may specify any type of services and apply it to the network policy.
This is just an example of QoS setting http://prntscr.com/589mzi. It does not have to be exactly like this.We seem to have TCP out of order issue on the 5GHz radio on AP370 that impacting some applications including Apple TV. Deploying this QoS seems to fix it. We have not verified the issue on other APs.
Could you please try the above suggestion and let me know? You may need to open a case if this work around does not help.
We have a iPad 1:1 program with:
- 1100 Student iPads
- 100 Faculty iPads
- 5 Real AppleTVs
- 100 Windows 7 laptops running AirServerApp
- 25 AP330s
- 75 AP121s
We have the following VLANS:
- iPad-Students (4000)
- iPad-Facutly (4001)
- Student Network (4092)
- Admin Network (4093)
- Management (4085)
- IT_Staff (4094)
Our classrooms have a hard wired podium which puts the faculty laptop on VLAN 4092
Our core/edge switches are HP Procurve( 5412zl, 5406zl, 3500yl)
We are considered a high density environment so we have forced all Student iPads to the 5Ghz radio, with the 2.4Ghz radio staggered throughout the building to help with Co-Channel Interference.
We are seeing an issue with our AP121's related to multicast traffic. The CPUs during the day with no filtering on the multicast (mDNS/Bonjour) traffic run at 100%. We feel that this is causing an issue
with airplay dropping and other connectivity issues.
We have tested multicast rate-limiting in two ways. You can issue a command on the AP via the SSH CLI:
interface eth0 rate-limit multicast 100
100 sets the eth0 interface to only allow 100kbps of multicast traffic. This seems to help lower the CPU. (You can also accomplish this via 6.2r1's new "Supplimental CLI" feature).
We have also tried limiting the multicast traffic via our backend switches but we are running into a firmware bug we are awaiting HP to resolve.
Today we setup a QOS policy for 5000,7000 & 7100 to set the DSCP value to 40. We had to set this up on the APs and on all our Core/Edge switches.
Check your AP's and their CPUs and see if they are 100%. I would love to get in contact with anyone who is also seeing these issues.