Meraki

Aleixo6028

Guys

I need some help. I have a switch in the C9300L-48UXG-4X stack, and it's running CS 17.2.2.

We're using 802.1x wired, and it works great!

The problem occurs when we reload the switch. After the switch boots, the clients aren't authenticated with 802.1x and MAB. It works again when we disable the port and enable it again. After that, the client authenticates.

PhilipDAth

17.2.2 is not a recommended software version from what I can see.
https://documentation.meraki.com/Cloud_Monitoring_for_Catalyst/Onboarding/Cloud_Monitoring_for_Catal...

I would try a recommended release, like 17.12.3.

Aleixo6028

My switch is currently running CS 17.2.2. Can I use iOS XE 17.12.4? What's the difference between CS 17.2.2 and iOS XE 17.12.4?

I've seen in some articles that when I upgrade from 17.2.2 to 17.12.4, my device will have monitoring functionality, not Meraki Cloud management.

CKnetworking

Hi,

I gave it a try in my lab with a Catalyst 9300 in "Configuration Source: Cloud" mode (formerly known as "Cloud Management" mode) and different IOS XE firmware versions. Since a firmware downgrade from IOS XE to CS is restricted, I wasn't able to try out with the latest CS firmware.

For my tests, I was using a client (Lenovo notebook) using MAB for authentication and Cisco ISE 3.4P3 as RADIUS server. I've collected the AAA logs from the switch right after rebooting it. In the logs posted below, I've altered the MAC address of my client for obvious reasons.

Access Policy

This is the Access Policy I've configured in the Meraki Dashboard and applied to the switchport.

Name: ise

Authentication method: RADIUS server

RADIUS servers: "RADIUS Server testing" enabled, "RADIUS CoA support" enabled and "Enable RADIUS accounting servers" enabled

Connection -> Policy Type: Hybrid authentication

Connection -> Host mode: Multi-Auth

Connection -> 802.1X control direction: Both

Options: "Voice auth" enabled"

All other options are set to the default setting.

Behavior with IOS XE 17.15.4

*Sep 26 20:44:18.143: %SESSION_MGR-5-START: Switch 1 R0/0: sessmgrd: Starting 'dot1x' for client (aabb.ccdd.eeff) on Interface GigabitEthernet1/0/48 AuditSessionID 000000000000000B87C4FD27
*Sep 26 20:44:18.855: %SESSION_MGR-4-TERMINATE: Switch 1 R0/0: sessmgrd: Authentication session terminated for client (aabb.ccdd.eeff) on Interface GigabitEthernet1/0/48 AuditSessionID 000000000000000B87C4FD27 Reason lost-carrier
*Sep 26 20:44:22.172: %SESSION_MGR-5-START: Switch 1 R0/0: sessmgrd: Starting 'dot1x' for client (aabb.ccdd.eeff) on Interface GigabitEthernet1/0/48 AuditSessionID 0A0D10AC0000000C87C50D1B
*Sep 26 20:44:42.173: %DOT1X-5-FAIL: Switch 1 R0/0: sessmgrd: Authentication failed for client (aabb.ccdd.eeff) with reason (No Response from Client) on Interface Gi1/0/48 AuditSessionID 0A0D10AC0000000C87C50D1B
*Sep 26 20:44:42.174: %SESSION_MGR-7-STOPPING: Switch 1 R0/0: sessmgrd: Stopping dot1x for client aabb.ccdd.eeff on Interface GigabitEthernet1/0/48 AuditSessionID 0A0D10AC0000000C87C50D1B
*Sep 26 20:44:42.174: %SESSION_MGR-5-START: Switch 1 R0/0: sessmgrd: Starting 'mab' for client (aabb.ccdd.eeff) on Interface GigabitEthernet1/0/48 AuditSessionID 0A0D10AC0000000C87C50D1B
*Sep 26 20:44:42.203: %MAB-5-SUCCESS: Switch 1 R0/0: sessmgrd: Authentication successful for client (aabb.ccdd.eeff) on Interface Gi1/0/48 AuditSessionID 0A0D10AC0000000C87C50D1B
*Sep 26 20:44:42.223: %SESSION_MGR-5-SUCCESS: Switch 1 R0/0: sessmgrd: Authorization succeeded for client (aabb.ccdd.eeff) on Interface GigabitEthernet1/0/48 AuditSessionID 0A0D10AC0000000C87C50D1B

As you can see in the logs from IOS XE 17.15.4 above, the first MAB authentication attempt after a switch reboot fails but next one is successful. There's no need to bounce the port in order to get the client to authenticate itself successfully.

Behavior with IOS XE 17.18.1

*Sep 26 19:35:50.151: %SESSION_MGR-5-START: Switch 1 R0/0: sessmgrd: Starting 'dot1x' for client (aabb.ccdd.eeff) on Interface GigabitEthernet1/0/48 AuditSessionID 000000000000000B87864E5E
*Sep 26 19:35:50.151: %SESSION_MGR-5-FAIL: Switch 1 R0/0: sessmgrd: Authorization failed or unapplied for client (aabb.ccdd.eeff) on Interface GigabitEthernet1/0/48 AuditSessionID 000000000000000B87864E5E. Failure reason: Authc fail. Authc failure reason: AAA Server Down.
*Sep 26 19:35:50.830: %SESSION_MGR-4-TERMINATE: Switch 1 R0/0: sessmgrd: Authentication session terminated for client (aabb.ccdd.eeff) on Interface GigabitEthernet1/0/48 AuditSessionID 000000000000000B87864E5E Reason lost-carrier
*Sep 26 19:35:54.262: %SESSION_MGR-5-START: Switch 1 R0/0: sessmgrd: Starting 'dot1x' for client (aabb.ccdd.eeff) on Interface GigabitEthernet1/0/48 AuditSessionID 0A0D10AC0000000C87865E95
*Sep 26 19:36:14.263: %DOT1X-5-FAIL: Switch 1 R0/0: sessmgrd: Authentication failed for client (aabb.ccdd.eeff) with reason (No Response from Client) on Interface Gi1/0/48 AuditSessionID 0A0D10AC0000000C87865E95
*Sep 26 19:36:14.264: %SESSION_MGR-7-STOPPING: Switch 1 R0/0: sessmgrd: Stopping dot1x for client aabb.ccdd.eeff on Interface GigabitEthernet1/0/48 AuditSessionID 0A0D10AC0000000C87865E95
*Sep 26 19:36:14.265: %SESSION_MGR-5-START: Switch 1 R0/0: sessmgrd: Starting 'mab' for client (aabb.ccdd.eeff) on Interface GigabitEthernet1/0/48 AuditSessionID 0A0D10AC0000000C87865E95
*Sep 26 19:36:14.293: %MAB-5-SUCCESS: Switch 1 R0/0: sessmgrd: Authentication successful for client (aabb.ccdd.eeff) on Interface Gi1/0/48 AuditSessionID 0A0D10AC0000000C87865E95
*Sep 26 19:36:14.305: %SESSION_MGR-5-SUCCESS: Switch 1 R0/0: sessmgrd: Authorization succeeded for client (aabb.ccdd.eeff) on Interface GigabitEthernet1/0/48 AuditSessionID 0A0D10AC0000000C87865E95

As you can see in the logs from IOS XE 17.18.1 above, the behavior is (almost) completely identical to IOS XE 17.15.4.

Conclusion

This cloud be an issue with the CS 17.2.2 firmware. You could open a Meraki support case for this or move on to either IOS XE 17.15.4 (currently marked as "stable release candidate") or IOS XE 17.18.1 (currently marked as "beta").

Best regards,

Chris

Aleixo6028

Thank you very much for your feedback, it helped me a lot.

Just to confirm the configuration.

Below the MAB

below the 802.1x configuration

In my case, we work with a laptop and a Cisco phone. I enabled Multi-Host so that only one device needs to authenticate.

Could this be the configuration?

CKnetworking

Hi,

if I understood you correctly, your setup looks like this: Switch <-> VoIP phone <-> Laptop, correct?

Is the phone authenticating using MAB and the laptop authenticating using 802.1X?

Are there any specific reasons you're using two separate access policies (one for MAB and one for 802.1X) instead of a single one with "Policy Type" set to "Hybrid authentication"?

First of all: I'd only use the host mode "Multi-Host" with very specific use cases and never on client-facing ports as it introduces a potential security risk. Just imagine you're connecting a VoIP phone to your switch. After the VoIP phone is authenticated successfully, the switchport will be put into the forwarding state. Since the host mode "Multi-Host" only requires the first connected device to authenticate, all further connected devices to that very same switchport won't need to authenticate themselves anymore. This means that now anyone with physical access to that VoIP phone can connect any arbitrary device to it (most of the VoIP phones have a second port on the back for connecting a client device) and can simply access your network.

In your case (based on the information and screenshots you've provided), I'd create and use a single access policy using hybrid authentication and host mode multi-auth like this:

Don't forget to set the Critical Auth/Failed Auth VLAN to your preferred settings.

Please keep in mind that in the suggested configuration above your RADIUS server needs to include the RADIUS attribute Cisco-AVPair "device-traffic-class=voice" in its Access-Accept frame or else your VoIP phone will be put in the configured data VLAN instead of the voice VLAN. In Cisco ISE, this can be achieved easily by going to your authorization profile and activating the "Voice Domain Permission" option under "Common Tasks".

Best regards,

Chris

Aleixo6028

if I understood you correctly, your setup looks like this: Switch <-> VoIP phone <-> Laptop, correct?

yes, correct

Is the phone authenticating using MAB and the laptop authenticating using 802.1X?

We are not authenticating the phone on MAB, so we are authenticating the laptop on 802.1x

I was facing a problem with hybrid authentication mode in version CS 17.2.2, I believe that in version 17.15.4 it should work fine, I will need to do the tests

Do you know if it's recommended to use caching ?

Do you know if it's recommended to use the re-authentication interval?

I have good news: I upgraded to iOS XE 17.15.4, and after the reload, 802.1x and MAB worked fine, no problems.

CKnetworking

Hi,

@Aleixo6028 wrote:
We are not authenticating the phone on MAB, so we are authenticating the laptop on 802.1x

In this case, deactivate the "Voice auth" option within the access policy but I would highly recommend to authenticate your phones as well.

@Aleixo6028 wrote:
Do you know if it's recommended to use caching ?

As every so often: It depends. I normally enable it on branches to mitigate some risks such as unreliable internet connection (= and therefore unreachable AAA servers) so that users and devices still can authenticate successfully if they've authenticated themselves within the given "Caching timeout" value before.

@Aleixo6028 wrote:
Do you know if it's recommended to use the re-authentication interval?

Same here: It depends. Some hardening guides recommend doing so as it mitigates some risks. It can also help clients placed wrongly in the "Failed Auth VLAN" (for whatever reason) to get back to their intended one. I most often set it to 7200 seconds.

@Aleixo6028 wrote:
I have good news: I upgraded to iOS XE 17.15.4, and after the reload, 802.1x and MAB worked fine, no problems.

Awesome news! The "native" IOS XE firmware will be the future as the CS firmware won't be developed any further once IOS XE becomes a stable release. I highly recommend you to enable the Cloud CLI feature (a native read-only SSH tunnel via the cloud to the switch) which helps tremendously when troubleshooting or if you want to get some quick information out of the switch. To enable it, go to "Organization" -> "Early Access" and simply switch on "Cloud CLI for Cloud-native IOS XE".

Best regards,

Chris

Aleixo6028

Today I noticed a reload on the switch and the problem occurred.

Below you can see that the "domain" is set to "Unknown."

I took a look and it was assigned to the failed VLAN.

Meraki

Community

Problem 802.1x Meraki - 9300 UXG

Problem 802.1x Meraki - 9300 UXG