WIFITECHBLOG

It's been over a year since my last blog post...  Not good.

If you have ever been confused by these two settings, you're not alone.  MFP and AP Authentication are both configured from the same page via the WLC GUI.  This makes one ponder the difference between the two options.

According to Cisco, AP Authentication is used for encrypting the AP to AP RRM traffic whereas MFP is used to protect the 802.11 management frames (hence the name...).  Also, it should be noted that these two options are mutually exclusive.

Sources:
AP Authentication - http://www.cisco.com/en/US/docs/wireless/wcs/4.0/configuration/guide/wcstemp.html
MFP - http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a008080dc8c.shtml

Best Practices for Mobility:

1.  Use the same, non-routable virtual IP.  To verify the virtual address, use the show interface summary command.  Also, ping the virtual address to make sure it's not routable.

2.  All controllers must be configured for the same LWAPP transport mode.  Use the show switchconfig command to verify LWAPP transport mode, and the config switchconfig mode to change any of the parameters.

3.  IP connectivity between all WLCs is required (checked by creating the tunnel)

4.  WLCs must have the same mobility group (except for guest tunneling)

5.  WLCs must be running the same version of code.

6.  MACs and IPs are required to build the tunnel.

7.  Do not create overly large mobility groups.

Source
http://www.cisco.com/en/US/customer/tech/tk722/tk809/technologies_tech_note09186a0080810880.shtml

My good friend Leigh is really doing a bang up job on his blog...  Putting me to shame!  It's given me motivation to make the following post though.

Here's something that I just read in the WLC Configuration Best Practices:

"With the Cisco IOS Software Release 12.2(33)SXH6, there is an option for PFC3C mode chassis to exclude VLAN in the Load-distribution . Use the port-channel load-balance src-dst-ip exclude vlan command in order to implement this feature. This feature ensures that traffic that belongs to a LAP that enters on the same port."

The bold is original, I added the italics for emphasis.  On my configs I've always used port-channel load-balance src-dst-ip, but never exclude vlan...  Seems like a good thing to try my next go-round.

I ran into an interesting problem last Monday (02/01/10) at work - someone had deployed APs at a remote location and configured them as autonomous APs. I performed a quick lightweight upgrade on them, and made the mistake of leaving static IPs on them.

The upgrade tool asks for your WLC address so I thought that would prime the APs with that address for the controller... Wrong. As soon as the APs booted to their lightweight IOS (the standard recovery image) I lost connectivity with them (no DHCP so option 43/60 is not available. APs are on a different domain than the switch - why it kept this but not snmp and passwords is irritating - so controller DNS didn't work). Passwords were of course reset, so telnet/ssh responded with "password required but none set." SNMP was also reset... I thought I had lost connectivity to them and would be required to ship out new APs!

In reviewing some of the Cisco literature, though, I found a cool little workaround. You can set the IP helper-address to the IP address of the controller, and then use the "forward protocol" command to forward all CAPWAP/LWAPP traffic to the IP helper-address, i.e. the controller (protocols 12222, 12223 for LWAPP and 5246, 5247 for CAPWAP)! Once connectivity was re-established to the APs, I set them to DHCP and removed the forward protocol commands and set the IP helper-address back to the DHCP server. Problem solved without sending new APs!

I've been reading the 802.11 Wireless LAN Fundamentals recently, just while traveling. It's not sinking in too well, really, but I'm slowly making some connections with real-world applications. They're few and far between, though. Studying the wireless physical layer isn't high on my priority of learning, but I guess it makes a good cornerstone...

A more pressing wireless question I've come up with is AP fallback mode. I would like all the APs on our network to be setup in Local mode so that they aren't overutilising their resources and creating a lot of heat in the process. However, because of our network configuration, we don't have backup WLCs in each location we have wireless deployed. So in order to get the APs to work properly in fallback mode, I think we're going to have to deploy them all in H-REAP.

Basically, I would like to keep the APs in Local mode unless they need to failover, in which case I'd like them in H-REAP. Since that's not possible, I have 2 options:

1. Keep the APs in Local mode 100% of the time. The drawback here is that when the APs failover, they tunnel all the traffic across our WAN to the closest WLC, but take up a lot of the bandwidth doing so. Also, the clients are forced to get IPs from a site across the WAN, which ultimately disrupts some of the applications they are able to access since they are hitting the firewalls with different IPs.

2. Keep the APs in H-REAP. This forces the APs to do the client authentication, association, etc., and forces them to use more resources thus giving less throughput to the clients. Plus, everything I'm reading says it isn't recommended except for remote sites where it's not cost effective to place a controller.

We had set everything to H-REAP. I think now, though, that we should have all APs deployed in Local mode and just recognize that if a controller fails, the clients won't have connectivity, or might not be able to access all their applications.