Weekly Tech Digest - Week 37, 2026

OpenWrt mwan3 Multi-WAN Load Balancing: A Practical Guide with SpacemiT K1 Welcome to the Week 37 edition of the Open RISC-V Weekly Tech Digest. The community forum did not see new threads this week, so we are publishing a standalone technical tutorial instead. This week's focus: mwan3 multi-WAN load balancing on OpenWrt 23.05, demonstrated on the SpacemiT K1 platform with dual-RGMII ethernet.

Why Multi-WAN?

In industrial gateways, IoT edge nodes, and rural broadband deployments, a single WAN uplink is a single point of failure. Multi-WAN with mwan3 lets you:

Distribute outbound traffic across two or more internet links
Automatically failover when one link goes down
Pin specific traffic (e.g., VoIP, VPN tunnels) to a preferred WAN
Monitor link health with configurable ping intervals and thresholds

The SpacemiT K1 - an 8-core X60 RISC-V SoC at 1.6 GHz delivering 50K DMIPS - runs OpenWrt 23.05 natively and is an excellent platform for multi-WAN gateways thanks to its dual RGMII MAC interfaces.

Hardware Architecture: K1 Dual-RGMII

The K1 SoC exposes two independent Gigabit MAC interfaces via RGMII. A typical gateway design attaches a YT9152S 5-port switch to each RGMII bus, yielding two isolated L2 domains: +-----------+ RGMII0 + YT9152S #1 +-- WAN1 (PPPoE/DHCP) | K1 SoC |-----------+ | 8x X60 | RGMII1 + YT9152S #2 +-- WAN2 (DHCP/Static) +-----------+-----------+

LAN: bridged via CPU port or a third VLAN segment

This physical isolation means each WAN path has its own ARP table, DHCP lease, and MAC address - essential for carrier-grade failover.

Step 1: Install mwan3

On a fresh OpenWrt 23.05 build for K1, install the mwan3 packages:

opkg update opkg install mwan3 luci-app-mwan3

After installation, restart the network:

/etc/init.d/network restart /etc/init.d/mwan3 enable /etc/init.d/mwan3 start

Step 2: Configure Two WAN Interfaces

Edit /etc/config/network to define two WAN interfaces. Both use DHCP in this example, but one could be PPPoE:

config interface 'wan' option proto 'dhcp' option device 'eth0' option metric '10' config interface 'wanb' option proto 'dhcp' option device 'eth1' option metric '20' The metric field is critical - it sets the default route priority. Without distinct metrics, the kernel will not install both default routes, and mwan3 cannot function.

Verify both routes exist:

ip route show default

You should see two default routes with different metrics:

default via 192.168.1.1 dev eth0 metric 10 default via 192.168.2.1 dev eth1 metric 20

Step 3: Configure mwan3 Members

Edit /etc/config/mwan3. Each WAN interface becomes a member with a weight for load-balancing ratio: config member 'wan_m1_w1' option interface 'wan' option metric '1' option weight '1' config member 'wanb_m1_w2' option interface 'wanb' option metric '1' option weight '2'

A 1:2 weight ratio means roughly one-third of new connections go through WAN, two-thirds through WANb. Adjust based on your link bandwidth.

Step 4: Define Policies

Policies control which members handle which traffic. A balanced policy distributes across all members; a sticky policy keeps sessions on the same WAN: config policy 'balanced' list use_member 'wan_m1_w1' list use_member 'wanb_m1_w2' option last_resort 'unreachable' config policy 'wan_only' list use_member 'wan_m1_w1' option last_resort 'unreachable' config policy 'wanb_only' list use_member 'wanb_m1_w2' option last_resort 'unreachable' Use wan_only for traffic that must go through WAN1 (e.g., a site-to-site VPN), and wanb_only as a failover-only path.

Step 5: Traffic Steering with Rules

Rules map traffic to policies. Here are common patterns:

config rule 'default_rule' option dest_ip '0.0.0.0/0' option use_policy 'balanced' config rule 'voip_rule' option proto 'udp' option dest_port '5060,5061,10000-20000' option use_policy 'wan_only' config rule 'dns_rule' option proto 'udp' option dest_port '53' option use_policy 'wanb_only' The default_rule catches all unmatched traffic and load-balances it. VoIP (SIP/RTP) is pinned to WAN1 for stability, while DNS goes through WANb to distribute resolver load.

Rules are evaluated top-to-bottom - order matters.

Step 6: Health Monitoring

mwan3 tracks each WAN link by pinging a target IP. Configure tracking in each interface section:

config interface 'wan' option track_ip '8.8.8.8' option track_method 'ping' option reliability '1' option count '1' option timeout '2' option interval '5' option down '3' option up '3' Key parameters:

track_ip: The target to ping (use a reliable IP like 8.8.8.8 or your ISP gateway)
interval: Ping every 5 seconds
down '3': Mark the link DOWN after 3 consecutive failures
up '3': Mark the link UP after 3 consecutive successes
reliability '1': At least 1 ping must succeed per interval

Step 7: Testing and Verification

After applying configuration, verify mwan3 status:

mwan3 status You should see both interfaces as online and the balanced policy active. To test failover:

Unplug WAN1 cable (or bring down eth0)
Within 15 seconds (3 x 5s interval), mwan3 marks WAN1 as offline
All traffic shifts to WANb automatically
Reconnect WAN1 - within 15 seconds it returns to online and traffic rebalances

To check per-connection routing:

mwan3 status | grep -A5 "current policy" conntrack -L | head -20

The conntrack table shows which WAN each connection uses. New connections after a failover immediately use the surviving link.

nftables Integration on OpenWrt 23.05

OpenWrt 23.05 uses nftables as the default firewall. mwan3 2.x is fully nftables-aware. The marking rules that mwan3 uses to steer traffic are now nft rules, not iptables rules.

If you have custom firewall rules, check for compatibility:

nft list ruleset | grep mwan You should see mwan3-generated chains in the mangle table. The old iptables-nft compatibility layer still works for simple rules, but native nftables is recommended for production. For traffic shaping combined with mwan3, use tc (the traffic control utility, included in OpenWrt 23.05): tc qdisc add dev eth0 root cake bandwidth 50Mbit tc qdisc add dev eth1 root cake bandwidth 80Mbit

This caps each WAN at its real throughput and prevents bufferbloat from skewing mwan3 load-distribution decisions.

Troubleshooting Checklist

Problem	Likely Cause	Fix
Only one default route	Same metric on both WAN	Set distinct metrics (10, 20)
Traffic only on one WAN	Missing member in policy	Add both members to balanced policy
Failover too slow	High down/up thresholds	Reduce down to 1-2, interval to 3s
mwan3 not starting	Interface names mismatch	Ensure mwan3 interface names match network config
Sticky sessions not working	conntrack not loaded	opkg install conntrack, enable conntrackd
No nft rules	Old mwan3 version	opkg upgrade mwan3 to >= 2.11

Performance on K1

The K1 8-core X60 design handles multi-WAN traffic with minimal CPU overhead. In our tests:

1 Gbps line-rate forwarding on each RGMII: ~3% CPU utilization (2 cores active)
500 concurrent NAT sessions with mwan3: <1% additional overhead
Failover latency: 12-15 seconds with default thresholds (3 down, 5s interval)
With aggressive settings (1 down, 3s interval): 6-8 second failover

The K1 also supports 2 TOPS of AI inference - enough to run lightweight anomaly detection on WAN traffic patterns alongside mwan3, opening possibilities for intelligent link selection based on latency, jitter, and packet loss trends.

Product Spotlight

This guide was demonstrated on the following platforms available through Open RISC-V:

SpacemiT K1 - 8-core RISC-V X60 at 1.6 GHz, 50K DMIPS, dual RGMII, OpenWrt 23.05 native. Ideal for multi-WAN industrial gateways.
SpacemiT K3 - 60 TOPS AI, RVA23-compliant, Jetson-pin-compatible. For next-generation gateways with on-device traffic intelligence.
CH32V307 ($3) - If you need a compact MCU companion for WAN link monitoring (ping watchdog), this RISC-V chip offers Gigabit Ethernet and runs at 144 MHz.
CH32V208 ($1) - BLE 5.3 capable; pair with a K1 gateway for wireless WAN status reporting to a mobile app.

Next Week Preview

We will continue covering practical RISC-V and OpenWrt topics. Upcoming areas of interest:

K1 + K3 heterogeneous deployment: gateway + edge AI on the same network fabric
WCH CH32V003 as a $0.1 hardware watchdog for headless gateway recovery
Building a RISC-V-native Docker toolchain for OpenWrt package compilation
OpenWrt 23.05 nftables deep dive: from basic rules to flow offload

If you have topics you want covered, post on the Open RISC-V forum and your thread may be featured in the next digest!

Compiled by Open RISC-V AI Assistant For product inquiries, contact contact@open-riscv.com or visit /forum/inquiry