Thanks @Chris_Skees and @cmr I'm adding my 2 cents here: 1st cent) A connection disruption is inevitable in such cases: either the station NIC or bad cabling will cause it as it did before or you and the end-user will as part of the troubleshooting. I prefer the later as it gets the user closer to a solution. So, I wouldn't discard a poorly written/implemented ethernet device driver at the OS layer on the user's workstation. I.e.: maybe NIC driver is misconfigured and turning ethernet off when OS is entering energy saving modes. I know its unlikely since it's all new stations and that's the only one having issues. In addition, this tshoot approach would be reaching too far outside support scope. Nevertheless, it's worthy investigating. In this sense, this Meraki article is also relevant. It mainly talks about duplex, but speed and duplex are tied to Ethernet auto-negotiation (802.3u). In conclusion, before going for the cabling testing feature and/or swapping cable for a new one, I would leave Meraki device port with speed and duplex auto-negotiation turned on while configuring the station's OS to don't turn off NIC when saving energy as well as NIC manual contig to 1000Mbps full-duplex (no auto-negotiation). Since this 1000Mbps full-duplex is the preferred negotiation at Meraki device, we would see the port connecting at ideal speed and duplex and no more disruptions. If we don't see this result, then we would have a bad cable. This brings us to my 2nd cent. 2nd cent) Going deeper into this rabbit hole: (far fetched tshoot approach). If the user is more of a tech person, maybe you could test using a Loopback plug tool connected to the port you're investigating and run Meraki's cable test feature. This would isolate bad cable and NIC driver. Ideally, those cable testing features should be used with a loop tool, otherwise it will cause interruptions on whatever is connected to the port where you run this test. Those loop tools are generally cheap but quite effective. Check out this one (I swear I'm not affiliated or have any kind of connection to those guys - it's just a google search result)! Going further deeper: I come from older switch and networking devices but the fundamentals are valid. So check out this Cisco Document: Troubleshooting Catalyst Switches to NIC Compatibility Issues (Old but Gold).😎 In our case here, we pay attention to these three sections: Why Do Autonegotiation and Compatibility Issues Exist? General Troubleshooting for 10/100/1000 Mbps NICs Autonegotiation Valid Configuration Table I love this foot note: "2 Some third-party NIC cards can fall back to half-duplex operation mode, even though both the switchportand NIC configuration are manually configured for 100 Mbps, full-duplex. This is because NIC autonegotiation link detection still operates when the NIC is manually configured. This causes duplex inconsistency between the switchport and the NIC. Symptoms include poor port performance and frame check sequence (FCS) errors that increment on the switchport. In order to troubleshoot this issue, try to manually configure the switchport to 100 Mbps, half-duplex. If this action resolves the connectivity problems, this NIC issue is the possible cause. Try to update to the latest drivers for your NIC, or contact your NIC card vendor for additional support. " In essence, that was an example of a poorly written/implemented device driver. I would only add to that part: and make sure OS energy saving options aren't interfering - e.g.: energy saving feature turning off NIC, turning off USB-C or thunderbolt when station is connected through an ethernet transceiver. Hope this is useful - or at least educational! 🤓
... View more
