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):
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.
The usual suspects in the case of autonegotiations are:
- bad cables
- bad ports, SFPs or NICs
- port configs (are they both set to auto and do they both list the 1000BASE-T FD ability?)
- bugs, compatibility or legacy issues
I would not recommend a fixed speed and duplex setting in this (or almost any) situation. The days of frequent autoneg issues and incompatible implementations are gone, on recent equipment such issues are very rare. If autoneg is not working, switching to a fixed setting is a workaround, hiding the underlying issue that causes the autonegotiation to fail. Not fixing this issue might allow it to bite you later.
Also, the probability of speed or duplex mismatches and the like is actually much higher in an environment with fixed settings, caused by left over settings when moving equipment around.
As an example, if in your case the cable is to blame, setting both sides to 1000 fixed could disable the link with the faulty cable completely. Autonegotation gracefully degrades you to 100. It is of course up to you or your monitoring equipment to detect and fix this.
Interesting blog post, with links some vendor recommendations: "EtherealMind on Autonegotiation"
Best Answer
I believe the answer is no.
Unfortunately, because of the history of Ethernet, you often see statements about it that are only true for 10Mb/s operation, or only for half-duplex operation and so forth.
802.3 clause 28.1.4.1 says:
In other words, you don't get link test pulses sent if you force the speed to 100Mb/s or 1000Mb/s. They are unnecessary, because idle symbols are continuously transmitted in these modes.