Isn’t that just “architectures supported by dockerhub”?
When you compile your own binaries, you could use any architecture, of course easiest is to use the architectures supported by gcc.
Using a couple of simple commands (that take quite some time to run and use up quite some diskspace) you can create a gcc cross-compilation environment on your Linux PC, I have done that several times in the past to compile programs for unusual architectures.
Thank you. Will check again. Maybe some rule added it.
No, it’s “architectures supported by Docker,” period:
$ docker buildx ls
...linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
There is no MIPS toolchain for Docker for a number of reasons:
- There is no MIPS backend for the Go compiler that Docker is based on.
- The Linux kernel tech underpinning Docker requires certain CPU virtualization features. It may be that the small embedded SoCs MikroTik uses wouldn’t support Docker even if the prior problem were addressed.
- Small embedded SoCs will not have the resources to run most containers. The nature of Docker is to pack separate copies of core libraries like libc around inside each container. People brag about getting bare-bones containers down to 5 MiB or so, but that’s a huge slice of a 16 MiB device. Add an actual application atop that, plus storage for the application’s use, and you might not have space even to store it in flash, much less get it to boot.
Ok… I guess my assumptions about what Docker really does were wrong (I only have experience with Docker images running within a amd64 system). I thought it was process-based only.
However, the issue of storage size is completely orthogonal to processor architecture. MikroTik makes (far too many) 16MB devices with ARM architecture, but also have made a lot of 128MB MIPSBE and TILE devices.
Isn’t that just “architectures supported by dockerhub”?
When you compile your own binaries, you could use any architecture, of course easiest is to use the architectures supported by gcc.
Yes. Dockerd and associated utilities can be installed and/or built anywhere a recent enough working Linux is available.
But not having access to prebuilt imaged from dockerhub requires local cross compiling, raising the bar substantially for the average user.
Especially cross compiling for Tilera is not easy, regarding support for it was dropped from “official” Linux, is limited in gcc and not existing clang.
Most users will expect dockerhub support if they read “docker support”.
Docker containers are stripped-down native VMs. (e.g. ARM on ARM, rather than x86 on ARM or similar.) The kernel and all the infrastructure needed to support booting and running it — NIC firmware, filesystems, init system, etc. — are external to the container, but inside, it’s functionally a separate Linux box. Anything the container needs that can’t be gotten at via the Linux kernel ABI must be included inside the container.
The single most common way to build a Docker container is to start with Alpine Linux (the 5 MiB distro I spoke of) and then use its package manager to install all the stuff you want for the container, then configure it and pack it up.
While it is possible to have a single executable inside the container and nothing else, it generally requires static linkage. Static linkage affords certain types of optimization you don’t get with dynamic linkage, but some bloat is unavoidable.
the issue of storage size is completely orthogonal to processor architecture.
Sure.
It’s also an irony that the RouterOS devices with SD cards and USB ports for fixing the storage problem tend to be the non-ARM devices. There are no ARM switches in the current lineup with USB, and few routers.
Still, this’ll sort itself out. I fully expect we’ll get beefier ARM routers and switches meant to run containers, eventually.
Me, I’m waiting for an ARM-based hEX PoE S+. Seriously, MikroTik: put that one out, and I’ll have my order in the same day.
This ospf warning is what I see in the router logs again and again, multiple devices.
instance { version: 2 vrf: 0 router-id: 10.255.255.50 } area { 0.0.0.0 } interface { p2p ToTallowbox 10.10.195.1 } neighbor { router-id: 10.255.255.51 state: Full } received wrong LS Ack for router 10.255.255.18 10.255.255.18 0x8000049d expected 0x8000049e
V2 routing:
6 D address=10.10.195.1%ToTallowbox area=backbone-v2 state=ptp network-type=ptp
cost=10 retransmit-interval=5s transmit-delay=1s hello-interval=10s
dead-interval=40s
Followed by the link collapsing as OSPF reestablishes the route.
Link is over a very solid Ubiquiti Airfiber between RB100AH and MT switch and from there to the various MT routers on this tower. Worked great on 6.48. None of these warnings.
From what I see it looks like anything running 6.x on a 7.x network generates problems in OSPF.
Today I updated my CRS326-24G-2S+ to 7.3.1. Something wrong?
Info from site:
Info from WinBox:
Yes, http://forum.mikrotik.com/t/v7-4beta-testing-is-released/158543/1
Would be interesting to see if CRS326 is fixed too, not just 328 as the changelog states.
I used the instructions L3 Hardware Offloading for my CRS326-24G-2S+. ROS 7.3.1
After saving the configuration data in text form (/export compact terse show-sensitive file=xxx) , there is no information in the file about l3hw on all switch ports.
Only data about switch:
/interface ethernet switch set 0 l3-hw-offloading=yes
That means that for the global setting the default is “no” and for the per-port settings the default is “yes”.
The output you are looking for is probably in output of
/interface/ethernet/switch/port export verbose
It is like ‘show run all | sec interface’ in Cisco world.
What is beefier than AWS Graviton? Graviton2/3? We already have a server-grade CPU in a short depth pizza box with NVME slot in CRS2XXX line. That should be good enough for majority of workloads that do not require storage redundancy.
How to check BGP advertisement in ROS v7.
dump.ADV is not working. When i try to dump-saved-advertisement 0 save-to=“bgp-view1.pcap”
No such file is saved or created in router. Please Help
i agree, remember this is a network equipment in first place, container support is a complementary feature
if you need more server like specs what you realy need is a separate real server
remember that the resources your containers will take will not be available for network jobs so if you abuse it can hurt network performance, “there is no free lunch”
If most of the forwarding is done by switch hardware (L3HW), having spare CPU resources and RAM for containers is really nice to have. It is saving space and electricity for both home lab racks, and especially racks in POPs, where space is at a premium.
Not needed, IMO
*) bridge - added more details for loop detection warning;
*) bridge - fixed TCP, UDP port parsing for loop detect warning;
This fixed the false positive “Transmit loop detected” for EoIP/IP-IP tunnels in bridges 
Thanks, MikroTik crew!
Routers you’re referring to (forwarding done in L3HW) cost 1kUSD and upwards (more likely a few grands). So if you actually need that kind of L3 performance, then surely you can spare another few hundred USD for a decent server (either ARM based, or for greater flexibility, x86_64 based) and a few bucks for another 1U of rack space? And believe me, there will be times when L3HW won’t handle just everything and in those moments you’ll be happy to have CPU sitting around mostly idle.
leds - fixed wireless related LED behavior with WW2 package;
How exactly it is supposed to work? I’m still getting exactly the same error (“Couldn’t change LED Trigger - Cannot assign interface to trigger! Interface is disabled or this is not a wireless interface! (8)”) as with the previous releases.