cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1772
Views
6
Helpful
11
Replies

Wired 802.1X Authentication was restarted - Windows 11 Machines Only

jmins
Level 1
Level 1

Hi, we are using 9200L switches and our Windows 11 machines are experiencing the below issue.  Windows 10 machines are fine.  So I'm not sure if it's totally related to Windows 11 or if the switch port configuration needs to be adjusted.  The Windows 11 device will reauthenticate every few minutes and the event viewer displays the following error:  "Wired 802.1X Authentication was restarted. Restart Reason: Peer Initiated"  Any ideas?

11 Replies 11

@jmins what RADIUS server are you using? What do the logs indicate?

I assume the Windows 11 devices are receiving the same GPO settings as the Windows 10 devices correctly?

From the CLI of the switch run "show authentication session interface <ifname> details" and provide the output.

M02@rt37
VIP
VIP

Hello @jmins 

Do you have logs on NPS server ?

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

jmins
Level 1
Level 1

...

jmins
Level 1
Level 1

..

Try to troubleshoot 

1- change the Mode to multi-host (only for one port' just for testing)

authentication host-mode multi-host

Then check how mac address appear in mac table in this port' if it one and pc stable connect then do not do next step

2- put back multi-auth

remove below 

Mab

authentication event fail action next-method
authentication order dot1x mab
authentication priority dot1x mab

Make port do only 802.1x 

Then check PC is it stable connect 

MHM

thomas
Cisco Employee
Cisco Employee

What are your ISE Authorization Profile settings? Did you mistakenly set the Reauthentication Timer to 20 seconds?

I would consider the default of 1800 in ISE as an absolute minimum and suggest 3600 (1 hour) and preferably 28800 (8 hours).

image.png

Greg Gibbs
Cisco Employee
Cisco Employee

The question regarding what RADIUS server you are using was never answered. Are you using Cisco ISE, MS NPS, something else?

What authentication protocol are you using? EAP-TLS, PEAP(MSCHAPv2), TEAP, etc?

If the client is reauthenticating every 20 seconds, that would lead me to believe that the authentication is failing for some reason. The root cause could be multiple things including supplicant issues, certificate validity/trust issues, fragmentation/MTU issues in the path (if using EAP-TLS).

The switch configuration and session output is not enough information to provide any meaningful assistance. You would need to look at the endpoint (supplicant config, EAP certificate validity/trust, packet captures), RADIUS server (logs, EAP certificate trust chain, packet captures) as well as any fragmentation, MTU mismatches, and packet captures along the path.

pcbron
Level 1
Level 1

I'm having the same issue with several brand new 9200Ls that we just received.   Firmware (17.6.5) and dot1x config are identical to an existing 9200L that has been working as expected since summer.  I also tried upgrading to 17.09.04a.   Clients are a mix of Windows 10 and Windows 11.    The same clients work fine on the original 9200L but reauthenticate repeatedly on the new ones. 

Our RADIUS server is Portnox CLEAR and we're using EAP-TLS.   CLEAR indicates that authentication is successful every time.  The switch concurs, but as with the OP the Windows event log says that authentication was restarted:

Network Adapter: Surface Ethernet Adapter #6
Interface GUID: {92ec4e22-ae9b-47e1-8361-85cf5d9461d8}
Connection ID: 0x2
Restart Reason: Peer Initiated

This repeats every few seconds.  The switch logs the following:

Dec 22 2023 13:22:46.472 CST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/2, changed state to down
Dec 22 2023 13:22:47.176 CST: %SESSION_MGR-5-START: Switch 1 R0/0: sessmgrd: Starting 'dot1x' for client (70bc.108a.d212) on Interface GigabitEthernet1/0/2 AuditSessionID 17140A0A000000DC92FA9CFC
Dec 22 2023 13:22:48.369 CST: %SESSION_MGR-5-SUCCESS: Switch 1 R0/0: sessmgrd: Authorization succeeded for client (70bc.108a.d212) on Interface GigabitEthernet1/0/2 AuditSessionID 17140A0A000000DC92FA9CFC
Dec 22 2023 13:22:48.975 CST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/2, changed state to up
Dec 22 2023 13:22:49.284 CST: %SESSION_MGR-5-START: Switch 1 R0/0: sessmgrd: Starting 'dot1x' for client (70bc.108a.d212) on Interface GigabitEthernet1/0/2 AuditSessionID 17140A0A000000DD92FAA538
Dec 22 2023 13:22:49.975 CST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/2, changed state to up
Dec 22 2023 13:22:50.395 CST: %SESSION_MGR-5-SUCCESS: Switch 1 R0/0: sessmgrd: Authorization succeeded for client (70bc.108a.d212) on Interface GigabitEthernet1/0/2 AuditSessionID 17140A0A000000DD92FAA538
Dec 22 2023 13:22:50.867 CST: %SESSION_MGR-5-START: Switch 1 R0/0: sessmgrd: Starting 'dot1x' for client (70bc.108a.d212) on Interface GigabitEthernet1/0/2 AuditSessionID 17140A0A000000DE92FAAB68
Dec 22 2023 13:22:51.959 CST: %SESSION_MGR-5-SUCCESS: Switch 1 R0/0: sessmgrd: Authorization succeeded for client (70bc.108a.d212) on Interface GigabitEthernet1/0/2 AuditSessionID 17140A0A000000DE92FAAB68
....repeats indefinitely...

I used Wireshark to compare the Access-Accept packets from the RADIUS server for working and broken connections and they are identical except for IDs and such. 

I discovered today that the ethernet adapter used affects the outcome.  Testing with my Surface (Windows 10), the Surface Dock and Microsoft USB adapters both reauthenticate repeatedly.  A Dell USB-C adapter works normally.   All of these work normally on the original 9200L.

The affected ports are in access mode on VLAN 8.  If I change the access VLAN to another VLAN (90, for instance), the problem disappears.    I don't know what, if anything, is special about this VLAN.    VLAN 8 is in use on the original 9200, as well, though it is mapped to 108 on the uplink in preparation for renumbering in the future.  I tried mapping it on the new 9200s but it didn't resolve the issue.  All of these switches are connected to the same Dell OS 10 switch with identical end-user and uplink port configurations.

 

 

hslai
Cisco Employee
Cisco Employee

@pcbron Many thanks for sharing your findings.

On VLAN 8 vs another VLAN, I would suggest checking any differences between them, especially in terms of number of client mac addresses and WoL settings.

On Dell USB-C adapters working vs Microsoft USB adapters not working, I would ensure the firmware is up to date on the Microsoft USB adapters and verify the settings on the adapters and Windows power settings.

On older 9200L working vs newer 9200L not working, if not already done, please engage Cisco TAC support, who should be able to help debugging on the switches further to determine why the interfaces decide the links are down periodically.

I am working with TAC on this.  It is a very strange set of circumstances.  After additional testing, I found different results with various combinations of VLANs, ethernet adapters (USB and built-in) and computers, all of which work fine with our original 9200L.

I will share our findings once there is something to report.

We narrowed this down to having spanning-tree portfast enabled on the ports.  Disabling portfast resolves the issue.   Portfast is enabled on all of the ports on the original 9200L, though, so it still isn't clear why it breaks 802.1x on the new 9200Ls with the same firmware and configuration.   TAC actually asked me if we could do without portfast, but I think that's missing the point.  It should work and it does work on the older switch.