I would like to propose an enhancement to the current RouterOS Container system that could significantly improve flexibility for advanced networking use cases, especially in multi-WAN and edge-computing environments.
Current Limitation:
In RouterOS containers, access is currently limited to:
veth interfaces
selected /dev devices
system-exposed virtual resources
However, there is no ability to assign or access physical Ethernet interfaces (e.g. ether1, ether2, etc.) directly or in a controlled manner from within a container.
Proposed Feature:
Introduce an optional and strictly controlled feature for:
"Controlled Interface Passthrough for Containers"
This would allow users to assign a physical interface to a container in a safe, abstracted way, while still keeping RouterOS as the hardware and routing authority.
If needed, I would be happy to provide deeper technical use cases or implementation ideas.
Please do, because a perceived need to bind a container to a single network interface is usually (not always) indicative of a failure at the routing layer, and here you are on the forum of the Router…OS.
What precisely can you do with this that you cannot achieve even with proper configuration of the routing?
Don’t recapitulate your list of use cases. Give specifics.
For instance, binding a physical interface and a VETH into a 2-port bridge likely solves some of your use cases.
I have not read the OP in depth. But do you have reference of any OS having such a "direct hardware network port" access? I have never come across such a thing in Linux environments.
Thanks for the feedback. I think my proposal might have been misunderstood.
I am not requesting raw hardware access or bypassing RouterOS control over physical interfaces.
My intention is more specific: I want a controlled abstraction layer where a container can:
Observe WAN interface metrics (latency, loss, bandwidth, state)
Influence routing decisions (distance, policy routing, failover rules)
Optionally bind traffic policies to a specific WAN interface
without directly accessing or owning the physical NIC.
In other words, RouterOS remains the single authority over ether interfaces, FastPath, and firewalling. The container acts as an intelligence / decision engine, not a hardware controller.
This is similar to a “network control-plane plugin” rather than device passthrough.
The reason I raised this idea is to simplify advanced multi-WAN automation without breaking RouterOS architecture.
I agree that raw NIC passthrough would be dangerous and unnecessary.
Yes, I definitely created a container that works with MikroTik router settings. Yes, I definitely created a container that configures the MikroTik router settings.
To me "direct etherX passthrough" be more useful than the odd split proposed here...
I'm not sure I'd call raw NIC passthrough "dangerous", per se. Like more things in RouterOS... it's how you use things that makes them "safe" or "unsafe". I have not tested container passthrough, but I suspect it already allow USB ethernet dongles to passthrough, so I don't see any significant change in threat profile from internal ethernet.
For the loose use case described here... Native API get a container direct stream of any RouterOS value that needs to be obtained (e.g. /interface/ethernet/listen). REST API also work, but you run into the need to poll since REST API times out. And newer /app support secret variable that allow providing the need RouterOS account to container, so from the RouterOS config side that credentials are not exposed in plain export..
On these things:
For the more "orchestration" stuff, RouterOS does support OpenFlow that allow more standard approached to "control plane plugin". And there is also NetFlow that support that can get a container the flows, if you want to have container update RouterOS config based on traffic things.
Exactly! My ultimate goal with this "Controlled Passthrough" is to move away from legacy, static routing methods.
By exposing a lightweight virtualized representation of the interfaces into a minimal Linux container, we can bypass the limitations of standard iptables and RouterOS PCC. Instead, we can implement eBPF/XDP or advanced iproute2 logic directly within the container to achieve:
True SD-WAN Engine: Real-time, application-aware load balancing based on live, sub-second link quality (Latency, Jitter, Packet Loss), which is impossible with blind PCC.
Dynamic Weights: Auto-adjusting traffic distribution dynamically as line capacities (like Starlink) fluctuate, with near-zero CPU overhead.
Sub-Second Failover: Instantly rerouting sensitive sessions (Gaming/VoIP) before connections drop.
This approach keeps RouterOS as the absolute hardware and firewall authority, while using the container as a hyper-fast, intelligent control plane engine!
