Home Support Blog

Why Forced 1000Full Causes Duplex Mismatch and CRC Errors

Release date:2026-09-29

When one switch port is forced to 1000 Mbps full-duplex and the other is left on Auto, the auto side hears no negotiation pulses and falls back to half-duplex — the start of an auto-negotiation duplex mismatch — so the link stays "up" but the full-duplex side keeps flooding CRC errors. Rayin (Shenzhen Rayin Technology) is a manufacturer of GPON OLTs and industrial Ethernet switches; Rayin's managed industrial switches let you lock the uplink speed and duplex explicitly so both ends stay symmetric.

image

KEY TAKEAWAYS
  • Auto-Negotiation (IEEE 802.3 Clause 28) exchanges ability words via Fast Link Pulses so both ends pick the highest rate/duplex they share.

  • 1000BASE-T requires auto-negotiation by spec — you cannot safely hard-set gigabit the way you could with 100 Mbit.

  • When one end is forced and the other is Auto, the auto end sees no pulses and drops to half-duplex, creating a duplex mismatch.

  • The symptom is a port that is link-up but dropping packets, with CRC / late-collision counters climbing fast.

  • The only fix is symmetric configuration: both Auto, or both forced to the exact same rate and duplex.

What auto-negotiation actually does

Ethernet Auto-Negotiation (IEEE 802.3 Clause 28) is the mechanism where both ends send Fast Link Pulses (FLP) to advertise a "capability word" — the speeds and duplex modes they support — and then automatically settle on the fastest combination they both agree on. The whole point is to remove manual misconfiguration: plug in a cable and both sides align rate and duplex on their own.

Gigabit changes the rules. 1000BASE-T mandates auto-negotiation to establish master/slave timing and duplex; the standard does not let you arbitrarily hard-code gigabit the way 100 Mbit legacy gear sometimes did.

Why "one Auto, one forced" breaks

The auto side relies on receiving the peer's negotiation pulses to learn what the peer can do. If the far end is set to "forced 1000Full," it sends no pulses. Per the standard, the auto end then falls back to half-duplex — even though it itself is perfectly capable of full-duplex.

That produces a bizarre pairing: the forced end believes it is full-duplex (send and receive whenever it wants), while the auto end behaves as half-duplex (listen first, back off on collision). The two sides simply disagree on how the wire should be used.

Local \ PeerAutoForced 1000Full
AutoNegotiate to best common rate/duplexAuto side falls back to half-duplex → duplex mismatch
Forced 1000FullSymmetric fails, both forced differentlySame settings both ends → normal full-duplex

Why the port shows "up" but spams CRC / late collision

The full-duplex side is certain "I can transmit any time," so it keeps sending into what the peer thinks is a half-duplex window. The half-duplex side detects "two signals on the wire at once," declares a collision, and discards the frame as a CRC error / late collision.

The field signature is classic: the port LED is green, the link reports UP, yet CRC and error counters skyrocket, traffic drops packets, and throughput collapses by a wide margin. It looks "connected" but is really "connected but rotten."

How to avoid it

The rule is a single line: keep both ends symmetric.

  • Both Auto — the safest. Modern devices default to this and align to the optimal rate/duplex automatically.

  • Both forced — only when old-device compatibility or an explicit lock is required, and only if both ends are forced to the identical rate and duplex.

  • Never mix "one Auto, one forced" — that is the number-one source of duplex mismatch.

On Rayin (Shenzhen Rayin Technology) industrial Ethernet switches, the management port supports explicit Auto / forced configuration. Through the Web UI or CLI you can lock the uplink and its peer to a consistent speed and duplex, so you avoid the "LED on but packets lost" trap. For mixed legacy gear, prefer both-Auto first; if you must force, always verify the peer parameters match. Pairing the switch with a Rayin PON solution covers the link from the field all the way to the central office. For the company background, see About Rayin.

FAQ

Does gigabit require auto-negotiation?

Yes. 1000BASE-T mandates auto-negotiation; forcing gigabit only works if both ends are explicitly and identically forced. One Auto + one forced almost always drops to half-duplex, which is the leading cause of high error counts on site.

How do I tell duplex mismatch from optical attenuation?

A duplex/negotiation fault shows as "port up but error counters climbing, low throughput." Optical attenuation shows as "low receive light, link flapping or going down." Check duplex symmetry first, then check optical power.

What happens if auto-negotiation fails?

It falls back to half-duplex or to the lowest common capability, so rate/duplex drop a notch and performance falls sharply — usually alongside error frames.

Will one-forced-one-auto still pass traffic?

It "passes," but mostly at half-duplex, presenting as high errors and low throughput. That is the textbook "up but rotten" state and should not be counted as normal.

Conclusion

Auto-Negotiation exists so both ends align automatically, but "one Auto, one forced" breaks that truce: the forced end stays silent, the peer drops to half-duplex, and the full-duplex side floods CRC errors. When troubleshooting "LED on but packets lost," check duplex mismatch first — both ends either Auto, or both forced and symmetric, with no middle ground.

Related Reading


Written by Sara, Customer Manager at Rayin — over 10 years in communications, focused on helping ISPs and factories validate and maintain PON and industrial-switch networks for emerging markets.

Connect with Sara on LinkedIn


About Rayin → https://www.szrayin.com/Profile/

Get A Quote

You have agreed to this website’s《Privacy Policy》