Lightwieght APs Registering to WLC over WAN

Recently I was onsite with a client cursing the fact that their shiny new lightweight access points (LAPs) refused to talk to their assigned WLAN controller (WLC).  Nothing seemed to work, even manually assigning the WLC address to the LAP via the command line didn't help.


As a result I spent a frustrating few hours trying to troubleshoot the whole thing.  The LAP could ping the controller's admin interface (the AP manager interface does not respond to ping) and at one point the LAP even registered successfully with the controller.  Overnight it disassociated itself and couldn't see the WLC again.  Head scratching time.


Eventually, having traced the problem all the way back to the WLC, I discovered that although the WLC was receiving the LWAPP join requests, and transmitting a response, the firewall in front of the controlller wasn't seeing the traffic.  Puzzling.  Checking the ARP table on the ASA revealed the issue.  Because the AP manager doesn't reliably respond to traffic, other than LWAPP, the ASA had no ARP entry for the WLC.  Adding a static entry resolved the issue.  


Once I'd found the source of the problem, it was relatively easy to set up a way so that a completely un-configured LAP could automatically pick up the controller's address and register via DHCP:


1. Configure your firewall in front of your WLC, make sure the correct ports are allowed (UDP 12222 & 12223) and that NAT etc will not interfere.  Add a static ARP entry for your WLC's AP manager interface.
2. Set up a DCHP pool with the network address of your wireless control subnet
3. Set the default gateway as the router in the path to the WLC
4. Set option 43 as an IP address option, with the address of the AP manager interface on your WLC
5. Add the router's IP address on the wireless control subnet to the excluded DHCP addresses.


After that, you should be able to plug in any un-configured LAP and it will automatically get an IP address, register with the WLC and download the correct image.  As an aside, if you happen to interrupt a LAP while it's re-imaging itself, it can sometimes result in a corrupted image.  In this case, you should be able to find the old image still in the flash and boot from that.  The download should then work.


So there you have it, a (nearly) foolproof way of setting up LAPs.

MPLS tomfoolery

So, today's quest was to get a client's site down in England up and runnning on their new MPLS backbone with resilient VPNs over ADSL and 3G.  A quest not exactly assisted by the complete lack of kit when I arrived.  Eventually the kit was tracked down and a somewhat truculent courier forced to return with it.

I'm not sure what it is, but for some reason telcos never seem to be able to get any sort of connection right first time.  This time there was a routing issue within the MPLS cloud which took me an age to confirm and get the telco to resolve.  Needless to say, by this point the client had decided to abort the switch over, so although the MPLS is working now, the site is still on the old connection .

Oh and a little tip - when you're turning up on site expecting to configure a 3G connection, make sure your client knows that they need a SIM card for the HWIC!  

The 3G resilience config has been quite interesting to develop, and I'll post sometime next week on how to implement it, once I've ironed out any bugs in my config :)