A housing authority finds one switch port locked at 100/full while the attached legacy device is at 100/half after hard-coding speed and duplex on only one end. What is the likely result?
Select an answer to reveal the explanation.
Short Explanation
Hard-coding only one side is like setting your walkie-talkie to full-duplex while the other person still takes turns—they talk over each other. Expect a duplex mismatch and ugly collisions.
Full Explanation
When a housing-authority switch port is hard-coded to 100/full while the legacy device is at 100/half because only one end was hard-coded, the likely result is a duplex mismatch. The full-duplex side transmits whenever it wants; the half-duplex side uses CSMA/CD and sees late collisions/errors when the other side talks simultaneously. The outcome is collisions, CRC errors, and poor performance—exactly the failure mode created by setting speed/duplex on only one end while the other remains half duplex (often after failed or bypassed autonegotiation behavior).
Autonegotiation will silently convert both ends to 1000/full always fails because hard-coding one end typically breaks consistent autonegotiation outcomes and does not magically force both to gig full. The link becomes immune to all CRC errors by design fails—the mismatch increases errors. STP immediately blocks every VLAN on that access switch fails by concept: STP may react to instability elsewhere, but duplex mismatch on one access port does not instantly block every VLAN as the defined result.
Exam caveat: Hard-code both ends the same or autonegotiate both ends. One-sided hard-coding is a classic duplex-mismatch recipe on exam items and in production.
Operational check: Align both ends (both auto or both 100/full if the device truly requires it), bounce the port if needed, clear counters, and verify the absence of collisions/CRC while traffic flows. Document legacy devices that require static settings so the next change does not reintroduce one-sided hard-coding.