Is https://hub.docker.com/r/frrouting/frr supported?
I was going to ask the same thing. My guess is that containers aren’t allowed to make changes to the RouterOS routing table. This is based on the fact that one has to manually create interfaces for the containers. A workaround to this is to simply bridge physical interfaces with container interfaces. Not optimal as it’s going to have to copy each and every packet from one interface to the other.
Anyone else try this? If not, I might give it a go this week.
Here is my config for the nextdns client for use on CHR. The nextdns client does have builds for ARM, so for those interested it would probably work there as well.
Dockerfile:
FROM debian:bullseye-slim
RUN apt-get update && apt-get install -y apt-transport-https curl && \
curl -o /usr/share/keyrings/nextdns.gpg https://repo.nextdns.io/nextdns.gpg && \
echo "deb [signed-by=/usr/share/keyrings/nextdns.gpg] https://repo.nextdns.io/deb stable main" | tee /etc/apt/sources.list.d/nextdns.list && \
apt-get update && apt-get install -y nextdns
EXPOSE 53/tcp 53/udp
CMD /usr/bin/nextdns run ${NEXTDNS_ARGUMENTS} -config ${NEXTDNS_ID}
Commands on CHR:
/interface bridge
add name=docker
/ip address
add address=172.17.0.1/16 interface=docker network=172.17.0.0
/interface veth
add address=172.17.0.2/16 gateway=172.17.0.1 name=veth1
/interface bridge port
add bridge=docker interface=veth1
/container envs
add list=nextdns name=NEXTDNS_ARGUMENTS value="-listen :53 -cache-max-age 0s -\
report-client-info=true -detect-captive-portals=false -control /var/run/ne\
xtdns.sock -timeout 5s -max-inflight-requests 256 -auto-activate=false -lo\
g-queries=false -cache-size 10MB -max-ttl 0s -discovery-dns -use-hosts=false"
add list=nextdns name=NEXTDNS_ID value=abc123
/container
add dns=192.168.20.5,192.168.20.10 envlist=nextdns file=nextdns-09132021v1.tar \
interface=veth1 logging=yes
/ip firewall nat
add action=masquerade chain=srcnat src-address=172.17.0.0/16
add action=dst-nat chain=dstnat dst-address=192.168.30.20 dst-port=53 \
protocol=tcp to-addresses=172.17.0.2 to-ports=53
add action=dst-nat chain=dstnat dst-address=192.168.30.20 dst-port=53 \
protocol=udp to-addresses=172.17.0.2 to-ports=53
/container start 0
DAMN IT! Me too... I just bricked my RB4011. I uploaded a .tar image too big. Container status never changed to "stopped" so I continued doing other things. When I restarted the router... silence. I'll try to unbrick.
.
… guess the most un-thorny way would be installing qemu …
running an open-wrt mips guest
installing docker-support
building a container
and copy it over to your target system
.
… if you’re done … copy it to a cloud-drive …
… and I give it a check
.
(please:
- rancid-with-git;
- freeradius 802.1x-proxy
… and a - full-featured frad-ldap-kerberos-AD-policy-daemon : )
.
Because it supports protocols that RouterOS doesn’t?
As someone else alluded to - it runs contained so it won’t affect the RouterOS routing table directly, but you could use a diff protocol to talk between your router and container, then the container use its different route protocols to build up its own route table and share those routes to RouterOS. Very hacky though.
Some issues:
Hap AC^2
Installed iperf3 docker container per
http://forum.mikrotik.com/t/iperf3-server-on-routeros-arm/151747/1
Good when its working.
Doesn’t remember the container setup properly on /system/ reboot.
Before Reboot
/container
add envlist=iperf file=disk1/docker/iperf.tar hostname=iperf interface=veth1 logging=yes
root-dir=disk1/docker/iperf-r
After Reboot
/container
add envlist=iperf file=disk1/docker/iperf.tar root-dir=disk1/docker/iperf-r
Often gets into a mode (after running an iperf3 test) where looks to be using 1 core fully, and then router reboots.
and usually (eventually) deletes the root-dir folder.
** Also needs a disabled=yes option **
so on reboot it only attempts to start not disabled containers
** Actually perhaps a start mode setting like a windows service might be good.
automatic, delayed, manual, disabled
**
I wonder what’s the point? Running container with routing engine … on a router?
Why not take a decent RPI (more RAM, user can choose decently sized storage) and run FRR there? Pair RPI with a decent managed switch and you have a winning combination if you really need all those routing gems not available in ROS.
Because I really love the Mikrotik hardware, but profoundly hate RouterOS.
If one could easily run Debian and frr on Mikrotik hardware, this would be insane!
Unfortunately I don’t think that will ever happen…
The idea to use openwrt the container build process is interesting! I looked into it and unfortunately it’s going to be more complicated than that because it seems it relies on upstream base images, and there are no prebuild base images for mips big endian. All seem to be mipsle, and outdated (though that’s not necessarily a problem.) For example Debian mips was last available for Buster (Debian 10.) I can probably use the Debian distro build scripts with some modifications to create a mipsbe image to be used as a base container for the Mikrotik. I looked into many distributions (Debian, Ubuntu, Gentoo, Fedora) and haven’t found anything ready in mipsbe and Debian seems the most ready to work with. If anyone knows of a base image built for mips be, or a build process ready to go to build one from another distro that could be adapted, please let me know. Otherwise I’ll probably do what I just described to try to make a mipsbe base image build from Debian Buster.
It already happened: https://www.earth.li/~noodles/blog/2020/09/rb3011-mainline.html
normis - will there be pull support in the future? Im have tested a number of containers since the 7.1rc3 release and really look forward to the feature, just wish it had pull support. 
about time someone tried to use nextdns. is it working well? sending client device names etc?
It works just like the nextdns client that I run on some raspberrypis - no problems at all.
Adding docker to RouterOS opens up some interesting possibilities that I am wondering if Mikrotik are going to explore. Namely allowing a docker to get deeper into the workings of the RouterOS configuration (with appropriate permission of course). The low level packet manipulation of RouterOS is great but some of it’s higher level features, like DHCP (e.g. adding traffic queues via radius) are missing features and if nothing else are complex to setup.
It would be awesome to optionally be able to offload these higher level features to docker where it would for example handle the DHCP requests and make the appropriate RouterOS config changes to suit. Others have mentioned running FRR, which essentially is also a high level application - having the ability of a docker container to add and remove dynamic routes from the routing table.
Because docker could run people’s own software (or there may even be a place for a commercial market), much more complex and sophisticated things could done on the Mikrotik’s without them having to decide if a feature is worth implementing and supporting.
On further thinking this could be mostly done with the docker talking through the API. However there would be a problem with figuring out the current state. Dynamic config entries are automatically wiped when ROS restarts whereas config entries created via the API would not. It would be hard for a docker to figure out it’s state given there is no search pattern match functionality in the API (so you couldn’t match on say a comment hashtag). It would be great if you could create dynamic entries through the API (or ones that could be tagged in a way that the docker could start by saying “give me a list of all the configs I created before”).
While the matching capabilities of the API are quite limited, in many cases you can match what is possible in the query, then retrieve the entire matched list and do the remainder of the matching in the client.
I have made several API programs (on external systems so far) that work this way, and it should work fine unless you are manipulating very long lists and want to see only a very small part of it.
For example, for some purpose I want to list open IPsec connections through a NAT router. In the API I query I query /ip/firewall/connection/print and there I match on protocol=udp and seen-reply=true, retrieve that entire list and in the client I match dst-address~“:4500$”.
Of course this means I am potentially retrieving a long list, but at least I cut out the tcp connections before transferring it (about 3/4 in our router). It handles lists of thousands of items just fine, but of course with hundreds of thousands of items that could be different.
I’ve been using the mips_24kc-21.02.0 tag on https://hub.docker.com/r/openwrtorg/rootfs . However it appears to be a dead end at the moment as it looks like the mips kernel on the current release is not built with proper support for containers (http://forum.mikrotik.com/t/7-1rc3-containers-broken-on-mipsbe/151855/1)
I run AdGuard Home on a Windows 10 box, but there is a docker image available.
How would an RB4011 fair with AdGuard Home docker installed, in docker, with OISD (8.7MB) block list?
Would this be possible?
How it resource-management done on the way the docker/containerisation is implemented ?
What amount of resources (% cpu, i/o , mem) are maximum allowed to be consumed or is there no protection again resource-hoggers?
Because in principle, the routerOS core tasks must not be impacted if some container runs into issues, starts looping forever etc,etc.