Half Duplex Default on 100M WAN Interface

[KVERHCLT]

A Cisco router wan interface had a config change to support a new 1G internet circuit but had to be rolled back to the original 100M circuit. The speed was hard coded back to 100M but duplex left blank. This appears to have caused the duplex setting to default to half duplex creating a mismatch between the router and service providers NID. The mismatch was not discovered until 2 days later and after a ticket was opened with the service provider, for packet loss, who found no issues and stated they were hard coded to100M full duplex since circuit was originally installed. Around the time the service provider responded with no trouble found, the packet loss cleared. It was then that a review of logs showed the Cisco router WAN interface was half duplex but then changed on its own to full duplex around the time the ticket was opened with the service provider. The question is, could the transition from half duplex to full duplex on the router wan interface occur without a physical change as neither party said they made any change? What conditions would have to occur to change the router wan interface back to full duplex?

[paul driver]

Hello

---

@KVERHCLT wrote:
The question is, could the transition from half duplex to full duplex on the router wan interface occur without a physical change as neither party said they made any change? What conditions would have to occur to change the router wan interface back to full duplex?

---

I very much doubt that, especially if the interfaces are hardcoded and negotiation is turned off. On the high end rtrs nowadays you seem not to be able to hard-code any interface speed without turning off link negotiation first, and when you do it should automatically default to its lowest capable speed and that goes for the other way around - removing the a hardcode speed value is negated until you re-enable negotiation

Lastly in both cases either change should tear down and reinitialised the link. port

[Ramblin Tech]

I believe the behavior depends on what hard-coding the port to 100Mbps actually does, which is likely to be implementation-specific. That is, (1) does it force the port into 100BASE-TX without auto-negotiation, or (2) does it leave auto-nego of speed/duplex/pause/etc in place, but the only speed it advertises during the capabilities exchange phase is 100Mbps?

To me, either (1) or (2) are plausible explanations for the initial state of 100/hdx, if half-duplex is the default for no auto-nego or failed auto-nego of duplex mode. However, for the port to "magically" start operating at 100/fdx after the SP operator investigated the trouble ticket leads me more toward (2). My speculation is that initially, the speed was correctly advertised by auto-nego and negotiated to 100Mbps, but the duplex mode negotiation failed for reasons unknown, and defaulted to hdx. During the course of investigating the trouble ticket, one (or both) ends of the link were bounced, resulting in a re-negotiation that correctly landed on 100/fdx.

[Elliot Dierksen]

My experience is that a device with duplex forced does not respond to duplex negotiation requests. That means the side in "auto" must go to half duplex. Telco's love to force duplex, but my experience is that forcing duplex has caused way more problems than it ever solved. IMHO of course, and YMMV.

[Ramblin Tech]

Hi @Elliot Dierksen 

I agree that hard-coding duplex tends to disable auto-nego in most Cisco products, but I believe that is out of convention/convenience. I do not believe that there is any reason why hard-coding duplex could not simply result in only that duplex option being advertised by auto-nego. For example, most Cisco products do not support HDX at 1Gbps speeds and higher, but they still support auto-nego in high speeds ports like 1000BASE-T and 10GBASE-T. I assume that they only advertise FDX during the capabilities exchange. I believe that this is also what happens with some products when speed is hard-coded: auto-nego is still enabled, but only that speed is advertised during the capabilities exchange, with duplex, pause, master-slave role, etc being negotiated as per usual.

And yes, also agree that if an auto-nego port gets no response from its link partner during negotiation, it should default to HDX at its lowest speed. [Edit: ... should default to HDX at its lowest speed in the absence of Parallel Detection to detect the proper speed]

-Jim

[Joseph W. Doherty]

---

@Ramblin Tech wrote:

And yes, also agree that if an auto-nego port gets no response from its link partner during negotiation, it should default to HDX at its lowest speed.

---

My experience has been (NB: most on Cisco equipment, but have worked with other vendor equipment) speed can be derived from hardware.  For example, if you have two 3x speed Ethernet ports, and auto not being used, but one side is hard coded to 100 Mbps, other side will detect its "speed", 100 Mbps, and set itself to match.  However, if one side hard coded to 100 Mbps, and other side, hard coded to 10 or gig, it won't come on-line.

The implicit auto-speed matching seems to work well as long as both interfaces have a common speed capability, again even without auto.

Other Ethernet attributes, like duplex, and other optional capabilities, unless hard coded (if possible) to agree on both sides, do appear to require auto negotiation.

Auto negotiation also seems to be possibly also required for auto MDI/X and, I recall (?) reading it also supports some additional error checking (possibly like two 3x ports falling back to 100 Mbps if all 4 wires not good).

The above, though, I recall appeared to be common behavior, but if something isn't actual standard (like 10 Mbps FD?), well device behavior might vary.  For example, I recall (?) early Cisco devices that supported a hardcoded 10 Mbps FD would error disable if host and it had a duplex mismatch.

[Ramblin Tech]

Hey Joe,

"... auto not being used, but one side is hard coded to 100 Mbps, other side will detect its "speed", 100 Mbps, and set itself to match."

I believe this is a function of Parallel Detection, which is supportable at 100BASE-TX, 100BASE-TX4, and 10BASE-T. When one end of the link supports parallel detection and the other operates at one of these PHYs albeit without Fast Link Pulse auto-negotiation, the parallel detection end can detect the proper speed, but not the duplex. This results in operation at the correct speed, but always at HDX.

-Jim

[Joseph W. Doherty]

---

@Elliot Dierksen wrote:

Telco's love to force duplex, but my experience is that forcing duplex has caused way more problems than it ever solved. IMHO of course, and YMMV.

---

Yes, them and many greybeards do/did prefer, but unsure I would agree with it causing more problems, although I likely would agree it didn't really solve many either.

The two reasons, I believe, for these long standing predilections are, I believe, when auto first came out, often you would run into issues between different devices, especially if devices were from different vendors.  I.e. both devices would be auto, and FD capable, but end up in HD mode.  (Which wasn't nearly as bad as one side being HD and the other FD, and possibly HD/HD not even noticed, especially on a p2p link that's not very busy.  [Laugh - a great interview question, I thought, back in the day, which is better 10 Mbps FD or 100 Mbps HD?])

Second, I believe, hard coded interfaces establish the connection just a tad faster, as they don't need to take time to negotiate.

[pieterh]

>>> The speed was hard coded back to 100M but duplex left blank. <<<
this probably also means autonegotiate is still enabled!

autonegotiate only works correct if it is anabled on both sides
all instances in my history where one side is fixed and the other side negotiated ended up in 100/half initially on the negotiated side
NB! this is technically not negotiatiated but a fallback because negotiation failed

I also experienced autonegotiate handshake is repeated in a certain interval so yes from time-to-time it works and later it fails again.
this result in a very strange pattern fo the datastream.