Bonding in Linux: Where One Link Failure Brings Down a Service
One physical port on a server is a single point of failure that is rarely factored into redundancy calculations. Disks are mirrored, power is backed up, but the link remains a single instance.
While it is up, the scheme looks operational: monitoring is silent, the load balancer considers the node alive, and the on-call engineer is the last to learn about the problem.
Failure of a network interface breaks not an abstract “network” but concrete things. Neighbor entries in the routing table are cleared, the virtual gateway address goes away if it is hosted on this node, and long-lived connections are terminated.
Services with long sessions fail first: database replication, distributed storage, message queues, background exports that will have to be restarted.
Bonding in Linux removes this risk: multiple physical interfaces are combined into one logical interface, and link failure is survived without losing the address.
Active-backup mode keeps one port operational and the rest in hot standby; failover takes seconds and does not require coordinated switch configuration. Link aggregation with LACP adds aggregate bandwidth and distributes flows across all links.
The difference between a “quick-and-dirty” setup and a working scheme is in the details. State monitoring is needed on both sides: a local indication is not enough if the remote port is no longer passing traffic.
Aggregation requires coordinated settings on the switch; otherwise the links will not come together into one. A mistake in mode selection turns the backup into a new point of failure that will manifest exactly at the moment of an incident.
Next, we break down how this is addressed: which mode fits your scenario, how to verify failover by simulating a link failure, and what should be included in monitoring so that link failure remains invisible to users.
Channel Redundancy: What Changes After Configuration
After the bundle is built, the network no longer depends on a single point: link failure, port errors, or switch reboot no longer tear down the connection.
In active-backup mode, traffic goes through the active member, and the standby takes over within fractions of a second — TCP sessions are not re-established, so downtime for the application service is measured not in minutes but in a pause the user does not notice.
In an LACP bundle, the effect is different: the flow is distributed by hash policy, and the total channel throughput grows with the number of live links.
Traffic distribution is selected for the load profile — layer3+4 when there are many applications and thousands of sessions, or layer2 when traffic goes between pairs of addresses.
An honest caveat: a single connection with the same five-tuple of addresses and ports is pinned to one link, so the bundle increases total bandwidth, not the speed of an individual flow.
Network redundancy is confirmed not by the fact that a mode is enabled but by measurements: counters per member, bundle state, and the number of failovers during a planned link outage.
Verification parameters (miimon, arp_validate) determine how quickly the system notices a failure — the downtime window depends on them, not on the number of physical ports.
Boundaries also need to be kept in mind: two links in one switch do not protect against failure of the switch itself, so in production the bundle is spread across two devices (MLAG/vPC).
The behavior of modes and their limitations are described in detail in Linux kernel bonding documentation — this is what we rely on when choosing a scheme.
Bonding Modes in Linux: Which to Choose for the Task
Interface aggregation modes differ not by “speed” but by which failure they cover: link failure, lack of bandwidth, or flow distribution across channels.
There is no universal option — the mode is selected based on what the switch at the other end supports and what loss of availability must be survived.
| Mode | When it fits | Limitations |
|---|---|---|
| Active-backup scheme (active-backup) | Only redundancy is needed: communication channel, pair of switches | One interface works, total bandwidth does not increase |
| Load-balancing aggregation (balance-xor, LACP) | The switch supports aggregation, aggregate bandwidth is needed | Requires coordinated configuration on both sides, one flow goes over one channel |
| Adaptive load balancing (tlb/alb) | Bandwidth is needed, aggregation on the switch is unavailable | Mostly outbound traffic is distributed, behavior depends on the driver |
| Round-robin transmission (balance-rr) | Narrow scenarios with predictable homogeneous traffic | Packet reordering, latency-sensitive applications suffer |
Limitations of modes manifest not on a test bench but during the first abnormal situation: an uncoordinated mode on one side causes loops or silent loss of part of the traffic, visible only in metrics.
Therefore, verification includes disconnecting a link, returning the interface to service, and checking that long-lived sessions do not break.
We choose the mode after reviewing the topology: how many physical channels, one switch or two, how sensitive traffic is to packet order. This filters out options that look workable only in documentation.
Implementation Order: From Topology Audit to Handover
The stages are arranged so that changes on production nodes do not turn into downtime. Each step has a readiness criterion and an artifact: port map, configuration, test protocol.
-
Topology audit. We look at where cables physically arrive: how many ports are free, whether they are spread across different switches and power feeds, and which aggregation modes are already configured on the network side.
A common finding is that both links are connected to one chassis, and redundancy exists only on paper.
-
Redundancy scheme. We select a mode for the task: active-backup with ports on different switches protects against hardware failure; aggregation adds bandwidth. We document on the diagram the behavior during link failure and when it returns, so the on-call shift has no guesswork.
-
Interface configuration. We build the bundle using bonding in Linux over physical ports, set link liveness monitoring, traffic distribution parameters, MTU, and VLANs on top of the bundle. We apply it so that the node remains available at all times.
-
Failover verification. We disconnect the link physically — one at a time and both at once. We measure recovery time and packet loss, review logs and session behavior, and separately check traffic return to the primary port.
-
Monitoring. We set up polling of bundle state and alerts for transition to standby, so degradation does not live unnoticed for months.
-
Training and handover. We provide configurations, the diagram, and the test protocol, and show the on-call shift how to replace a port and what to check afterward.
Until failover is verified under load, redundancy remains an assumption — we perform acceptance with measurements before and after.
Configurations, Diagrams, and Procedures: What We Hand Over to the Customer
We hand over not only a working node but everything needed for its independent operation in six months and in three years.
We store configurations in a version control system: a change is validated on a test bench, and only a verified set reaches production nodes, not an edit “by hand on a live machine.”
- Ready interface configurations: combining ports into a bond interface, selecting the mode (active-backup or link aggregation), link priorities and failure reaction timers — with notes on which parameters are tuned for specific hardware.
- Network diagram: switch topology, port and VLAN map, rack connection order — with clearly marked points of failure and what will happen if each of them fails.
- Failover procedure: how traffic behaves during link failure or switch failure, how long it takes, what is considered normal behavior, and what is a reason for intervention.
- Redundancy verification procedure: how to safely pull a cable or shut down a port and make sure connectivity is not interrupted without taking the service out of operation.
- Diagnostics instructions: a set of commands by which the on-call engineer distinguishes link failure from a problem with upstream equipment or the service itself.
- Node datasheet and change procedure: port set, addressing, procedure for adding a new interface, and how to roll back to the previous configuration.
Each document is tied to the real diagram, not written “from a template”: the on-call shift can act on it without calling us.
Case Study: How We Eliminated Connectivity Outages on Two Access Nodes
Two access nodes served the customer's internal services: a file cluster and a terminal gateway for remote employees. Each had one physical channel to the switch, the second port was idle, and a port or patch cord failure took the entire node off the network.
Before Redundancy Implementation
Metrics were collected over a quarter of observation: four unplanned outages, in total about three hours of unavailability; the on-call shift learned about each failure from a user call.
Failover to the backup port was performed manually, and some failures occurred at night and were detected only in the morning. The cost of downtime was missed export windows and repeated task runs.
What We Changed and What We Got
We built an aggregated interface from two physical ports on Linux in a redundancy mode: the active channel is checked by link state and neighbor availability; on failure, traffic moves to the second one without manual intervention.
We added alerts for active channel change and loss of both — the on-call engineer sees the event immediately.
Over a comparable observation period: failover takes fractions of a second and does not break sessions to the cluster, there are zero outages due to network failure, and detection is instant via alert.
Rollback was tested separately: removing the aggregation returns the node to its original configuration without reinstallation or repeated coordination with the network team.
Technical Doubts Before Configuring Aggregation
Doubts before aggregation are usually purely technical: whether the hardware is compatible, whether we will lose access to the server when changing the mode, and what to do if the switch is configured differently from the server.
Let's address three questions that are most often raised before work begins and that cover the main configuration risks.
Does our hardware support bonding, and which modes will actually work?
The mode is set by the mode parameter. active-backup (active link plus hot standby) and 802.3ad (LACP with port aggregation on the switch) are supported by drivers of common wired cards.
Before work, we capture ethtool output and the current link state — they show which modes the card supports and whether it will lose connectivity when switching to a bundle.
Will the service have to be stopped during failover?
Interfaces are added to the bundle one at a time: first the free port and link verification, then moving addressing and routes. On active traffic, the pause is measured in seconds; with active-backup, in fractions of a second.
The working configuration is saved separately, and access via the management console is kept open: if the server does not respond over the network, rollback is one command.
What happens if the switch does not support LACP?
Some links will not come up, and the remaining ones will start dropping packets or cause a MAC address table flood on the switch. Therefore, before changes we verify port modes: LACP on both sides, identical VLANs, coordinated speed and duplex on all members.
If aggregation on the switch is unavailable, active-backup remains — redundancy without changes to its configuration.
How Does Link Aggregation Differ from Route Redundancy?
Link aggregation and route redundancy cover different failure levels.
In Linux, bonding/teaming combines physical ports into one logical interface at the stack and switch level: a cable break or port failure does not interrupt connectivity because traffic moves to the remaining members.
Redundancy works higher — when what is unavailable is not the port but the next hop, route, or an entire carrier.
The difference shows in the cost of error. Aggregation requires a coordinated mode on both sides of the channel: with dynamic negotiation (LACP), the server and switch agree on membership; active-backup mode requires no switch configuration and survives even its reboot.
Route redundancy imposes no such requirements on the port, but failover takes time — from protocol timers to routing table convergence.
| Approach | Failure level | When it fits | Limitations |
|---|---|---|---|
| Link aggregation | Link, port, switch module | Server and switch on the same site, one carrier | Requires a coordinated mode on both sides, the logical path shares common points of failure |
| Route redundancy | Node, route, carrier | Two providers, different sites, internet access | Failover is not instantaneous, depends on protocol and detection settings |
Choosing a scheme starts with an inventory of failure points. One cable, one port, one chassis means aggregation; different carriers, sites, or routes means routing-level redundancy.
In practice, the mechanisms almost always work together: link failure remains invisible to the service, while loss of an entire site moves traffic to the backup path.
Let's Discuss Your Redundancy Scheme and Come Back with a Plan
To assess a redundancy scheme, there is no need to open access to the production environment. A few inputs are enough — they reveal the topology, aggregation mode, and which failures the scheme already survives and which it does not.
- Interface configuration with current aggregation settings — files from both nodes if the bundle is built on both sides.
- Connection diagram: how many physical channels, which switches they go to, whether there are independent paths between them.
- Load-balancing mode and traffic distribution algorithm across channels, with a note on whether they were changed after launch.
- Description of failures that have already occurred: what exactly dropped — the channel, the switch-side port, or the entire node.
- Downtime requirements: acceptable failover window and whether there is traffic for which interruption is unacceptable.
On a call, we clarify what cannot be read from the configuration: how the bundle behaves on failure, whether there is redundancy on the network side, and how important the order of bringing channels back into service is.
We will come back with an implementation plan: stages, sequence of changes, checkpoints after each step, and rollback to the original configuration. Describe the task — we will prepare an estimate for your environment.