Router's orange 10/100 light not on, with SLC 5/05

More of a "Is this normal" question.

I was troubleshooting why I couldn't ping an SLC from my desk. I have a Spider 5TX between my 5/05 and a PV550. I fixed the problem by correcting the subnet.

Anyway, while troubleshooting I noticed that the 10/100 light on the ethernet port on the 5TX doens't come on for my SLC. I checked 4 other identical systems, and they all had no 10/100 light on the ethernet ports. Does packet traffic not go fast enough on the SLC connection to trigger the 10mbit light on my router? Observation tells me that is the case, but I'd like to hear more experienced opinions.

Connection light should be on. SLC 5/05 are only 10mb so you wont get the 100 light. Are you positive it's a 5/05 and not a 5/01, 5/02 or 5/03? Because that port is not Ethernet but DH485.

On the Spider 5TX, the green LED is for Data and the yellow LED is for Speed.

The yellow LED stays dark for 10 Mb/s and lights up for 100 Mb/s.

The green LED goes on solid for a valid data link, and flashes when there is data traffic. I don't know how much data traffic is reflected by each flash.

If your SLC-5/05 controllers are more than 20 years old, they might have only 10 Mb/s Ethernet ports. Or, they might have Auto-Negotiate turned off, or be hard-set for 10 Mb/s, or have a cabling problem that doesn't allow them to support 100 Mb/s link speed.

I just checked a couple of SLC-5/05's from our boneyard; one has a laminated label on the front with "10/100" over the port and "ENET" vertically next to it. The other has no labels and might be a 10-Mb only unit and has other markings suggesting it's from the late 1990's.

This is normal. *Off* Orange light for the Spider 5TX simply means it's been auto negotiated to 10Mbits. Ken, thanks again. The answer to my question was as it often is, RTFM. Sorry guys.

auto negotiated to 10Mbits

Click to expand...

I will try not to go down a rabbit hole, but wanted to mention that "Auto negotiation" is not the same as "auto detect".

Auto-Negotiation is a two-way process when two Ethernet devices get connected with a twisted pair cable. The devices first attempt to negotiate for 100/Full, and if they can't agree on that, they drop to 100/half, then 10/full, then 10/half.

If only one device is capable of Auto-Negotiation, it does each of those steps by itself, with no responses from the "dumb" device on the other end.

This usually happens quickly and smoothly and there's no problem other than the fact that the network runs a little slower on that specific link. A device that can't Auto-negotiate generally doesn't make full use of the network anyhow.

But some devices that Auto-Negotiate also try to check on the link status later, to see if they can speed it up. I don't think there's a standard for how long the device will wait between re-negotiation attempts.

Sometimes I see this done with 100 Mb/Full Duplex and EtherNet/IP IO networks. A user will configure a 1756-ENBT (for example) for 100/Full and disable auto-negotiation, but connect it to a switch that doesn't have auto-negotiation disabled.

Even though the switch will establish 100/Full communications, it didn't do it via Auto-Negotiation, so it comes back and checks on the link at some time in the future by disabling the link and attempting another auto-negotiate session.

This disconnection and re-negotiation of the link speed and duplex results in packet loss in the I/O connection, and thus the fault and breaking of the I/O connections in the ControlLogix.

It's not relevant to your SLC-5/05; if it can only run at 10 Mb/s then it's not going to be affected by the occasional link drop/establish cycle.

Rule of thumb: only disable auto-negotiate if you can do so on both sides of the link, and there's otherwise a good reason for doing it.

Thanks to Ken and other members that give such concise and complete answer's to questions asked.