Higher Education

We all know that Apple created a great at-home product and I'm sure we all have faculty that are yearning to use them in the classroom. If we can assume and agree for a moment that bonjour gateways (and airgroup) are simply bad ideas from a traffic flow perspective, what are other schools doing / how are other schools responding to requests for AppleTV usage in the classroom?

Currently, we're basically dealing with it and supporting the faculty as best we can for the use of a non-enterprise product in an enterprise environment.  Forcing those that insist on using it to apply a password on the device.   Then we warn them repeatedly that everyone in the building with an Apple device can see that ATV, and if they fail to secure it, we're not responsible for what ends up on the screen in the middle of their class.

So you have all wireless users in a given building on the same IP subnet? That certainly would make things easier. We enable vlan pooling and share them across campus. There's no guarantees an AppleTV and client would be on the same broadcast domain.

- Ryan -

That's correct.  We've assigned two /22 blocks for wireless (One for an SSID using WPA2 Enterprise, the other is for an open SSID secured via Captive Portal) to each of our buildings, and everyone in the building shares the same space.

We have had major issues getting Apple TV to work in our school - it is almost a year now and we have made a lot of progress with Aruba but are still not there yet.

 

As you mention - one vlan with broadcast turned on (that is Bonjour enabled) and it works fine. But this goes against good network design. We have multiple VLANS and drop broadcast and multicast - so the first issue was even getting the Apple TV's to show up.

Also - bonjour does not work across a NAT'd subnet  - another thing to watch out for...

 

Anyway - when Airgroup was released we thought we had found the answers to all our issues. But their initial release failed to mention that it didn't;t support multiple controllers - so we (our vendor and eventually Aruba) spent weeks trying to work out why it wouldn't.

Eventually the word filtered down from the US that multi controller would be supported in the next firmware release.

 

Great - no issues - at least we know why. So Apple TV now does work - but because we want to roll out 100 of them across campus - we needed a solution to restrict who could see what - Clearpass!!

 

Yes - clearpass advertises quite clearly that it supports restrict airplay devices by user and or locations. Perfect - we have clearpass already so let's go for it. Nope...Can't get it to work. Again over a week with engineers on site to finally tell us the issue is that it doesn't work with VRRP - only LMS.  Really??? REALLY??? Why is this not written on the box? Anyway - again - look at the big picture and if they have finally worked out why and we need to use LMS instead of VRRP then OK.

 

Implement the first restriction to limit the Year 6 Apple TV's to only be seen by clients on the Year 6 105 AP's and it sort of works. Sometimes you cannot see them other times you can...it is anything but stable.

 

Over 2 weeks now and they still do not have a solution. To their credit they are obviously not giving up and agree that it should work - but still struggling to work out why.

 

As an aside  - with the latest update in Apple TV you can now have the APple TV prompt for an onscreen random password each time you connect. This means that only people in the room who can see the screen can therefore see the password and connect.

 

This is better for us than having to remember static passwords and manage the issues if they leak. Also - as the kids are still on a NAT'd "guest" vlan they can't connect anyway - only the teachers on the internal vlan...but that is another thing we need to address....sigh.....

AirGroup is only officially supported in ArubaOS 6.3.0.0, which was released a couple of weels ago for Early Deployment.

 

I guess you ewere using the alpha & beta versions in a Production environment. You can expect problems when you do that.

 

Aruba should not announce new features that are nowhere neear ready for Production. AirGroup was officially announced at AirHeads 18 months before all the needed software ras released. This is unacceptable! 

 

I totally agree! Because of the premature release, it has made everyone (including Apple) telling customers like us to implement it, but it is nowhere near ready fro production. A sad state of affairs.

- Ryan -

Actually, I believe Apple said that AirPlay would work in the enterprise before Aruba announced AirPlay. A petition from the EDUCAUSE WLAN fgroup, along with other pressures, caused Apple to propose some mDNS enterprise extensions.  There is an IETF working group working on the details. If implemented, solutions such as AirGroup could become obsolete.

Bruce

Are you able to point me to where it says Airgroup is only officially supported on 6.3.0.0?

 

At no time have we been advised that Airgroup is in beta mode.... this is what we have been told direct from TAC several months ago,,

 

"Airgroup 6.1.3.4 is not supported on multiple controllers in integrated mode"

 

We are being advised to update to 6.1.3.6-airgroup, which was just released last week which does support this.

We were advised that the airgroup feature would be rolled up into the main firmware release in due course - but never advised that it was not fit for production.

 

I would never knowingly use beta products in a production environment - and if so I need to follow this up with Aruba.

Wally

I may have misspoke.

Aruba "forked" their code to develop AirGroup as a Technology Preview,, but AirGroup is fully integrated in the main OS tree in 6.3.0.0. The Technology Preview is not generally current. Notice the latest Airgroup version is 6.1.3.6, but the latest Aruba OS General Availability versions are 6.1.3.9&  6.2.1.2.

The Early Deployment 6.3.0.0 is available for early adopters.

 

 

I don't recall it saying "beta", however, you were obtaining AirGroup functionality via a "Technology Release", which means it is a branch off from the code train in order to provide specific technology feature(s). In other words, it's not baked into the standard ArubaOS releases. That's where 6.3.0.0 comes in, wherein it is part of ArubaOS.

My general rule of thumb is to put technology releases in lab environments only, only deploy early releases if you are desperate and get blessings from Aruba TAC and ACE teams; otherwise, only deploy general releases into your production environment.

- Ryan -

Ryan,

 

I agree with you.

I was the one that slipped & mentioned "beta" since Technology Previews & Beta software are both designed for Lab environments and, perhaps, very limited production deployment for testing purposes.

Thanks guys...point noted - but bottom line it still doesn't do what it says on the tin!

 

However we are desperate! We have close to 1300 iPads deployed and the need to deploy 100 Apple TV's to classrooms in the next 2 months. 

 

Maybe as you say - the answer lies more with Apple getting their act together on enterprise deployment and dropping / adapting mDNS....(sigh again...)

 

I sympathize with your situation. Unfortunately, it seems you are stuck shoehorning the consumer product into your enterprise environment. Isolated/single VLANs per classroom and/or large broadcast domains are likely the only workable and "reliable" solutions at this point.

Keep us up-to-date on progress.

- Ryan -

We are actually considering using Clearpass to completely block Apple TVs from our network - That's one way of solving the problem.  :smileyhappy:

 

Our Technology Director is somewhat antagonistic towards Apple products so that makes the decision a bit easier internally, but of course sometimes forces outside of IT make these decisions for us.  We are more heavily invested in Google products and solutions, and hope they have something comparable to Apple TV that is enterprise ready in the near future.  I am encouraged that Google has put forth a lot of effort to make Chrome OS easy to administer in an enterprise environment.

We have a similar problem to everyone else regarding network design and bonjour/mdns.

At the moment we have 6 lecture theatres running a trial Apple TV set up, but it is a local network only purely for sharing ouput accross multiple screens between pupils and staff.

ArubaOS 6.3.x will help us achieve what we want, but it is early release and we don't expect to move to it until Xmas when it is proven stable (this might change if there are no reported issues)

What we are looking at is a halfway house scenario where we might get some AP135's and utilise the 2nd network port on the AP to provide connectivity for the airport which in theory should mean that the Aruba controllers can then see the Apple AP and we can use CPPM to  have some form of control over access as well as grant external access through the apple AP which has been a common complaint amongst the test students. It will be a bit of a bodge and not very elegant, but might do until we get a later release of 6.3.x

 

 

Interesting read

 

I’ve got it working in a couple places doing some mac filtering with dhcp, more of a test scenario

 

Was thinking about a new ap group/ or perhaps a single ap config(hesitant to start a bunch of one off ap’s though) with a single vlan assigned to the VAP’s

 

I was planning on moving to 6.3 before the start of school and was looking forward to playing with the airplay feature.  I suppose I still will, but I will adjust my expectations accordingly.

 

Along those same lines has anyone given Chromecast a go?

 

chromecast wiki

So, I got Chromecast the day after the announcement at Best Buy and it is a very, very slick device.  What it does NOT have are enterprise controls like passwords to be able to Cast to a device, so until then, it will not be appropriate for Higher Education or the enterprise.

I do agree the chromecast is a slick device.... along with no password on a device - it also does not support any wpa-enterprise connections - and with only a wifi interface that presents access challenges as well

 

but it does appear to be something that access could be controlled via airgroup w/clearpass - ie utilises ssdp  etc.   so create a device wifi network / map these devices to a separate vlan - then use airgroup controls to limit discovery/access.

 

so perhaps a different option than apple TV - but not yet a better solution for Higher Ed classroom deployments etc...

We implemented 6.1.3.6-AirGroup about three weeks ago with great success in a small multi controller environment. Other than some tweaking for what the AppleTV's authenticated role was permitted to do on the network we had no issues.

Kent,

How many controllers are handling the mDNS traffic, what's the peak client count (not just iOS clients) on your highest subscribed controller, and how many controllers are in the stack? Also, are you doing vlan pooling? And can you describe your L2 and L3 topology as it pertains to your wireless network and its interconnects to the core?

Thanks in advance for sharing!

Sigh - again...:smileysad:

Just done a major upgrade on the controllers over the holidays and we seem to have gone 1 step forward and 3 steps backwards.

We have moved from 4 x 3400 controllers to 1 x 3400 as master and 1 x 7210 as controller running the 214 Ap's now deployed (90% AP105)- we plan to replace the 3400 with another 7210 as master for complete redundancy once funds become available.

 

We have also upgraded from ArubaOS 6.1.3.6-AirGroup to ArubaOS 6.3.0.0 that has rolled up the airgroup functionality into the main production OS (at least as far was we are being told).

 

With 1 controller now running the AP's -  we have 10 Class C VLAN's configured into a VLAN Pool - with IP addresses being assigned by our Windows DHCP server and 1 other VLAN assigned for the APPLETV's. Once school opens we will have about 1300 clients. We use 1 SSID with clearpass to provision the clients according to their group membership and device - eg Staff on iPads get a 10.1.X.X address - Students get a Guest VLAN IP of 192.168.X.X that has no access to the AppleTVs as Bonjour does not work across NAT subnet. Drop Broadcast and Multicast is turned ON and as well as Convert Broadcast ARP to Unicast.

 

What we are now seeing is a recurrence of the old problem that I posted before of the Apple TV being visible to the staff iPad - client connects for a period of time and mirrors OK - then connection drops and nothing will bring the Apple TV back as an option on the iPad until you turn Airplay Off and On on the AppleTV and cycle the wireless on the iPad as well (must do both).

 

Then the AppleTV reappears and then you can connect again. It may work for 15 minutes - it may work for 15 seconds - but it will drop again and you need to go through the whole process again.

 

On a side note - what has happened to the Airgroup section on the main Dashboard page - this used to show Airgroup Servers and Clients - but this is now gone on 6.3.0.0????

 

Anyone have this working with stability as yet - any advice based on the info above?

Wally

 

 

 

#7210

Very troubling issue; my sympathies. Is back dating code an option? Anything dot zero dot zero frightens me for a production network, and it appears this serves as a reminder to me about that. If you can find a temp solution to support your apple TVs without AirGroup, you could backdate to 6.2.x.x...I hear the latest is reported stable. Disclaimer: I'm on 6.1.3.8.

Good luck!

Wally,

Is it possible to do a limited test of this in your environment and then grow it slowly to other parts? There are multiple things that you are attempting. Is there a clue what is making it break? A limited rollout might help with that.

Yeah - good point - something we may well need to do.

Going back to basics for a moment as maybe I am making this all too hard - jump in at any point any correct my understanding:

 

Question 1:

With Drop Broadcast / Multicast turned ON - even if iPad and Apple TV are in the same VLAN on the same SSID - then they will not see each other without Airgroup? Correct? This is fundamental to all my understanding of what I am trying to solve here so I need to be crystal clear on this.

 

Question 2:

As Drop Broadcast / Multicast is at the SSID level - then if we were to create Multiple SSID's for each floor with broadcast enabled and clients assigned to the same VLAN - then Airplay should work without Airgroup - but we would suffer a bandwidth hit due to the broadcast traffic.?

 

We can test this to see the performance.

At a minimum we would have to have at least 1 SSID per floor of 200 clients and 10 Apple TV's. In theory we could half this again if required - as in some areas mobility is not an issue as the kids are based in classrooms. (eg we would have an SSID of Year 6 - Class1-4 and then Year 6 Class 1-8).

 

If this logic is correct then I can do some testing with just 1 or 2 clients and a new SSID to see if it works.

Appreciate the help as always

Wally.

 

 

Aghh - just thought of something...our clients do 802.11X authentication - which Apple TV does not support - so I have to have 2 SSID's no matter what if we want to continue with this.

 

So even with broadcast and multicast enabled on each SSID - will Airplay work without Airgroup? Does the enabling broadcast work across the SSID - or within the SSID?

 

IF it works across SSID then we have major issues - as if we have multiple SSID for each floor (say 20) all with broadcst enabled - then traffic will be seen by all. If broadcast stays within SSID - then we need Airgroup as Apple TV and Client cannot share the same SSID with our current authentication methods...

---

@Wally wrote:

Aghh - just thought of something...our clients do 802.11X authentication - which Apple TV does not support - so I have to have 2 SSID's no matter what if we want to continue with this.

 

So even with broadcast and multicast enabled on each SSID - will Airplay work without Airgroup? Does the enabling broadcast work across the SSID - or within the SSID?

 

IF it works across SSID then we have major issues - as if we have multiple SSID for each floor (say 20) all with broadcst enabled - then traffic will be seen by all. If broadcast stays within SSID - then we need Airgroup as Apple TV and Client cannot share the same SSID with our current authentication methods...

---

Getting to all of your questions:

 

Having the Airgroup Service enabled, you can have drop broadcast and multicast enabled, and it will still work, even across subnets.  You can have AppleTVs on one subnet, clients on another subnet and they can still find each other.

 

Drop Broadcast and Multicast works at the Virtual AP level, so you can drop it for one VAP, but allow it for another VAP, BOTH on the same VLAN.

 

If you have Apple TVs in the same space as the other WLAN you can have two SSIDs on each access point where you need to have an Apple TV.  The word is that IOS7 will support 802.1x for AppleTVs, but that is aways off, and the process to provision them is not very straightforward.

 

After that, we have to look at your RF environment to find out why things are dropping in a limited deployment.  If things work out fine, we attempt to scale.

 

 

 

 

Colin

Appreciate the reponse - but I am still wanting to clarify something as simply as possible and some of the terminolgy is still leaving me a little unclear.

---

These are the scenarios I can imagine - please let me know you if you think Airplay will work or not - or indeed if there is a scenario I have missed.

 

Scenario 1:

Airgroup Enabled

ATV SSID - MAC Auth

iPAD SSID - 802.1X

Drop Broadcast / Multicast Enabled on the Virtual AP's with both SSIDs

iPad and Apple TV in different subnets / VLAN

Will it work - Yes / No?

 

(Real life testing so far - does work but seeing constant drop outs)

 

Scenario 2:

Airgroup disabled

ATV SSID - MAC Auth

iPAD SSID - 802.1X

Drop Broadcast / Multicast Enabled on the Virtual AP's with both SSIDs

iPad and Apple TV in same VLAN

Will it work - Yes / No?

 

Scenario 3:

Airgroup disabled

ATV SSID - MAC Auth

iPAD SSID - 802.1X

Broadcast / Multicast are Enabled on the Virtual AP's with both SSIDs

iPad and Apple TV in same VLAN

Will it work - Yes / No?

 

Scenario 4:

Airgroup disabled

ATV SSID - MAC Auth

iPAD SSID - 802.1X

Broadcast / Multicast are Enabled on the Virtual AP's with both SSIDs

iPad and Apple TV in diffrent subnet VLAN

Will it work - Yes / No?

 

This is about as simple as I think I can make it for me to get it through my head!!:manvery-happy:

 

Wally

1.  Yes.

2. No.

3.  No.

 

 

The scenario where you are seeing constant drop outs, please characterize those drop outs...  Is something connected and it stops playing?

What about option 4?

 

The drop outs are exactly that - will have the screen up in mirror mode and Airplay just disconnects.

It seems to happen with more regularity when a movie of some form is playing rather than just a static image.

Wally

That would seem to be an RF issue more than anything else. The device only requires Airgroup to discover the target device. After that, there is no discovery, especially during a session.

So you seem to indicate the Airgroups only role is discovery? If you can initially see the ATV then further problems are not discovery  / Airgroup related?

 

Then I struggle to think what could be going on here - or even where to go next.

We are testing during school holidays at the moment on a floor with 8 classrooms -  1 AP105 and 1 ATV in each room.

ARM is enabled as is band steering otherwise no other fine tuning.

No students present, - just me on the empty floor otherwise connected to the AP in the classroom. Maybe 100 other clients on the network across the whole school otherwise (214 AP's) but not on this floor.

What RF issues could be at play here?

 

As an aside - in the scenarios I presented - let me rephrase - is there no configuration possible - ignoring bandwidth implications - that will allow Airplay to work - WITHOUT airgroup. I thought same subnet  - broadcast enabled would work but suck as far as bandwidth is concerned with a large client base.

 

I want to elimate Airgroup first and then start working from there and reintroduce if possible.

Wally

 

 

Colin, I think his scenario 3 will work:

 

# quote:

#Scenario 3:

#Airgroup disabled

#ATV SSID - MAC Auth

#iPAD SSID - 802.1X

#Broadcast / Multicast are Enabled on the Virtual AP's with both SSIDs

#iPad and Apple TV in same VLAN

#Will it work - Yes / No?

 

Wally, AirGroup is simply a method to circumvent Apple's limited options for service discovery. It's essentially being an arbitar for the mDNS service accouncements from the AppleTV and the mDNS service discovery messages from clients across multiple subnets. If your devices are on the same subnet AND you are not dropping bcast/mcast, then YES, this should work as it is simply a flat network. The only caveats is that you need to make sure you are stopping the traffic via the firewall. To be safe, you can add an "any any udp 5353 permit" towards the top of the role that both AppleTVs and clients receive.

 

To answer your scenarios in my opinion:

 

1.) Yes (supposedly)

2.) No, because you're dropping the mDNS traffic via the virtual-ap knob

3.) Yup, same broadcast domain (vlan) and allowing mcast/bcast

4.) No, mDNS traffic natively stays on the broadcast domain

 

From my perspective, you have what seems to be a critical application for you. If that's the case, I would NOT rely upon a brand new code train that Aruba considers "Early Availability" - despite what Aruba or others may have reported. If anything is critical in your network, it's better to wait for stability. $0.02.

 

---

@Wally wrote:

So you seem to indicate the Airgroups only role is discovery? If you can initially see the ATV then further problems are not discovery  / Airgroup related?

 

Then I struggle to think what could be going on here - or even where to go next.

We are testing during school holidays at the moment on a floor with 8 classrooms -  1 AP105 and 1 ATV in each room.

ARM is enabled as is band steering otherwise no other fine tuning.

No students present, - just me on the empty floor otherwise connected to the AP in the classroom. Maybe 100 other clients on the network across the whole school otherwise (214 AP's) but not on this floor.

What RF issues could be at play here?

 

As an aside - in the scenarios I presented - let me rephrase - is there no configuration possible - ignoring bandwidth implications - that will allow Airplay to work - WITHOUT airgroup. I thought same subnet  - broadcast enabled would work but suck as far as bandwidth is concerned with a large client base.

 

I want to elimate Airgroup first and then start working from there and reintroduce if possible.

Wally

 

 

---

Do you have any ACLs on user roles on your users AND the role that the Apple TV gets?

 

On checking - AppleTV joins via MAC Auth an is assigned an Apple TV role - VLAN 20

The Apple TV role has a 1 Policy of allow all - IPV4 Any Any Any permit

 

The users on the iPad are succesful 802.1x authentication against Clearpass get an an Authenticated role (Vlan pool)

with 2 policies:

Allow All - with IPV4 -Any Any Any permit

RA-Guard - IPV6 - User Any icmpv6 rtr-adv Deny

I recall seeing similar behavior with my initial testing with arigroup - discovery would work - but then it would drop the airplay session.  This was to official apple tv devices - didn't see it to google tv box or xbmc (those kept working fine).   It was apparently a limitation apple had placed into the airplay devices - where they only respond to packets from devices on the same subnet.   I only had the controller bridge wireless clients to vlans.... the routing was handled by upstream devices.   without a local ip on the vlans involved the controller could not re-transmit the refresh query to the apple tv sourced from a node on the same local subnet.

So this would ultimately break the airplay link - by putting a local ip on the controller for the apple-tv vlan made the apple devices much happier. 

 

This was with the early tech releases for air-group.   So my apologies if they did ultimately find a work around and this issues no longer applies... but it just sounds sooo familiar to what had me pulling my hair out.  

---

This sounds hopeful - but I must admit I am a little confused as to the exact implementation you suggest.

 

My mind may work diffrerently - but if outline our setup - any specific feedback would be appreciated.

For example:

 

At present - the Controller hosting the AP,  Apple TV and iPad in question has an IP of 10.1.80.5 (part of VLAN 20 - 255.255.255.252)

The AP in the classroom gets an IP from DHCP for the VLAN of the switch in that buildng - for example - 10.1.140.50

The Apple TV in that classroom - joins via MAC Auth and is assigned an IP from DHCP according to its role from VLAN 20 of 10.1.81.78 (255.255.255.222)

The iPads join and get an iP from DHCP in the VLAN pool that is one of 10 Class C addresses -10.1.188.X - through 10.1.198.X

 

So in this case the the Controller and the Apple TV share an IP from the same VLAN 20 Subnet ( I assume this is what you mean?).

Do you suggest that the controller also has to have a local IP from the VLAN pool the clients use assigned to it as well? If so - how and where would this be applied?

Many thanks

Wally

 

---

@Wally wrote:

---

At present - the Controller hosting the AP,  Apple TV and iPad in question has an IP of 10.1.80.5 (part of VLAN 20 - 255.255.255.252)

The Apple TV in that classroom - joins via MAC Auth and is assigned an IP from DHCP according to its role from VLAN 20 of 10.1.81.78 (255.255.255.222)

 

---

Wally, I'm confused. I'm interpreting your configuration to look something like this then:

 

vlan 20
interface vlan 20
 ip address 10.1.80.5 255.255.255.252
!
user-role "AppleTV"
 vlan 20
!

 However, you said that the AppleTV gets an address from 10.1.81.64/27 (I assumed your 255.255.255.222 mask was a typo). There seems to be an overlap of networks here. You have vlan 20 for the controller assigned as 10.1.80.4/30 but the AppleTV ALSO gets vlan 20 but is associated with 10.1.81.64/27. How is connectivity working at all?

 

---

@Ryan wrote:

---

@Wally wrote:

---

At present - the Controller hosting the AP,  Apple TV and iPad in question has an IP of 10.1.80.5 (part of VLAN 20 - 255.255.255.252)

The Apple TV in that classroom - joins via MAC Auth and is assigned an IP from DHCP according to its role from VLAN 20 of 10.1.81.78 (255.255.255.222)

 

---

Wally, I'm confused. I'm interpreting your configuration to look something like this then:

 

vlan 20
interface vlan 20
 ip address 10.1.80.5 255.255.255.252
!
user-role "AppleTV"
 vlan 20
!

 However, you said that the AppleTV gets an address from 10.1.81.64/27 (I assumed your 255.255.255.222 mask was a typo). There seems to be an overlap of networks here. You have vlan 20 for the controller assigned as 10.1.80.4/30 but the AppleTV ALSO gets vlan 20 but is associated with 10.1.81.64/27. How is connectivity working at all?

 

---

Sorry - big typo - try a Subnet of 255.255.252.0 - this give an IP range of 10.1.80.0 - 10.1.83.255

Does this make more sense?

Wally

Understood, however you still would have a client with a source IP address of 10.1.81.78/22  (for example) on vlan 20, and since the controller has an address on vlan 20, it would send it using the vlan 20 interface of the controller. However the subnet mask of the controller does not match that of the client; 10.1.81.78 is not an address that falls within 10.1.80.4/30. I'm still confused on how you're able to pass any traffic at all.

 

To clear this up, I would use a different vlan ID and subnet (that does not overlap) for your clients than from your controller.

 

trschick's anecdotyl statement sounds like a likely problem too. For whatever it's worth, I have a couple of IAPs at home and had to disable AirGroup in order for my iPad/iPhone to consistently see the AppleTV as an option. Otherwise, my experience mirrored that of trschick.

Wally,

 

For what it is worth, everything that Ryan is saying is correct...  BUT this is something that you need to first deploy in simple, straightforward circumstances FIRST and then grow them to more complicated scenarios.

 

Clients in the same VLAN with "drop broadcast and multicast" off or on should work all the time with Airgroup Enabled

Clients in diffrent VLANS with "drop broadcast and multicast" off or on should work all the time with Airgroup Enabled

IPV6 on creates a variable where devices could discover each other over IPV6, BUT if you are using VLAN pooling, they might not be able to reach each other over IPV6, so it will not work.  IPV6 should be off, period.

 

Long story short, start out with simple use cases and make sure it works for those cases.  Other things like masks and addressing that Ryan brought up can be looked at, at the same time to ensure everything is okay.  ClearPass Policy Manager enforcement for Airgroup does not need to be enabled until later...  Start simple, and find out where it breaks, otherwise it is almost impossible to get to the bottom of what is happening here.

---

@Ryan wrote:

Understood, however you still would have a client with a source IP address of 10.1.81.78/22  (for example) on vlan 20, and since the controller has an address on vlan 20, it would send it using the vlan 20 interface of the controller. However the subnet mask of the controller does not match that of the client; 10.1.81.78 is not an address that falls within 10.1.80.4/30. I'm still confused on how you're able to pass any traffic at all.

 

To clear this up, I would use a different vlan ID and subnet (that does not overlap) for your clients than from your controller.

 

trschick's anecdotyl statement sounds like a likely problem too. For whatever it's worth, I have a couple of IAPs at home and had to disable AirGroup in order for my iPad/iPhone to consistently see the AppleTV as an option. Otherwise, my experience mirrored that of trschick.

---

Sorry - still wasn't clear enough the subnet mask was a typo in both instances- both the controller and the Apple TV have the same subnet mask /22  - so 10.1.80.4 and and 10.1.81.78 are on the same subnet.

It sounds like your config should not be impacted with the issue I had making the apple TV disappear.

 

I dug through my email and here is specifically the issue I ran into:

-----------------------------------------------

it appears the appletv will not respond to this query....

-----------------------------------------------

 

and looks like this has been addressed in more recent code.

 

I concur that there appear to be multiple issues to investigate - device discovery is one

the stream between ipad/appletv is another

 

are any other wifi client - to - client streams impacted.... ie scp/ftp between clients or perhaps a skype call to pc on the appletv vlan - at least determine if it is specific to airplay or for any long connection - the up to 15 minutes might indicate some sort of timer... are devices asked to reauth...perhaps dhcp? and perhaps that is impacting airplay enough to drop any current streaming session

 

You don't have anything that on the controller that kills client - to - client communication.

 

More testing today...

I have removed CPPM from the Airgroup settings on the controller so that there is no restrictions or limitations being applied based on locations or users. The AppleTV in question was not registered with CPPM anyway - but just wanted to make sure).

 

Then setup an ATV on VLAN 20 - 10.1.80.88

an iPad client on VLAN 139 - 10.1.197.10

and a wired desktop - 10.1.141.35

 

Started a ping between the desktop and the ATV and the desktop and iPad and all replied OK.

Then started from iPad connected to ATV and mirrored and ran a photo slideshow and within several minutes the connection drops and the ATV disappears from the iPad (it appears to happen more frequently with videos rather than images - but this is not conclusive by any means).

 

Now interesting thing is that the ping between desktop and iPad starts to timeout. Check the iPad and the iPad still shows joined to the Wireless network with full strength - but there is no network connectivity. Ran a show users on the controller and still shows me as associated to the SSID - but I can't connect to anything from the iPad.

 

Turn wireless off and on and ping instantly comes back and ATV is now visible again and I can connect and mirror again. Run it for several minutes and the again it drops - pings timeout and same situation again. Throughout this the ATV replies to all pings.

 

So - is this not an Airplay issue at all but an iPad or wireless issue on the VAP being used for the iPads??? (using clearpass to authenticate the user).

 

As a test - I setup the iPad to not autolock and ran a photo slideshow locally - but not in Airplay mode - and pinged the Ipad - 2 hours later - no timeouts and the iPad is still connected.

So - does Airplay cause the issue - or does another issue show up only during Airplay actvitiy? I can maybe understand Airplay dropping but not total failure of nertwork connectivity.

 

Put the controller into logging level debug user and watched for what happens during the drop and I see: (the ipad mac is 34:51:c9:df:a8:56)

 

Aug 17 14:20:45 :527000:  <DBUG> |mdns|  mdns_send_packet_pseudo_mcast 496 MDNS Pkt to SOS: pkt_len=1382, buf_len=14336. To=34:51:c9:df:a8:56, vlan=139

Aug 17 14:20:45 :527000:  <DBUG> |mdns|  mdns_generate_response_packet 1544 Sending solicited fragmented response to mac: 34:51:c9:df:a8:56

Aug 17 14:20:45 :527000:  <DBUG> |mdns|  mdns_send_packet_pseudo_mcast 496 MDNS Pkt to SOS: pkt_len=1384, buf_len=14336. To=34:51:c9:df:a8:56, vlan=139

Aug 17 14:20:45 :527000:  <DBUG> |mdns|  mdns_generate_response_packet 1544 Sending solicited fragmented response to mac: 34:51:c9:df:a8:56

Aug 17 14:20:45 :527000:  <DBUG> |mdns|  mdns_send_packet_pseudo_mcast 496 MDNS Pkt to SOS: pkt_len=1400, buf_len=14336. To=34:51:c9:df:a8:56, vlan=139

Aug 17 14:20:45 :527000:  <DBUG> |mdns|  mdns_generate_response_packet 1544 Sending solicited fragmented response to mac: 34:51:c9:df:a8:56

Aug 17 14:20:45 :527000:  <DBUG> |mdns|  mdns_send_packet_pseudo_mcast 496 MDNS Pkt to SOS: pkt_len=1386, buf_len=14336. To=34:51:c9:df:a8:56, vlan=139

Aug 17 14:20:45 :527000:  <DBUG> |mdns|  mdns_generate_response_packet 1544 Sending solicited fragmented response to mac: 34:51:c9:df:a8:56

Aug 17 14:20:45 :527000:  <DBUG> |mdns|  mdns_send_packet_pseudo_mcast 496 MDNS Pkt to SOS: pkt_len=372, buf_len=14336. To=34:51:c9:df:a8:56, vlan=139

Aug 17 14:20:45 :527000:  <DBUG> |mdns|  mdns_generate_response_packet 1562 Sending solicited response to mac: 34:51:c9:df:a8:56

Aug 17 14:20:45 :527000:  <DBUG> |mdns|  rx_mdns_pkt_from_sos 472 Rcvd packet from SOS: vlan 139, len 117

Aug 17 14:20:45 :527000:  <DBUG> |mdns|  mdns_parse_packet_from_sos 417 pkt from SOS: vlan 139, mac 34:51:c9:df:a8:56 ip 10.1.197.10

Aug 17 14:20:45 :527000:  <DBUG> |mdns|  mdns_parse_packet 2216 mdns response packet received; mac=34:51:c9:df:a8:56, ip=10.1.197.10, origin=1

Aug 17 14:20:45 :527000:  <DBUG> |mdns|  mdns_cache_update 528 mac 34:51:c9:df:a8:56 cache write; cache_flush=0, name=_dacp._tcp.local, type=PTR, clasz=IN

Aug 17 14:20:45 :527000:  <DBUG> |mdns|  mdns_cache_update 538 mac 34:51:c9:df:a8:56 goodbye

 

 

The last line is pretty definitve - GOODBYE!!

 

Now as trschick suggested - maybe this is not unique to Airplay - so I need to test with another app that will generate constant traffic such as skype or ftp - will do that next but any ideas based on the above is appreciated.

 

Wally

You said iPad remains in user table but what about association table?

What does show ap remote debug mgmt-frames for that ap/iPad show? Anything occur during that period?

Anything show auth-tracebuf for the iPad during that time?

What does show arm history for that ap show during that time?

What are your dhcp lease times and does this occur at or half of the max lease time period?

When connectivity breaks:
- does your router have an arp entry still for the iPad?
- can the iPad ping its default gateway IP? (Net Master is a good iOS tool.)
- assuming there's an IP on the iPad vlan, does the controller still have an arp entry for the iPad?


I can say that iOS devices do a very poor job encoding video and actually send the entire image/screen_frame continuously (rather than send diffs like other encoded video streams). That being said, I imagine the tolerance is fairly low. FTP/Skype tests are a good idea; looking forward to hearing those results.

OK more testing today:

 

Came into work and the iPad in question was being pinged overnight and had not lost connectivity.

 

Started Airplay and within 10 minutes it had dropped again.

 

Then I started Goodplayer a video player App which allows you to transfer the files via HTTP – and did this between a workstation and the iPad and it copied 4 x 700Mb files over about 40 minutes and never dropped once. I also streamed a video straight from Goodplayer on the iPad to the desktop and again it played no issues and I never lost connectivity. Of course – lack of symptoms doesn’t mean that there is no issue – just that it didn’t show up during this test

.

What I did not test was extended transfer of files from one WIRELESS VLAN to another WIRELESS VLAN – this test was Wireless to Wired. When I get my hands on two iPads tomorrow I can test that.

 

Also - Ryan, went through your suggestions and:

Once dropped - cannot ping default gateway for the VLAN from the iPad

 

Checked Arm History on the AP in question and it hadn’t changed since the 14th August when it increased its power.

 

TTSWLSW02) #show ap arm history ap-name APN

 

Interface :wifi0

Interface :wifi1

ARM History

-----------

Time of Change       Old Channel  New Channel  Old Power  New Power  Reason

--------------       -----------  -----------  ---------  ---------  ------

2013-08-14 15:36:34  11           11           18         21         P+

I: Interference, R: Radar detection, N: Noise exceeded, Q: Bad Channel Quality E: Error threshold exceeded, INV: Invalid Channel, G: Rogue AP Containment, M: Empty Channel, P+: Increase Power, P-: Decrease Power, 40INT: 40MHZ intol detected on 2.4G, NO40INT: 40MHz intol cleared on 2.4G, OFF: Turn off Radio, ON: Turn on Radio

 

 

User table still showed the iPad entry and the Association table for the AP still showed my iPad after the drop.

Did a remote debug mgmt. frames after I connected and then ran it again after a drop and nothing changed after the drop.

The last entry as was the initial success of the first join.

 

#show ap remote debug mgmt-frames ap-name APN

 

Traced 802.11 Management Frames

-------------------------------

Timestamp        stype         SA                 DA                 BSS                signal  Misc

---------        -----         --                 --                 ---                ------  ----

Aug 18 09:39:43  assoc-resp    d8:c7:c8:ad:30:58  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58  15      Success

Aug 18 09:39:43  assoc-req     34:51:c9:df:a8:56  d8:c7:c8:ad:30:58  d8:c7:c8:ad:30:58  36      -

Aug 18 09:39:43  auth          d8:c7:c8:ad:30:58  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58  15      Success (seq num 2088)

Aug 18 09:39:43  auth          34:51:c9:df:a8:56  d8:c7:c8:ad:30:58  d8:c7:c8:ad:30:58  60      -

Aug 18 09:39:30  disassoc      34:51:c9:df:a8:56  d8:c7:c8:ad:30:58  d8:c7:c8:ad:30:58  60      STA has left and is disassociated

Aug 18 09:31:36  deauth        d8:c7:c8:ad:30:58  60:fe:c5:f4:11:08  d8:c7:c8:ad:30:58  15      - (internal only)

Aug 18 09:31:11  disassoc      60:fe:c5:f4:11:08  d8:c7:c8:ad:30:58  d8:c7:c8:ad:30:58  60      STA has left and is disassociated

Aug 18 09:30:51  assoc-resp    d8:c7:c8:ad:30:58  60:fe:c5:f4:11:08  d8:c7:c8:ad:30:58  15      Success

Aug 18 09:30:51  assoc-req     60:fe:c5:f4:11:08  d8:c7:c8:ad:30:58  d8:c7:c8:ad:30:58  29      -

Aug 18 09:30:51  auth          d8:c7:c8:ad:30:58  60:fe:c5:f4:11:08  d8:c7:c8:ad:30:58  15      Success (seq num 46)

Aug 18 09:30:51  auth          60:fe:c5:f4:11:08  d8:c7:c8:ad:30:58  d8:c7:c8:ad:30:58  60      -

Aug 18 09:29:45  assoc-resp    d8:c7:c8:ad:30:50  14:36:05:e8:6b:b5  d8:c7:c8:ad:30:50  15      Success

 

Then did the auth-tracebug and similar results – nothing changed between the initial join and after the drop.

 

#show auth-tracebuf mac 34:51:c9:df:a8:56

 

Auth Trace Buffer

-----------------

 

 

Aug 18 09:47:16  station-down           *  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58                   -      -

Aug 18 09:48:31  station-up             *  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58                   -      -    wpa2 aes

Aug 18 09:48:31  eap-id-req            <-  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58                   1      5

Aug 18 09:48:31  eap-id-resp           ->  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58                   1      11   wally

Aug 18 09:48:31  rad-req               ->  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58                   65484  201

Aug 18 09:48:31  rad-resp              <-  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58/Clearpass-Server  65484  76

Aug 18 09:48:31  eap-req               <-  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58                   2      6

Aug 18 09:48:31  eap-resp              ->  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58                   2      166

Aug 18 09:48:31  rad-req               ->  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58/Clearpass-Server  65485  386

Aug 18 09:48:31  rad-resp              <-  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58/Clearpass-Server  65485  984

Aug 18 09:48:31  eap-req               <-  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58                   3      908

Aug 18 09:48:31  eap-resp              ->  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58                   3      144

Aug 18 09:48:31  rad-req               ->  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58/Clearpass-Server  65500  364

Aug 18 09:48:31  rad-resp              <-  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58/Clearpass-Server  65500  139

Aug 18 09:48:31  eap-req               <-  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58                   4      69

Aug 18 09:48:31  eap-resp              ->  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58                   4      6

Aug 18 09:48:31  rad-req               ->  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58/Clearpass-Server  65479  226

Aug 18 09:48:31  rad-resp              <-  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58/Clearpass-Server  65479  113

Aug 18 09:48:31  eap-req               <-  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58                   5      43

Aug 18 09:48:31  eap-resp              ->  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58                   5      43

Aug 18 09:48:31  rad-req               ->  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58/Clearpass-Server  65478  263

Aug 18 09:48:31  rad-resp              <-  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58/Clearpass-Server  65478  145

Aug 18 09:48:31  eap-req               <-  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58                   6      75

Aug 18 09:48:31  eap-resp              ->  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58                   6      107

Aug 18 09:48:31  rad-req               ->  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58/Clearpass-Server  65506  327

Aug 18 09:48:31  rad-resp              <-  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58/Clearpass-Server  65506  161

Aug 18 09:48:31  eap-req               <-  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58                   7      91

Aug 18 09:48:31  eap-resp              ->  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58                   7      43

Aug 18 09:48:31  rad-req               ->  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58/Clearpass-Server  65499  263

Aug 18 09:48:31  rad-resp              <-  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58/Clearpass-Server  65499  113

Aug 18 09:48:31  eap-req               <-  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58                   8      43

Aug 18 09:48:31  eap-resp              ->  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58                   8      43

Aug 18 09:48:31  rad-req               ->  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58/Clearpass-Server  65495  263

Aug 18 09:48:31  rad-accept            <-  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58/Clearpass-Server  65495  247

Aug 18 09:48:31  eap-success           <-  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58                   8      4

Aug 18 09:48:31  wpa2-key1             <-  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58                   -      117

Aug 18 09:48:31  wpa2-key2             ->  34:51:c9:df:a8:56  d8:c7:c8:ad:30:58                   -      117

 

 We are meeting with the Vendor on Tuesday and they will Open a case with TAC for us - (our support agreement does not allow us to contact TAC directly).

 

Will test with 2 iPads tomorrow and see if we can make it happen on something other than Airplay.

Wally

What about show datapath session table | include <ip address> ? Are there table entries when you lose connection? I have seem a couple of 802.1X issues where the table entries disappeared, but only when using 802.1X on ArubaOS 6.3.0.1.

 

---

@bosborne@liberty.edu wrote:
What about show datapath session table | include <ip address> ? Are there table entries when you lose connection? I have seem a couple of 802.1X issues where the table entries disappeared, but only when using 802.1X on ArubaOS 6.3.0.1.

---

Great - Will try that tomorrow as well - I think we will also try setting a VAP on the same VLAN without 802.1X and see what happens.

We are on 6.3.0.0 at the moment.

Wally

 

Remind me... have you verified whether or not the drops occur when iPad and appletv are on SAME vlan AND AirPlay/AirGroup is turned off on the controller?

Is there any reason you are not running 6.3.0.1? Although I do not see it in the release notes, there may be a patch in there that resolves or changes your issue.

Back with more updates!!

 

Yes - can confirm that with iPads on same VLAN 20 (non 802.1x) we do not see this activity at all.

 

Have tested with multiple iPads today using Facetime between them for over 2 hours and no drop outs.

 

Went back to Airplay and tested different iPads on different AP's and different Apple TV's - same issue - disconnect in less then 10 minutes and the iPads in question lose all network connectivity - but User Table and Association table show as connected.

 

Did the #show datapath session table | include 10.1.197.14 of the iPad in question after the drop and the results were

10.1.128.47     10.1.197.14     1    61117 2048   0/0     0 0   1   pc1         5    1         60         FCI
10.1.128.47     10.1.197.14     1    61111 2048   0/0     0 0   1   pc1         a    0         0          FCI
10.1.128.47     10.1.197.14     1    61102 2048   0/0     0 0   1   pc1         f    0         0          FCI
10.1.197.14     10.1.128.47     1    61117 0      0/0     0 0   0   pc1         5    0         0          FYI
10.1.197.14     10.1.128.47     1    61111 0      0/0     0 0   1   pc1         a    0         0          FYI
10.1.197.14     10.1.128.47     1    61102 0      0/0     0 0   1   pc1         f    0         0          FYI

 

The 10.1.128.47 is the IP of my workstation doing the ping test to the iPad - no other traffic was showing.

 

Turned wireless off and on and ping came back as did all other traffic as shown in the same command (abbreviated results)

(TTSWLSW02) #show datapath session table | include 10.1.197.14
10.1.128.47     10.1.197.14     1    61147 2048   0/0     0 0   1   pc1         11   0         0          FCI
10.1.197.14     17.173.254.222  17   16403 16385  0/0     0 24  0   tunnel 613  4    3         132        FTC
10.1.128.47     10.1.197.14     1    61153 2048   0/0     0 0   1   pc1         c    0         0          FCI
10.1.128.47     10.1.197.14     1    61165 2048   0/0     0 0   0   pc1         1    1         60         FCI
10.1.128.47     10.1.197.14     1    61159 2048   0/0     0 0   1   pc1         6    0         0          FCI
10.1.128.47     10.1.197.14     1    61167 2048   0/0     0 0   0   pc1         0    1         60         FCI
10.1.197.14     17.173.254.223  17   16403 16386  0/0     0 24  0   tunnel 613  4    3         132        FTC
10.1.197.14     17.151.224.30   6    55658 443    0/0     0 24  0   tunnel 613  4    9         2012       TC
10.1.197.14     96.16.170.161   6    55659 443    0/0     0 24  0   tunnel 613  4    8         1099       TC
10.1.197.14     10.1.5.9        17   57206 53     0/0     6 56  0   tunnel 613  4    0         0          FTCI
10.1.197.14     17.173.254.222  17   16403 16384  0/0     0 24  0   tunnel 613  4    4         176        FTC
10.1.5.9        10.1.197.14     17   53    57206  0/0     0 56  0   tunnel 613  4    0         0          FI
10.1.5.9        10.1.197.14     17   53    55585  0/0     0 56  0   tunnel 613  5    0         0          FI
17.173.254.223  10.1.197.14     17   16386 16403  0/0     0 24  0   tunnel 613  4    0         0          FY
10.1.197.14     224.0.0.251     17   5353  5353   0/0     0 24  0   tunnel 613  5    0         0          FTCI
10.1.197.14     96.7.55.11      6    55656 80     0/0     0 24  0   tunnel 613  5    0         0          TCI
10.1.5.9        10.1.197.14     17   53    50589  0/0     0 56  0   tunnel 613  4    0         0          FI
17.173.254.222  10.1.197.14     17   16384 16403  0/0     0 24  0   tunnel 613  4    0         0          FY
17.173.254.222  10.1.197.14     17   16385 16403  0/0     0 24  0   tunnel 613  4    0         0          FY
10.1.197.14     10.1.5.9        17   50589 53     0/0     6 56  0   tunnel 613  4    0         0          FTCI
96.16.170.161   10.1.197.14     6    443   55659  0/0     0 24  0   tunnel 613  4    7         3960
10.1.197.14     10.1.128.47     1    61147 0      0/0     0 0   1   pc1         11   0         0          FYI
96.7.55.11      10.1.197.14     6    80    55656  0/0     0 24  0   tunnel 613  5    0         0
10.1.197.14     10.1.128.47     1    61153 0      0/0     0 0   1   pc1         c    0         0          FYI
17.151.224.30   10.1.197.14     6    443   55658  0/0     0 24  0   tunnel 613  4    8         5191
10.1.197.14     10.1.128.47     1    61167 0      0/0     0 0   0   pc1         0    1         60         FI
10.1.197.14     10.1.128.47     1    61165 0      0/0     0 0   0   pc1         1    1         60         FI
10.1.197.14     10.1.128.47     1    61159 0      0/0     0 0   1   pc1         6    0         0          FYI
10.1.197.14     10.1.5.9        17   55585 53     0/0     6 56  1   tunnel 613  5    0         0          FTCI

 

So still puzzling - any other advice on what to trace when this happens? Still waiting for Aruba to come in tomorrow - so may be able to get somewhere - but likely to be a day of collection logs first...

Wally

Looks like traffic should be flowing through tunnel 613 from controller to ap. when problem happens, you can examine show datapath tunnel table | include "613 " and see if traffic continues incrementing into the tunnel.

I agree...get to 6.3.0.1 just in case.

I have to say, however, that at some point it is wise to digest this as evidence of a "x.x.0.0" release's performance for a feature that breaks the RFC for multicast DNS (ie passing discovery messages across broadcast domains). I know you want it to work and Aruba says "absolutely it will work" but your circumstance and likely others' show it does not. Bottom line: not ready for prime time....$0.02.

I can confirm the issue trschick is reporting was limited to 6.1.3.4-AirGroup code and was corrected in 6.1.3.6-AirGroup.  This also shouldn't be seen as an issue in 6.3.0.0.

OK - just a few updates as a result of last minute testing today..

 

IPV6 is already disabled - confirmed.

 

Started rolling back the setup today step by step to see what would happen.

Removed 1 Apple TV from clearpass - but still had AppleTV and Controller in VLAN 20 - and iPad in VLAN 131.

Airgroup Enabled - Drop Multicast / Broadcast enabled.

Same old problem - can see and Connect to Apple TV no issue - but repeatedly drops connection AND AppleTV is no longer visible on iPad until Airplay is cycled on Apple TV as well as wirless on iPad.

 

Next Step - joined my iPad to the same MAC Auth SSID as the Apple TV and as such received an IP in same VLAN 20.

All other configs remain the same.

Apple TV was visible and remained stable for around 15 minutes and then dropped - BUT and this is the BIG but  - Apple TV was still visible as an option on the iPad and I simpy reconnected. This is in stark contrast to the previous scenarios of the AppleTV not only dropping the connection but disappearing from the iPad as an option until airplay is cycled off and on.

 

As of leaving the office today - the iPad was still mirroring OK. Obvioulsy more extensive testing needed and i am not drawing any conclusions on 30 minutes of testing - but with time zone differences just wanted to give an update.  

 

Wally

Sounds like you have two problems then.

1.) disconnects...need to throw both tv and iPad in debug and watch logs for when this happens. Look at mgmt-frames to see if its a roaming event or perhaps arm scanning or something else that correlates with drops.

2.) service discovery intermittently not working with AirGroup. Open a case.

---

@Wally wrote:

On checking - AppleTV joins via MAC Auth an is assigned an Apple TV role - VLAN 20

The Apple TV role has a 1 Policy of allow all - IPV4 Any Any Any permit

 

The users on the iPad are succesful 802.1x authentication against Clearpass get an an Authenticated role (Vlan pool)

with 2 policies:

Allow All - with IPV4 -Any Any Any permit

RA-Guard - IPV6 - User Any icmpv6 rtr-adv Deny

---

I would just disable IPV6, period on the controller while you are doing this. (config) #no ipv6 enable.  Why do you have that RA-Guard ACL in there?

 

Wally, are you certain that the client isn't roaming during this drop?

 

Im not all that well versed with the interworkings of the bonjour service or airgroup as of yet, but i'm trying lol

 

just flipped through the release notes for 6.3.0.1, I didn't see a hit with regards to your airplay issue

Not 100% sure - no - can look into that and see if the client does jump AP's but I don't believe so.

Even if it does - why would I have to cycle airplay and the wireless on the iPad for the Apple TV to show up again. It is almost as if the 2 devices have to reregister with Airgroup server to show up again. Maybe a drop I can undersrtand and then a quick reconnect - but the actual Apple TV disappears from the list.

 

With all the AP's in the same AP Group I would assume this information would still be known.

 

Just wanted to say thanks for this thread.  I'm the network admin for a K-12 school district (37,000 kids, 8,000 staff).  We currently have around 200 ATV's in production.

 

Recently we've created a new SSID for the ATV's.  We set the Vlan Pool it uses to the same as our internal SSID vlan.

 

We are on 6.1.3.6-Airgroup.

 

We've had mixed results.  Previously we had the ATV's on the Same 802.1x authenticated SSID as the clients.  We had issues when the ATV's lost power, they would also lose their time.  When this happens the certificate is unable to be validated when it tries to reconnect to the network.  (Frustrating).

 

We do not have Airgroup enabled.  We do not use Clearpass.  We do NOT drop broadcast and multicast.

 

We've found on the same SSID, using the same VLAN Pool, it works great!  (It doesn't matter if they're on the same network, as long as their in the same pool).

 

On seperate SSID's, using the same VLAN (only one vlan), it works great!

 

On seperate SSID's, using the same VLAN Pool, it works if they automagically get the same network.  If they do not get the same network, it doesn't show up.

 

The issue we currently have is that we can't run the ATV's on the same SSID as our clients, due to the ATV's 802.1x drawbacks when the devices completely lose power.  They're unable to connect to the mandatory NTP server.  We're struggling :-(

 

We're rather reluctant to goto 6.3.x.x so far.

 

Our administration needs a solution, as these are not going away anytime soon.  Great thread!

 

Ok some more updates and seems we may be getting somwhere at last:

We have had our vendor in working with TAC remotely and the summary of the invetigation is:

 

Issue Description

>> ipads laggy and frequently dropping off network when using airplay, happens on wpa-aes2 ssid, but not on psk or open

 

Observations

>> whilst the issue is triggered by airplay, it seems to be not directly related to airplay

>> client is still associated when issue occurs

>> issue happens randomly, but needs airplay traffic to trigger it

>> datapath, ap, tunnels etc all look fine when issue happens

>> there are no logs or events that suggest when the issue happens – these two points start to suggest AP itself is involved.

>> ap debug client table shows packets still tx/rx when issue happens which is a little strange.

 

Workaround

>> disable mpdu-agg in ht ssid profile

>> cost of workaround is reduced thruput.

 

Todo – Aruba

>> I have enough information to attempt a reproduction – I don’t have an appleTV though, but will try to workaround

>> raise bug on the issue once determined it’s not already fixed in 6.3.0.1

>> analyze the crash that happened when trying to disable aggressive scanning.

 

Todo –

>> need to get 6.3.0.1 into the network as it has fixes and R&D may ask for this step anyways

 

So for us - we are still waiting to get onto 6.3.0.1. We have had a big conference on this week and I don't want to mess about with firmware updates until this finishes - so next week will do the update.

 

Testing in classrooms so far this week has shown Airplay to be stable (as in no drop outs) - but video mirroring is jerky about every 2-3 seconds (note: this across VLANS - with users on 802.1x) so still not a perfect solution.

 

Swapping back to both users and AppleTV on the same MAC Auth VLAN and video is smooth and no airplay issues (as shown previously)

 

We are certainly 1 step forward in having Aruba determine the issue - but fair enough from their side that they want us on the latest firmware before raising a bug report.

 

Will update once we have gone to 6.3.0.1

Wally

 

 

"We do not have Airgroup enabled. We do not use Clearpass. We do NOT drop broadcast and multicast.

We've found on the same SSID, using the same VLAN Pool, it works great! (It doesn't matter if they're on the same network, as long as their in the same pool)."


No AirGroup and on different L2 segments and it works?....How is that possible (assuming you have more than 1 network in vlan pool)

"No AirGroup and on different L2 segments and it works?....How is that possible (assuming you have more than 1 network in vlan pool)"

 

That's a great question!  I'm not exactly sure... 

 

(aruba1) # show airgroup status

AirGroup Feature
----------------
Status
------
Disabled

AirGroup Enforce Registration
-----------------------------
Status
------
Disabled

AirGroup Service Information
----------------------------
Service Status
------- ------
airplay Enabled
airprint Enabled
itunes Enabled
remotemgmt Enabled
sharing Enabled
chat Enabled
allowall Enabled