Cisco Catalyst 9800

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 017 – Cisco Catalyst 9800 – Local Web Auth Configuration Guide

Hey!

Welcome to another one of our Cisco C9800 configuration blogs!

This time we will be covering Local Web Authentication (LWA), where guest sessions are managed by the WLC itself.

We can authenticate against RADIUS, TACACS, LDAP or local WLC Guest Users database. In this guide we will use local WLC Guest Users.

As I was preparing for deployment for a customer that would be using 2 x foreign C9800CLs in HA SSO & 2 x anchor C9800CLs in HA SSO I had my lab set up in this configuration also. In this scenario, the WLAN that I will be using is being guest anchored via a tunnel from the foreign WLC to the Anchor.

This meant that all the configuration you see below had to be replicated across both the foreign and the anchor WLCs.

We will include the steps we used from the official Cisco config guide but will add screenshots from our lab WLCs to hopefully make it a bit easier to follow.

Official Cisco guide:

https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/config-guide/b_wl_16_10_cg/wireless-web-authentication.html

Below are the steps to configure LWA.

1. Configuring AAA Authentication (GUI)

Procedure

Step 1 Choose Configuration Security AAA.
Step 2 In the Authentication section, click Add.
Step 3 In the Quick Setup: AAA Authentication window that is displayed, enter a name for your method list.
Step 4 Choose the type of authentication you want to perform before allowing access to the network, in the Type drop-down list.
Step 5 Choose if you want to assign a group of servers as your access server, or if you want to use a local server to authenticate access, from the Group Type drop-down list.
Step 6 To configure a local server to act as a fallback method when servers in the group are unavailable, check the Fallback to local checkbox.
Step 7 Choose the server groups you want to use to authenticate access to your network, from the Available Server Groups list and click > icon to move them to the Assigned Server Groups list.
Step 8 Click Save & Apply to Device.

As we are using local WLC Guest Users database to authenticate against, we will specify ‘local‘ Group type for ‘login‘.

AAA Config

2. Creating Parameter Maps

Procedure

1 Choose Configuration Security Web Auth.
2 On the Web Auth page, click Add.
3 In the Create Web Auth Parameter window that is displayed, enter a name for the parameter map.
4 In the Maximum HTTP Connections field, enter the maximum number of HTTP connections that you want to allow.
5 In the Init-State Timeout field, enter the time after which the init state timer should expire due to the user’s failure to enter valid credentials on the login page.
6 Choose the type of Web Auth parameter.
7 Click Apply to Device.
8 On the Web Auth page, click the name of the parameter map.
9 In the Edit WebAuth Parameter window that is displayed, choose the required Banner Type. If you choose Banner Text, enter the required banner text to be displayed. If you choose File Name, specify the path of the file from which the banner text has to be picked up.
10 Enter the virtual IP addresses as required.    
11 Set appropriate status of WebAuth Intercept HTTPSCaptive Bypass Portal, and Watch List Enable.
12 In the Watch List Expiry Timeout field, enter the time in seconds after which the watch list should time out.
13 Set appropriate status for Disable Success WindowDisable Logout Window, and Login Auth Bypass for FQDN.
14 Check the Sleeping Client Status checkbox to enable authentication of sleeping clients and then specify the Sleeping Client Timeout in minutes. The valid range is between 10 minutes and 43200 minutes.
15 Click the Advanced tab.
16 In the Redirect for log-in field, enter the name of the external server to send a login request.
17 In the Redirect On-Success field, enter the name of the external server to redirect after a successful login.
18 In the Redirect On-Failure field, enter the name of the external server to redirect after a login failure.
19 To configure external local web authentication, perform these tasks: Under Redirect to External Server in the Redirect Append for AP MAC Address field, enter the AP MAC address. In the Redirect Append for Client MAC Address field, enter the client MAC address. In the Redirect Append for WLAN SSID field, enter the WLAN SSID. In the Portal IPV4 Address field, enter the IPv4 address of the portal to send redirects. In the Portal IPV6 Address field, enter the IPv6 address of the portal to send redirects, if IPv6 address is used.
20 To configure customized local web authentication, perform these tasks: Under Customized Page, specify the following pages: Login Failed Page Login Page Logout Page Login Successful Page
21 Click Update & Apply.

Here you can choose a certificate that you want to present guests with when they hit the Captive Portal:

Normally, we would want to have a cert signed by a trusted public CA, but since we don’t have one we won’t select anything in the ‘Trustpoint’ field.

Another thing to point out here is that the Virtual IPv4 Address and Trustpoint certificate must be specified in the global Web Auth Parameter Map. Adding new map won’t even have that options.

Web Auth Config 2

For simplicity, we have just used ‘global‘ Web Auth Parameter Map.

3. Configuring the Web Authentication WLANs

Follow the procedure given below to configure WLAN using web auth security and map the authentication list and parameter map:

Procedure

  Command or Action Purpose
1 enable Example:
Device> enable
Enables privileged EXEC mode. Enter your password if prompted.
2 configure terminal Example:
Device# configure terminal
Enters global configuration mode.
3 wlan profile-name wlan-id ssid-name Example:
Device(config)# wlan mywlan 34 mywlan-ssid
Specifies the WLAN name and ID. profile-name is the WLAN name which can contain 32 alphanumeric characters. wlan-id is the wireless LAN identifier. The valid range is from 1 to 512. ssid-name is the SSID which can contain 32 alphanumeric characters.
4 no security wpa Example:
Device(config-wlan)# no security wpa
Disables the WPA security.
5 security web-auth {authentication-list authentication-list-name | parameter-map parameter-map-name} Example:
Device(config-wlan)# security web-auth authentication-list webauthlistlocal Device(config-wlan)# security web-auth parameter-map sample
Enables web authentication for WLAN.Here, authentication-list authentication-list-name : Sets the authentication list for IEEE 802.1x. parameter-map parameter-map-name : Configures the parameter map. Note  When security web-auth is enabled, you get to map the default authentication-list and global parameter-map . This is applicable for authentication-list and parameter-map that are not explicitly mentioned.
6 end Example:
Device(config)# end
Returns to privileged EXEC mode.
WLAN 1
WLAN Config 1

Layer 2 security we will select none here:

WLAN 2
WLAN Config 2

Foreign WLC policy to Anchor the SSID:

Foreign WLC SSID Policy

Anchor WLC policy for the SSID:

Anchor WLC SSID Policy

4. Configuring Pre-Auth Web Authentication ACL (GUI)

Before you begin

Ensure that you have configured an access control list (ACL) and a WLAN.

Procedure

Step 1 Choose Configuration Tags & Profiles WLANs.
Step 2 Click the name of the WLAN.
Step 3 In the Edit WLAN window, click the Security tab and then click the Layer3 tab.
Step 4 Click Show Advanced Settings.
Step 5 In the Preauthenticaion ACL section, choose the appropriate ACL to be mapped to the WLAN.
Step 6 Click Update & Apply to Device.
WLAN 3
L3 WLAN

We use the pre-auth ACL here that only allows guests access to DNS and DHCP while blocking access to the network until they have authenticated.

Pre-Auth ACL
Pre-Auth ACL

5. Configuring a Local Banner in Web Authentication Page (GUI)

Procedure

1 Choose Configuration > Security > Web Auth.
2In the Webauth Parameter Map tab, click the parameter map name. The Edit WebAuth Parameter window is displayed.
3In the General tab and choose the required Banner Type: If you choose Banner Text, enter the required banner text to be displayed. If you choose File Name, specify the path of the file from which the banner text has to be picked up.
4 Click Update & Apply.

6. Create Local WLC Guest Users Credentials

What was not covered in the Cisco guide was how to add a guest user. To create a new guest user:

Navigate to Configuration > Security > Guest User:

Guest User

Now we have everything configured and a guest user account set up we are ready to connect to the guest LWA WLAN – Woohoo!

iPhone Captive portal
iPhone Connected

Successfully connected client via LWA and anchored to the anchor WLC from the foreign WLC:

Foreign WLC Client

Successfully connected client via LWA and anchored on anchor WLC:

Anchor WLC Client

I was just using the default captive portal in my lab – if you or your customer would like to customise the captive portal here is the Cisco guide and a screenshot of where you can download the webauth bundle from Cisco for your C9800! The bundle is very dated and has a proper vintage feel to it but it’s certainly possible to adjust it so it looks OK πŸ™‚

https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wlan-security/115951-web-auth-wlc-guide-00.html#anc8
Web Auth Bundle

Hopefully, this post helps and saves you guys a bit of time if you need to configure a Local Web Authentication (LWA) WLAN in the future.

As always any feedback or comments are always welcome.

X

WN Podcast 021 – Cisco Catalyst 9800 – Built & Basics

Welcome to our new WiFi Ninjas Podcast episode!

Today, we kick of the Cisco Catalyst 9800 Podcast series, where we will cover some nitty & gritty stuff and share our real world deployment tips and experiences about those new, hot WLCs!

Let’s start with basics πŸ™‚

  • What is C9800?
  • 9800-80 – 2RU Appliance
    • 80Gbps
    • 6000 APs
    • 64,000 Clients
    • 100Gbps Uplink Module Option!
  • 9800-40 – 1RU Appliance
    • 40Gbps
    • 2000 APs
    • 32,000 Clients
  • 9800-CL – Public/Private Cloud Virtual Controller
    • VMWare/KVM/AWS/GCP
    • 2Gbps of centrally-switched traffic
    • 6,000 APs
    • 64,000 Clients
    • Supported features that were not supported on the AireOS vWLC
      • SSO High Availability
      • Local or Flex Mode APs
      • Guest Anchoring
  • 9800-SW – Embedded 9300/9500 Switch Controller
    • 200 APs
    • 4,000 Clients
    • Indirect AP Support (APs can be connected to downstream switches)
  • 9800-L
    • 250 Aps
    • 5000 clients
    • Max throughput 5Gbps
    • Fixed uplinks 2 x 10gbps
  • Features
  • Built
    • VMware
      • Networking
        • 3 interfaces
        • HA considerations
        • Trunk
          • Accept Promiscuous Mode!
        • Central vs Flex
        • OOB
          • Not used
      • Kill the autoinstall, CLI (at least for us) is quicker
      • VLAN and SVI for mgmt
      • Set country code
      • Specify interface (mgmt SVI) to be used for wireless mgmt / AP join
      • Create a cert, validate its creation with sh wireless management trustpoint
      • Configure SSH
    • Physical
  • Challenges
    • Internal DHCP
      • ‘Reserved Only’ turned on by default
      • Configure DHCP Pool, starting IP, ending IP, lease time, gate, DNS, domain
      • Set DHCP Server IP address to be C9800 mgmt.
    • Prime bug
    • Compatibility with other Cisco infra
    • AAA attribute
  • Guest Flow
    • MAB CWA
    • Redirection ACL is not applied anywhere, it’s just referred to by ISE AuthZ Profile
    • Use WLAN guest ACL or have it referenced back by RADIUS

With tons of love x,

WiFi Ninjas

WN Blog 015 – Cisco Catalyst 9800 – Software Upgrade

Upgrading Cisco Catalyst 9800 software is easy and sleek.

You could use all standards protocols to put a new image on the controller: FTP, TFTP, SFTP or HTTPS.

Here are the steps:

  • Download new .bin image from Cisco; I went for the newest TAC recommended image.
  • On the WLC, go to Administration > Software Upgrade or simply start writing ‘upgrade’ in the search bar. Select Transport Type (I used HTTPS), bootflash File System and select newly downloaded image with .bin extension. Click ‘Download & Install‘ and confirm that you really, truly and purposefully want to do it!
  • Wait for the file to finish downloading to the WLC and hit ‘Save Configuration & Reload‘ once Status is all green.
  • Lastly, train your Jedi skills. Be patient.

Installation and reload is extremely fast and takes just a minute or two (at least for the CL version).

Enjoy!

WN Blog 014 – Cisco Catalyst 9800 – Configuration Guide (FlexConnect)

It’s simple, right? Sure! Took me a while to figure that one out.

Our goal in this post is to demo Cisco Catalyst 9800 WLC FlexConnect Configuration.

It’s assumed you’re familiar with all C9800 solution building blocks (we’ve covered it before here) but if it’s your first time, here is very quick recap:

Basic C9800 Configuration Blocks

And this is the lab. Note that VLAN 20 is now removed from the ESXi Trunk on the switch port G0/7. It is no longer needed as the AP plugged to port G0/1 will be dropping users’ data locally now.

Lab Environment

Pre-reqs

  1. Since we’re leveraging FlexConnect local switching (AP puts wireless users into the network, data traffic is no longer tunneled back to the C9800 WLC), AP trunk must allow vlan 20 (that is a wireless users VLAN, local to the AP)
  2. C9800-CL VM is freshly deployed as shown here or it is configured for central switching as shown here
  3. C9800 can communicate with the network; wireless management interface (VLAN 11 in this example) is up
  4. AP is registered to the C9800

In this example, we still have my AP registered as ‘local’ (central switching), centrally switched SSID is up, my phone is associated and has full access following the ‘central switching deployment’ blog here.

AP joined as ‘local’
9800-PSK-Central SSID is up and 1 client (my phone) is associated on 5GHz

The only places where the config is different between Central and Flex are:

  1. Policy Profile – sets SSID set to local switching and maps to a local VLAN
  2. Flex Profile – defines AP Flex attributes like AP Native VLAN, Local Auth and AP Local VLANs are specified here
  3. Site Tag – tells the AP to join as Flex and use specific Flex Profile

I’ll put more wording around the above only, as we’ve already covered all other relevant details in the ‘centrally switched’ blog post here.

Steps

This is how we registered AP as Flex and configured locally switched Flex WLAN.

1. Clean up the config

For simplicity, I just deleted all Profiles and Tags except of RF Profile and RF Tag (and that’s it, I didn’t delete anything else; still, don’t worry if you start with a fresh blank config :))

2. Create new WLAN profile

WLAN Profile – General Tab
WLAN Profile – Security Tab

3. Create Policy Profile

Policy Profile – General Tab

Central Switching” must be unticked to enable Flex Connect Local Switching; it also makes sense to untick “Central DHCP” as we’re probably happier with DHCP process being handled locally and not via a WLC. I also like to include the VLAN ID that we are mapping this Policy Profile to in the Name or Description, as we might have more Policy Profiles mapping different VLANs for different WLANs and it’s good to know what policy does what just by glancing at its name or description.

Policy Profile – Access Policies Tab

“VLAN/VLAN Group” is where you map WLAN to a VLAN! There is no direct equivalent to that mapping as we know from the AireOS. Please note that if you create a VLAN & name it (either through CLI: (config)# vlan 20; (config-vlan)# name LAB-WIRELESS-USERS or GUI: Configuration > Layer2 > VLAN) and use VLAN name to refer to it in a Policy Profile, it WILL NOT WORK! You must refer to a VLAN via its ID (and not a name, since it doesn’t exist on the AP!). If you want to refer a VLAN name here, you must specify 100% matching VLAN ID and corresponding VLAN name in the Flex Profile. See “Flex Profile” section below for more details.

4. Create Policy Tag

Policy Tag, stiching WLAN Profile and Policy Profile together

5. Create AP Join Profile

AP Join Profile – General Tab

6. Create Flex Profile

Flex Profile – General Tab
Flex Profile – Local Authentication Tab
Flex Profile – Policy ACL Tab
Flex Profile – VLAN Tab

We didn’t have to create Flex Profile for Centrally Switched WLAN, but we will need it here. We can use Flex Profile for many different things, but those are quite important:

  • General Tab
    • Native VLAN ID – this is where we specify AP mgmt. VLAN that the AP will be sitting in.
    • Efficient Image Upgrade – this means that when we upgrade the controller code, it will be pushed to just one Flex AP (called the FlexConnect Master AP in AireOS) tagged with a Site Tag containing the same Flex Profile. The code will then be distributed to the remaining APs locally without the need to transfer it over WAN or Internet multiple times. Neat.
  • Local Authentication Tab
    • This is where we can specify a RADIUS server local to the AP for wireless clients authentication so it doesn’t have to be central and go through a DC somewhere far far away. Radius Server Group can also be used in a very valid scenario, where the preference is to use central RADIUS for authentication and visibility and switch to local (from AP perspective) RADIUS when the central one is down. EAP based WLANs would gain a survivalability element in case the WLC or communication to the WLC goes down. Existing clients could potentially re-authenticate and new ones could connect but bear in mind that Flex AP and WLAN in not-connected mode (WLC not reachable) would lose access to RRM and roaming optimisation mechanisms.
  • Policy ACL Tab
    • If you ever want to use any ACLs on APs / WLANs configured as Flex Local Switching, you must create an ACL in ‘Configuration > ACL’ and, on top of that, you MUST add this ACL under ‘Flex Profile > Policy ACL’ tab! By doing so, the specific ACL is pushed down to the AP and can be refered to (statically or via RADIUS).
  • VLAN Tab
    • This is where you can create VLANs that will be pushed down to the AP. Remember VLAN/VLAN Group under Access Policies Tab of the Policy Profile, where we mapped the profile to wireless users’ VLAN 20 using VLAN ID? If we’d like to refer to the VLAN by its name, we would need to have a matching VLAN/name configured here!

7. Create Site Tag

Site Tag

We’ve come to the last place, where Flex relevant config sits! The second we untick “Enable Local Site”, “Flex Profile” dropdown appears. For the AP to join the WLC as a Flex AP, we need to untick “Enable Local Site” and select “Flex Profile” that the AP will use.

8. Create RF Profile (for 2.4 and 5GHz) and RF Tag

Since I created them in our ‘central’ switching blog and didn’t delete them, refer to our blog here to find out more about RF Profiles and Tags.

Apply all tags to relevant APs

AP(s) will now reboot and should join back as a Flex AP and broadcast our SSID:

AP Joined in Flex AP Mode
Flex SSID “9800-PSK” is broadcasted and a client (my phone) is happily connected

That’s it! πŸ™‚ We massively hope it was helpful for someone!

Tons of love,

WiFi Ninjas x

WN Blog 013 – Cisco Catalyst 9800-CL – Redundancy HA SSO (CLI and Deeper Dive)

Hey! And welcome to another C9800 blog πŸ™‚ Recently, Matt has blogged about Redundancy configuration using GUI and covered HA/SSO operation here. Today, I wanted to do a deeper dive into the topic. Enjoy!

Lab Environment:

In my lab, both C9800-CL VMs will sit on a single ESXi box. In the real world, they would rather be distributed across separate VM hosts or even separate geographical locations. In any case, configuration would stay identical and same pre-reqs are still relevant. Most importantly, both vWLCs need access to the LAN on their mgmt. interface (that will also be used by APs to register to) and a separate ‘P2P’ L2 link to form & monitor HA and sync configuration.

See a full picture of my lab below:

Lab – Fuill Picture

And to make things simple, also see a simplified logical diagram of C9800-CL networking and interfaces mapping to the VMware vSwitches:

Lab – Simplified Diagram

HA/SSO nitty-gritty stuff

  • HA/SSO in C9800 works differently to how it works in Aironet, it’s more like a VSS now.
  • Initially, both C9800-CL WLCs will require management IP address.
    • Note, that management IP is optional for a secondary WLC if you have a console access to it. Mgmt IP is no longer required to form a HA Pair
  • Redundancy Management as we know it from AireOS (additional IP per WLC from the same subnet as mgmt.) doesn’t exist anymore and therefore Redundancy Port IP is no longer automatically derived from the Redundancy Management IP (it used to be 169.254. + last two octets of the Redundancy Management IP) – you have to manually specify “Redundancy Port” IP and elect one of the VM interfaces to be used as a Redundancy Port (RP)
  • “Redundancy Port IP” is now called “Redundancy Local IP” (GUI) or “Local HA Interface IP” (CLI) <- same thing, just called differently in different places
    • Local HA Interface IP (I’ll call it just that as we’ll use CLI to form HA/SSO in this example) should be in a different subnet to a management interface. This subnet should not be routable.
  • Both WLCs are using the same mgmt. IP to maintain AP CAPWAP during failover once HA/SSO is formed
  • Two units are using a dedicated Redundancy Port (now called HA-Interface) to sync
  • Role election happens at boot, uses priority (1-15, default is 1; higher priority is preferred) or lowest MAC if priority is the same; two controllers are supported, not more
    • It’s best practice to assign higher priority to the preferred active WLC
  • Standby WLC continuously monitors Active via RP keepalives
  • Gratuitous ARP is sent by a Secondary WLC that is taking over the Active role
  • No preempt functionality is supported – failback, if needed, is manual
  • Timers:
    • SSO Failure Detection: 50 ms
    • Reconciliation Time (Standby becoming Active): max 1020ms
  • Reloading Active WLC via CLI: # reload will also reload a standby immediately
  • Forming HA wipes out the config!!!
    • Always form a HA first, configure later
  • WLC Interface used for HA will disappear from the interfaces list (sh ip int br etc. will not list it anymore)

HA/SSO Pre-reqs

  • HA Pair can only be formed between two WLCs of the same form factor (C9800-CL VMs in this example)
  • Both WLCs must be running same code version
  • Max RP RTT = 80ms, min bandwidth = 60Mbps, minimum MTU = 1500
  • Both WLCs are built, accessible, VMware networking is configured, WLCs have access to the LAN and separate L2 link for the HA is available between the WLCs
    • C9800-CL HA-Interface that we intend to use as a Redundancy Port L2 HA inter-vWLC link must be put into a separate, unused VLAN! Using existing VLAN/subnet, especially if it’s management VLAN/subnet, would theoretically work (I’ve tested it) but it will cause instability, duplicate ARP entries and ARP resolution issues. See below the ‘show logging’ output from my switch, where I had HA-Interfaces IP sitting in the mgmt. subnet:
  • See full deployment guide of the C9800-CL for VMware ESXi in our previous blog here
  • Prepare IP addresses and subnets; in this example we will use the following:
    • Active WLC
      • Chassis 1, priority 2
      • Mgmt. (VLAN 11): 10.10.11.35 /24
      • HA Local IP (VLAN 666): 10.10.66.35 /24 (VLAN 666
    • Backup WLC
      • Chassis 2, priority 1
      • Initial Mgmt (VLAN 11): 10.10.11.40 /24 (optional if have console access, won’t be used anymore once HA is formed)
      • Mgmt: (VLAN 11) 10.10.11.35 /24 (shared between HA WLCs once HA is formed)
      • HA Local IP (VLAN 666): 10.10.66.40 /24

HA/SSO Configuration

I feel CLI gives us better visibility into what is happening on both WLCs while forming HA Redundancy, therefore we will use CLI here. It is possible to use GUI too, but I am not a huge fan of “click, wait, pray and hope for the best” approach, where I can’t see what’s happening πŸ™‚

CLI

  • Active C9800-CL
    • # chassis ha-interface Gig 3 local-ip 10.10.66.35 /24 remote-ip  10.10.66.40
    • # chassis 1 priority 2
    • # wr
    • # reload
  • Standby C9800-CL
    • # chassis ha-interface Gig 3 local-ip 10.10.66.40 /24 remote-ip  10.10.66.35
    • # chassis 1 renumber 2
    • # chassis 1 priority 1
    • # wr
    • # reload

GUI

Refer to our previous C9800-CL Redundancy blog written by Matt here

Note: Standby WLC would need to be accessible on its management IP address to use GUI for Redundancy configuration.

Tshoot & Validation

It is good and useful to know how to monitor, tshoot and validate HA Redundancy configuration. You can do it in both CLI (see below) and GUI (Monitoring > System > Redundancy; Dashboard > Slot: Active / Standby)

Chassis

# show chassis

Show Chassis
  • Validate Chassis# and Priority. Also see the HA state (“Ready” is the final and desired stage, you can also see “Initializing” etc.) and HA-Local IP of both C9800-CL VMs.

# show chassis ha-status local

Show Chassis HA-Status Local
  • Check before the reboot while forming the HA
  • Active should have higher priority, HA Local and Remote IPs and assigned interfaces are shown, together with Chassis# and Priority that will be assigned to this local WLC upon reboot (you might have changed those values and it can be slightly confusing, so it’s best to check after configuring and before rebooting_

Redundancy

# show redundancy

Show Redundancy
  • Another useful show command, where we can validate uptime in current state, versions, modes and more!

Want to Know More?

Yeh, totally get it – me too πŸ˜‰ I’ll drop some useful stuff that I came across and used at some point here that might help with configuration and troubleshooting.

Manual failback

  • # redundancy force-switchover
  • Can be very useful in scenarios like primary DC maintenance, where Backup C9800-CL takes over. Since there is no preempt mechanism in C9800 HA (former Active WLC won’t claim its original Active role back when it comes back online)

Clear HA Configuration

  • # chassis clear
  • # reload

This is how it looks in the CLI:

Note: it’s enough to clear chassis information on the active HA Pair WLC, despite the information that the ‘other’ (Backup) chassis will keep its HA configuration. I’ve tested it and it will not! Backup chassis will also reboot with clear redundancy config!

  • Chassis clear is used to break the HA; be careful with this as you will end up with duplicate IPs! Both former Active and Passive WLCs will share identical configuration upon reboot!

Duplicate IP addresses after clearing chassis config

Successful HA/SSO Formation

This is how successful HA  formation should look like in a console of both Active and Passive WLCs:

Successful HA/SSO Formation upon reboot once ha-interface was configured; Active (left) was elected Active due to higher priority

That’s it for now! It feels great to play around with new toys and discovering differences between old and new WLCs! Don’t hesitate to comment, add to the discussion or simply let the world know that you are enjoying beta-testing Cisco gen 1 products as much as we are πŸ˜‰

WN Blog 011 – Cisco Catalyst 9800-CL – Redundancy HA SSO (GUI and Basics)

Hey!

Welcome to another one of our blogs on configuring the new Cisco Catalyst 9800 WLC.

This time we are going to take you through configuring 2 x C9800-CLs for redundancy HA SSO. 

First here is an overview of my home lab setup:

Matts Lab

I currently have 2 x ESXi servers and a C9800CL on each of them – what it is important to point out below here is that I have VLAN 12 configured to use for my L2 redundancy ports between the WLCs.

ESXI Servers vSwitch Config

Interface Gigabit Ethernet 3 will be used for the L2 HA in this setup:

ESXI C9800 Network adapters

Just want to point out here that at this stage we have 3 x interfaces – Gigabit Ethernet 1 – 3:

C9800s Ethernet Interfaces

I then began the redundancy configuration on both of the WLCs.

On the primary WLC I specified the “local IP” as the IP address I had just set up on VLAN 12 and the remote IP address of the secondary WLC that I had just created on VLAN 12.

HA interface I have used Gigabit Ethernet 3.

I wanted the WLC on the left to be the primary WLC so I set the active chassis priority to higher than the secondary WLC on the right:

C9800s Redundancy Config

After I applied the configuration I then saved the config and reloaded both of the WLCs at the same time, crossed my fingers and prayed to the wireless networking gods! πŸ˜€

C9800s Save & Reload

A few minutes later…

C9800s Successfully in Redundancy HA SSO 1

We can see now that the WLCs have rebooted and successfully formed an HA SSO pair. You can now also see a new dropdown on the dashboard to flip between active and standby stats:

C9800s Successfully in Redundancy HA SSO 2

Standby stats:

C9800s Successfully in Redundancy HA SSO 3

Note the G3 interface is gone after forming a HA:

C9800 No Gigabit Ethernet 3
C9800 No Gigabit Ethernet 3 GUI

Also note that HA/SSO is required to take advantage of a very nice new featur of the C9800 series WLCs, which is the “always on” feature from its hitless upgrades.

Here is how it works:

  • The controller automatically selects groups of APs that can be upgraded, while other nearby APs will still provide coverage to the clients
    • RRM is used to determine AP neighbors that can provide redundant client coverage
    • The aggressiveness of these groupings is configurable.
      • You can have many groups (few APs per group), with very minimal coverage impact, but it will take a long time to complete.
      • Or you can have fewer groups (more APs per group) with a greater chance for coverage impact but will complete much more quickly
  • The secondary Controller is upgraded to the new software version and rebooted
  • The controller uses 802.11v to shuffle clients away from the APs in the first group so that they can be rebooted without impacting the clients
    • Clients not supporting 802.11v will get ungracefully kicked off the AP
  • The controller moves those APs to the new controller, thus upgrading the AP code when they join
    • Once upgraded and controller-joined, clients may join these APs
  • The same process is automatically repeated for all successive groups of APs
  • Once all APs are moved to the N+1 controller, the code is upgraded on the primary controller and it is rebooted
  • Once the primary controller is back online, the APs can optionally be moved back to the primary controller

There you go – that is how you set up and configure your virtual C9800CLs for HA/SSO – hopefully this blog saves you a bit of time if you ever need to do something similar!

PS. Shout out to Ashley Georgeson who helped with this πŸ™‚

WN Blog 010 – Cisco Catalyst 9800 – Configuration Guide (Basics & Central Switching)

Finding C9800 stuff hot and interesting? You’re not alone out there! πŸ™‚

After initial C9800 configuration (see this blog) and registering your first AP (our AireOS AP Join Blog is still applicable here) you’re pretty much ready to go! There are just some pre-reqs to consider before we can associate with our first C9800 BSSID.

Pre-reqs

  • C9800 is built, GUI and CLI access is working
  • AP is registered
  • AP mgmt. VLAN (VLAN 10 in this example) is operational, AP has connectivity with to at least the vWLC
  • VM mgmt. VLAN (VLAN 11 in this example) is operational, C9800 can communicate with the network
  • WiFi Users VLAN (VLAN 20 in this example) is operational and, since it’s central switching we talk about here, VLAN 20 is allowed on C9800-CL management trunk (Gi2 in this example), on Port Group on the vSwitch C9800 Gi2 is mapped to and on ESXi management trunk to the switch; VLAN 20 must be allowed across entire path from the C9800 to its gateway

Note: since we’re talking central switching mode here, authenticated WiFi users’ traffic will be dropped into WiFi users VLAN at the vWLC level!

Lab Environment

To get better picture, see my lab environment below:

Lab Environment

New C9800 Architecture

Even though C9800 offers pretty much features parity with our beloved AireOS WLC, it is slightly different. If you spent some quality time with Cisco DNA Center you will feel comfortable with the new GUI and structure. If not (like me), be prepared to change some old habits and approach C9800 with an open mind πŸ™‚

C9800 is designed to fit perfectly into Cisco SDA world and integration with DNAC and use of SGTs. But don’t worry if you don’t have few DNAC boxes worth Β£70k each and a fabric underlay lying around. C9800 can still work in a traditional way. The only real difference is where we configure the same stuff as we did in AireOS (using Profiles) and how we stich it together (using Tags).

Look at the visual representation of major blocks building a basic WiFi setup.

Wireless Setup Flow Overview

You can create multiple WLAN Profiles (SSIDs) and Policy Profiles and correlate both using a single Policy Tag. You then choose your AP Join Profile and Flex Profile (if in use) and correlate both using Site Tag. Your 2.4 and 5GHz RF profiles are stitched together using RF Tag. You now have all the config needed for the AP and SSID to operate described with just 3 tags, that are finally assigned to the AP of your choice. Takes some time getting used to, but it’s really not too bad.

Let’s dive straight in. Once we start looking at the real config it shouldn’t feel too overwhelming.

Note: only the WLAN Policy is mandatory but it is best practice to use all 3 policies and understand impact they all have on our wireless network.

Configuration

In this example we’ll configure simple WPA2-PSK WLAN and cover more interesting stuff like popular enterprise security approaches using EAP (PEAP, EAP-TLS, BYOD) in future blogs! Guest flow (CWA with ISE) already has its blog and you can find it here: https://wifininjas.net/index.php/2019/08/13/wn-blog-009-c9800-wlc-guest-mab-cwa-ise/ πŸ™‚

Below steps show how to configure your first centrally switched WLAN. It’s PSK-based, but you can easily translate it to any other auth method. Have fun πŸ™‚

1. Configure WLAN Profile

This is a pretty standard WLAN configuration that we’re all familiar with. Quite a few boxes to tick, tons of possibilities, standard Cisco overcomplication that feels like 1:1 port from the AireOS. Simplifying opportunity missed. But let’s not digress!

Go to Configuration > Tags & Profiles > WLANs or (I like to do that), Advanced Wireless Setup (top-right corner), where you can switch between all main solution building blocks from one list.

Advanced Wireless Setup

Amazing, isn’t it?

In General tab, configure Profile Name (must be unique) and SSID name (can have more than one on the same WLC) along with WLAN ID (ID <=16 = included in default Policy Profile, ID > 16 = won’t be included in default Policy Profile), Radio Policy (2.4GHz, 5GHz, or both). As L2 security in Security tab, use WPA + WPA2 with AES encryption and PSK key mgmt and specify ASCII PSK Key. FT should be disabled here due to Krack vulnerability. Leave all other security details on their default values. Advanced tab settings can also be left on default but please be mindful of the impact some settings on the performance and compatibility of your SSID. This is a topic for another discussion, but in essence I’d say that:

  • Aironet IE enables SSID name inclusion in beacons among many other things, which is helpful AF but can affect clients compatibility with this SSID
  • P2P Blocking is normally enabled on Guest SSIDs (blocks WiFi clients from attacking each other)
  • 802.11v can seriously affect (positively or negatively) your roaming behaviour – test with your clients
  • 802.11k is generally a good feature to use as it should reduce time your clients spend scanning off channel for alternative APs while roaming
  • Band select can be useful in some scenarios, but steer away when used with voice as it will make roaming slower
WLAN Profile General tab
WLAN Profile Security tab

2. Create a VLAN

Since we’re dealing with central switching, we might think that we would need a dedicated SVI on the C9800 sitting in the VLAN into which we would like to drop authenticated users’ traffic in the same fasion as we did in AireOS. We could do it and it would work, but it’s not necessary here. All we need is to create VLANs (as opposed to SVIs) to get centrally switched WLANs to work.

Add VLAN in CLI ((config)#vlan [VLAN ID]; (config-vlan)#name [VLAN name]) or GUI in Configuration > Layer2 > VLAN > Add

In this example I’m using VLAN 20 for wireless users. L3 sits on my core switch. VLAN 20 is allowed on vSwitch and ESXi trunk. Refer to the lab network diagram for more clarity – one pic speaks thousand words.

Add VLAN for wireless users

3. Configure Policy Profile

This is where we can configure TrustSec, decide if we want to use Central Switching, Authentication, DHCP or Association, map WLAN to a VLAN, apply an ACL to an SSID, turn on RADIUS Profiling, specify QoS, AVC, CAC, Anchors, AAA Policy (attributes returned to the NAC), basic WLAN timers and many more. Sounds easy? I know, I too feel it’s slightly on the overcomplicated side πŸ™‚

General Tab:

Policy Profile – General Tab

Minimum config required:

  • Specify Name
  • Set Status to ENABLED
  • Enable Central Switching and Central DHCP

If you want to know more:

  • WLAN Switching Policy can move certain roles (switching, auth, DHCP, association) between AP and WLC. Central everything is the default. Note that “Central DHCP” must be used in Central Switching mode. If you disable it, clients won’t get an IP at all. Authentication and Association roles can be moved between WLC and AP and either would work just fine.
  • Passive Client (in short) allow comms from wired devices to wireless devices with static IP address by enabling WLC to pass ARP requests to them. Normally WLC proxies that responses but since there is no DHCP used, WLC wouldn’t know about those devices.

Access Policies Tab:

Policy Profile – Access Policies Tab

Minimum config required:

  • Specify VLAN/VLAN Group assignment (use just a VLAN number or use VLAN name set in step 2.)

If you want to know more:

  • VLAN/VLAN Group is where we specify the VLAN we want to drop wireless users into! This is extremely important to understand, since we don’t assign WLANs to dynamic interfaces (central) nor we have VLAN to WLAN mapping (flex) anymore. I have assigned ‘LAB-WIRELESS-USERS’ VLAN 20, that I created in step 2.
  • WLAN ACL can be applied to do basic firewalling on the AP or WLC level (depending if using central switching or Flex) before the traffic even hits the firewall.

Let’s leave the rest on default for now. We’ll cover it in more details in future blogs.

4. Configure Policy Tag

Policy tag just stitches WLAN Profile and Policy Profile together, nothing else πŸ™‚

We could mix and match different WLAN and Policy Profiles while creating different tags. Example:

  • PSK WLAN with Policy Profile on VLAN 20
  • EAP WLAN with Policy Profile on VLAN 20
  • MAB WLAN with Policy Profile on VLAN 666

You get the drill.

Policy Tag

Minimum config required:

  • Create a new Policy Tag and select WLAN and Policy Profiles created in previous steps

5. Configure AP Join Profile

Here we’ll configure basic parametres used by APs after they join a controller.

AP Join Profile – General tab

Minimum config required:

  • Specify AP Join Profile Name

If you want to know more (I’ll only mention stuff I think is useful and filter out the noise):

  • If setting up a quick SSID is all we need, we can just create AP Join Profile, and specify its name in General tab. All other settings within the AP Join Profile can be left on default.
  • CAPWAP tab allows us to adjust CAPWAP & Retransmit timeouts and hardcode Primary and Secondary Controller Name and IP for N+1 designs.
  • AP tab allows us to set a Country Code, AP EAP Auth (FAST, PEAP, TLS), enable Hyperlocation, adjust BLE Beacons and AP Packet Capture settings (can capture straight to FTP location which is quite cool).
  • Management tab allows us to specify specific AP code that AP should download upon Joining the WLC, enable AP SSH access, set local mgmt user and dot1x credentials and set thresholds for detecting rogue APs.

Note: Flex Profile configuration is not required in Central Switching architecture.

6. Configure Site Tag

Now, Site Tag is slightly special πŸ™‚

You might expect that since Policy Tag was just stitching profiles together, why would Site Tag be any different?

In Central Switching mode we don’t even specify Flex Profile assignment (let’s discuss it in more details in C9800 Flex blog post). We just specify Site Tag Name, AP Join Profile and, most importantly, we specify if the site is Local (centrally switched) or not (flex). It is confusing AF! In our example, we configure Site Tag with “Enable Local Site” checked.

Site Tag configuration

Minimum config required:

  • Set Site Tag Name, specify AP Join Profile configured in previous step and check “Enable Local Site” (which means that AP will leverage central switching).

7. Configure RF Profile

Custom RF Profiles are optional but extremely helpful to have, especially if your C9800 WLC caters for sites that have different RF requirement coverage areas. Maybe some sites will have APs expected to work in a High Density or Voice environment, while most APs would be serving ‘just data’ hungry stations? We would create different RF profile for each coverage type (High Density, Voice, Data) and for each band (2.4 and 5GHz).

Minimum config required:

  • None – custom RF Profiles are optional

If you want to know more:

  • General tab is just for specifying Name, Band and Description. Make sure your RF Profile is Enabled.
  • 802.11 tab is used to specify Data Rates and MCS Rates. Disabling low data rates is crucial in most scenarios (I personally never had to allow low data rates but I’ve heard stories where others had to due to weird wireless stations requirements). In short, management and control traffic is exchanged at lowest mandatory data rate. Clients associated with our BSSID would rate shift down when moving away from the AP and when the SNR drops for any reason. Supporting low rates and setting mandatory rate too low would contribute to sticky clients behaviour, slower transmission speeds for dodgy clients sitting on low data rates, increased airtime utililisation by those clients and finally, low mandatory rates would contribute to more airtime being consumed for control and management frames, leaving less space for data transmissions. Generally, in most situations, I would set minimum mandatory rate to 12 (standard deployment) or 24 Mbps (higher density), disable all lower rates and set all higher rates to supported. Please note that proper RF design following a proper on-site survey and predictive survey (and sometimes pre-deployment survey with AP-on-a-stick) is extremely important when tweaking radio configuration! Crap in crap out, can’t mitigate shit design with good config.
  • RRM tab is quite a comprehensive topic on its own! Let’s try to keep it short. You might want to increase default number of clients per AP that generate traps. Transmit Power Control (TPC) is extremely important to use wisely and to our advantage. Normally, it’s best to try and match Tx power level of the least powerful wireless device in the network. Allowing maximium available Tx power on the AP won’t necessarily mean ‘better coverage’. Coverage works in both directions – from AP and from a client. Not matching Tx power between AP and a client might cause asymmetric traffic patterns, where client can hear the AP, but AP can no longer hear the client. You also don’t want to go too low with Tx power as the goal is to maintain as high MCS rate as possible. Normally, 2.4GHz AP max Tx should be considerably lower than 5GHz max Tx. Dynamic Channel Assignment (DCA) is another supremely important factor contributing to general performance of a WiFi network. Do we want to bond channels? Do we want to use all available 5GHz channels there? The answer is “it depends”. I’d consider using 40MHz only in smaller deployments and only if it wouldn’t contribute to excessive channel contention. Remember that doubling the channel width doubles the interference and reduces SNR by 3dB. Also, even without ‘our’ APs, RF spectrum might already be crowded so we might want to stick to 20MHz sometimes even in smaller sites. Generally speaking it seems wise to stick to 20MHz in most cases in the enterprise world (but not only!) unless sheer higher throughout is required and you fully understand implications of bonding channels. Also, newer use “Best” channel width as we’ve seen it going wild with using 80MHz in central London on sites with 20+ CCI in a busy multi-tenant building. Now, which UNII bands to use? Stick to non-DFS channels 36-48? Use 36-64? Or maybe use all 19 available (in the EU) channels? It’s hard to answer this with a ‘one size fits all’ type of an answer, but in most cases we’d use all UNII bands, unless we have some weird clients that don’t work too well with upper bands and/or don’t support 802.11k while quick roaming is important.
  • Lastly, there are features like RX SOP or Client Load Balancing in the Advanced tab. RX SOP solves half of the CCI issue by ignoring signal below configured thershold from neighbouring BSSIDs operating on the same channel on an AP level. But how about contention on the wireless station level? Exactly. It’s still there. To solve this issue better, we’d want to think about 802.11ax, where OFDMA and BSS colouring should combat that contention crap nicely. Final tip – be careful with Client Load Balancing as it might hard disassociate your precious clients, potentially making them unhappy, especially if they’re in the middle of a call or conference. I now feel we should have a separate blog and podcast about the RF Profiles and RRM. And we probably will!

8. Configure RF Tag

We are almost there! With RF Profiles sorted, we just need to stich 2.4 and 5GHz profiles together with an RF Tag.

RF Tag configuration

Using RF Profiles and RF Tags, again, is optional (but cool, so please use it).

9. Apply Tags to the APs

Yup, this is the last step.

Select APs to tag and tag them with three tags we have created above (out of which only Policy Tag is mandatory).

Apply tags to APs

Think of tagging APs as of adding them to their relevant AP Groups with specific WLANs and RF Profiles. Well, kind of πŸ™‚

That’s it. Simple. Similar to the AireOS that we all know and love so much, isn’t it? πŸ™‚

Thanks for surviving going through this lengthy post and see you in the next WiFi Ninjas Blog!

WN Blog 009 – Cisco Catalyst 9800 – Guest MAB CWA ISE Config

Hey!

Welcome to another one of our blogs on the configuration of the new series of WLC from Cisco the C9800!

In this post, I want to go through with you an issue that I ran into when configuring a Guest SSID which was using MAB with a CWA to redirect to a portal on ISE. 

A high-level overview of the C9800 -40 + 3800i APs – Local mode, Central Switching & Authentication. ISE was configured correctly and was working correctly as it should of the AireOS 5508 that I was replacing and was still working.

I had followed all the steps & configured everything in this Cisco guide apart from the BYOD flow as that was not a requirement for this project.

Cisco guide: https://community.cisco.com/t5/security-documents/ise-and-catalyst-9800-series-integration-guide/ta-p/3753060

But I was hitting two scenario issues – the first one was that I was not being redirected to the portal when connecting to the SSID but I was authenticated on ISE and had internet. The second was that I was being redirected and could authenticate with ISE by inputting the code but then not getting any internet after.

The configuration for the first scenario where I was not getting redirected but I was authenticated and had internet was that I had created the “Redirect_Webauth_ACL” and that was applied globally on the WLC – very much the same as you would on AireOS.

The configuration for the second scenario where I was being redirected but then not getting any internet was that I had applied the “Redirect_Webauth_ACL” to the “WLAN ACL” in the “Access Policy” of the Guest “Policy Profile”

So even though I had followed the documentation neither scenario was working how I would expect it to. I am going to take you through below in some screenshots the config I had applied and where as well as show you how I managed to get it working even though what I did was not clear from the Cisco guide.

One thing to call out here for when you come to write an ACL on the C9800 is to remember that they use the IOS syntax instead of what you would be used to on the AireOS WLCs.

Cisco 9800 Guide Notes
Cisco 9800 Guide Notes

From the Cisco guide this is an example of how to write the web auth redirect ACL – Cisco ACL example for the C9800:

Cisco Guide ACL
Cisco Guide ACL Example

This is where you configure the ACLs and can see that the ACL that I had configured for the web auth redirect is called “GUEST_REDIRECT_ACL”

9800 ACL Overview of all ACLs highlighting the Guest
9800 ACL Overview of all ACLs highlighting the Guest Redirect

We can have a look at the redirect ACL rule here and can see that I have specified the two ISE servers and DNS (I had previously made the ACL more specific but after many hours of troubleshooting I decided to make it bit more open)

Guest Redirect ACL
Guest Redirect ACL

Now I want to show the WLAN config where you can see the Authorisation & Authentication lists that have been specified are the two ISE servers:

Guest WLAN Security 1
Guest WLAN Security 1
Guest WLAN Security 2
Guest WLAN Security 2

Now in this scenario where I was being authenticated but not redirected, in the policy profile for the guest I had not specified the redirect ACL here.

Guest Policy Profile without ACL
Guest Policy Profile without ACL applied

When I did specify the redirect ACL in the access policy above I was now being redirected but then was not getting any internet.

Checked the guide again to make sure everything was correct which it seemed it was so left me scratching my head at this point as to why was not working as expected.

So I reached out to my security friend Aref who skills far surpass mine when it comes to security & ISE to double-check ACL config & ISE policies for the Guest Wireless MAB.

Here are a few screenshots of how ISE is configured:

ISE Config 1
ISE Config 1
ISE Config 2
ISE Config 2
ISE Config 3
ISE Config 3
ISE Config 4
ISE Config 4
ISE Config 5
ISE Config 5

So Aref confirmed that all looked good from an ISE configuration perspective – so how did we get it working I hear you ask, great question! What we had to do was to specify another ACL which we called “DENY_GUEST_INTERNAL” which in this rule we basically blocked any access to RFC 1918 but then allowed anything else and we applied this ACL to the Guest “access policy” in the “policy profile” with the redirect just applied at a global level and now we finally got redirected as well as internet!

Here are some screenshots of the other ACL, its configuration and where we applied it:

C9800 ACLs overview highlighting Deny Guest Internal
C9800 ACLs overview highlighting Deny Guest Internal
Deny Guest Internal ACL
Deny Guest Internal ACL
Policy Profile with ACL applied
Policy Profile with ACL applied

It was quite a long day of troubleshooting and trying different scenarios before we managed to finally get it working as expected and I feel that the way we did finally manage to get it working was not clear from the Cisco documentation so hopefully this can help save you guys some time if you have to configure a guest network with CWA + MAB and run into the same scenarios as I did.

Hope you enjoyed this blog on another configuration gotcha from the C9800 – as we deploy more of these and find anything else that we think may help others who will be implementing these for the first time we will post more blogs with our findings!

πŸ™‚

WN Blog 007 – Cisco Catalyst 9800 – Internal DHCP Server Config

Hey!

A quick short blog on some internal DHCP configuration for the C9800 WLC!

As we are starting to implement the new generation of the wireless controller for customers, we anticipate that we will stumble over a few gotchas with config and plan to share through short blogs with you guys to hopefully save you some time.

One of the requirements for this customer was to use the C9800 as a DHCP server for the guest network. After I had configured the DHCP pool, WLAN, Policy, VLANs, TAGs, etc and I went to test connectivity to the guest WLAN – the 9800 was not giving out DHCP IP address’.

Took me longer than I would have liked to troubleshoot but I eventually found out what was causing the C9800 to not be handing out DHCP IP address’ – it was one button that was enabled by default when creating the DHCP pool! β€œReserved only – Enabled” after I disabled the β€œreserved only” my clients were being given DHCP from the C9800.

I re-created the config for you guys in my lab at home as an example and got some screenshots below for you just in case you have a similar requirement for a customer ????

9800 SVI Example
SVI example for guest VLAN

This is an example of how to and how I have set my SVI for the guest network on the C9800 WLC

9800 DHCP Pool Example
C9800 DHCP pool Reserved only enabled

This is the option on the DHCP pool that caused me hours of troubleshooting why guests were not being given out DHCP IP address πŸ˜€

C9800 DHCP pool Reserved only disabled

So I would recommend having this option disabled if you have a requirement to use the internal DHCP server on the C9800

DHCP Pool Advanced
DHCP Pool Advanced Tab

In the DHCP pool advanced tab is where you add the default router and DNS servers

9800 Policy 1
9800 Policy profile and VLAN

This is where you assign the VLAN to your policy profile

9800 Policy
9800 DHCP Server IP

When using the C9800 WLC as an internal DHCP server make sure you use the management IP address here of the C9800

9800 Policy tag
9800 Policy tag

This is where you tie the WLAN profile and policy profile together with a policy tag

9800 DHCP Client
9800 DHCP Client

In this screenshot can see that my client device has been given a DHCP IP address from the DHCP pool successfully

9800 client
9800 client

So remember guys when you are configuring an internal DHCP Server on the C9800 if you are having issues with clients not getting a DHCP IP address make sure “DHCP reserved” is disabled!