Bonding Examples

Bonding Examples

Bonding in RouterOS combines multiple physical network interfaces into a single logical interface, providing increased bandwidth, redundancy, and load balancing capabilities. Bonding is essential for high-availability deployments where network uptime and performance are critical requirements. This documentation covers practical bonding configurations for various network scenarios, from basic link aggregation to advanced hardware-offloaded implementations.

The bonding implementation supports multiple modes, each designed for specific use cases and network requirements. Understanding these modes and their appropriate applications ensures optimal performance and reliability. Whether connecting to enterprise switches, configuring cross-stack redundancy, or implementing simple failover protection, the correct bonding configuration makes the difference between a resilient network and one vulnerable to downtime.

Bonding Modes Overview

RouterOS supports seven bonding modes that determine how traffic distributes across member interfaces and how failover behaves. Each mode offers different trade-offs between bandwidth utilization, compatibility, and feature availability. Selecting the appropriate mode depends on the connected equipment capabilities, traffic patterns, and redundancy requirements of the deployment.

The bonding mode determines both the load balancing algorithm and the failover detection mechanism. Some modes require matching configuration on both ends of the aggregation, while others operate independently. Hardware offloading support varies by mode and device capabilities, making mode selection particularly important on devices with switch chips that can offload bonding operations.

Mode	Load Balancing	Failover Detection	LACP Required	Hardware Offload	Best For
802.3ad (LACP)	Hash-based	LACP negotiation	Yes	Yes	Enterprise switches
balance-rr	Round-robin	ARP monitoring	No	No	Simple aggregation
balance-xor	Hash-based	ARP monitoring	No	Yes	Consistent flows
active-backup	Single active	ARP/MII monitoring	No	Yes	Maximum redundancy
balance-tlb	Adaptive	ARP monitoring	No	No	Dynamic environments
balance-alb	Adaptive	ARP monitoring	No	No	Mixed environments
broadcast	All interfaces	Link status	No	No	Specific redundancy

LACP (802.3ad) Configuration

Link Aggregation Control Protocol (LACP) provides automatic configuration and monitoring of aggregated links. LACP enables dynamic aggregation where member ports can be added or removed without manual reconfiguration on either end. The protocol continuously monitors link health and automatically redistributes traffic when member links fail or are added.

LACP operates by exchanging Protocol Data Units (PDUs) between both ends of the aggregation. These PDUs contain information about the link capabilities and current state. When LACP detects a link failure, it automatically removes the failed member from the aggregation group while maintaining connectivity through remaining members. This dynamic behavior makes LACP ideal for environments where links may change or where automatic failover without manual intervention is required.

The LACP rate determines how frequently LACP PDUs are exchanged. A faster rate (1 second) provides quicker failover detection but generates more CPU overhead. The default rate of 30 seconds balances responsiveness with resource efficiency for most deployments. Consider faster rates only when sub-second failover is critical and the device can handle the additional processing load.

Basic LACP Configuration

Creating a basic LACP aggregation requires matching configuration on both the MikroTik router and the connected switch. The aggregation group combines multiple physical ports into a single logical interface that functions as a standard network interface for routing, bridging, and firewall configuration.

# Create LACP aggregation group with two member ports
/interface bonding add name=bond-lacp slaves=ether1,ether2 mode=802.3ad lacp-rate=30secs

# Verify aggregation status
/interface bonding print

# View detailed LACP partner information
/interface bonding lacp print

# Assign IP address to the bonded interface
/ip address add address=10.0.0.1/24 interface=bond-lacp

The LACP partner information shows the remote device’s aggregation capabilities and current state. Verify that the partner shows all expected member ports as synchronized. Any ports showing as defaulted or not synchronized indicate configuration mismatches or cabling issues requiring attention.

# Check LACP status for all member ports
/interface bonding lacp print detail

# Monitor LACP in real-time
/interface bonding lacp monitor

LACP with Transmit Hash Policy

The transmit hash policy determines how traffic distributes across member ports in LACP mode. The default layer2 policy hashes based on source and destination MAC addresses, which works well when traffic flows to many different destinations. For more granular distribution, layer3+4 hashing provides better distribution for traffic to specific destinations.

Layer3+4 hashing uses source and destination IP addresses and port numbers for hash calculation. This policy typically provides better distribution when traffic flows to a limited number of destinations, such as when the bonded interface connects to a single upstream router or firewall. The trade-off is slightly higher CPU usage for hash calculation.

# Create LACP with layer2+3 hash policy for better distribution
/interface bonding add name=bond-lacp-hash slaves=ether1,ether2,ether3,ether4 \
  mode=802.3ad lacp-rate=30secs transmit-hash-policy=layer-2-and-3

# Verify hash policy configuration
/interface bonding print detail

# Check traffic distribution across members
/interface bonding print stats

LACP with Link Monitoring

Link monitoring ensures rapid detection of failed member ports by periodically checking link connectivity. ARP monitoring sends ARP queries to a target IP address and marks links as down if responses are not received. MII monitoring checks the physical layer link status without requiring network-layer connectivity.

ARP monitoring provides more reliable failure detection when the connected device may maintain link-level connectivity without Layer 3 functionality. Configure the monitoring target as an IP address on the remote device that will always respond to ARP requests. Multiple targets provide redundancy in monitoring by using any reachable target.

# LACP with ARP monitoring for rapid failover
/interface bonding add name=bond-lacp-monitor slaves=ether1,ether2 \
  mode=802.3ad lacp-rate=30secs link-monitoring=arp arp-ip-targets=10.0.0.2

# Add multiple monitoring targets for reliability
/interface bonding set [find name=bond-lacp-monitor] arp-ip-targets=10.0.0.2,10.0.0.3

# MII monitoring alternative for physical layer checks
/interface bonding add name=bond-lacp-mii slaves=ether1,ether2 \
  mode=802.3ad link-monitoring=mii

Active-Backup Mode

Active-backup mode provides simple failover protection by designating one member port as active while others remain standby. When the active link fails, a standby link automatically takes over. This mode offers maximum redundancy without the complexity of LACP negotiation, making it suitable for connections to equipment that does not support LACP.

The primary interface parameter specifies which port serves as the active link. When the primary link fails, the first available backup interface becomes active. When the primary link recovers, it automatically reassumes active status. This behavior ensures that the preferred path is always used when available while maintaining instant failover capability.

# Create active-backup bond with ether1 as primary
/interface bonding add name=bond-backup slaves=ether1,ether2,ether3 \
  mode=active-backup primary=ether1

# Verify active interface
/interface bonding print

# Configure MAC address assignment for transparent failover
/interface bonding set [find name=bond-backup] fail-over-mac-address=active

The fail-over-mac-address setting affects how MAC addresses appear to connected devices during failover. With the default setting, the bond interface MAC changes to the MAC address of the newly active interface, which may cause brief connectivity disruption. Setting this to “active” maintains the primary interface MAC address on the bond, providing more transparent failover for connected equipment.

Balance-Xor Mode

Balance-xor mode provides static load balancing based on a hash of source and destination MAC addresses. This mode offers predictable traffic distribution without the overhead of LACP negotiation. All member ports remain active, with traffic distributed according to the hash policy.

The static nature of balance-xor means that failover requires link monitoring to detect failures. Without monitoring, failed ports continue to have traffic directed to them until the failure is detected through other means. Configure appropriate link monitoring to ensure rapid failover.

# Create balance-xor bond with layer2+3 hashing
/interface bonding add name=bond-xor slaves=ether1,ether2,ether3 \
  mode=balance-xor transmit-hash-policy=layer-2-and-3

# Verify traffic distribution
/interface bonding print stats

# Add ARP monitoring for failover detection
/interface bonding set [find name=bond-xor] link-monitoring=arp arp-ip-targets=10.0.0.1

Balance-RR Mode

Balance-rr (round-robin) mode distributes traffic sequentially across all member ports. This mode provides simple aggregation without requiring matching configuration on the remote device. However, balance-rr has limitations including potential packet reordering that can impact application performance.

Round-robin distribution works well for scenarios requiring simple bandwidth addition without switch configuration. The sequential distribution ensures all links are fully utilized but may cause issues with protocols sensitive to packet ordering. Consider alternative modes for latency-sensitive applications or connections to equipment that cannot handle out-of-order packets.

# Simple balance-rr for basic aggregation
/interface bonding add name=bond-rr slaves=ether1,ether2 mode=balance-rr

# Add monitoring for failover
/interface bonding set [find name=bond-rr] link-monitoring=mii

Hardware Offloaded Bonding

Hardware offloading moves packet processing from the CPU to the switch chip, enabling wire-speed performance for bonding operations. Not all bonding modes support hardware offloading, and offload capability depends on the device’s switch chip capabilities. Hardware-offloaded bonding requires specific configuration to ensure proper operation.

Devices with qualifying switch chips can offload 802.3ad and balance-xor modes. Offloaded bonds participate in hardware switching, providing full bandwidth without CPU involvement. This capability is essential for high-throughput deployments where CPU-based processing would become a bottleneck.

CRS3xx Series Configuration

CRS3xx series switches support hardware-offloaded bonding when using compatible modes and configurations. The bonding interface must be created with hardware offloading enabled, and the member ports must be properly configured as switch ports.

# Create hardware-offloaded LACP bond on CRS3xx
/interface bonding add name=bond-hw-lacp slaves=ether1,ether2 mode=802.3ad

# Add bonding interface to bridge with hardware offloading
/interface bridge port add bridge=bridge1 interface=bond-hw-lacp hw=yes

# Verify hardware offloading status
/interface bridge port print detail

# Check switch chip offload status
/interface bridge switch print

The hardware offloading status appears in the bridge port details. The “hw” field indicates whether offloading is active. If offloading is not active, verify that the bonding mode supports hardware offloading and that the switch chip is properly configured.

CRS1xx/2xx Series Configuration

CRS1xx and CRS2xx series switches support a subset of bonding modes for hardware offloading. These devices require specific switch chip configuration to enable bonding offload.

# Create balance-xor bond for CRS1xx/2xx hardware offload
/interface bonding add name=bond-crs slaves=ether1,ether2,ether3,ether4 \
  mode=balance-xor

# Configure switch port settings for bonding
/interface ethernet switch port set ether1,ether2,ether3,ether4 \
  default-vlan-id=1 vlan-header=leave-as-is

# Add bond to bridge with hardware switching
/interface bridge add name=bridge1
/interface bridge port add bridge=bridge1 interface=bond-crs hw=yes

Bonding with VLANs

VLANs on bonded interfaces combine the bandwidth of multiple physical links with the network segmentation benefits of VLAN tagging. This configuration is common in environments requiring both link aggregation and multi-tenant network isolation.

VLAN interfaces created on top of bonded interfaces inherit the bonding characteristics while providing Layer 3 connectivity for individual VLANs. The bonding distributes VLAN traffic across member ports based on the configured hash policy.

# Create LACP bond
/interface bonding add name=bond-vlan slaves=ether1,ether2 mode=802.3ad

# Create VLAN interfaces on the bond
/interface vlan add name=vlan10 vlan-id=10 interface=bond-vlan
/interface vlan add name=vlan20 vlan-id=20 interface=bond-vlan
/interface vlan add name=vlan30 vlan-id=30 interface=bond-vlan

# Configure IP addresses on VLAN interfaces
/ip address add address=192.168.10.1/24 interface=vlan10
/ip address add address=192.168.20.1/24 interface=vlan20
/ip address add address=192.168.30.1/24 interface=vlan30

Bonding in Bridge Configuration

Bonded interfaces function as regular interfaces in bridge configurations, enabling Layer 2 switching across multiple aggregated links. This setup is common when aggregating uplinks to switches while maintaining transparent bridging.

# Create aggregation bond
/interface bonding add name=bond-bridge slaves=ether1,ether2 mode=802.3ad

# Create bridge for Layer 2 forwarding
/interface bridge add name=bridge-local

# Add bond to bridge
/interface bridge port add bridge=bridge-local interface=bond-bridge hw=yes

# Add other ports to the bridge
/interface bridge port add bridge=bridge-local interface=ether3 hw=yes
/interface bridge port add bridge=bridge-local interface=ether4 hw=yes

Bonding for WAN Uplinks

Bonding multiple WAN uplinks increases available bandwidth for internet-facing traffic. This configuration requires careful consideration of how traffic distributes across providers and how to handle asymmetric routing scenarios.

When bonding WAN links from different ISPs, IP address assignment and routing require special attention. Each member port typically connects to a different ISP with separate IP addressing. The bonding interface itself does not hold an IP address; instead, member ports maintain their individual IP configurations.

# Create active-backup bond for primary/backup WAN
/interface bonding add name=bond-wan slaves=ether1,ether2 mode=active-backup primary=ether1

# Configure IP on the active interface (this will be the primary)
/ip address add address=203.0.113.1/24 interface=ether1

# Add default routes through both providers
/ip route add gateway=203.0.113.254 distance=1
/ip route add gateway=198.51.100.254 distance=10 check-gateway=ping

# Configure NAT for outbound traffic
/ip firewall nat add chain=srcnat out-interface=bond-wan action=masquerade

Monitoring Bonding Status

Regular monitoring ensures bonding configurations operate correctly and helps identify issues before they cause network outages. Monitor both the bonding interface status and individual member port statistics to maintain visibility into aggregation health.

# View bonding interface status
/interface bonding print detail

# Check LACP partner status
/interface bonding lacp print detail

# Monitor member port statistics
/interface bonding print stats

# Monitor in real-time
/interface bonding monitor [find name=bond1]

Troubleshooting Common Issues

Bonding configuration issues typically manifest as asymmetric traffic distribution, failover failures, or link instability. Systematic troubleshooting identifies the root cause and guides corrective action.

LACP negotiation failures often result from mismatched configuration between devices. Verify that both ends use the same mode, LACP rate, and hash policy. The LACP partner information shows the remote device’s capabilities and current state.

# Diagnose LACP issues
/interface bonding lacp print detail

# Check for defaulted ports indicating negotiation failure
# Defaulted ports show configuration mismatch

# Verify physical connectivity
/interface ethernet print stats

# Check for errors on member ports
/interface print stats-detail

Hash distribution problems manifest as uneven load across member ports. Traffic to a limited number of destinations may not distribute well with layer2 hashing. Consider switching to layer2+3 hashing for better distribution.

# Check traffic distribution
/interface bonding print stats

# Compare bytes-sent and bytes-received across members
# Significant imbalance indicates hash policy issues

# Change hash policy for better distribution
/interface bonding set [find name=bond1] transmit-hash-policy=layer-2-and-3

Related Topics

• Interface Configuration - General interface setup and options
• Switching - Layer 2 switching features
• VLANs - VLAN configuration across bonded interfaces
• Bridge Configuration - Bridge setup with bonded interfaces
• Hardware Ports - Physical port documentation
• Failover WAN Backup - Port-based failover configurations
• CRS3xx Switch Features - Hardware offloading details