The short answer
How to Troubleshoot an Ethernet Connection
To troubleshoot an Ethernet connection, establish what changed and whether one device or many are affected, check the link light and the switch port status and swap the cable, read the port speed, duplex, and error counters on the switch, confirm the port VLAN matches the device subnet, confirm the device address, mask, and gateway, ping from a laptop in the same subnet before testing across the firewall, check the ARP and MAC tables to see who is actually answering, test the application port with a TCP connection test, and record the cause when the connection is restored.
Key points
- Bottom up: physical, then switch port, then addressing, then firewall and application. Do not skip a layer because it looks fine.
- The switch port counters tell the truth: CRC errors and late collisions mean a cable or a duplex mismatch, not a software problem.
- Test from inside the subnet first. A ping across the firewall tests three things at once and tells you nothing when it fails.
- A duplex mismatch works at low traffic and fails under load; force both ends or auto-negotiate both ends, never one of each.
- Ping proves the network path; only a connection to the application port proves the device will talk.
- Write down what changed, what you measured, and what fixed it; the next failure is usually the same one.
What you need
- A laptop with an Ethernet port, a known-good patch cable, and the switch console or management login
- The network drawing and IP schedule for the affected segment
- A cable tester or a spare cable of the right length
- The device manual for its Ethernet status indicators
- Access to the firewall log
- The controller or SCADA communication status display
Procedure
- 1
Define the failure
One device or many? Total or intermittent? Since when, and what changed just before: a firmware update, a new cable, a moved port, a firewall rule, a power event? A failure across many devices behind one switch or link points at that switch or link; a single device points at its cable, port, or configuration.
- 2
Check the physical layer
Look at the link light on the device and the port light on the switch. No light on either end means the cable, the port, or the device port is dead: swap in the known-good cable, then try another switch port. Fiber: confirm the transceiver type matches at both ends and the fibers are not swapped.
- 3
Read the switch port status
On the switch, show the port status: up or down, speed, duplex, VLAN, and the error counters. A port that is administratively down or error-disabled was turned off by a person or by a protection feature, and the log says which.
- 4
Check speed and duplex
Both ends should agree. Auto on one end and forced on the other produces a duplex mismatch: the auto end falls back to half duplex, and the port shows late collisions on the half side and CRC or alignment errors on the full side. Set both ends to auto-negotiate or both to the same forced setting.
- 5
Check the error counters over time
Clear the counters, wait ten minutes under normal traffic, and read them again. CRC and input errors that climb point at the cable, a connector, or noise coupled from a nearby drive cable. Output drops point at congestion. Zero errors with no communication means the problem is above the physical layer.
- 6
Confirm the VLAN
The port VLAN must match the subnet the device is addressed in. A device moved to another switch port on a different VLAN links fine and reaches nothing.
- 7
Confirm the device addressing
Read the address, mask, and gateway from the device itself. A mask of 255.255.0.0 on a device whose neighbors use 255.255.255.0, a gateway in the wrong subnet, or a duplicate address each produces a device that partly works.
- 8
Ping from inside the subnet
Put the laptop on an access port in the same VLAN with an address in the same subnet, and ping the device. Success here means the device, cable, port, and VLAN are good and the problem is routing or firewall. Failure here rules those out and keeps the search local.
- 9
Check who is answering
Look at the ARP table on the laptop after the ping and at the MAC address table on the switch. The MAC should be the device and the port should be the one on the drawing. A different MAC is a duplicate address; a different port is a mislabeled cable.
- 10
Test across the firewall
Now ping from the client that actually needs the device. If it fails while the local ping works, read the firewall log for the denied connection and check the gateway on both devices.
- 11
Test the application port
Ping success does not mean the protocol works. Test a TCP connection to the port the application uses, such as 502 for Modbus TCP or 44818 for EtherNet/IP. A refused or timed-out connection with a working ping is a service not running, a device connection limit, or a firewall rule that allows ping but not the port.
- 12
Restore and record
After the fix, watch the counters and the communication status for long enough to see the original failure would have recurred. Record the symptom, the measurements, the cause, and the fix on the work order and in the network notes.
Symptoms and where to look
| Symptom | Most likely layer | First check |
|---|---|---|
| No link light either end | Physical | Cable swap, then another switch port, then the device port |
| Link light, no ping from same subnet | Port or addressing | Port VLAN, device address and mask, duplicate address |
| Ping works locally, not from the client | Routing or firewall | Gateway on both ends, firewall log |
| Ping works, protocol does not | Application | TCP test to the port, device connection count, service enabled |
| Works then drops under load | Duplex mismatch or congestion | Late collisions, CRC errors, output drops on the port |
| Drops when a drive runs | Noise | Cable routing next to drive output cable, shield bonding, CRC errors that track the drive |
| Whole switch or area drops for seconds | Loop or spanning tree | Switch log for topology changes, a new cable between two switches, storm control counters |
Useful commands
ipconfig /all
ping 10.5.10.21 -t
arp -a
tracert 10.5.10.21
Test-NetConnection 10.5.10.21 -Port 502
show interfaces status
show interfaces GigabitEthernet1/0/5
show mac address-table interface GigabitEthernet1/0/5
show logging | include 1/0/5
clear counters GigabitEthernet1/0/5Verification
- Link is up at the expected speed and duplex on both ends.
- Error counters do not increase over ten minutes of normal traffic, including with drives running.
- Ping from inside the subnet and from the client both succeed with no loss.
- The application connection is established and the communication status on the controller or SCADA is good.
- The cause is recorded and the drawing or schedule is corrected if it was wrong.
Frequently asked questions
- The link light is on but the switch shows the port down. How?
- The device sees a carrier from the switch while the switch has the port administratively down, error-disabled, or in a state that stops forwarding. Read the switch port status and log; the port was disabled by configuration, by a security feature such as port security or BPDU guard, or by a loop protection feature.
- Should I force 100 Mb full duplex on PLC ports?
- Only if both ends are forced identically and the setting is documented. Modern equipment auto-negotiates reliably, and the classic failure is a forced switch port talking to an auto device, which negotiates to half duplex. Default to auto on both ends.
- The device pings but its web page and its protocol both time out. What does that mean?
- The network path is good and the device is not serving the port. Common causes: the service is disabled, the device has reached its connection limit and needs old connections to time out, the firmware crashed the TCP stack while ICMP still answers, or a firewall allows ICMP but not the port. Power cycle the device only after checking the firewall and connection count.
- How do I find a loop?
- A loop shows as every port on the switch flashing continuously, high CPU on the switch, and devices across the whole VLAN dropping. Look at the switch log for topology changes and the storm control counters, then find the cable that was added most recently between two switches or between two ports on the same switch. Enable spanning tree and loop protection so the next one is blocked instead of felt.
Related topics
- Ethernet Device Drops OfflineAn industrial Ethernet device that disappears and comes back. Duplex mismatch, cabling, spanning tree, and the switch counters that identify it in minutes.
- How to Diagnose Packet LossFind where and why frames are dropped: measure loss with a continuous ping, localize it hop by hop from both directions, read the port counters on the path, and match the pattern to its cause: a cable, a duplex mismatch, congestion, a loop, or a radio link.
- Device Times OutA polled device that answers late or not at all: how to read the driver counters, tell a dead device from a slow one, and find the timeout setting, the bus loading, the radio latency, the duplicate address, or the device that is simply too busy to answer.
- How to Assign IP Addresses on a Control NetworkBuild an addressing plan before the first device is configured: one subnet per zone and site, a fixed block layout so an address says what the device is, static addresses on everything that controls a process, and a schedule that is kept current.
- How to Configure VLANs on a Control NetworkTurn a zone plan into switch configuration: a VLAN per zone with its own subnet, access ports for devices, tagged trunks between switches, a native VLAN that carries nothing, a separate management VLAN, and routing between VLANs only through the firewall.
- How to Test FiberTest a fiber link at acceptance and at fault: inspect and clean every connector, measure end-to-end loss with a light source and power meter in both directions and at the operating wavelengths, and record everything with the fiber schedule.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.