Recommendation for a router only - No WiFi needed

I'm looking for some suggestions for a device to handle routing/firewall duties on my home network. I do not need wifi on the device. I will be running SQM QoS. I'm thinking of a device with a good CPU, memory and a good price. Raspberry Pi comes to mind, but what say ye LEDE users?

An x86 PC.

How much bandwidth do you need to route?
And how many devices using it simultaneously on the LAN?

I've been successful running MT7620A based routers with SQM layer_cake on a 15/10 VDSL connection. Loading is about 30% with layer_cake. These routers are $18-$30US on aliexpress.

The Ubiquiti EdgeRouter X @ ~$50 provides a dual core 880MHz MIPS 1004Kc processor with 256MB of storage and 256MB of RAM. This has 4 Gigabit LAN ports and 1 Gigabit WAN port while the Raspberry Pi only has 1 Fast Ethernet port.

1 Like

Does it actually work with LEDE? I had some kind of impression that there were issues.

See Table of Hardware: Ideal for LEDE (filtered for devices w/o wifi).

You can further filter yourself according to your needs (e.g. 100Mbit/Gbit ports, 17.01.4 or snapshot support, CPU MHz + cores, ...).

1 Like

Oh wow! Thanks @tmomas! I was looking at a different ToH that didn't have all of those columns!

Hello Everybody!

I agree. There are nice small fanless machines on the Chinese market:
J1900 Celeron CPU
4x Gigabit Intel LAN Ports
VGA and USB ports - what means it is almost impossible to BRICK such a machine
Please go to and search for "partaker" - you will find a lot of configurations (RAM, SSD)
My main router at home is such a machine and its running flawlessly

At this point, with the mess Intel is making of its patches for Meltdown/Spectre, I really wouldn't be looking at Intel. Moreover, a modern MIPS SoC like the Mediatek mentioned earlier can easily handle 100+ Mbps.

Also... Raspberries are not routers. They handle Ethernet through an USB bus, for f***'s sake.

1 Like

It's not so clear the Meltdown/Spectre issues are particularly worrisome for routers. For the most part, they are local privilege elevation exploits. If you don't allow anyone to log into your router then its not exploitable as far as I know. On the other hand, for cloud providers where perhaps hundreds of different customers are logging into a single hardware box running different virtual machines, that's a major issue. So, this seems to me to be a very serious problem for VPS / cloud providers.

Agreed that raspberry pi is not a good router platform. Would love to see someone put together a decent and well supported ARM board with 3-4 gigabit interfaces. Espressobin seems very attractive, but I'm not so clear on how well supported the hardware is. Armbian lists it as experimental for example. My understanding is that it's limited by a single interface to the CPU so it might not route a gigabit for example.

The APU2 platform looks quite nice, but Meltdown/Spectre are equally applicable, so it's not a way to avoid that issue, just a nice price point for a reasonably competent board.

Yeah. I have an APU2 running as well, but with Ryzen on the table I wouldn't be buying a Jaguar SoC that quickly anymore either (I suppose AMD will push Ryzen to that part of the market as well).

I thought I saw some commits for the Espressobin in master recently. Might be worth checking. Kernel 4.14 seems to promise support for it, but to what extent, I do not know.
-------- Oorspronkelijk bericht --------
Aan 24 jan. 2018 17:17, Daniel Lakeland schreef:

Though an upcoming low-power embedded Ryzen system sounds nice in theory, it doesn't seem to be on the shelves so to speak. As of today I have to agree that the intel based firewall appliances with 4 or 6 Intel NICs are the way to go for high performance routing.

seems to be a beast, they have 4 port versions at a lower price point as well. They support AES-NI so are particularly great if you're routing OpenVPN.

The worrying part of meltdown is that by default, mitigations will be enabled and cause a drop in performance. Routing is syscall heavy as far as I know.

Edit: actually PTI can be disabled through a kernel parameter. Forgot about that.