Cisco WLC

WN Blog 029 – Setting Up MPSK on a Cisco C9800 WLC

Hey!

Welcome to our latest blog, today we will be showing you how to configure a Cisco C9800 WLC to use the “MPSK” (Multi Pre Shared Key) feature.

Multi-PSK feature supports multiple PSKs simultaneously on a single SSID. You can use any of the configured PSKs to join the network. This is different from the Identity PSK (iPSK), wherein unique PSKs are created for individuals or groups of users on the same SSID.

Restrictions on Multi-PSK:

  • Central authentication is supported in local, flex, and fabric modes only.
  • In central authentication flex mode, the standalone AP allows client join with the highest priority PSK (priority 0 key). New clients that do not use the highest priority PSK are rejected during the standalone mode.
  • We can have up to 5 x MPSKs (0-4) with 0 being the highest priority.
  • Multi-PSK does not support local authentication.

For more information around central and local authentication check out our C9800 WLC series where we have covered nicely the difference between these methods of authentication.

Let’s take a look at my lab set up – I am running a virtual C9800-CL and it is on version 17.1.1s.

Now we will show you where you need to go to configure your WLAN to use the MPSK feature. First click on the “configuration” tab on the left and then we will select “WLANs” which is under the Tags & Profiles.

Then either pick one of your already created WLANs or create a new WLAN – in this example, I have called my SSID “Cisco-MPSK”. Once selected move on to the “security” tab inside of the WLAN.

Inside of here we will see many options, under “layer2” we want to make sure that we have the following WPA2 check boxes highlight below selected and then we can enable MPSK.

When you enable MPSK you will be able to start adding your MPSK’s and this is what the configuration box will look like. You will have the option to select the priority (remember 0 is the highest priority), which key format you want to use, if you would like the password type to be encrypted or unencrypted & then finally whatever you would like your MPSK to be.

When you have finished entering all of your MPSKs (remember we can have a maximum of 5) this is what your configuration will look like.

We can also verify that MPSK has been successfully enabled via the CLI.

If you run the following command – “#show wlan id 1” (You will need to make sure that you use the relevant WLAN ID number for your WLAN that you configured MPSK for)

Also we can run the “#show run wlan” command and we will be able to see here that MPSK is enabled on your WLAN and what keys are in use.

Ok, so now that we have verified that everything is configured as we are expecting it to be – let’s connect a couple of clients to make sure it works!

In this demo I used my two iPhones to connect to the MPSK and used a different MPSK for each iPhone and they connected first time without any issues at all. You can verify your connected clients in multiple ways on the Cisco C9800.

First of all right from the dashboard we can see my Top WLANs which is the profile Star9800 (this is the profile I configured the Cisco-MPSK) under and we can see that I have two clients connected. We can drill down further by clicking on this WLAN, or alternatively we can go to Monitoring > Wireless > Clients.

This is the view once we have gone to the Monitoring > Wireless > Clients view and we can see my two iPhones connected, their IP address’, which AP & SSID they are associated to & that they are in the run state.

If you click on one of the devices you can drill down even further to get more details & statistics for the client and this is what that view would look like.

Again, if you are a CLI kind of person we can verify the connected devices on CLI by using the following command – “#show wireless client summary”

There you go, that is just how simple & easy it is to set up MPSK on your Cisco C9800 WLC – something which is so powerful & useful for your wireless network. This lets you have accountability & improved security to your PSK wireless networks which I personally think is a much better option than using captive portals with open authentication or an SSID with a single PSK for all users.

I hope you enjoyed this blog and if you have your own Cisco C9800 AP at home or you use it currently in your production network – give setting up a MPSK SSID a go and let me know your feedback!

Much love, as always – WiFi Ninjas x

WN Blog 001 – AP Join Issues with Cisco WLC

So you have just deployed your new shiny Cisco WLCs and you have been waiting for weeks for the cablers to install your APs as per your design and you are sitting there all excited as you can finally enable the switch ports that the APs are connected to but… Oh no, no APs are joining the WLC.

I have certainly been there in that situation and I am going to share with you my usual things to check and troubleshoot.

Firstly we need to understand the process and priority for Cisco APs to discover and join the WLC

AP Discovery Process:

  • WLC Discovery
  • DTLS/ Join
  • Image Download
  • Configuration Check
  • Registered

Now we know the process we need to understand the different methods that APs can discover WLCs

AP-to-WLC DISCOVERY Algorithm (find as many WLCs as you can): 

  •  AP goes through the following to compile a list of WLCs 
    • CAPWAP discovery broadcast on local subnet 
    • AP broadcasts CAPWAP discovery message on UDP 5246 
    • WLC responds back with unicast to the AP 
  • Over the Air Provisioning (OTAP) 
    • deprecated 
  • Locally stored controller IP addr 
    • remembers up to 8 previously used controllers and tries to come back to them 
  • DHCP vendor specific option 43 
    • IP addr should be ‘mgmt int IP’ 
    • DHCP has option 43 configured, but an AP sees code ‘241’ (like police code 10-4), which is the WLC IP 
    • Option 43 format 
      • Windows Server: can be standard IP 
      • IOS: hex (‘f1040a0f64fd’) 
  • DNS resolution of ‘CISCO-CAPWAP-CONTROLLER.localdomain’ 
    • should resolve to the ‘mgmt int IP 
  • Manually set: 
    • via CLI: 
      • capwap ap ip address 10.10.113.5 255.255.255.0 (Example IP & subnet)
      • capwap ap ip default-gateway 10.10.113.1 (Example Gateway)
      • capwap ap controller ip address 10.10.111.10 (Example WLC IP)
        • Alternatively can do the following command:
      • capwap ap primary-base “WLCname” “WLCip”
    • via GUI: 
      • High Availability 
  • In no controller found, start over 

AP goes through ALL disocevry methods to see how many WLCs it could find before moving to join phase 

Now we understand the DISCOVERY phase we can move on to the JOIN phase.

  • Can be hierarhical, hardcoded 
    • Primary, Secondary, Tertiary 
    • Tries the secondary etc. if the primary has no space or has not answered the join request 
  • With many controllers, one might be configured as a master controller 
    • CONTROLLER > Advanced > DHCP > Master Controller Mode 
    • Master controller is prefered to join, if no other controllers are hardcoded 
  • If there are no hardcoded controllers and there is no master configured, AP will join least loaded WLC 
    • Lowest ratio (%) is preferred 
    • If the load is identical, secure DTLS tunnel is preffered over the 5046 UDP port 
  • AP sends a join request message to every WLC, which contains 
    • AP Hardware Version 
    • AP Software Version 
    • AP name 
    • Number and type of radios 
    • Certificate payload 
    • Session payload; test payload 
       
  • Responding to a Controller Request 
    • WLC responds with 
    • Controller name 
    • Controller type 
    • AP capacity 
    • Current AP load 
    • ‘Master Controller’ status 
    • AP-Manager IP address 
    • Certificate payload 
    • AP waits for its ‘Discovery Interval’ expire, then selects a controller and sends an CAPWAP Join Request to that controller 

Now we understand the JOIN phase we can move on to the CONFIGURATION phase.

  • AP moves to an image data phase 
  • Controller upgrades or downgrades the AP 
  • Code is sent in CAPWAP messages 
  • Config then sent to AP 
  • AP applies config to RAM 
  • AP clears all its parameters upon joining the controller 
  • Controller sends everything over: SSIDs, channels, powers etc. 
  • Controller checks/updates APs config frequently 

Once AP has successfully completed the configuration phase it should join the WLC – but, what if it doesn’t? Where do I start?…

(I am going to make the assumption that you have recorded all of your AP MAC addresses correlating to a hostname in a nice excel sheet.)

Ok lets start with the Olivia Netwon John (Physical):

  • If you are physically on site and able to check your AP – does it have any lights? If so what are they doing – different light statuses can be a good indicator of what is going on with the AP.
  • If you are remote can you access the switch the APs are connected to?
    • Check the following commands:
      • “Show CDP neighbour” – Can you see the AP MAC address? Connected to the port you are expecting?
      • “Show power-inline” – Can you see the AP drawing the correct amount of power from the switch?

Ok so we have verified that Olivia (physical – come on keep up kids) is ok and the AP has power and is most likely flashing red, blue & green on repeat. So what’s next? There is no right or wrong way for what order you do these following steps in but is important that we verify all of them.

If possible console on to the AP and view the output message – there could be some information here that makes it very obvious what the issue is. Whilst consoled onto the AP verify that AP has correct FW code on it. If AP is to be controlled by WLC it should be “lightweight” mode and “K9W8” in the FW version – if AP is to not be controlled by WLC should be “autonomous” mode and “K9W7” in the FW version.

Log on to the CLI of the WLC and do some debugs and look at AP join stats to see if we can get any indicators of what the issue may be.

“Show ap join stats detailed [AP MAC Address]” –

Now lets enable some debugs with the following commands

  • “debug mac address [AP MAC Address]”
  • “debug capwap events enable”
  • “debug capwap errors enable”

With these debugs enabled and filtered on the AP MAC address pay attention to the outputs as there may be some key indicators in there for what the reason the AP is not joining the WLC. Like this example below there was a country code mismatch which will look something like this:

Which leads me on nicely to what we can make sure is configured correctly on the WLC that will cause APs to not join:

  • Regulatory domain
    • If WLC and AP do not match regulatory domains AP will not join WLC
  • Time & Date
    • If the time and date is significantly out on either the WLC or the AP will not join the WLC
  • Licenses
    • If the WLC is not licensed/ does not have enough licenses AP will not join the WLC – check you have the right amount available to how many APs should be on the WLC
  • Add AP to security policy on WLC
    • Recently I had this issue where a 1562i would not connect to the WLC even though everything configured the same as a 3802i connecting on a different port. I added the MAC address to the security policy on the WLC and it successfully joined!

Ok so lets move onto DHCP.

  • Check to make sure that the DHCP scope has not ran out of leases.
    • I have had this issue before when upgrading code on the WLC and APs rebooting or going off to join secondary WLC whilst primary is rebooting and then coming back and there not being enough DHCP leases left.
      • In this situation now what I do is shut down the AP VLANs on the switches to contain the APs during the upgrade.
    • Is your option 43 HEX correct?
      • I would definitely recommend checking this especially if you did not actually enter it yourself – I have seen in the past a customer who I sent a correct option 43 HEX string somehow had managed to change the HEX string so AP was trying to translate a different IP address for the WLC!
  • Slight curve ball here but still kind of relates to DHCP opt 43.
    • Recently I was upgrading a customers WLAN from a single WLC2504 and old 1142 APs to new WLC5520s and 2802 APs. Option 43 was configured correctly (I double checked) – Turned AP on and could not see it trying to join the new WLC. What happened was DNS was configured to point to the old current WLC2504 so AP was joining that one instead of the new WLC5520! Something for you guys to bear in mind if you are ever in a similar scenario 🙂

Last but not least – the firewall:

  • Make sure capwap ports are allowed through the firewall 
    • Capwap ports = 5246-5247 and the protocol is UDP

So that is it – my checklist of what I do if APs are not joining the WLC – I hope this post is useful for you guys!