Multi-chassis Link Aggregation Group

Multi-chassis Link Aggregation Group

Multi-chassis Link Aggregation Group (MLAG) in RouterOS enables LACP bonds to span two separate MikroTik devices while the client device believes it’s connected to a single machine. This provides physical redundancy in case of switch failure, making it ideal for data center and enterprise deployments where uptime is critical.

MLAG operates by establishing peer communication between two devices using ICCP (Inter Chassis Control Protocol). The peers synchronize bridge host tables and present a unified LACP system to connected clients. When one device fails, the other seamlessly takes over without disrupting connectivity. This capability transforms two separate switches into a single logical redundancy pair, eliminating single points of failure in critical network infrastructure.

How MLAG Works

MLAG relies on peer devices exchanging control information through a dedicated peer port. This peer connection carries ICCP traffic that synchronizes MAC address tables and LACP system IDs between the two devices. The client-facing bonds on each device share the same MLAG ID, appearing as a single aggregation group from the client’s perspective while actually consisting of interfaces on two separate hardware platforms.

The ICCP protocol operates at Layer 2 using EtherType 0x88B5 with a destination MAC of 01:80:C2:00:00:0E. These are link-local packets that never leave the peer link, ensuring MLAG control traffic remains isolated from the rest of the network. Each MLAG node must have a direct physical connection between their designated peer ports—this link carries all synchronization traffic and must be sized appropriately for the expected inter-node traffic volume.

Primary and Secondary Election

When MLAG peer communication is established, the devices elect a primary node based on priority and MAC address. The device with the lower mlag-priority value becomes primary; if priorities are equal, the device with the lower bridge MAC address wins. The primary device’s MAC address becomes the system ID used in LACP negotiations with clients and in STP BPDU bridge identifiers. Both nodes share the same bridge MAC address when MLAG is active, creating the illusion of a single device to connected clients.

Hardware and Software Support

Starting with RouterOS version 7.22, MLAG configuration moved from a dedicated submenu to the bridge interface itself. This change enables any RouterOS device—including virtual CHR instances—to function as an MLAG node. Hardware-offloaded MLAG remains limited to specific platforms: CRS3xx, CRS5xx, and CRS8xx series switches, plus CCR2116, CCR2216, and RDS2216 routers. All other devices handle MLAG purely in software, which impacts performance for high-throughput deployments.

Packet Forwarding and Load Balancing

MLAG handles different traffic types differently, with distinct behaviors for broadcast, unknown unicast, and multicast (BUM) traffic versus unicast traffic. Understanding these behaviors helps in designing networks that avoid loops while maximizing throughput.

BUM Traffic Flow

BUM traffic follows a two-stage forwarding process. In the first stage, when a node receives BUM traffic, it floods the packet locally to all ports in the same VLAN and simultaneously forwards a copy over the peer port to the other MLAG node. This peer-port forwarding only occurs if the peer port is a member of the same VLAN—in practice, this means you must include the peer port in all VLANs used by MLAG-connected devices.

In the second stage, when the peer node receives BUM traffic over the peer port, it floods to all regular bridge ports (those without an mlag-id). For MLAG bond interfaces, the receiving node makes a decision based on link status: if both local and remote links are active, it suppresses flooding to avoid duplicates; if only the local link is active, it floods to ensure delivery reaches all destinations.

Unicast Load Balancing

Unicast traffic takes a different path than traditional LAG. In standard LAG configurations, outgoing packets distribute across all active links based on the transmit hash policy. In MLAG, traffic does not load-balance across the peer-port between switches when both links are active. Instead, traffic always uses the local member links—the shortest path to the destination. The peer-port serves as a failover path only when local MLAG links fail.

In configurations where each MLAG node has 2+2 active links (two links per node), transmit hashing operates only among the two local links, not across all four. True load balancing across the full MLAG pair requires multiple dual-connected bonds with incoming traffic already distributed across both pairs.

RouterOS Version Differences

RouterOS 7.22 introduced significant changes to MLAG configuration syntax. The old configuration existed under /interface/bridge/mlag, while new versions configure MLAG directly under the bridge interface using the mlag- prefix. Upgrading to 7.22 or later automatically converts existing MLAG configurations to the new format. Downgrading to versions before 7.22 erases the MLAG configuration entirely—always back up your configuration before downgrading.

Setting	Old (7.21-)	New (7.22+)
Configuration location	/interface/bridge/mlag	/interface/bridge
Heartbeat interval	heartbeat	mlag-heartbeat
Peer port	peer-port	mlag-peer-port
Priority	priority	mlag-priority
Status	status	mlag-state
Active role	N/A	mlag-active-role
System ID	system-id	bridge-id

Quick Setup Example

This example demonstrates a complete MLAG setup using CRS317 and CRS309 devices as MLAG peers with an LACP client. The peer link uses SFP+1 on both devices, while client connections use SFP+2 on each peer.

Client Configuration

First, configure the client device with a standard LACP bond. Use the 1-second LACP rate for faster link establishment:

/interface bonding
add mode=802.3ad name=bond1 slaves=sfp-sfpplus1,sfp-sfpplus2 lacp-rate=1sec

Peer Device Configuration

Configure matching MLAG bonds on both peer devices with the same mlag-id:

# Peer1
/interface bonding
add mlag-id=10 mode=802.3ad name=client-bond slaves=sfp-sfpplus2 lacp-rate=1sec

# Peer2
/interface bonding
add mlag-id=10 mode=802.3ad name=client-bond slaves=sfp-sfpplus2 lacp-rate=1sec

Configure the bridge with VLAN filtering, MLAG peer port, and set Peer1 as primary by assigning lower priority:

# Peer1 - Primary node
/interface bridge
add name=bridge1 vlan-filtering=yes mlag-peer-port=sfp-sfpplus1 mlag-priority=50 priority=0x1000 frame-types=admit-only-vlan-tagged

# Peer2 - Secondary node
/interface bridge
add name=bridge1 vlan-filtering=yes mlag-peer-port=sfp-sfpplus1 priority=0x1000 frame-types=admit-only-vlan-tagged

Add bridge ports. The peer port should accept only tagged traffic; the client bond handles untagged VLAN 10:

# Peer1
/interface bridge port
add bridge=bridge1 interface=sfp-sfpplus1 frame-types=admit-only-vlan-tagged
add bridge=bridge1 interface=client-bond pvid=10

# Peer2
/interface bridge port
add bridge=bridge1 interface=sfp-sfpplus1 frame-types=admit-only-vlan-tagged
add bridge=bridge1 interface=client-bond pvid=10

Configure VLAN membership. The peer port must be a tagged member of all VLANs used by client connections:

# Peer1
/interface bridge vlan
add bridge=bridge1 tagged=sfp-sfpplus1 vlan-ids=10
add bridge=bridge1 tagged=sfp-sfpplus1,client-bond vlan-ids=20

# Peer2
/interface bridge vlan
add bridge=bridge1 tagged=sfp-sfpplus1 vlan-ids=10
add bridge=bridge1 tagged=sfp-sfpplus1,client-bond vlan-ids=20

Monitoring MLAG

Verify MLAG status on both peers. The state should show “connected” and the active roles should be “primary” and “secondary”:

# On Peer1
/interface bridge monitor [find name=bridge1]

Expected output:

                  state: enabled
    current-mac-address: B8:69:F4:1B:B0:7C
              bridge-id: 0x1000.B8:69:F4:1B:B0:7C
            root-bridge: yes
         root-bridge-id: 0x1000.B8:69:F4:1B:B0:7C
         root-path-cost: 0
              root-port: none
             port-count: 2
  designated-port-count: 2
           fast-forward: no
             mlag-state: connected
       mlag-active-role: primary

# On Peer2
/interface bridge monitor [find name=bridge1]

Expected output:

                  state: enabled
    current-mac-address: B8:69:F4:1B:B0:7C
              bridge-id: 0x1000.B8:69:F4:1B:B0:7C
            root-bridge: yes
         root-bridge-id: 0x1000.B8:69:F4:1B:B0:7C
         root-path-cost: 0
              root-port: none
             port-count: 2
  designated-port-count: 1
           fast-forward: no
             mlag-state: connected
       mlag-active-role: secondary

Check client LACP status to confirm both interfaces are active:

# On Client
/interface bonding monitor bond1

Expected output:

                    mode: 802.3ad
            active-ports: sfp-sfpplus1,sfp-sfpplus2
          inactive-ports:
          lacp-system-id: 74:4D:28:7B:7F:96
    lacp-system-priority: 65535
  lacp-partner-system-id: B8:69:F4:1B:B0:7D

MLAG Bridge Settings

The following settings control MLAG behavior on bridge interfaces:

Property	Description
mlag-heartbeat	Time between heartbeat messages (1s-10s, default: 5s). Set to none to disable.
mlag-peer-port	Interface used for ICCP peer communication. Can be Ethernet or bond.
mlag-priority	Priority for primary node election (0-128, lower is preferred, default: 128).
mlag-state	Current MLAG state: connected, connecting, or disabled.
mlag-active-role	Current role: primary or secondary.

MLAG Bond Settings

Property	Description
mlag-id	Unique identifier shared between peers (0-4294967295). Must match on both MLAG nodes for the client to see a single LAG.

STP Considerations

MLAG supports STP, RSTP, and MSTP protocols. Both MLAG nodes must use identical STP priority and configuration for dual-connected bridge ports. When MLAG bridges become the STP root, both devices show as root bridges in the bridge monitor output.

For ports connected to clients where no other RSTP/MSTP bridges exist, configure edge=yes on both MLAG nodes to enable rapid forwarding state and minimize packet loss during failover:

/interface bridge port set [find interface=client-bond] edge=yes

Limitations

MLAG has several compatibility restrictions to be aware of before deployment:

• L3 Hardware Offloading: MLAG is incompatible with Layer 3 hardware offloading. Disable L3 hardware offloading when using MLAG.
• MVRP: Multiple VLAN Registration Protocol (MVRP) is incompatible with MLAG. Registered VLANs on dual-connected bonds do not synchronize between MLAG nodes.
• Peer Port Requirements: The peer port must be included as a tagged member in all VLANs that span both MLAG nodes. Failing to do so breaks VLAN traffic across the peer link.
• Peer Link Redundancy: For production deployments, consider using a bond interface (LACP) for the peer port rather than a single interface. This prevents a single interface failure from splitting the MLAG cluster.