Before you read. A server is plugged into a gigabit switch with a gigabit card and a cable rated well past gigabit. The link is up and everything works.
The interface reports 100 Mb, half duplex.
Nothing is broken and nobody configured it that way. What happened?
Most of this track is about what happens after a link works. This topic is about the link itself: the two things every Ethernet connection agrees before it carries anything, what happens when the agreement goes wrong, and why the wrong answer is a slow network rather than a dead one.
Some words you will need
- duplex
- Whether both ends may transmit at once. Full duplex means yes, half means take turns.
- auto-negotiation
- Two interfaces exchanging what they support and settling on the best both can do.
- parallel detection
- What an interface falls back to when the other end does not negotiate at all.
- late collision
- A collision detected after the first 64 bytes of a frame. On a modern link, a symptom rather than an event.
- link aggregation
- Treating several physical links between two devices as one logical link.
- LACP
- Link Aggregation Control Protocol. How two devices agree to form a bond.
What breaks without this
A slow network with nothing wrong in it. A duplex mismatch leaves everything up and working, at a fraction of the throughput, and no tool reports an error unless you go and read the counters.
Somebody bonds two links and reports that it did not help. Aggregation behaves in a way that surprises people, and knowing what it is for before promising it to anybody saves an awkward conversation.
A port is disabled and nobody can say why. Administrative state and link state are different things reported side by side, and reading them the wrong way sends people to the wrong end of the cable.
Speed, duplex, and what negotiation actually does
Two interfaces have to agree on two things before a link carries anything: how fast, and whether both may talk at once.
Auto-negotiation is how they agree. Each end advertises what it supports, both pick the best they have in common, and the link comes up. When both ends negotiate, this works and nobody thinks about it, which is why the failure is confusing when it arrives.
The failure is one end not negotiating. Somebody has hard-set the speed and duplex on a switch port, usually years ago, for a reason nobody remembers. A hard-set interface stops advertising, so the other end has nothing to negotiate with.
What it does then is a rule worth knowing, because it produces the exact symptom at the top of this page. The negotiating end falls back to parallel detection: it can still sense the link’s signalling and work out the speed, but there is no way to detect duplex from the signal. So it guesses, and the specified guess is half duplex.
One end hard-set to full, the other guessing half. Both ends are up. Neither is misconfigured in any way a tool will complain about. And the speed drop in the opening scenario is the same story a step further, where the fallback also failed to sense the higher speed.
The rule that follows: hard-set both ends or negotiate on both ends, never one of each. Setting one end to be certain is the thing that causes the problem it was meant to prevent.
If you already work on networks: why a duplex mismatch is slow rather than broken, and what a late collision means
A duplex mismatch does not break a link, which is exactly what makes it hard to find. Understanding why needs the two ends’ assumptions side by side.
The full duplex end believes it may transmit whenever it likes, because on a full duplex link nobody collides. It ignores carrier sense entirely.
The half duplex end believes it must listen before transmitting and must watch for collisions while it does. That is CSMA/CD, the access method half duplex Ethernet has always used.
Now put them together. The full duplex end sends whenever it wants, including while the half duplex end is mid-frame. The half duplex end detects that as a collision, aborts its own frame, and backs off. Meanwhile the frame it aborted is lost, and the full duplex end has no idea anything happened.
So the link works, and it drops frames whenever both ends happen to talk at once. TCP handles the loss by retransmitting, which topic 09 showed collapses the congestion window, so throughput falls off a cliff under load and looks fine when idle. That combination, fine when tested and terrible when used, is the fingerprint.
The counter that names it is the late collision. An ordinary collision on a correct half duplex segment is detected within the first 64 bytes, because the segment is short enough that a collision at the far end propagates back before the frame finishes. A collision detected after 64 bytes means the other end started transmitting long after it should have known the wire was busy, and on a correctly configured link that cannot happen.
Late collisions on a link that should be full duplex are close to diagnostic of a duplex mismatch. Topic 14’s panel made the point that the collision counter outlived the thing it measured and became a troubleshooting tool. This is the case it became a tool for. Late collisions appear at the half duplex end, and frame check sequence errors usually appear at the other, so the two ends report different symptoms of the same fault.
Enabling and disabling an interface
Two independent states, reported together, and reading them the wrong way round wastes an afternoon.
Topic 01 introduced both without naming the distinction. UP is administrative:
somebody enabled the interface, and it stays that way whether or not anything is
plugged in. LOWER_UP is physical: the driver can see something at the other end
of the cable.
| What you see | What it means |
|---|---|
| UP, LOWER_UP | Enabled, and something is there |
| UP, no LOWER_UP | Enabled, and nothing is plugged in or the far end is off |
| No UP | Somebody disabled it. The cable is irrelevant |
An interface that is administratively down does not care about the cable, and that is the case people misdiagnose: hours spent on a cable that was never the problem, because the port was shut and nobody looked at the first flag.
The reverse also matters for security work. Disabling unused ports is standard hardening, so an unused socket in a meeting room grants nothing, and topic 45’s material on reducing what is exposed applies directly here.
If you already work on kit remotely: the shutdown that locks you out, and the protection worth configuring first
The command that disables an interface is the most dangerous one on a network device, because it works perfectly and there is no undo from the far end of the link you just turned off.
The classic version is disabling the interface you are connected through. The command succeeds, the session ends mid-keystroke, and the device is now reachable only by somebody walking to it. The same shape catches a mistyped interface name, a change applied to the wrong device out of two open sessions, and a firewall rule that locks out management along with everything else.
Two protections make this survivable and both need arranging before you need them. The first is out of band access, which topic 51 covers: a console server or a management path that does not depend on the thing you are changing. The second is a timed rollback, which most platforms offer under some name: the device applies the change, waits for you to confirm within a few minutes, and reverts to its previous configuration if you do not. If the change cuts you off, you cannot confirm, and the device puts itself back.
The habit that goes with them is to read the interface name back before pressing return, out loud if you are alone, because the failure mode here is not a misunderstanding of the command. It is a correct command aimed one line off.
Aggregation, and what it does not give you
Link aggregation combines several physical links between the same two devices into one logical link. Two cables, one interface as far as everything above it is concerned.
Two 1 Gb links are bonded into one interface. What speed does the bond report, and what does a single transfer across it actually get?
# Fedora CoreOS 44.20260707.3.1, kernel 7.1.3-200.fc44.aarch64
# linux network namespaces, topology one-switch
# two devices, one logical link built from the physical ones between them
$ ip -n h1 link add bond0 type bond mode 802.3ad
$ ip -n h1 link set h1eth0 down
$ ip -n h1 link set h1eth0 master bond0
$ ip -n h1 addr add 10.0.0.1/24 dev bond0
$ ip -n h1 link set bond0 up
$ ip -n h1 link set h1eth0 up
# what it negotiated, and how it decides which member carries a given flow
$ ip -d -n h1 link show bond0 | grep -oE "mode 802[0-9a-z.]*|xmit_hash_policy [a-z0-9+]+|lacp_active [a-z]+|lacp_rate [a-z]+"
mode 802.3ad
xmit_hash_policy layer2
lacp_active on
lacp_rate slow
# the member is now a slave and the bond holds the address
$ ip -n h1 -br link show
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
bond0 UP 02:00:00:00:00:01 <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP>
h1eth0@if3 UP 02:00:00:00:00:01 <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> Three fields in that output are the vocabulary.
mode 802.3ad is LACP, the protocol the two ends use to agree that they are
forming a bond and which links are in it. The alternative is configuring both
ends statically, which works and has no way to notice when one end disagrees.
LACP exchanges keepalives, so a member that is up but not actually passing
traffic can be taken out of the bond.
lacp_rate slow is how often those keepalives go, and slow means every 30
seconds. Fast means every second, and detects a failure much quicker at the cost
of more chatter.
xmit_hash_policy layer2 is the important one, and it is where the surprise
lives.
A bond does not split a conversation across its members. It hashes something from each frame, here the MAC addresses, and uses the result to pick one member. Every frame with the same hash takes the same link, which is deliberate: splitting one conversation across two links of slightly different latency would deliver frames out of order, and TCP reads out of order delivery as loss.
So two bonded gigabit links give two gigabits of aggregate capacity across many conversations, and any single transfer still runs at one gigabit. Somebody copying one large file sees no improvement whatsoever, and this is the promise that gets made and broken.
What aggregation genuinely buys is capacity in aggregate, and redundancy: lose one member and the bond stays up with less capacity, which is often the real reason to build one.
If you already work on networks: choosing a hash, and the case where it makes everything worse
The hash policy decides which member a flow lands on, and the default is frequently wrong for the traffic you actually have.
Hashing on MAC addresses is the simplest and it fails in the most common topology there is. Consider a bonded uplink from an access switch to a router. Every frame going upstream has the same destination MAC, the router’s, and every frame coming back has the same source. So the hash produces the same answer for nearly everything, every flow lands on one member, and the second link carries almost nothing while the first saturates.
The measurement is bleak and the diagnosis is easy: interface counters on a bond whose members are wildly unequal are telling you the hash is not distributing.
Hashing on IP addresses fixes the router case, because the addresses differ per conversation even when the MACs do not. Hashing on addresses and ports distributes better still, and separates multiple conversations between the same pair of machines, which matters for a backup server or a database replica talking to one peer.
The limit nobody escapes is that a single flow is a single flow. No hash policy splits one TCP connection, because doing so would reorder it. If one transfer needs more than one link’s worth of bandwidth, aggregation is not the answer and a faster link is.
Two practical notes. Both ends should agree on a policy, and they do not have to, since the hash decides only which member this end transmits on. Asymmetric policies work and produce traffic distributed one way and not the other, which is a confusing thing to measure.
And there is a specific failure worth naming: a bond configured on one end and not the other. LACP prevents it by refusing to bring members up without a partner, which is a good argument for LACP over static configuration. Statically bonded on one end and separate ports on the other gives you two switch ports carrying the same MAC address, which is a loop, and topic 19 is about what a loop does.
Prove it
You have this when you can look at an interface and say what was negotiated and whether both ends agreed.
# Linux: speed, duplex and whether negotiation happened
ethtool <interface> | grep -E "Speed|Duplex|Auto-negotiation"
# the error counters that name a duplex mismatch
ip -s link show <interface>Three things to look at. The negotiated speed and duplex. Whether auto-negotiation is on. And whether the error counters are moving, because a counter that is non-zero and static is history while one that climbs under load is a live fault.
On Windows the same facts are in the adapter’s advanced properties and in
Get-NetAdapter. On a switch, the interface status page reports speed, duplex
and whether each was negotiated or forced, and the forced ones are what to be
suspicious of.
The honest limit: this is the one topic in the block with nothing captured about its main subject. Speed and duplex are properties of physical Ethernet hardware, and the virtual interfaces this track’s labs are built from have neither. The bonding block above is real; there is no honest way to produce a duplex mismatch in a namespace, so this page does not pretend to.
What trips people up
1. Hard-setting one end to be certain
That is the cause rather than the cure. A hard-set interface stops advertising, the other end falls back to guessing, and the specified guess for duplex is half. Set both ends or negotiate on both.
2. Expecting a duplex mismatch to break the link
It does not. Both ends come up and work, and the link drops frames whenever both transmit at once, so it is fine when idle and terrible under load.
3. Reading UP and LOWER_UP as one thing
UP is somebody having enabled the interface. LOWER_UP is something being
plugged in. An interface that is administratively down does not care about the
cable at all.
4. Promising that bonding makes a transfer faster
It does not. A bond hashes each flow onto one member to keep frames in order, so a single transfer gets one link’s worth. Aggregation buys capacity across many conversations, and redundancy.
5. Leaving the hash policy at the default on an uplink
A bond to a router hashing on MAC addresses sends nearly everything down one member, because the router’s MAC is on every frame. Wildly unequal member counters are the sign.
6. Static bonding instead of LACP
A static bond has no way to notice that the far end is not bonded. Configured on one end only, it presents the same MAC on two switch ports, which is a loop.
Work it through
A backup job that used to finish overnight now runs into the morning. The server and the switch both report the link up at one gigabit. The network team confirms no changes. The server team confirms no changes. Throughput measures about 30 megabits.
Start with the gap between reported and measured, because it is enormous. Thirty megabits on a link reporting a gigabit is not congestion and not a slow disk, both of which would land much closer to the line rate. A factor of thirty means something is going wrong per packet.
Duplex mismatch fits the shape exactly. Both ends report up, the speed negotiated correctly, and the duplex did not. Under a backup’s sustained load both ends transmit constantly, collisions happen continuously at the half duplex end, and TCP’s response to that loss is to collapse its window, which topic 09 showed produces precisely this: no errors anywhere and throughput on the floor.
The check is the counters, at both ends, and they will disagree with each other. Late collisions at the half duplex end, and frame errors at the other. Both ends matter here: reading only one gives half the evidence and the half you get depends on which end you logged into first.
The likely history is worth guessing at because it points at the fix. Somebody hard-set that switch port years ago, the server was replaced, the new card negotiates, and the mismatch arrived with the new hardware while everybody was looking at the backup software.
Two things not to do. Do not conclude the network needs upgrading, because the link is already fast enough and the problem is that it is not being used. And do not fix it by hard-setting the server to match, which works and leaves the trap armed for the next person. Set both ends to negotiate.
Try it
Read your own interface. The command depends on what you are sitting at.
ethtool <if> on Linux, Get-NetAdapter on Windows and read LinkSpeed,
ifconfig <if> on macOS and read the media: line. Note the speed, the duplex
and whether negotiation is on. Most people have never looked, and
interface counters and port status
puts all three side by side with real output from each.
Look at the counters. ip -s link show on Linux, netstat -e on Windows,
netstat -i on macOS. On a healthy link the errors and drops are zero or a small
static number left over from a cable being moved. A counter climbing while you
watch is a live fault.
Find a bond if you have one. Any server with two cables to a switch probably
has one. cat /proc/net/bonding/bond0 on Linux gives the mode, the hash policy
and the state of each member, and comparing the byte counters of the two members
tells you whether the hash is actually distributing.
Check yourself
A switch port is hard-set to 1000 full. The server negotiates. What does the server end up at, and why?
Probably 1000 half, or slower.
A hard-set interface stops sending negotiation advertisements, so the server has nothing to negotiate with and falls back to parallel detection. That can sense the speed from the signalling, and there is no way to detect duplex from the signal, so the specified fallback is half duplex.
The result is one end full and one end half, both up, neither reporting a configuration error.
Why does a duplex mismatch produce a slow link instead of a dead one?
Because both ends work, they just disagree about the rules.
The full duplex end transmits whenever it likes, including while the other end is mid-frame. The half duplex end sees that as a collision, aborts its frame and backs off, so frames are lost whenever both happen to transmit at once.
TCP retransmits the losses and cuts its congestion window in response, so throughput collapses under load and looks perfectly fine when the link is idle. That is why it survives testing and fails in production.
What is a late collision and why is it diagnostic?
A collision detected after the first 64 bytes of a frame.
On a correctly configured half duplex segment that cannot happen, because the segment is short enough that a collision at the far end propagates back before 64 bytes have been sent. A collision arriving later means the other end started transmitting long after it should have known the wire was busy.
The end that reports late collisions is the half duplex end of a duplex mismatch. The other end usually reports frame check sequence errors instead, so the two ends describe the same fault differently.
Two gigabit links are bonded between a server and a switch. How fast is a single large file copy?
One gigabit.
A bond hashes each flow onto one member and sends every frame of that flow down the same link. That is deliberate: splitting one conversation across two links would deliver frames out of order, and TCP reads reordering as loss.
Two gigabits is the aggregate across many conversations. A single transfer is a single flow and gets one member’s worth, which is why bonding disappoints anyone who was promised a faster copy.
What it does buy is capacity across many flows, and redundancy when a member fails.
A bonded uplink to a router shows one member carrying almost all the traffic. What is wrong?
The hash policy, most likely hashing on MAC addresses.
Every frame going up to the router has the router’s MAC as its destination, and everything coming back has it as the source. So the hash produces nearly the same answer for all of it and picks the same member every time.
Hashing on IP addresses fixes it, because the addresses differ per conversation even when the MACs do not. Hashing on addresses and ports distributes better again and separates several conversations between the same pair of machines.
Why is LACP preferable to configuring a bond statically at both ends?
Because a static bond cannot tell whether the far end agrees.
LACP exchanges keepalives, so both ends confirm they are bonding, and a member that is physically up but not passing traffic can be removed from the bond.
The failure a static bond allows is a bond configured on one end and not the other. That presents the same MAC address on two separate switch ports, which is a loop, and the next topic is about what a loop does to a network.
References
- IEEE 802.3 Standard for Ethernet - IEEE Standards Association, which specifies auto-negotiation, parallel detection and the half duplex fallback. Accessed 2026-08-10.
- IEEE 802.1AX, Link Aggregation - IEEE Standards Association, which defines LACP. Accessed 2026-08-10.
- Linux Ethernet Bonding Driver HOWTO - Linux kernel documentation, on the modes and hash policies in the capture. Accessed 2026-08-10.
Where the output came from. The bonding block was produced on
blog/scripts/topologies/one-switch.sh through blog/scripts/netlab.sh, and the
bond, its mode and its hash policy are the kernel’s own.
Everything about speed and duplex on this page is sourced rather than captured, and that is a real gap rather than an oversight. Those are properties of physical Ethernet hardware negotiating over copper, and a veth pair in a namespace has no speed, no duplex and no negotiation to observe. Producing a duplex mismatch would mean writing a transcript by hand, which this track does not do. The Prove it section names the commands to run on hardware instead.
If you also work on Linux. Configuring networking on the Linux+ track covers interface state and making it persist across a reboot, which is the administration half of the first part of this page.