airplay connections dropping

  • 3
  • Question
  • Updated 3 years ago
Apple AirPlay, with a variety of receiver devices: MacBooks running AirServer and Reflector as well as Apple TVs, seems very unstable. Discovery is not really a problem; this isn't a Bonjour Gateway issue.

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?
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes

Posted 4 years ago

  • 3
Photo of Ryan_w

Ryan_w

  • 40 Posts
  • 8 Reply Likes
We have similar issues with Airplay and it seems to have become worse since iOS8 was released.  Maybe because of the new Airplay direct feature.  Sometimes we can stay connected for hours, but other times only seconds.  Pretty random, could even be Wifi interference I guess.  I wish Apple would make a switch to form a persistent connection which can't be dumped as easily.  

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.
Photo of Travis Kaufman

Travis Kaufman, Champ

  • 113 Posts
  • 30 Reply Likes
Same - we are testing with limiting mDNS on the network. Also trying to create seperate realms for each IDF ( x# of APs per IDF)
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
I'm working on isolating sectors of my network as well, reports aren't in yet on how much it seems to be helping AirPlay stability.
Photo of David

David

  • 18 Posts
  • 0 Reply Likes
What I did for this was to put the AppleTVs on the same vlan/subnet as the computers that are most likely/frequently connecting to them (which was the WiFi vlan). Is the airplay device name changing / incrementing?
Photo of Travis Kaufman

Travis Kaufman, Champ

  • 113 Posts
  • 30 Reply Likes
David - in our setup we have 3 VLANs 1 for Students, 1 for Staff, 1 for Networked Devices.  We saw alot of network overhead from mDNS.  So we put the Apple TVs on the Staff VLAN. So now only 2 VLANs are using bonjour from Aerohive.  We see the Apple TV names, however, they change/vary in the day. Most likely due to the TV's going into sleep mode.   

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. 
Photo of David

David

  • 18 Posts
  • 0 Reply Likes
When I had this issue it was because of the names switching/incrementing as you described. One thing I did at one point was to turn off the Bonjour service for all my Aerohive APs except for one (delete bonjour from the profile, push an update to all but 1 devices). I don't know if that helped things out,  but the incrementing due to devices seeing each other is definitely part of the problem.

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.
Photo of Travis Kaufman

Travis Kaufman, Champ

  • 113 Posts
  • 30 Reply Likes

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.  
Photo of cabrower

cabrower

  • 13 Posts
  • 2 Reply Likes
Travis do you happen to have a case# for this issue?
Photo of Travis Kaufman

Travis Kaufman, Champ

  • 113 Posts
  • 30 Reply Likes
I had a case: 00091011  But its closed. Pending an update on the bug fix. 
Photo of cabrower

cabrower

  • 13 Posts
  • 2 Reply Likes
Awesome we are on 6.2r1 and noticed a similar issue with Bonjour last night. Only certain VLANs were obtaining an IP address. So I want to see if my support guy can link the two.
Photo of cabrower

cabrower

  • 13 Posts
  • 2 Reply Likes
Not sure if they had you try this but I was just playing around with ours about an hour ago. The situation went like this:

AP (BGD) Rebooted and only 2 of the 5 vlans obtained an IP address. You can test this via this command (_test bgd show 1)

So I issued the following commands:
        no bonjour-gateway vlan 4001
*Note: (4001 was one of the missing vlans)

I then issued the following command:
        bonjour-gateway vlan 4001

Ran "_test bgd show 1" again and all the VLANs obtained addresses.
Photo of Travis Kaufman

Travis Kaufman, Champ

  • 113 Posts
  • 30 Reply Likes
Let me know if they can link them.  And no, they had me do this.  If I wanted VLAN 10-12 re-advertising.  I needed to input VLAN 9-12 then VLAN 9 would be dropped. 
Photo of Travis Kaufman

Travis Kaufman, Champ

  • 113 Posts
  • 30 Reply Likes
Its working fine, and as you mentioned we only have 1 AP as the BDD.  We want to move towards separate realms. But time permitting.... The issue is the Disconnects to the actual Apple TV, which I suspect too much mDNS traffic on the backend. 
Photo of Travis Kaufman

Travis Kaufman, Champ

  • 113 Posts
  • 30 Reply Likes
We have tried to block UDP 7000 and UDP 5353 even SOURCE any to 224.0.0.251 and bi-drectional... no luck. Apple TV = Unicorn Magic
Photo of Travis Kaufman

Travis Kaufman, Champ

  • 113 Posts
  • 30 Reply Likes
Sorry TCP 7000
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
Where have you tried to implement the blocking? If you're doing it within a local subnet, you're not going to traverse the network boundary, you'd have to do it further downstream...
Photo of cabrower

cabrower

  • 13 Posts
  • 2 Reply Likes
We have tried implementing this on our HP Core Switch:

class ipv4 "bonjour"
     10 match udp 0.0.0.0 255.255.255.255 eq 5353 0.0.0.0 255.255.255.255 eq 5353
exit


policy qos QOSBonjour
     10 class ipv4 bonjour action rate-limit kbps 100
exit


vlan 4000
     service-policy qos "QOSBonjour" in
exit
Photo of Travis Kaufman

Travis Kaufman, Champ

  • 113 Posts
  • 30 Reply Likes
is this working? Do you have counters on this?  We have a HP 5412 and HP 2920 at the access level. 
Photo of David

David

  • 18 Posts
  • 0 Reply Likes
I also downgraded 1 device (my BDD) to 6.1 to resolve my issue, but mine was mostly a discovery issue.
Photo of Travis Kaufman

Travis Kaufman, Champ

  • 113 Posts
  • 30 Reply Likes
I downgraded to 5.1r5 for outdoor AP170s
Photo of GeoffEvans

GeoffEvans

  • 11 Posts
  • 1 Reply Like
Anyone - if i have an APPLE TV on the network, What Port/IP should we create an ACL for to block the name being advertised? WE want only 1 apple tv centralized in one area, and not broadcast around our network for others to see. Any info?
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
mDNS is udp 5353
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
This is a pretty significant use case; I'd like to hear someone from Aerohive chime in.
Photo of Eastman Rivai

Eastman Rivai, Official Rep

  • 146 Posts
  • 17 Reply Likes
J

What is the AP model do you have? is the issue observed on both radios?

Thanks,
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
Eastman, I've had the issue on AP120, AP121, AP141, and AP230.
Photo of Eastman Rivai

Eastman Rivai, Official Rep

  • 146 Posts
  • 17 Reply Likes

J

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.

Thank you,
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
Something like this?

Photo of Eastman Rivai

Eastman Rivai, Official Rep

  • 146 Posts
  • 17 Reply Likes
It should be ok, you may apply it to the network policy and test.  http://prntscr.com/58a57p
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
I have updated with this setup, will be evaluating results over the next few working days.
Photo of cabrower

cabrower

  • 13 Posts
  • 2 Reply Likes
We are seeing a very similar issue and have a case open with Tier 3 at Aerohive.

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.

Chris Brower
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
Eastman,

We are in a down period right now, and AirPlay is not really being used at the moment. I will report back after we have a period of normal usage again.
Photo of cabrower

cabrower

  • 13 Posts
  • 2 Reply Likes
How are you guys making out with your issues?
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
Don't have a full pulse on the situation yet, but the problem is certainly not solved.
Photo of Travis Kaufman

Travis Kaufman, Champ

  • 113 Posts
  • 30 Reply Likes
same - issues are still present. 
Photo of Ryan_w

Ryan_w

  • 40 Posts
  • 8 Reply Likes
We are still seeing issues too.  I have been testing the new peer to peer Airplay, but even it is dropping the connection, usually only after a few minutes. We have manually assigned 5ghz channels to all our APs to avoid using 149 or 153 so peer to peer can use them.
Photo of David

David

  • 18 Posts
  • 0 Reply Likes
What helped a lot for us was to turn IGMP snooping off on our switch (juniper). Before we did this, we had a lot of problems with repeating devices and drops.
Photo of AragonHouseStud .

AragonHouseStud .

  • 1 Post
  • 0 Reply Likes
Has anyone made any progress with this? We are running APTVs on same VLAN as staff devices (APTV. Hard wired, staff ipad connecting via ap121/ap330) and ios7 ipads AirPlay fine whilst ios8 ipads drop intermittently. Anyone have success with the qos changes?
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
qos change seemed to help marginally, but I suspect the problem is a combination of AirPlay being very sensitive to sub-optimal connectivity as well as some iOS flaws

https://medium.com/@mariociabarra/wifried-ios-8-wifi-performance-issues-3029a164ce94
Photo of Ryan_w

Ryan_w

  • 40 Posts
  • 8 Reply Likes
We are still seeing problems with iOS8 and ATV and are trying to work with Apple Support to fix the problem.  Even peer to peer Airplay has the issue, so I'm not certain any network adjustments will fix your issues.  We actually just ordered a WiFi interference device analyzer to make sure we don't have interference issues in our area.
Photo of Ryan_w

Ryan_w

  • 40 Posts
  • 8 Reply Likes
So far with iOS 8.1.3 and a Gen4+ iPad Airplay peer to peer is working much better for us.  On peer to peer we can get 30-60 minutes now without a drop.  We have manually set all our 5ghz channels to avoid 149 and 153 which Airplay peer to peer uses.  It is also working better on our infrastructure network too, but usually drops in under 15 minutes.