Skip to content
MikroTik RouterOS Docs

MLPPP

MLPPP

Section titled “MLPPP”

Multilink PPP (MLPPP) enables combining multiple physical PPP links into a single logical interface, providing increased bandwidth through aggregation and link redundancy through failover. This capability is particularly valuable for scenarios requiring higher throughput than single links can provide, such as aggregating multiple DSL lines or bonding cellular modems.

MLPPP works by fragmenting packets across multiple physical links and reassembling them at the destination. This load balancing increases effective bandwidth while maintaining packet ordering. If any link fails, traffic automatically redistributes across remaining links without session interruption.

Summary

Section titled “Summary”

MLPPP operates at the PPP layer, requiring no special support from underlying networks. Each physical interface runs standard PPP (or PPPoE), while the MLPPP interface bundles them together. The protocol handles packet fragmentation, sequencing, and reassembly transparently to higher layers.

Two deployment modes exist: single-link MLPPP and multi-link MLPPP. Single-link mode enables MRRU (Maximum Reconstructed Receive Unit) for full-sized packet transmission across a PPP link. Multi-link mode aggregates bandwidth across multiple links for improved throughput.

Key benefits include:

  • Bandwidth Aggregation: Combine multiple links for higher throughput
  • Load Balancing: Distribute traffic across all active links
  • Failover: Automatic redistribution when links fail
  • MRRU Support: Transmit full-sized Ethernet frames over PPP
Section titled “Single-Link MLPPP”

Single-link MLPPP enables MRRU support on a single PPP connection. This configuration is used when full-sized packets must traverse the PPP link without being reduced to the standard PPP MTU.

Section titled “When to Use Single-Link MLPPP”

Enable single-link MLPPP when:

  • PPP traffic must carry packets larger than the standard PPP MTU
  • Encapsulation overhead would otherwise force fragmentation
  • Both endpoints support MRRU and must preserve larger payload sizes end-to-end

Configuration

Section titled “Configuration”

Configure single-link MLPPP on a PPPoE client:

/interface pppoe-client add name=pppoe-out1 interface=ether2 \
    service-name=isp user=username password=secret \
    mrru=1600

The mrru=1600 parameter enables single-link Multilink PPP, allowing packets up to 1600 bytes to be transmitted without fragmentation at the PPP layer.

Verify the configuration:

/interface pppoe-client monitor pppoe-out1

The output shows MRRU status:

           status: connected
         mrru: 1600
Section titled “Multi-Link MLPPP”

Multi-link MLPPP combines multiple physical links into a single logical interface with aggregated bandwidth. This requires multiple PPP connections to the same provider or endpoint.

Requirements

Section titled “Requirements”

Multi-link MLPPP requires:

  • Multiple physical interfaces (separate DSL lines, cellular modems, etc.)
  • ISP or peer supporting MLPPP on each link
  • Links must have similar latency for optimal performance

PPPoE Limitation

Section titled “PPPoE Limitation”

RouterOS 7.15.3 does not allow PPPoE client interfaces to be used as bonding slaves. A configuration such as slaves=pppoe-1,pppoe-2,pppoe-3 fails because /interface bonding only accepts supported slave interface types such as Ethernet ports.

For PPPoE deployments, use the single-link MLPPP configuration with mrru shown above when you need larger PPP payloads on one session. If you need to combine multiple access circuits, use a design built around supported lower-layer interfaces rather than bonding PPPoE clients.

Design Note

Section titled “Design Note”

Older examples sometimes describe multi-link MLPPP as if PPPoE client interfaces could be placed into /interface bonding with mode=balance-rr. That is not supported in RouterOS 7.15.3. PPPoE clients are logical PPP interfaces, not valid bonding slaves.

If you need multiple access circuits, aggregate them at a layer where the underlying interface type is supported by RouterOS, then run PPP or PPPoE over that supported transport as appropriate.

Verification

Section titled “Verification”

Verify single-link MLPPP by monitoring the PPPoE client directly:

/interface pppoe-client monitor pppoe-out1

Confirm that mrru is present in the monitor output and that the session is in the connected state.

Bridging Limitations

Section titled “Bridging Limitations”

RouterOS can use MLPPP to carry larger PPP payloads, but PPPoE interfaces are not valid bridge ports. You cannot add a PPPoE client interface to /interface bridge port, and you cannot use a PPPoE interface as a tagged port in /interface bridge vlan.

Do not use commands like these with MLPPP over PPPoE:

/interface bridge port add bridge=bridge1 interface=pppoe-out1
/interface bridge vlan add bridge=bridge1 tagged=pppoe-out1 vlan-ids=10,20,30

RouterOS rejects both configurations because pppoe-out1 is a PPP logical interface, not an Ethernet bridge port.

For MLPPP over PPPoE, treat the PPPoE interface as a routed interface. If you need Layer 2 extension between sites, use a RouterOS feature designed for Ethernet transport rather than adding the PPPoE interface to a bridge.

Troubleshooting

Section titled “Troubleshooting”

Common MLPPP issues and solutions.

Poor Performance

Section titled “Poor Performance”

Multi-link MLPPP requires links with similar characteristics. If links have significantly different latency, performance degrades.

Solution: Use links with similar bandwidth and latency. Consider single-link MLPPP with MRRU if bonding multiple diverse links.

Section titled “Link Failures”

When one link fails, traffic redistributes. Brief interruptions may occur during redistribution.

Solution: Monitor the PPPoE client state directly with /interface pppoe-client monitor, or monitor the supported lower-layer interfaces used to transport the PPP session.

MRRU Not Working

Section titled “MRRU Not Working”

If MRRU is enabled but large packets still fail:

Solution:

  • Verify MRRU is set on both endpoints
  • Check intermediate network devices don’t fragment oversized packets
  • Ensure firewall allows larger packet sizes

Fragmentation Issues

Section titled “Fragmentation Issues”

Out-of-order packets can cause application problems:

Solution: MLPPP includes sequencing information to reorder packets. Ensure no middleboxes are reassembling packets incorrectly.

Use Cases

Section titled “Use Cases”

MLPPP serves several practical scenarios:

ISP Aggregation: Combine multiple ISP connections for higher bandwidth or redundancy. Useful for businesses needing more bandwidth than single ISP provides.

Cellular Bonding: Aggregate multiple cellular modems for improved throughput. Common in mobile deployments or remote locations.

DSL Bonding: Combine multiple DSL lines from the same provider. Many providers support DSL bonding for business customers.

Large-Payload PPP Links: Use single-link MLPPP with MRRU when a PPP path must carry larger payloads without reducing end-to-end MTU.

See Also

Section titled “See Also”