Ask Slashdot: Which Router Firmware For Bandwidth Management? 104
First time accepted submitter DeathByLlama (2813725) writes "Years ago I made the switch from DD-WRT to Tomato firmware for my Linksys router. I lost a couple features, but gained one of the best QoS and bandwidth management systems I have seen on a router to date. Admins can see graphs of current and historical bandwidth usage by IP, set minimum and maximum bandwidth limits by IP range, setup QoS rules, and see and filter graphs and lists of current connections by usage, class or source/destination — all from an elegantly designed GUI. This has allowed me to easily and intelligently allocate and adjust my network's bandwidth; when there is a problem, I can see where it's coming from and create rules around it. I'm currently using the Toastman's VPN Tomato firmware, which has about everything that I would want, except for one key thing: support for ARM-based routers (only Broadcom is supported). I have seen other firmware projects being actively developed in the last few years, so in picking a new 802.11ac router, I need to decide whether Tomato support is a deal-breaker. With solid bandwidth management as a priority, what firmware would you recommend? Stock Asuswrt? Asuswrt-Merlin? OpenWRT? DD-WRT? Tomato? _____?"
Re:Pfsense (Score:5, Interesting)
In your haste to get FP, you missed the requirements in TFS.
I use pfSense extensively, but its bandwidth controls are not easy to use, and nobody would recommend deploying it on ARM in 2014.
You could give Gargoyle a try.... (Score:4, Interesting)
You could give Gargoyle a try......
http://www.gargoyle-router.com... [gargoyle-router.com]
I'd seriously think about a dedicated router (Score:5, Interesting)
The problem is all those consumer wifi+router deals tend to have kinda crap firmware. While there are, in theory, OSS alternatives they seem to be less than speedy with the updates and support for new hardware.
So I'd look elsewhere. The two things I'd put at the top of your list:
Monowall, on an APU.1C. It is like $150 for the unit, and then $20-30 for an enclosure and CF card. Monowall should support everything you need, it is really feature rich, is pretty easy to use, and the APU.1C is fast enough it shouldn't have issues even with fairly fast internet.
A Ubiquiti Edgerouter Lite. This is a funny looking and named lil' router with quite a bit of performance under the hood, thanks to the hardware routing logic its chip has. $100 and it can push gigabit speeds for basic routing setups. It is also extremely configurable, since it runs a Vayetta fork, which is a Linux OS customized for routing. However to configure the kind of things you want, you might have to hop in to the CLI, I don't know that the GUI has what you need. It supports that though, and you can even hop out of the specialized routing CLI and get a regular Linux prompt where you can install packages and such.
If you want a more supported solution, you could look at a Cisco RV320. Costs like $200 and is a fast lil' wired router (uses the same basic chip as the Edgerouter, just slower). I haven't used one but I'm given to understand you can make them do a lot. Sounds like they firmware may be a little flakey though.
You then just set your consumer WAP+router in to "access point" mode and have it just do the wireless functions.
This is all more expensive and complex than just running on a consumer WAP+router, but more likely to be able to do what you require. It also means you can change out components without as much trouble. Like say your WAP gets flakey, and you want a new one with the latest technology. No problem, just buy it. You don't have to worry if it supports the routing features you need because it doesn't do that for you.
If you are stuck on doing an all in one, then you could look at a Netgear Nighthawk R7000 or the new Linksys WRT1900AC. The Netgear does have bandwidth management and QoS in its native firmware (I haven't played with the features, but I can confirm they are there as I own one) and there is a "myopenrouter" site that has OSS firmware for it (ddwrt mod I think). The Linksys router supposedly is going to have OpenWRT support soon as Linksys worked directly with the OpenWRT team for it.
Re:Out of scope I think but.... (Score:3, Interesting)
Almost all router bandwidth management is shit. (Score:5, Interesting)
Almost all router bandwidth management is shit.
Bandwidth management schemes currently used by everything you mention are all base on rate limiting packet delivery based on some mythical QoS value, and they ignore the actual problem that the people who are using these things are attempting (and failing) to address.
The problem is that the point of a border routers is to hook a slower border uplink to a faster interior connection; on the other end of the slower uplink, you have a faster ISP data rate. In other words, you have a gigabit network in your house, and the ISP has a gigabit network at their DSLAM, but your DSL line sure as hell is *NOT* a gigabit link.
What that means is that software that attempts to "shape" packets ignores an upstream-downloads or a downstream-uploads ability to overwhelm the available packet buffers on the high speed side of the link when communicating to the low speed side of the link.
So you can start streaming a video down, and then start an FTP transfer, and your upstream router at the ISP is going to have its buffers full of untransmitted FTP download packets worth of data, instead of your streaming video data, and it doesn't matter how bitchy you are about letting those upstream FTP packets through your router on your downstream side of the link, it's not going to matter to the video stream, since all of the upstream router buffers that you want used for your video are already full of FTP data that you don't want to receive yet.
The correct thing to do is to have your border router lie about available TCP window size to the router on the other end, so that all intermediate routers between that router and the system transmitting the FTP packets in the first place also lie about how full the window is, and the intermediate routers don't end up with full input packet buffers with nowhere to send them in the first place.
Does your border router do this? No? Then your QoS software and AltQ and other "packet shaping" software is shit. Your upstream routers high speed input buffers are going to end up packed full of packets you want less, and you will be receiver live-locked and the packets that you *do* want won't get through to you because of that.
You can either believe this, or you can get a shitty router and not get the performance you expect as the QoS software fails to work.
Then you can read the Jeffrey Mogul paper from DEC Western Research Labs from 1997 here: http://citeseerx.ist.psu.edu/v... [psu.edu] ...after which, you should probably ask yourselves why CS students don't read research papers, and are still trying to solve problems which were understood 27 years ago, and more or less solved 17 years ago, but still have yet to make their way into a commercial operating system.
BTW: I also highly recommend the Peter Druschel/Guarav Banga paper from Rice University in 1996 on Lazy Receiver Processing, since most servers are still screwed by data buss bandwidth when it comes to getting more packets than they can deal with, either as a DOS technique against the server, or because they are simply overloaded. Most ethernet firmware is also shit unless it's been written to not transfer data unless you tell it it's OK, separately from the actual interrupt acknowledgement. If you're interested, that paper's here: http://citeseerx.ist.psu.edu/v... [psu.edu] and I expect that we will be discussing that problem in 2024 when someone decides it's actually a problem for them.