Feb 18

Cisco Prime Infrastructure does not update quickly after making changes to an access point.

For the past few of years I have been told that I should make all of my changes to my wireless controllers through WCS, now called Prime Infrastructure (PI). I have have been very reluctant to do this because some tasks were not possible in PI and others are simply easier to do on the controller.

In an effort to use PI more, I started configuring new access points (AP) through PI. I would find the new AP by the MAC, then change the name, IP address, AP Group, etc… This would cause the AP to reboot. After the reboot, I would wait and wait, and wait for PI to tell me the AP was online. In the time I was waiting, I would go into the controller and find that the AP had been online for 3-5 minutes, yet PI still showed it as down and not registered. I would force PI to pull the configuration on the controller, then it would display the correct AP status.

This was very frustrating to me, Why doesn’t PI know that the AP is back up? PI just reset the AP, so Why doesn’t it pole the controller for that AP’s status?

The fix to this issue is a simple check box. If you go to the controller, under MANAGEMENT –> SNMP (On the left) –> TRAP CONTROLLERS –> AP. You will find a check box next to AP Register. Check that box next to AP Register, then click APPLY. Don’t for get to save your config.

Trap Control, AP Register

Trap Control, AP Register

After you check this box, the controller will send an SNMP trap to PI informing it that an AP just registered. For this to work, you have to have your PI server as a trap receiver on your controller. To add an SNMP Trap receiver go to MANAGEMENT –> SNMP (On the left) –> TRAP RECEIVER and add it there.

If you do not have AP Register checked, PI will wait until the next scheduled time to pole that controller to find out about any new APs that joined or left that controller. In my case, it was 15 minutes. After making this change, PI knew that the AP was online with in seconds of it being online.

I hope this helps your experience with Cisco Prime Infrastructure!!!

Jan 28

Cisco WLC says Bonjour to Apple devices

Can I show my iPad on that big-ass conference room screen? Yes sir. Yes you can. To do iPad mirroring, you need AirPlay which means you need to support multicast over wireless. Specifically, Apple’s Bonjour protocol. Cisco’s WLC code currently has the features to support this type of functionality. So, as IT professionals, we can say yes to iPad mirroring, and make it work over the enterprise network in a standardized, scalable manner.

So how do we make this work? And more importantly, since we are talking about video over wireless, how do we ensure the quality of streamed Youtube videos in HD? This is how I did it…


Which wired device to use? This is the device that will receive and display the mirrored iPad screen. We went through the steps listed below, just in lab. Here is a pic of the messy messy lab:

Bonjour gateway lab

The following devices were tested for connectivity and video quality:

  • AppleTV
  • Mac Mini running AirServer
  • PC running AirServer
  • PC running Reflections

Reflections was eliminated because we found it could not mirror wireless to wired. The other three options performed generally the same. PC running AirServer was chosen as it made the most sense for our organization.


High level diagram:

(Please click on the image for better viewing)

WLC 5508
1142n APs
Wireless clients (iOS Devices 7.x and 6.x) use Airplay to mirror to the PCs running AirServer.
APs are in mDNS mode and snooping the vlan the PCs reside in.
AirServer (1.9.4) installed on wired PCs. Giant monitors are connected to these PCs.
Wireless clients in separate WLAN.

My WLCs are in the Data Center and we needed to have this functionality working in our user campus. So the WLC didnt know about the wired devices that were running AirServer. One option is to enable multicast throughout your enterprise network (not fun). In 7.5 Cisco provided functionality to achieve this by having the AP snoop on the vlan the wired device is in. This feature is called mDNS AP.

Enabled bonjour gateway and mDNS AP (trunk mode)
And by the way this allows you to do more than just AirPlay – AirPrint, File Sharing, etc are available services as well.
Here is the config I used on the AP switchport that is doing mDNS snooping:

interface GigabitEthernet0/2
description AP
switchport trunk encapsulation dot1q
switchport trunk native vlan 50
switchport trunk allowed vlan 50,10
switchport mode trunk

Where vlan 50 is the vlan for APs. And vlan 10 is the vlan for the wired PCs running AirServer.

And then configure the WLC to set the AP(s) to mDNS AP mode:

config mdns ap enable AP-NAME-01 vlan 10

AirPlay should work at this point, but it may not work very well. Disconnects and degraded video quality are symptoms I experienced. I used the following guide to optimize the wireless network for video.

Enabled videostream and wireless QoS
This is a big detailed doc and you may want to pick pieces and parts out that are relevant.

Verified via packet capture the client traffic is being marked for QoS (and Gold enabled on WLAN)
Differentiated Services Field: 0x80 (DSCP 0x20: Class Selector 4; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))

And so we have the finished solution. An iPad playing a Planet Earth video on YouTube that is being mirrored via AirPlay to a wired PC running AirServer.


Also, I used a few articles written by MRNCCIEW that were very helpful.