I85PREP
⌘ K
100-490 RSTECH study materials
100-490 RSTECH study resources

Hardcoded Duplex on an ISP Handoff

100-490 RSTECH · Put your knowledge to work in context.

All case studies

Hardcoded Duplex on an ISP Handoff

Calder Freight's primary internet circuit is a 100 Mb/s fiber-to-copper handoff: the carrier's media converter presents an RJ-45 to Gi0/0/0 on an ISR 4331. Last month the link flapped during a carrier maintenance window and the on-call engineer hardcoded speed 100 and duplex full on Gi0/0/0; the flapping stopped. Since then bulk uploads to a cloud ERP plateau at 20-30 Mb/s, roughly one in fifty VoIP calls over that circuit has clipped audio, and the carrier's NOC reports their side of the interface at 100 Mb/s half-duplex. On the ISR, show interfaces Gi0/0/0 reports 100 Mb/s, full-duplex, zero collisions, and input errors climbing by about 300 per minute consisting of CRC and runts; output errors are zero. The contract states both ends must be auto-negotiated. A second 50 Mb/s backup circuit is available.

1. Explain the mechanism that produced a duplex mismatch from a one-sided hardcode, and why the ISR reports zero collisions while the carrier sees them.

Read the worked answer

How the mismatch formed

Hardcoding speed and duplex disables autonegotiation on the ISR side. 100BASE-TX autonegotiation uses Fast Link Pulses; when the ISR stops sending FLPs, the carrier's still-auto port receives only the scrambled idle signalling. Parallel detection can infer the speed from the signal, but there is no way to convey duplex - and the 802.3 default for a 10/100 port that falls back to parallel detection is half duplex. So the carrier's side landed on 100/half while the ISR sits at 100/full. Both ends now believe they are correctly configured.

Why the counters look the way they do

  • The ISR, believing it is full duplex, transmits whenever it has a frame - it does not listen first.
  • The carrier side, at half duplex, uses CSMA/CD and may already be transmitting. When the two transmissions overlap, the carrier detects a collision (a late collision if it happens after the 64-byte window) and aborts the frame mid-flight.
  • The ISR receives a truncated fragment: a runt, with a bad FCS, so it logs CRC/input errors.
  • The ISR's own collision counter never increments, because a full-duplex interface disables collision detection entirely. Zero collisions on our side means nothing here - it is an artefact of the configured duplex, not evidence of a healthy link.

The 20-30 Mb/s ceiling is TCP interpreting that loss as congestion and collapsing its window.

2. The carrier will not change anything for five days and the business needs the circuit. What are your options for the interim, which do you recommend, and why?

Read the worked answer

Options

  1. Ask the carrier to hardcode 100/full on their side now. Two forced-full ends match, collisions disappear, and performance returns to line rate. This is the technically correct interim fix and costs the carrier one CLI command. Push for it first - do not assume the window is immovable.
  2. Match the carrier's actual state: set duplex half on Gi0/0/0. This removes the mismatch. Throughput becomes deterministic but is still half duplex: CSMA/CD, shared contention with the media converter, and worse jitter than full duplex. Voice may improve because collisions stop being random, but it is a band-aid, not a repair.
  3. Shift latency-sensitive traffic to the 50 Mb/s backup with a policy route or floating static for the voice gateway, leaving bulk ERP uploads on the primary.
  4. Leave it and wait. Not defensible: 300 errors per minute and clipped calls is an active fault.

Recommendation: pursue option 1 in parallel with option 3. If the carrier will not move, apply option 2 in a quiet period and accept degraded but stable throughput, while steering voice to the backup until the window. Do not 'fix' it by setting duplex auto on our side alone while the carrier is still auto - that is the correct long-term state, but if the physical layer is genuinely unstable it will simply start flapping again and you will have learned nothing.

3. What do you do in the scheduled window, and how do you prove afterwards that the original flapping was physical rather than a duplex artefact?

Read the worked answer

In the window

  1. Record a baseline: show interfaces Gi0/0/0, show interfaces counters errors, show controllers if the platform exposes it, and the carrier's agreed counter set.
  2. On the ISR, apply speed auto / duplex auto (or simply no speed / no duplex), ideally at the same time the carrier returns their side to auto per contract. Both ends auto is the required state.
  3. Verify immediately: show interfaces Gi0/0/0 must show 100 Mb/s full-duplex, and the input CRC/runt counters must stop climbing. Let it soak 30 minutes before declaring success, then re-enable the primary path for voice.

Proving the original flap was physical

The duplex hardcode was a response to flapping, and it only 'fixed' the flap by suppressing negotiation - which is not a fix. To separate causes:

  • Before the window, note show interfaces Gi0/0/0 | include flap and the carrier's carrier-transition count. If the flap count did not increase during the hardcoded period, the physical layer settled when autonegotiation stopped - consistent with a negotiation or media-converter issue rather than a failing fibre.
  • If after returning to auto the link flaps again, the hardcode was masking a real fault: log the timestamps, correlate them with carrier maintenance and with environmental events, and escalate to the carrier with the transition counts rather than hardcoding again.
  • Prevention: add monitoring on input errors/CRC and on interface transitions, and a change-control rule that no speed/duplex is ever hardcoded without the carrier confirming the same setting on their end and recording the ticket number.