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]

We were able to get this resolved, but the method was really weird and we hope someone can possibly explain why, since we are living in fear of what will happen if we have to reboot this switch for updates or if it crashes and reboots.

We had a 8 port dumb switch that we plugged in to the network jack on the wall and then plugged each user's PC into that switch. For every system, the PC could then connect to the network and pull the assigned address from DHCP. When we unplugged the switch and plugged the PC back directly into the Summit it stayed connected to the network.

[Stephen_Stormon]

We migrated to the "Most Stable Release" (21.1.5.2-patch1-5) as per https://www.extremenetworks.com/support/compatibility-matrices/sw-release-extremexos-eos/ and the problem still exists.

[Stephen_Stormon]

Update on this as I was able to get onsite. The PCs were able to wake but they aren't pulling an IP from the network. The switch port shows active, but the ARP table for those ports is empty. Things tried so far:

Hard set port speed and duplex instead of using "Auto"
Replaced NIC
Deleted static DHCP reservation for a couple of the systems

When I look at the ARP table on the switch, there are no entries for those PCs. When I add a static ARP entry, the switch then somehow knows that the entry is associated with the correct port that the PC is plugged into, but the PC still can't connect to the network.

[AdrianO]

To me it seems two separate issues but connected by a problem with broadcast traffic maybe...

For wol I would start capturing traffic on one of the ports to see if the magic packet directed to one of the problematic machines does arrive at least.

[Stephen_Stormon]

I don't see anything specifically in those release notes that mentions our issue? Did I just miss it?

It looks like the most stable version of XOS for these switches is EXOS 21.1.5.2-patch1-5. I'm wondering if I should downgrade to that version or go to the version that you mentioned?