An industrial switch port showing LINK UP confirms that the physical layer established some mode. It does not prove that both ends selected the same speed, duplex behavior, or flow-control capability. Ethernet auto-negotiation is a PHY process in which both devices advertise abilities, identify their common set, and apply a standard priority resolution. Forced settings, marginal pairs, or implementation differences can still produce low speed, frame loss, latency, or repeated link flaps.
Why two PHYs exchange abilities first
Before application frames cross a copper Ethernet link, each PHY must detect a peer and determine which operating modes both sides can support. With auto-negotiation enabled, Fast Link Pulse, or FLP, bursts encode an ability word. The advertised information can include supported speeds, full or half duplex, pause capability, acknowledgement, and additional pages. These pulses belong to the physical layer; they are not VLAN or IP packets.
Each end intersects its local abilities with the peer advertisement. If an industrial switch supports gigabit full duplex while an older controller supports only 100BASE-TX full duplex, the common result should be 100BASE-TX full duplex. An advertised ability is therefore different from the active mode. Troubleshooting should capture both the local advertisement and the resolved link state.
How speed and duplex are resolved
Auto-negotiation does not merely select the largest number. It applies the priority defined for mutually supported modes. After resolution, the PHY configures signaling, clocking, and electrical behavior while the MAC adopts the corresponding frame-handling mode. Full duplex supports simultaneous transmission and reception and does not use the half-duplex collision process.
Gigabit copper also depends on all required pairs and a successful training process. Missing pairs, poor termination, excessive crosstalk, or impedance discontinuities can prevent gigabit operation. A port may fall back to 100 Mbps or repeatedly retrain. That symptom points to the complete channel, including patch cords, connectors, patch panels, and field cable, rather than proving a switch performance problem.
Why parallel detection can leave a duplex mismatch
If one end disables auto-negotiation and forces a 10 or 100 Mbps mode, the automatic end may use parallel detection to infer speed from the received signaling. Parallel detection generally cannot learn the forced peer’s duplex capability. The automatic side may therefore select half duplex while the forced side remains full duplex.
A duplex mismatch does not always take the link down. Under light traffic it can appear healthy. As load rises, throughput becomes asymmetric, retransmissions and latency increase, and FCS errors, late collisions, or related counters may grow. Counter names vary among chipsets, so engineers should correlate both ends, packet captures, and application behavior.
Read symptoms through the physical mechanism
When a port consistently resolves below the expected speed, first compare both advertisements and then bypass the installed channel with a known-good short cable. Recovery with the short cable points toward pair mapping, termination, a connector, or the permanent link. Continued failure shifts attention to port configuration, supported capabilities, firmware, and the attached device.
If the speed is correct but traffic is slow in one direction or error counters keep rising, verify duplex consistency. Energy Efficient Ethernet can enter a low-power state during idle periods. Some device combinations expose intermittent latency at low load. A controlled comparison with the same EEE setting at both ends can provide evidence, but a single improvement should not be treated as final proof.
Preserve evidence before changing the port
Record the administrative state, advertised abilities, resolved speed and duplex, pause settings, EEE status, link transitions, and error counters at both ends. If packet capture is needed, document the mirror point, traffic direction, and offered load. Change one item at a time: align both ends to auto, substitute one cable, or move one port. Multiple simultaneous changes destroy the evidence chain.
After recovery, verify more than the LINK indicator. Test bidirectional throughput, latency, packet loss, the real control or video workload, and stable counters. Industrial vibration, temperature, and electromagnetic conditions can make marginal faults intermittent, so keep a trend observation period and record the final port and cable configuration.
Configuration and acceptance principles
In most deployments, enable auto-negotiation on both ends and restrict advertisement only to modes that both devices genuinely support. If a legacy requirement makes forced settings necessary, configure identical speed and duplex on both ends and document the reason. For gigabit and faster copper links, follow the device documentation and applicable Ethernet requirements instead of using a forced mode to hide channel quality problems.
A practical acceptance record confirms five outcomes: advertised abilities are compatible, both ends report the same resolved mode, counters remain stable, the application passes its test, and a controlled disconnect recovers correctly. When supported, configure persistent alarms for unexpected speed changes, link flaps, and sustained error growth. FCTEL switch visibility and configurable fields vary by model and firmware, so confirm the current product documentation before making monitoring requirements.
