Security

Airheads, 

 

We've been having a bit of an issue with using Airplay during peak client density times. The connection from the client to the AppleTV severs without warning and then can be reconnected again. This tends to happen only during times where the classrooms are fully populated with students (also the worst time for it to fail). 

 

I am running 6.3.1.4 with Airgroup enabled, ARM settings set to default other than "Mode Aware Arm" being enabled, which wasn't enabled previously with the same issue occuring. I was using my own blend of uneducated guesses previously and last night created a clean ARM profile to test with and just re-enabled the Mode Aware Arm. I'll be finding out today if we still are experiencing issues. 

 

We have added an AP into every classroom in an effort to troubleshoot this issue. I also set the AP's to prefer 5GHz since they are now in closer proximity to each other. We have a mix of 105's, 125's and 135's. 

 

A few weeks back we discovered interference on 2.4Ghz due to some HVAC Variable Frequency Drives that we have since disabled for troubleshooting purposes. 

 

My questions are as follows:

 

What commands in the CLI can I use to watch the specific MAC address of the AppleTV in question to see if it gets reassociated to another AP during it's active connection?

 

Is "Client Aware" or "Client Match" supposed to leave that AppleTV on the current controller until it stops having an active connection? Is there another command that should do that? What are the implications campus wide of enabling such command if it should resolve our load balancing issue? 

 

Given the standard ARM profile, should the AppleTV's "stick" to their associated AP, even when there are a lot of clients on it's AP vs fewer on the close neighbor AP?

 

Thanks for the help, I'm running out of guesses on this one. 

 

#AP135

theiglu,

 

You should be able to see a device advertise itself in Airgroup as long as it is in the "airgroup servers" table.  It should stay there until it ages out (it could take 10 minutes)  It should be that way regardless of RF interference.  If your client device has a problem getting on the network, that will affect if it sees airgroup be advertised, or not.

 

Do you have "Drop Broadcast and Multicast" enabled on all of your Virtual APs to prune to useless multicast?

 

No, I was concerned that would kill AirGroup. I assume it's safe to use with Airgroup from your statement?

Keeps warning me about "Broadcast-Filter ARP" not being enabled and how without that it will kill all ARP requests (bad). 

 

But, in my Stateful Firewall, the Broadcast Filter ARP setting has no checkbox next to it at all. Just blank space. 

Air group was invented so that you can drop broadcasts and multicast and still use it.

Broadcast filter all and ARP need to be enabled in your virtual APS. Do not touch the global firewall settings.

What is the CLI command to show a particular VAP? I want to show what I have so I don't make a mistake and kick clients. 

I would go through the GUI:

 

Configuration>  All Profiles>  Wireless LAN> Virtual AP profile..

 

On the commandline type "show wlan virtual-ap" to see all your virtual APs.  type "show wlan virtual-al <name of virtual ap" to see the settings for that particular one.

 

Virtual AP profile "Academic-VAP"
---------------------------------
Parameter Value
--------- -----
AAA Profile Academic-AAA
802.11K Profile default
Hotspot 2.0 Profile default
SSID Profile Academic-SSID
Virtual AP enable Enabled
VLAN Academic
Forward mode tunnel
Allowed band all
Band Steering Enabled
Steering Mode prefer-5ghz
Dynamic Multicast Optimization (DMO) Disabled
Dynamic Multicast Optimization (DMO) Threshold 6
Drop Broadcast and Multicast Disabled
Convert Broadcast ARP requests to unicast Enabled
Authentication Failure Blacklist Time 3600 sec
Blacklist Time 0 sec
Deny inter user traffic Disabled
Deny time range N/A
DoS Prevention Disabled
HA Discovery on-association Enabled
Mobile IP Enabled
Preserve Client VLAN Disabled
QinQ Outer VLAN 0
Remote-AP Operation standard
Station Blacklisting Enabled
Strict Compliance Disabled
VLAN Mobility Disabled
FDB Update on Assoc Disabled
WMM Traffic Management Profile N/A

Drop Broadcast and Multicast Disabled

 

Needs to be enabled on all Virtual APs in that AP group, otherwise you will have congestion like you have been seeing.

So this isn't going to apply?

 

"Warning: broadcast-filter arp should be enabled with this option. Otherwise ARP requests will be dropped!"

 

Things in red make me nervous!

It is just a reminder. The output says it is already enabled and it is enabled by default.

Thanks, I'll see how things are with that change in place. 

You should go to Configuration> Wireless> AP Configuration.  Edit the AP group that your access points are in.  Expand Wireless LAN.  Expand Virtual AP.  Check to make sure that all the Virtual APs in that ap-group have "Drop Broadcast and Multicast" enabled, as well, for the full effect.

 

Yes, I did do that. It has been applied campus wide. 

In my experience, disabling multicast and enabling that other option for converting ARP whatever it was, that completely disabled AirPlay.  That was before AirGroups, though.  We don't have AirGroups implemented yet, since we don't own ClearPass yet, but if we use ClearPass, then can we disable multicasting and still have AirPlay work?

bnewall,

 

Yes.  That is one of the main drivers behind that feature.