Migrated to X440G2-48t-10G4 and some PCs can no longer connect to the network

[Stephen_Stormon]

Yesterday, we moved from a stack of x440-48t switches to a stack of X440G2-48t-10G4 switches and a large number of systems are unable to connect to the network. They are a mix of IPs set statically via DHCP reservations and others that just use whatever address they pull. They cannot be woken up via a WoL broadcast. The systems that don't wake up can be manually powered on and then need to have the IP address set in Windows to what it is statically set to in DHCP, rebooted, then set to use DHCP again and they can then connect to the network. The switches are running 22.4.1.4 patch1-2. All systems with issues are running Windows 10 and are on a mix of hardware.

We also replaced the core switch that this stack is connected to with a X460G2-24t-10G4 22.4.1.4 patch1-2. A number of months ago, we had attempted to replace just the core switch and we saw this same behavior with systems not being able to connect, so we went back to the old hardware and hoped that replacing the core and the desktop switch would avoid the issue but it did not.

Has anyone heard of this? Is there some setting that we are missing? We do have a policy in place to send traffic on port 4000 (used to WoL) to the correct VLAN which is working, since most systems wake.

[Stephen_Stormon]

Policy is disabled, netlogin is disabled, only one bootp server is specified, broadcast forwarding has been disabled and the problem still persists on every system that attempts to renew or request a DHCP lease unless there is a mini switch connected between the port and a PC.

All of the settings listed above are configured at our other location and we do not have this problem. The only difference between locations is that there is a L2 based load sharing group using two ports to connect the core Summit to the desktop Summit (the other location just has 1 uplink cable between switches that is not part of a group). I can't see how this would cause any issues (and I am hesitant to try and re-configure it unless I can see a documented case where this is a problem).

[PeterK]

Broadcast forwarding is not required for wake on Lan, when you use udp-profile...

I checked your config again... Please try again with disabled policy and/or netlogin. I think your policy config is not correct...

[Stephen_Stormon]

We disabled the dhcp-snooping and identity management on all ports. We need to leave broadcast forwarding enabled on the Desktops VLAN as it is used for Wake On LAN and had been configured with no issue.

I worked through this link https://gtacknowledge.extremenetworks.com/articles/How_To/Troubleshooting-DHCP-issues, and my results have me at even more of a loss based on my testing on one system.

These are the steps that I can take to replicate the issue:
1) PC is connected directly to the network and working fine
2) Delete the IP lease from DHCP
3) Run ipconfig /release on the PC
4) Shut down the PC and then power it back on
5) After entering username and password, the PC says "network or timeout error" and Wireshark on the DHCP server looks like this. (172.22.34.1 = IP of VR on core switch, 172.22.32.27 = IP of DHCP server, 172.22.34.2 = IP of VR on desktop switch)

6) Steps 4-5 were followed multiple times and the same result happened.
7) Install a small network switch inline between the Summit and the same PC used for testing.
😎 Turn on the PC, network login works, and Wireshark on the DHCP server shows this. (172.22.34.1 = IP of VR on core switch, 172.22.32.27 = IP of DHCP server, 172.22.34.2 = IP of VR on desktop switch)

9) Steps 2-4 were followed multiple times and the same result happened (could log into the PC after deleting the lease as long as the mini switch was still in place).

The DHCP troubleshooting article talks about issues with the client or the scope, but that clearly isn't the case here as the same PC either works or doesn't work with the addition of a dumb switch inline.

[PeterK]

I don't know. For troubleshooting I would recommend to disable security features and maybe other features (udp profile, qos,cos,diffserv settings), which are not required for the main function (switching, routing, dhcp-relaying). Then it I should be working...and after that you can re-enable these features step-by-step and check, where is the problem...

[Stephen_Stormon]

Is there a known/documented issue with the dhcp-snooping setting? We use identity management which requires that to be configured.