BPI-R4: Is active-backup bonding supported between eth2 and DSA ports?

Banana Pi Router design
1

Hi,

I’m running Ubuntu 24.04 on a BPI-R4, using Netplan with systemd-networkd.

The installed kernel is:

Linux bpi-router 6.11.0-bpi-r4+ #6 SMP Mon Nov 17 20:42:54 CET 2025 aarch64

I would like to configure an active-backup bond using these interfaces:

eth2 — primary SFP+ interface, using mtk_soc_eth lan1 — backup DSA port lan2 — backup DSA port

Several VLAN interfaces would be created on top of the bond. The goal is to keep one stable set of VLAN gateway addresses and routes while automatically switching the physical LAN connection if the active switch or link fails.

However, the installed kernel does not include bonding support:

# CONFIG_BONDING is not set
modinfo: ERROR: Module bonding not found

Is active-backup bonding expected to work with this combination of eth2 and the MT7988 DSA user ports?

If it is supported, would enabling CONFIG_BONDING=y or CONFIG_BONDING=m be sufficient, or would additional kernel patches or configuration be required?

Was bonding omitted from the BPI-R4 defconfig simply because it is not commonly needed, or is there a known compatibility issue with this hardware?

2

How have you installed this ubuntu? It does not look like bpi image not mine and also not official ubuntu kernel.

You have to get the kernel-source to update these setting(s).

3

The kernel was built on my main x86_64 machine from the 6.11-main branch after cloning the BPI-Router-Linux repository.

However, it looks like I used the wrong configuration: I just noticed that $board in build.conf was set to bpi-r2 .

I have now pulled the current repository, set board=bpi-r4 in build.conf , and ran:

git checkout 6.18-main
./build.sh importconfig
grep BONDING ../build/.config

This still gives me:

# CONFIG_BONDING is not set

So my question remains: Is bonding expected to work on the BPI-R4 if I enable CONFIG_BONDING , particularly with the MT7988 DSA switch ports?

4

I have just not enabled it to serve a very basic default config where every user can add what he needs and to keep compiletime and upload size as small as possible.

Have not tested it,just try it out.i expect it to be working as imho no specific hardware support is needed for it (should be done at core network layer,not sure if there is any hw-acceleration possible).

Why do you use 6.11? 6.12 (and 6.18 too) is a lts kernel i update from time to time.

Way is correct. Change build.conf then run build.sh with importconfig and then config (to select bonding).then build kernel without param and install it. Is the 6.11 also from my image? Looks different in name.

5

I don’t know what possessed me back in November 2025 when I chose 6.11. :slight_smile:

I’ve switched to 6.18 now, which I hope will be a better choice.

Thanks for the help! I’ll enable bonding and give it a try.

6

Just a quick follow-up: you were right, bonding works fine on the BPI-R4 with the 6.18 kernel.

I built 6.18.41 with CONFIG_BONDING=m and now have an active-backup bond running with ARP monitoring. eth2 (10G) is the preferred link, with lan1 and lan2 as 1G backups:

cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v6.18.41-bpi-r4-main

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: eth2 (primary_reselect always)
Currently Active Slave: eth2
MII Status: up
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0
Peer Notification Delay (ms): 0
ARP Polling Interval (ms): 1000
ARP Missed Max: 2
ARP IP target/s (n.n.n.n form): 192.168.xxx.xx1, 192.168.xxx.xx2, 192.168.xxx.xx3
NS IPv6 target/s (xx::xx form):

Slave Interface: lan1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 26
Permanent HW addr: 52:25:d4:xx:xx:xx
Slave queue ID: 0

Slave Interface: lan2
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 26
Permanent HW addr: 52:25:d4:xx:xx:xx
Slave queue ID: 0

Slave Interface: eth2
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 3
Permanent HW addr: e2:16:80:xx:xx:xx
Slave queue ID: 0

So no BPI-R4-specific bonding issue at all. The move to 6.18 and enabling CONFIG_BONDING did the job.

Thanks a bunch!

7

Small follow-up: I had to make one important change to get the bonding setup working reliably on the BPI-R4.

Using the default fail_over_mac=none, the bonding driver programmed the bond MAC onto eth2. With ARP monitoring enabled, the 10G slave then kept being marked down/up every few seconds even though physical carrier stayed LOWER_UP and ARP replies were visible on the wire.

Changing Netplan to:

parameters:
  mode: active-backup
  fail-over-mac-policy: active
  primary: eth2
  arp-interval: 1000
  arp-ip-targets:
    - 192.168.x.x
    - 192.168.x.x
    - 192.168.x.x
  arp-validate: active
  arp-all-targets: any

fixed the continuous flapping.

After reboot the bond now comes up as:

Bonding Mode: fault-tolerance (active-backup) (fail_over_mac active)
Primary Slave: eth2
Currently Active Slave: eth2
ARP Polling Interval (ms): 1000

So with fail_over_mac=active, each slave keeps its permanent MAC and the bond MAC follows the currently active slave.

That means a real failover also changes the router-facing MAC. My current expectation is roughly 1–3 seconds of client-visible interruption while the ARP monitor detects the failed path and neighbors/switches relearn the new MAC, but I still want to measure the actual interruption with a continuous ping during a real switch reboot/unplug test.

The Netplan setup is also much cleaner now, since all VLANs simply sit on bond0 instead of being duplicated across eth2, lan1, and lan2.