Ethernet autonegotiation differences between (10M | 100M | 1G) Ethernet

Question

I am studying for CCNA and on Wendell Odom's book is said that(regarding autonegotiation):

When autonegotiation fails on one node, to choose (half/full-duplex) we must use the rule:

If you have a 10/100 Mb/s interface -> use half-duplex
If you have a 1000 Mb/s interface-> use full-duplex

Why is that?

score 20 · Accepted Answer · edited May 23 '17 at 12:37

When autonegotiation fails on one node, to choose (half/full-duplex) we must use the rule:

If you have a 10/100 Mb/s interface -> use half-duplex

If you have a 1000 Mb/s interface-> use full-duplex

Why is that?

Summary

In brief, ethernet has been around since the 1980s... as a result

Old ethernet NICs only supported half duplex operation with no auto-negotiation. If you have auto-negotiation enabled in this situation, you must support all old NICs (which means falling back to half-duplex operation). Another answer mentions hubs, which also fall into this category.
Auto-negotiation is required by the 1GE spec; therefore, there is no point in forcing failure to half-duplex at 1GE speeds. 1GE auto-negotiation announces whether it is half / full-duplex capable.

These days, you should always try to use auto-negotiation unless you know the other port doesn't support it.

The table below may help explain the twisted history around auto-negotiation.

+------------+------+---------------+--------------+-----------------------+
| Standard   | Year | Speeds        | Media        | Auto-neg Status       |
+------------+------+---------------+--------------+-----------------------+
| 802.3i     | 1990 | 10M           | Twisted Pair | No auto-negotiation   |
+------------+------+---------------+--------------+-----------------------+
| 802.3u     | 1995 | 10/100M       | Twisted Pair | Optional, not trusted |
+------------+------+---------------+--------------+-----------------------+
| 802.3-1998 | 1998 | 100/100M      | Twisted Pair | Optional              |
+------------+------+---------------+--------------+-----------------------+
| 802.3ab    | 1999 | 10/100/1000M  | Twisted Pair | Optional @ 10/100M    |
|            |      |               |              | Required @ 1Gbps      |
+------------+------+---------------+--------------+-----------------------+

Impact of Duplex Mismatches:

Regarding Cisco's practice of falling back to half-duplex when auto-negotiation fails... One could rightfully object that falling back to half-duplex if auto-negotiation fails introduces a misconfiguration; however, the misconfiguration is tolerable. The worst that can happen in this situation is you get manually hard coded full-duplex on one side of a FastEthernet link, and auto-negotiation failing to half duplex on the other side of the link... the mismatched duplex causes link-level errors (collisions and runts), but you still can communicate pretty well, as long as you arent trying to exceed about one third of the link speed (i.e about 35Mbps on FastEthernet).

Potentially interesting details:

Original FastEthernet Auto-negotiation == bad juju

People had such bad experiences with early auto-negotiation in IEEE 802.3u (FastEthernet) that conventional wisdom was to disable auto-negotiation, and lock speed / duplex manually on all ethernet copper ports.

This practice of disabling auto-negotiation on all copper ports became so entrenched in old-timer's minds that it's still not unusual to find locked speed / duplex on Cat5e / Cat6 today, even though industry auto-negotiation implementations have reliable for over a decade. FYI, some ISPs still force 100M / full on their customer circuits under the misguided assumption that manual speed / duplex is more reliable.

Vendor support for advertising specific 1GE duplex modes

Auto-negotiation is required as part of IEEE 802.3ab (Gigabit Ethernet over copper); however, you still find some vendor implementations that permit you to hard-code GigE speed / duplex... I have seen some JunOS switches that permit full-duplex configuration on 1GE switch ports. Does this mean that the JunOS switch disables auto-negotiation on that 1GE port? No, this effectively means JunOS only advertises the configured speed / duplex during auto-negotiation.

Update for @ytti's question: Ethernet line conditioning

1GE auto-negotiation includes (quoting 802.3-2012, Clause 40.5.1):

Negotiation for 1000Base-T half / full duplex, or falling back to lower speeds, as required
Determining MASTER-SLAVE relationship between the PHYs
Negotiating EEE capabilities

Auto-negotiation is required by 802.3ab at 1GE, because GigabitEthernet auto-negotiation includes special line conditioning; this conditioning happens during the TRAINING mode of the MASTER/SLAVE PHY startup; the TRAINING mode ensures the line is stable enough to push 1000Mbps over Cat5e runs up to 100m long.

I'd like to read more on this auto-negotiation 'line conditioning', do you have link for it? Preferably page in 802.3 section three. Fully agreed that autonego should be used, unfortunately many telcos are still in 90s mind-set and products mandate no-autonego. Another good argument to try to convince them is that autonego provides RFI (Remote Fault Indication), which will cause both ends to go down, when one end is not receiving but can still send. — ytti, Aug 19 '13 at 06:44
@ytti, 802.3 generically refers to the line conditioning as TRAINING. TRAINING is part of the MASTER-SLAVE PHY negotiation that happens during auto-negotiation. You can find reference to MASTER-SLAVE negotiation in 802.3-2012, Section 3, Clause 40.5.1 (which describes all the auto-negotiation functions). To find more about training, search the 802.3-2012 PDFs for "TRAINING" — Mike Pennington, Aug 19 '13 at 09:17
Thanks, I was aware of clock election in ethernet. Thought line conditioning was something else. — ytti, Aug 19 '13 at 09:47
Master / Slave PHY startup includes what is called the Decision Feedback Equalizer (DFE - Ref 802.3-2012, Section 3, Clause 40.4.2.4); the DFE works along side other functions for Echo Cancellation / Near-End Cross-Talk (NEXT) Cancellation — Mike Pennington, Aug 19 '13 at 10:01
you're most welcome... it was a good refresher to surf through the 802.3 docs... — Mike Pennington, Aug 19 '13 at 10:59
As a rule, I prefer to hardcode everything, as a known state is much better than an unknown one. Why it is common usage to configure ports Half-Duplex when autonegociate isn't supported, that was because 802.3u (first Ethernet standard with Autoneg) MANDATED the interface not receiving any Autonegociation handshake to "dumb-down" to Half-Duplex This means that if you want to hardcode the duplex, the only way not to have a mismatch when the other end is auto, is to hardcode at HALF, because if you Hardcode at Full, the Auto end will follow standard and become HALF (bitten by edit timeout) — Remi Letourneau, Aug 20 '13 at 19:20
@RemiLetourneau, are you saying that your policy is hard code to half duplex on all ports? — Mike Pennington, Aug 20 '13 at 20:10
@MikePennington (Sorry for the delays) it's not a policy per say, it's just that if you have ONE end of a 10/100 link hardcoded, the only way not to have a mismatch is to hardcode it to Half Duplex. We did this a decade ago when switches were all 10/100 but architecture mandated that users be configured for 10 (as not to choke the uplink. The only way for that setup not to have duplex mismatch issues is to configure the ports to 10mb half duplex. Gig function differently, but for devices that only supports 10/100, HALF is the default fallback if there is no answer to Autonegociation. — Remi Letourneau, Sep 09 '13 at 14:31
(continued from above - char limiation) Our policy is to Hardcode every links between non-end-user devices (between switches, routers, etc...) that way, you have a KNOWN state. I've seen some case where autonegociate would act weirdly, even between the same vendor. Having core links be dynamically configured for whatever parameters (duplex, VLANs, Dot1Q, Port Aggregation) is a receipe for disaster: Easy to setup, but hard to debug, as everything can change dynamically I've seen race conditions between dynamic protocols that caused the ports to take 48h to come up correctly... — Remi Letourneau, Sep 09 '13 at 14:33

score 12 · Answer 2 · answered Aug 18 '13 at 20:26

When autonegotiation fails on one node, to choose (half/full-duplex) we must use the rule: ->If you have a 10/100 Mb/s interface -> use half-duplex

In the event that a hub is connected, a default of full duplex would cause too many collisions. A default of half duplex ensures communications continue regardless of the connected device (Switch or hub)

->If you have a 1000 Mb/s interface-> use full-duplex

The 1000Base-T standard was designed to require auto-negotiation, as well as a switched layer 2 domain (no hubs). This is because all four pairs need to communicate in full duplex at 250Mbps. As such, it is assumed that no hubs exist on the connection for the purpose of bidirectional communication.

BTW, hubs are a good reason for falling back to half-duplex, but it's not just hubs... early 10/100M NICs did not auto-negotiate at all... and the early FastEthernet auto-negotiation implementations were unreliable. — Mike Pennington, Aug 18 '13 at 22:34