cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2311
Views
0
Helpful
8
Replies

Windows 10 Update, Onboarding, vlan switching on login

Y C
Level 1
Level 1

All -

 

Our organization runs 2960x access switches. ISE 2.2. Integration with AD. All windows 10 devices. We have been doing wired dot1x for many months now. Computers are set to Computer & User authentication. Our ruleset look something like this -

 

1. If Domain Machine result = onboard vlan

2. If Domain Machine & id in group A = vlan A

3. If Domain Machine & id in group B = vlan B

 

Everything was working fine. Once a particular cumulative update came down, KB4535996 things started breaking. A machine will onboard just fine. ISE indicates the onboard rule hit, switch indicates onboard vlan. PC gets an onboard IP and is reachable on the network.

 

Once a group A / B id logs in, the network side of things seem ok. ISE indicates the A / B ID hit, switch applies appropriate vlan. Logs on windows machine indicate a successful dot1x user change. There is very little delay - maybe 1-2-3 seconds after typing your domain pw and hitting enter the port switches vlans. Problem is the device never does DHCP a second time. It retains the onboard ip it had previously. After maybe 30 seconds the globe in the system tray pops up instead of the normal pc/monitor icon and connectivity is lost. I've waited for an hour or more but still no dhcp request - I've spanned the client switchport - a dhcp request is never generated or leaves the client.

 

You can force a dhcp renew via ipconfig /release and /renew and it works fine - the moment you hit enter on /renew the request leaves, the normal dhcp steps take place, and everything is happy again.

 

You can uninstall the update KB4535996 and the problem goes away - onboard > student/staff switch happens seamlessly as it has been before. You can reinstall the same update on the machine and it breaks again. It is very repeatable and consistent across many machines - various dell and MS models, various nics (even usb > ethernet dongles) etc. It seems this update has changed default behavior (perhaps not on purpose) to re-do dhcp on a dot1x user change.

 

Hoping someone's run into this. Any thoughts or ideas? Easy solution is to add a script on startup that runs a release and renew. That actually works, tested it. But just seems like it's band-aiding a bigger issue.

1 Accepted Solution

Accepted Solutions

Hi,

 

   Remove this particular update "KB4535996", it has been confirmer by Microsoft to cause several problems, connectivity and performance issues; Microsoft should fix it in appropriate timeframe, and you'll apply the proper update.

 

Regards,

Cristian Matei

View solution in original post

8 Replies 8

Cristian Matei
VIP Alumni
VIP Alumni

Hi,

 

   I would say it has to do with the "Connected Standby" and "Modern Standby" features' actually with these features and some incompatibilities with various NIC drivers. Try to disable this Windows feature from registry and see if it works. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power an set "CsEnabled" to "0".

 

Regards,

Cristian Matei.

I removed my workaround startup script, made your registry change, and rebooted. The problem returned exactly as it was before - the vlan on the switchport changed but the device kept it's original onboard ip and hasn't renewed.

Hi,

 

   Remove this particular update "KB4535996", it has been confirmer by Microsoft to cause several problems, connectivity and performance issues; Microsoft should fix it in appropriate timeframe, and you'll apply the proper update.

 

Regards,

Cristian Matei

Y C
Level 1
Level 1

Does anyone know if there's anything formal (perhaps part of an RFC?) stating that on a dot1x user change the client must do dhcp again? It seems like it should be no different then a link down / link up event but I'd like to find something formal if possible. I'm pouring through RFC3580 now but if anyone knows specifically off hand it'd be appreciated.

Hi,

 

    There is no such thing specified in the RFC, about the DHCP behaviour as related to EAP; this is the job of the OS and NIC to re-initialize a DHCP Request, upon a new successful EAP session.

 

Regards,

Cristian Matei.

Yep, I agree with you that it's the job of the NIC/driver/os. I need something official to prove that to Microsoft though unfortunately.

 

We have the same setup (with different vlans / ip ranges) for wireless, and it still works there. For whatever reason this update is only affecting wired dot1x users.

https://answers.microsoft.com/en-us/windows/forum/all/kb4540673-2020-03-cumulative-update-network-stack/ab5355e7-9603-46e0-b97c-2261c220cf66

 

Ok, it's not just me. Here's two more cases of the same thing. They are noting a different update number but it's a newer cumulative update so it makes sense that it includes any bugs introduced by the past updates.

Hi,

 

 As i said, remove the update manually and wait for Microsoft to fix their stuff. If you look it up, there are way too many complaints regarding this KB.

 

Regards,

Cristian Matei.