PCs and laptops do not detect network without using a repeater device.

[mkennicutt]

We recently replaced all our switches with 'Catalyst 9300 48N UPOE's -- now certain endpoints (namely Panasonic toughbooks and HP PCs) do not detect when you plug in a network cable unless you use some sort of repeater like an IP phone (which fortunately most desks have) or small intermediary switch. Our network is a very simple star with homeruns to every desk and none of the runs gets even close to 300 meters. The odd part is that I can plug my laptop directly into the switchport and get connected with no problem, but if I am in my office going through the longer run through the patch panel (but still using the same switchport I just tested direct) it says on the adapter in Windows 'network cable unplugged'. I can get connected by using a small switch, an IP phone, or even using a Inland USB LAN adapter... but not using the built-in NIC (on either the toughbook CF-54 or HP Prodesk 600).

I've tested the network run with a Fluke tester and it finds no crosstalk or impedance faults and measures this particular run at 185 feet. But really this issue is much larger than my run. It's the entire office, which is admittedly older and the runs are CAT5, BUT we just built a brand new Public Works facility with all new CAT6e runs and also using these same Catalyst 9300 switches and they have the exact same issue over there. If they aren't going from the wall jack to either an IP phone or a port replicator or switch (all of which would act as repeaters/signal-boosters) the PCs and laptops alike will not see that there is a network cable plugged in.

Where do I even start troubleshooting this crazy issue??

[Dustin Anderson]

We have over 450 9300s and 50 UPoE without issues, so I would maybe look at port config, logs, and are there any custom settings on the end devices?

When you plug in a device, does the switch show connected on the port?

Is the device hard set on speed/duplex instead of auto?

Since you can see the issue on Cat6A, it's probably a config issue somewhere. I would also look if there is newer network drivers for the toughbooks etc.

Also, what code version are you running on the switch? We are currently upgrading to 17.9.3 from 17.6.4

[mkennicutt]

All clients should be auto-neg. Switches (presumable all) running 17.3.

If it helps... here is the config from my port:

interface FiveGigabitEthernet2/0/5
description PVIT Spare Office
switchport access vlan 2
switchport mode access
switchport voice vlan 200
device-tracking attach-policy IPDT_POLICY
no logging event link-status
trust device cisco-phone
auto qos voip cisco-phone
spanning-tree portfast
spanning-tree bpduguard enable
service-policy input AutoQos-4.0-CiscoPhone-Input-Policy
service-policy output AutoQos-4.0-Output-Policy

[Dustin Anderson]

The devices like phones etc that work, are they 100Mb, or 1Gb links?

What fluke do you have, like a LinkRunner that can test to the switch? I could see wiring if it's Cat5 and not Cat5E, but doesn't make sense in the new facility with Cat6A

I know 17.6.5 or 17.9.3 are the current recommended code for the 9300s. I don't see a specific bug as far as I can tell. Are you able to do an upgrade on any? not sure if you have spares or not. With ASIC updates takes about 20 min to reboot.

And anything in the show log on the switch?

[Dustin Anderson · Accepted solution]

I did find this bug on 17.3.4 Affects if the cable is over 50m, you can test workaround of setting power inline never, code update will correct it if it's this bug.

Cat9300-48UX ports may not link up when connected to peer Intel NIC I219
CSCwa10331 

Symptom: New C9300-24UX, C9300-48UXM, C9300-48UN switches may see a complete link down or an extended delay to link up when connected to Intel NIC i219-LM. When first plugging a client into the switch it can take anywhere from 30-60 seconds before the switch will show the respective interface as "up".

Conditions: Issue seen when C9300-24UX, C9300-48UXM, C9300-48UN switches connected to Intel NIC i219-LM PCs over longer cables/patch panels (more than 50 meters) The issue is fixed in 17.3.6, 17.6.3 and later releases

Workaround: Configure "power inline never" on the interface connected to the PCs Sometimes, disabling "ultra low power mode" on the NIC of the connecting endpoint and/or disabling "energy efficient ethernet" on both the switch and end client can cause the link negotiation to "link up" on expected timelines (roughly 1-5 seconds)

Further Problem Description: If this same issue is seen on the C9400 Switches (C9400-LC-48HN or C9400-LC-48HX) please refer to CSCwf94472.

[mkennicutt]

Thanks for digging for that!!! That might just be it. We're a small city government and the 'county' manages our network (they just give us access to switches). I'll put in a request to get all the 9300's updated. Thanks again!!

[Leo Laohoo]

mGIG switches do not support 10 Mbps.  

We have seen in several deployments where downstream clients, with 1 Gbps NICs, require 10 Mbps.  In one case, the clients would boot up but not accept DHCP handed out.  In another case, the downstream client would not join a server.