So if you’ve read some of my recent posts - you may have seen that I purchased a NetGear LB 1121 LTE Cellular modem to use for home internet backup.

Well - I decided to upgrade!

After using the NetGear modem for a while, I started having some issues where it would disconnect from the cellular connection intermittently. Since it’s not necessarily intended for the purpose I’m using it for, there wasn’t any good way to set up monitoring for it either.

So I opted to upgrade to a Meraki MG21. This is one of the latest additions to the Meraki family of network devices & is available with internal (MG21) and external (MG21E) antenna.

I was pretty excited to get one, since Meraki tends to have decent analytics & configuration - and they make everything so easy!

We’ll walk through the setup of the MG below - but if you’re interested in seeing what the device looks like as well, definitely check out the video above!

MG Setup - Changing the APN

Okay - so after I got the SIM card inserted into the MG, the first configuration step is making sure we have the correct APN configured. As a reminder, I’m using Google Fi as my cellular provider.

This change will need to be done on the local web management interface - not from Meraki Dashboard.

When the MG powers on, by default it will hand out DHCP addresses to any device connected to port 1. At the time of writing, these addresses were in the 192.168.5.x range.

Connecting a PC directly to the MG port, we should be able to reach the local management web page - either by typing in the IP address into our web browser, or using mg.meraki.com:

In my case, I could see that the MG had auto-detected my Carrier as Google Fi. However, it still had the incorrect APN.

Using the Configure tab, we can change that setting. You’ll be prompted for a username & password. By default, the username will be the serial number of the device (including dashes) with a blank password.

As shown in the screenshot above, we have a handful of options - though we’ll only care about APN.

First - change the Cellular Override option to Override SIM Settings. Then type in your APN. In my case, it’s h2g2 for Google Fi. Lastly, hit save at the bottom (just outside the view in the screenshot above).

With any luck, the modem will connect and you’ll see something like this:

The modem connects, gets an IP from the provider, and is able to validate connectivity to both the internet & Meraki Cloud.

When I originally set up my MG, I did run into some issues with this. My MG connected to the internet successfully, but said it couldn’t reach the Meraki Cloud. Not sure what caused it, but it shortly resolved itself within a few minutes. Just gotta be patient sometimes, I suppose!

Configuring the MG in Meraki Dashboard

Note: I won’t get into how to claim your device in dashboard or how to attach it to a network. If you need help, please check out the video above where I did show how to accomplish these steps

Okay! Now that our MG is configured for the correct cell network, we can log into the Meraki Dashboard and begin configuring it.

After we’ve added the MG to our network, we’ll see a new Cellular Gateway menu:

We’ll start first by going over to Configure > Settings

First section we’ll see is for Addressing & NAT:

As of today, the MG doesn’t support any form of direct internet pass-through. Instead, our only option is routed mode - where the MG will hold the IP provided by our Carrier & NAT any requests from the devices behind it.

We can change the DHCP subnet configuration here, which will affect what IP addresses are handed to clients behind the MG. In my case, I’m connecting this directly to a firewall as a secondary internet uplink - so the addressing & subnet doesn’t matter as much. By default, the MG will always consume the first available address as it’s own.

Next, we have a section for DHCP & subnets:

Here we can change our DHCP lease time, and what DNS servers are provided to our clients. The DNS setting does have pre-defined options for Umbrella DNS, Google DNS, or using whatever the upstream carrier provides. You’re also welcome to manually specify which DNS servers to use.

We can also configure reserved & fixed IP addresses here.

Reserved IP ranges are IP addresses that we don’t want the MG to provide via DHCP. So if we had any statically configured IP addresses, we could reserve them here.

Fixed IP addresses are for any client that needs a DHCP address, but we want that IP assignment to be permanent. We’ll enter the client name & MAC Address here, as well as the IP we want assigned to that device. In my case, I went ahead and inserted my firewall MAC address - and I’ll just allow the firewall to get its IP via DHCP from the MG.

By default, the MG will block all inbound traffic from the cellular network. If we need to allow any traffic inbound, we can change the Port Forwarding settings:

This allows for a light configuration of an inbound NAT. Right now, I probably won’t be using this. However, I may permit VPN access into my network via the MG at a later date.

If I needed to add anything here, the MG allows us to translate an external / public IP & port to any internal IP / port combination. It appears we can even add a IP filter to permit only trusted source addresses.

Lastly - We can configure settings for Traffic Shaping:

In this section, we can throttle our cellular throughput & configure uplink monitoring.

By default, the cell bandwidth is set to unlimited - but we can drop this down if needed. In my case, I am not using an unlimited cell data plan - so I will throttle cellular speeds to preserve data & reduce charges.

In addition, we can configure one or more IP addresses to check uplink connectivity. These addresses will be used to collect loss & latency data via the cellular connection. The MG monitoring dashboard will collect & graph this data for easy insight into the performance metrics.

Note: As a word of warning, these uplink monitors are constantly sending ICMP/ping requests. If you have a limited amount of cellular data, this may consume more data than you would like. In my testing, using only one IP for uplink monitoring consumed about 70-100M per day. More on this below…

Monitoring the MG

Now we get to the good stuff! The primary reason I opted to buy an MG was for monitoring & analytics.

Back on the dashboard, if we use the lefthand menu - we’ll go over to Cellular Gateway > Monitor > Cellular Gatways. Then select our MG out of the list.

The primary summary page isn’t too exciting:

The MG does have two gigabit ethernet ports - and we’ll see the status here.

We’ll also see the connectivity history to the Meraki cloud - which in my case is nearly 100%. Seems like one very minor blip just after 4am.

We can also see the current network utilization on the MG. This is great to have - though my current utilization is pretty low… (I am using this as a backup modem, after all).

On the left side of the page, we’ll see some of the usual info we expect from a Meraki device. Current IP, location, Serial number, and IMEI. Just below the view of the screenshot, there is also an indicator for firmware version.

Onto the Uplink tab! Let’s see what we have:

First we’ll see the Configuration section. This just gives us a quick view into what settings the MG currently has.

We’ll see the current IP info provided by our carrier, and also some statistics on our cellular connection.

Just below that info, we’ll see our cellular graphs:

This is what I wanted! It’s great to see a quick view into what our active uplink traffic is - as well as look back historically at what our LTE signal quality has been.

Not pictured here - but there is also a section of graphs on this page for our uplink monitor. This is where we can see our current & historical loss & latency stats for the cellular connection. After a few days of use - I disabled the uplink monitor due to the amount of data the feature consumes.

Finally, we also have the DHCP tab:

This will show our current DHCP subnet & any clients that have been provided an address. In my case, there isn’t any current leases here - because my firewall has a fixed IP.

Performance && Considerations

I’ve had the MG running for about a week now, and wanted to provide some things to think about.

First - How does the modem perform? Well, the first day I had it set up - I was able to get ~150M download speeds using the MG’s built-in speed test utility:

That being said - I’m lucky if I get 30-50M on an average day. I might have just gotten lucky that day with some light cellular utilization in my area. Overall though, I’m pleased with the speeds I get - they’ll certainly fit my needs.

For the few days that I had the uplink monitoring running, I saw good results. Usually 0% packet loss, with a rare spike of 5-10%. Latency was a little less reliable, but usually bounced between 50-150ms. This was also much less than the NetGear modem I had been using, which averaged 200-250ms.

Speaking of uplink tests! Let’s talk about data usage….

By default, the MG communicates intermittently with the Meraki cloud - which consumes some data. By my measurement, this is usually less than 10Mb/day. No problem here.

The uplink tests, on the other hand, do consume a bit of data. I’m not sure what frequency these run on, but it’s fairly often. Even with one uplink monitor to 8.8.8.8 configured, I was seeing data usage of 70-100Mb a day.

While seeing those metrics is valuable to me, it’s also not worth the data charges. If I was using a SIM card with an unlimited data plan - no doubt I would keep this feature enabled. However, since I am paying for the cell data used - I opted to disable this feature.

The MG does still perform it’s check-ins to the Meraki Cloud - so you’ll have availability statistics & monitoring… But disabling the uplink monitor means you’ll lose the granular data on loss & latency.

Lastly, and another word of warning, when you’re actively viewing the MG monitoring page - this also consumes additional data. To demonstrate - I’ll post a snippet of the screenshot from earlier:

If you notice, all the way on the far left there was barely any activity. However, once I loaded the MG monitoring page - you begin to see minor spikes in data usage as the Meraki Cloud starts actively polling the MG for data.

In my experience so far, this isn’t a ton of data. I’ve checked in to see how the MG has been performing a few times this week, and each time has totaled around 10-15Mb of data usage.

To sum up - I’m cheap and want to avoid excess data usage. Just wanted to provide some of that info as something to be aware of.

Final Thoughts

I’m only a week in, but pretty pleased with the MG’s performance. It’s maintained a very solid & stable connection compared to the NetGear modem it replaced. The device is intended to provide LTE connectivity or backup service for business networks, so I would certainly hope it would meet my home needs :)

Outside of that, I do wish there was a little better documentation & clarity from the Meraki team on data usage. Right now their documentation only mentions the 6-8Mb of usage due to backend data to/from the Meraki Cloud:

I would be happy to see additional settings on the uplink monitor to allow me to choose the polling frequency. I feel like throttling down the amount of requests could reduce data to a point where I would be comfortable re-enabling that feature.

Oh - and currently there are no native email alerts for the MG. So if the MG goes offline, etc… there is no alerting from the Meraki Dashboard. This kinda sucks. I’m sure this is coming soon, but for the time being I’m inclined to write my own monitor using the Dashboard APIs. (see note below!)

Overall, I’m happy with the device. Definitely looking forward to future feature & firmware updates to see where the Meraki team takes this platform!

Update 08/28/2020 - Looks like in the week since I posted this, Meraki added alerting for the MG! Now you can be notified if the cell gateway goes offline:

Hey there! First thing’s first - Hope all is well with everyone. The past few months have seen all sorts of craziness going on in the world. I’ve been lucky in the sense that my current job role was already well set up to make an easy transition to working from home all the time. That being said, I know it hasn’t been easy for everyone - and I know quite a few people who have lost their jobs, etc.

Second thing! As I’m sure you may have already seen above - I opted to spend some of my new-found free time trying out a new format. I’ve had a couple of ideas in the past for making short videos, but never forced myself to sit down and give it a shot. So here we are - after about a month of on-and-off work - I finally have something to share. Please give it a look if you’re interested, and I would appreciate any comments & feedback. I still have a few other ideas - so if this one goes well I may pursue producing a few more of these.

Okay - Now onto the real content!

A few months ago I had the chance to pick up a pair of Cisco Catalyst 9100 series access points from work. My home network has been running on Ubiquiti APs for years - but they’re getting old and I desperately needed to replace them. So along comes the Catalyst 9100 APs, which are capable of supporting 802.11ax clients - and why not take the time to upgrade & future proof? I needed some practice anyways, as I have a few customers at work that I think will be interested in these in the near future. I ended up with two 9120AXI APs.

So in the process of trying to dive on the opportunity to play with something new - I completely missed the fact that the 9100 APs have two different product SKUs. One which ships the AP pre-configured with the standard lightweight AP code that you might use if you had an external wireless LAN controller (WLC). And a second SKU that ships the AP with the Catalyst 9800 Embedded WLC (eWLC) software loaded. Of course, I grabbed the lightweight APs without checking.

Product SKUs (Example, using 9120AXI):
 - Standard Lightweight AP: C9120AXI
 - Pre-load with Embedded WLC: C9120AXI-EWC

I wrote in a previous blog about getting MAC address filtering set up on the Catalyst 9800 WLC. When I wrote that blog I was actually using the C9800-CL, which is a virtual machine version of the Catalyst 9800 controller software. I was originally excited to run the controller as a VM and not need a hardware appliance - but then got to thinking that maybe I should try and save VM resources as well. Which led me to looking at the 9800 eWLC.

Finding the Software Image

In order to convert an existing lightweight access point to one running the embedded WLC software - we first need to grab a copy of the software images from Cisco.com. Search for the model of your 9100 access point (in my case, the 9120AXI).

You’ll see two options for Software Type - and it may not immediately be obvious - but we’ll need to look under IOS XE Software to find the eWLC images:

Then we’ll grab the EWC AP image bundle. In my case, I was waiting on a specific feature set that wasn’t available until 17.x - so I downloaded the 17.2.1 software:

Okay - after we’ve done that - let’s drop everything onto a server/laptop/etc which has console connectivity to our AP and a running TFTP server.

Once you un-zip the contents of that AP image bundle, you’ll notice there are quite a number of files. We’ll only need two of them - one image to load onto the AP itself, and one that will get loaded for the WLC software container. Within the image bundle, there will be a readme.txt file that will tell you which image to use with your AP:

ap1g5 : AP1815, AP154x
ap1g4 : AP180x, AP183x, AP185x
ap1g7 : C9115, C9120
ap1g6 : C9117
ap1g6a : C9130
ap3g3 : AP380x, AP280x, AP156x

So in my case, I would use the file named ap1g7 since I had the 9120 APs. In addition, you should also see a file named C9800-AP-iosxe-wlc.binwhich we’ll need to load the controller.

What’s with that second image? Well - the Catalyst 9100 APs include a feature called Application Hosting (also found on some of the Catalyst 9000 series switches). This is equivalent to running a Linux container or Docker container directly on the AP hardware. At time of writing, this is only available for the embedded WLC software. However, there will be a future software update that will allow you to provision other software containers as well (according to the data sheet).

Converting the Access Point

Now we can get started on the actual conversion process. If it’s a new AP, we can just go ahead and boot it up with a console cable connected. If it’s already running something, you’ll likely want to factory reset the AP first. You can find detailed instructions here, but a quick summary - power off the AP, hold the mode button while plugging the AP back in, and keep the mode button held for at least 20-30 seconds. If you’re logged into the console during this time - you’ll actually see the AP counting how long you’ve held the button for. Once that counter shows at least 20 seconds, release the modebutton and allow the AP to reboot.

Once the AP is booted. The default login is Cisco / Cisco. The enable password is also Cisco. You may also want to quickly issue a show version, and take note of the current software version running on the AP (hint: we’ll need that later).

Next - it’s important to note that after we convert the AP - our default CLI will actually be the WLC, not the AP (even when connected via console). So we should configure a hostname and IP address for the AP now:

0xAP# capwap ap hostname <hostname>
0xAP# capwap ap ip <ip-addr> <netmask> <gateway>

Then we can load the new AP image and WLC image. Depending on which software version you’re running today, there is a different command to load the image:

0xAP# ! If you're running software 8.9 or lower, use the following:
0xAP# ap-type mobility-express <TFTP path to AP image> <TFTP path to WLC image>
0xAP# ! If you're running anything above 8.9, use the following:
0xAP# ap-type ewc-ap <TFTP path to AP image> <TFTP path to WLC image>

Once those commands are submitted, the AP will begin copying the software from the TFTP server. The AP will automatically reboot after the image load is completed.

Quick note: For one of my APs, the WLC software didn’t load correctly - and when my AP rebooted I was left with an error that said “EWC-AP in Recovery Mode”. Re-copying the WLC image fixed it without much trouble. If this happens, the AP will print out the command to re-image the WLC software, but I’ll also put it here for reference:

0xAP# ! If you end up in "EWC-AP Recovery Mode", run the following:
0xAP# archive download-sw ewc-ap <TFTP path to WLC image>

Okay - Once our AP has come back from loading up all the new software, we can get on with a bit of minimal config required to access the WLC web UI.

First, we’ll configure the WLC hostname & our local user account. This can be switched over later to your choice of directory service:

0xC9800eWLC# config t
0xC9800eWLC(config)# hostname <hostname>
0xC9800eWLC(config)# user-name <admin username>
0xC9800eWLC(config-user-name)# password <admin password>
0xC9800eWLC(config-user-name)# privilege 15

Next we’ll also provide the WLC with the administrative credentials used to manage the connected APs:

0xC9800eWLC(config)# ap profile <profile-name>
0xC9800eWLC(config-ap-profile)# mgmtuser username <AP admin user> password 0 <AP admin password> secret 0 <AP admin secret>

After that, we’ll go ahead and configure our basic network settings. This will be the IP address & gateway info that will be used to connect to the WLC web UI and SSH:

0xC9800eWLC(config)# interface gigabit 0 
0xC9800eWLC(config-if)# ip address <managemnt IP> <Network mask>
0xC9800eWLC(config-if)# no shut
0xC9800eWLC(config)# ip default-gateway <Gateway IP address>

Lastly - we’ll need to actually enable the web server. In my case, I opted to not enable the standard HTTP server. I only enabled the encrypted SSL-enabled web server:

0xC9800eWLC(config)# ! I only enabled the HTTPS server:
0xC9800eWLC(config)# ip http secure-server
0xC9800eWLC(config)# ! If you wanted to enable the plain-text / unencrypted web server:
0xC9800eWLC(config)# ip http server
0xC9800eWLC(config)# 
0xC9800eWLC(config)# ! Finally - Save the config
0xC9800eWLC(config)# exit
0xC9800eWLC# wr mem

When we save our config for this first time, the AP will verify that the initial configuration pieces have been completed. There is a bit of background cleanup that is performed - which removes any factory config that assisted with provisioning. Once that’s all done - we’re free to log into the web UI!

Embedded WLC Web Interface

I won’t spend a lot of time here, as there are far too many things to cover with the new 9800 series controllers. However, I did want to point out a few things that stand out regarding the Embedded WLC.

When we log into our WLC web UI - we’ll be able to use the username & password combo that we configured previously. Then we’ll be dropped into our WLC dashboard.

*Note: Screenshot taken a bit after I did my initial config. This has been running a bit now…

If we click on the number under the Access Points heading, we’ll be taken to a quick monitoring view of the current connected APs:

Here we can see the APs we have configured, along with their IP address & status info. We will also see what our Current Active WLC controller is, and what our Current Standby / Preferred Active if we have either configured.

By default, if we boot up a second AP running the embedded WLC software, it will automatically join the WLC cluster as the secondary node. Any WLC config/settings will be copied, then it’s ready in case the primary controller fails. In the event of a failure, the secondary WLC will take over - and be accessible using the same IP & login info that we used on the primary.

In my case, I’ve also configured one of my APs as a preferred primary controller. For me, this AP is connected to a switch that has a short battery backup - so it’s less likely to experience failure. This option can be configured on the individual AP itself. In the left-hand menu, drop into the Configuration section, then click on Access Points under the Wireless header. We’ll see a very similar screen to the AP monitoring screen from above. Click on the AP that we want to make our preferred primary, then jump over to the Advanced tab. There will be a checkbox for Preferred Controller:

WLC Image Repository

Last thing - and this one is important. Normally the WLC will have dedicated storage to keep AP software images, which it distributes to new APs when they come online. Unfortunately, while we gain the flexibility and limited footprint of the embedded WLC - we also lose that dedicated storage space. As you might imagine, storage on the AP is limited.

So we’ll need to make sure that the WLC has an external image repository that it can use. This configuration can be done via teh web UI and CLI. I’ll cover both very quickly here.

From the web UI - We’ll go to Administration > Software Management:

Here we’ll see our options for where to get images, as well as an inventory of current APs & their images. In the Mode drop-down, we’ll have the option of tftp, sftp, CCO, and Desktop. TFTP / SFTP are what we’re used to. With Desktop, we would just upload images directly from our laptop / PC. Interestingly though, CCO allows us to provide our Cisco.com credentials - and the controller can pull images directly from Cisco. We’ll even have the option to enable automatic software downloads - and specify whether we want to auto-download the latest software release, or only the latest recommended release.

On the CLI side of things - we can accomplish the same using the following commands on our WLC CLI:

0xC9800eWLC(config)# wireless profile image-download <profile name>
0xC9800eWLC(config-wireless-image-download-profile)# image-download mode tftp
0xC9800eWLC(config-wireless-image-download-profile-tftp)# tftp-image-server <IP address>
0xC9800eWLC(config-wireless-image-download-profile-tftp)# tftp-image-path <path to image files>

With that, any new APs that join our WLC should be able to auto-load the software necessary.

Thanks for reading!

Update 2020 / 05 / 19 - I’ve added a video above that walks through the steps detailed in this blog post.

If you’re using the ‘Basic’ Wireless setup, you may see an error when trying to apply the policy: “switch 1 dbm wireless Use of default ACL preauth v4 is not permitted”

If you come across this error, it’s a known bug (CSCvt18875) specific to only the ‘Basic’ setup wizard (which is what I used in this post below). If so, check out the video above which walks through the ‘Advanced’ setup and bypasses this error.

I’ve been spending a bit of time over the past few weeks building up a wireless lab. Trying to get a good understanding of how the new Catalyst 9800 wireless controller works, and how it differs from some of the previous iterations.

In order to play around with the new controller, I decided to try to build a new configuration that mimics my current home wireless. Today I am using Ubiquiti APs, which come with their own free controller software. Most of my current config is fairly straightforward - a few SSIDs, two APs, and a guest network with captive portal. One of my SSIDs is dedicated to any IoT devices and is more restrictive than the other networks. This network uses both a pre-shared key for authentication as well as MAC-based filtering.

In this post - we’ll walk through how to set up a new SSID with client MAC filtering.

Note: This was written using Catalyst 9800-CL version 16.12.1s. APs are configured in flexconnect with local authentication (no AAA, ISE, etc)

While this post is not focused on in-depth WLAN config, we will start by quickly setting up a new network.

Once you get logged into the controller - we’ll click on the Wireless Setup icon in the upper right-hand side. Then drop down to the Basic option:

This takes us through a pretty quick and easy wizard to set up our new location & wireless networks. At first, we will have no locations configured - so we will click Add:

We’ll start off building our location by giving it a name and description. These are used for some naming of policy objects within the WLC, so make sure to use a name that makes sense.

In my case, I’m also going with a flexconnect deployment - so we’ll select that option and also provide the AP native VLAN.

Next, we’ll click over to the Wireless Networks tab. This is where we will create our WLAN and apply the initial configuration. We don’t have any networks yet, so click Add

The two primary things we need to address are highlighted in red below. We need to create a WLAN and assign it to a VLAN. Let’s start with the WLAN by clicking Define new.

On the General tab, we’ll give this WLAN a profile name and a SSID.

Next, we’ll hop on over to the Security tab, and focus on the Layer 2 sub-tab. The first thing I want to point out - is that at this point, we will not be enabling the MAC Filtering checkbox. We’ll need some additional config first, then come back to this later.

Scroll down to the bottom of the window and there will be some settings for your authentication. By default, 802.1x will be enabled. This post won’t cover how to setup/configure that. Instead, we’ll be deselecting 802.1x and checking the box for PSK. Then a text field will appear for us to enter the Pre-Shared Key.

Once we click Apply to Device, we’ll finish up by assigning our VLAN or VLAN Group. In this case, I have already created a VLAN named IoT. If you haven’t created a VLAN yet, you can do so by going to Configuration > Layer 2 > VLAN. Then add a new VLAN under the VLANtab.

Click Add, then we’ll be back to the wizard and see the new WLAN we just created.

In order to finish up with the wizard, we just need to assign our Access Points. Click on the AP Provisioning tab. If you have already configured APs to join to this controller, you will see them on the left side under Available APs. Check which ones to apply this WLAN to, then click the arrow to move them to APs on this location.

Click Apply, and that will finalize all of the configuration we just did - then drop us back to the Wireless Setup page.

Okay - Now that we have that completed, we can move onto creating our MAC filtering policies.

Back in the menu - Let’s go to Configuration > Security > AAA

In this section - we first need to create an Authorization policy. Select the AAA Method List tab, then Authorization, then Add to create the new policy.

In here we’ll specify a name, then select Type: network, and Group Type: local. Then go ahead and Apply to Device

Once we have that, let’s go over to the AAA Advanced tab, and click Add in the Attribute List Name section.

Here we need to provide the SSID we want our MAC policy to apply to. Under Attribute Type, select SSID. Then under Attribute Value, select the target SSID that our policy will be tied to.

Don’t forget to click Save on the attribute before clicking Apply to Device!

Time to input our list of device MAC addresses! Drop into the Device Authentication section, and click Add - or upload a CSV file if you have one.

Input the device MAC Addrees and select the Attribute List Name that we configured just a minute ago. Then Apply to Device

After that - we should have our completed list of MAC addresses which will be permitted to join our wireless network. All we need to do is go back to our WLAN and enable MAC filtering.

Let’s go to Configuration > Tags & Profiles > WLANs

This should give us the list of any configured WLANS - including the one we created earlier. Go ahead and click on it to edit.

Next, we’ll jump straight to the Layer 2 section under the Security tab. Check the box for MAC Filtering and select the Authorization List we created from the drop down.

And we’re done! Clients that want to join our newly created SSID will need the pre-shared key we configured, but they will also need to be manually added to our MAC address filter as well. While this isn’t a perfect security measure since MAC addresses can be easily spoofed - it does add an extra layer of protection to keep unauthorized devices from inadvertently being able to join this specific WLAN.

In the event that a client is NOT on the authorized list, you may see the following logs in a client debug:

2019/10/25 22:26:12.327 {wncd_x_R0-0}{1}: [client-orch-sm] [22573]: (note): MAC: aaaa.aaaa.aaaa  Association received. BSSID aaaa.aaaa.b34d, old BSSID 0000.0000.0000, WLAN SuperSecret, Slot 1 AP aaaa.aaaa.b340, AP_3802-1F01
2019/10/25 22:26:12.327 {wncd_x_R0-0}{1}: [client-orch-state] [22573]: (note): MAC: aaaa.aaaa.aaaa  Client state transition: S_CO_INIT -> S_CO_ASSOCIATING
2019/10/25 22:26:12.328 {wncd_x_R0-0}{1}: [client-orch-state] [22573]: (note): MAC: aaaa.aaaa.aaaa  Client state transition: S_CO_ASSOCIATING -> S_CO_MACAUTH_IN_PROGRESS
2019/10/25 22:26:12.328 {wncd_x_R0-0}{1}: [client-auth] [22573]: (note): MAC: aaaa.aaaa.aaaa  MAB Authentication initiated. Policy VLAN 0, AAA override = 0, NAC = 0
2019/10/25 22:26:12.329 {wncd_x_R0-0}{1}: [ewlc-infra-evq] [22573]: (note): Authentication Success. Resolved Policy bitmap:11 for client aaaa.aaaa.aaaa 
2019/10/25 22:26:12.329 {wncd_x_R0-0}{1}: [ewlc-infra-evq] [22573]: (ERR): SANET_AUTHC_FAILURE - AAA Server Down username ac37434a673a, audit session id 000000000000006B3E9D2A55, 
2019/10/25 22:26:12.331 {wncd_x_R0-0}{1}: [client-orch-state] [22573]: (note): MAC: aaaa.aaaa.aaaa  Client state transition: S_CO_MACAUTH_IN_PROGRESS -> S_CO_ASSOCIATING
2019/10/25 22:26:12.331 {wncd_x_R0-0}{1}: [dot11] [22573]: (ERR): MAC: aaaa.aaaa.aaaa  Failed to assoc failure tr state entry. Incorrect validation status value :1
2019/10/25 22:26:12.331 {wncd_x_R0-0}{1}: [dot11] [22573]: (ERR): MAC: aaaa.aaaa.aaaa  Dot11 update co assoc fail. Sent assoc failure to CO. delete reason: 9, CO_CLIENT_DELETE_REASON_MAB_FAILED
2019/10/25 22:26:12.331 {wncd_x_R0-0}{1}: [client-orch-sm] [22573]: (note): MAC: aaaa.aaaa.aaaa  Client delete initiated. Reason: CO_CLIENT_DELETE_REASON_MAB_FAILED, fsm-state transition

On the opposite side, when a client is successfully able to pass MAC authentication - the logs will show the following:

2019/10/25 21:25:53.148 {wncd_x_R0-0}{1}: [client-auth] [22573]: (note): MAC: aaaa.aaaa.aaaa  MAB Authentication initiated. Policy VLAN 0, AAA override = 0, NAC = 0
2019/10/25 21:25:53.150 {wncd_x_R0-0}{1}: [ewlc-infra-evq] [22573]: (note): Authentication Success. Resolved Policy bitmap:11 for client aaaa.aaaa.aaaa 
2019/10/25 21:25:53.151 {wncd_x_R0-0}{1}: [client-auth] [22573]: (note): MAC: aaaa.aaaa.aaaa  MAB Authentication success.
2019/10/25 21:25:53.151 {wncd_x_R0-0}{1}: [client-orch-state] [22573]: (note): MAC: aaaa.aaaa.aaaa  Client state transition: S_CO_MACAUTH_IN_PROGRESS -> S_CO_ASSOCIATING

2019/10/25 21:30:08.626 {wncd_x_R0-0}{1}: [client-orch-sm] [22573]: (debug): MAC: aaaa.aaaa.aaaa  Received Dot11 association request. Processing started,SSID: SuperSecret2, Policy profile: Home_WLANID_3, AP Name: AP_3802-3F01, Ap Mac Address: aaaa.aaaa.c9a0 BSSID MAC aaaa.aaaa.b34d wlan ID: 3RSSI: 0, SNR: 32
2019/10/25 21:30:08.626 {wncd_x_R0-0}{1}: [client-orch-state] [22573]: (note): MAC: aaaa.aaaa.aaaa  Client state transition: S_CO_L2_AUTH_IN_PROGRESS -> S_CO_L2_AUTH_IN_PROGRESS
2019/10/25 21:30:08.626 {wncd_x_R0-0}{1}: [dot11] [22573]: (info): MAC: aaaa.aaaa.aaaa  DOT11 state transition: S_DOT11_ASSOCIATED -> S_DOT11_MAB_PENDING
2019/10/25 21:30:08.626 {wncd_x_R0-0}{1}: [client-orch-state] [22573]: (note): MAC: aaaa.aaaa.aaaa  Client state transition: S_CO_L2_AUTH_IN_PROGRESS -> S_CO_MACAUTH_IN_PROGRESS
2019/10/25 21:30:08.626 {wncd_x_R0-0}{1}: [client-auth] [22573]: (info): MAC: aaaa.aaaa.aaaa  Client auth-interface state transition: S_AUTHIF_ADD_MOBILE_ACK_WAIT_KM -> S_AUTHIF_MAB_AUTH_DONE
2019/10/25 21:30:08.626 {wncd_x_R0-0}{1}: [client-orch-sm] [22573]: (debug): MAC: aaaa.aaaa.aaaa  Processing MAB authentication result status: 0, CO_AUTH_STATUS_SUCCESS
2019/10/25 21:30:08.626 {wncd_x_R0-0}{1}: [client-orch-state] [22573]: (note): MAC: aaaa.aaaa.aaaa  Client state transition: S_CO_MACAUTH_IN_PROGRESS -> S_CO_ASSOCIATING
2019/10/25 21:30:08.626 {wncd_x_R0-0}{1}: [dot11] [22573]: (debug): MAC: aaaa.aaaa.aaaa  dot11 send association response. Sending association response with resp_status_code: 0 
2019/10/25 21:30:08.627 {wncd_x_R0-0}{1}: [dot11] [22573]: (info): MAC: aaaa.aaaa.aaaa  dot11 send association response. Sending assoc response of length: 137 with resp_status_code: 0, DOT11_STATUS: DOT11_STATUS_SUCCESS
2019/10/25 21:30:08.627 {wncd_x_R0-0}{1}: [dot11] [22573]: (note): MAC: aaaa.aaaa.aaaa  Association success. AID 1, Roaming = True, WGB = False, 11r = False, 11w = False
2019/10/25 21:30:08.627 {wncd_x_R0-0}{1}: [dot11] [22573]: (info): MAC: aaaa.aaaa.aaaa  DOT11 state transition: S_DOT11_MAB_PENDING -> S_DOT11_ASSOCIATED