I've noticed a trend lately. Rather than replacing a router when it literally stops working, I've needed to act earlier—swapping in new gear because an old router could no longer keep up with increasing Internet speeds available in the area. (Note, I am duly thankful for this problem.) As the latest example, a whole bunch of Netgear ProSafe 318G routers failed me for the last time as small businesses have upgraded from 1.5-9mbps traditional T1 connections to 50mbps coax (cable).

Yes, coax—not fiber. Even coax has proved too much for the old ProSafe series. These devices didn't just fail to keep up, they fell flat on their faces. Frequently, the old routers dropped speed test results from 9mbps with the old connection to 3mbps or less with the 50mbps connection. Obviously, that doesn't fly.

These days, the answer increasingly seems to be wireless routers. These tend to be long on slick-looking plastic and brightly colored Web interfaces but short on technical features and reliability. What's a mercenary sysadmin to do? Well, at its core, anything with two physical network interfaces can be a router. And today, there are lots and lots of relatively fast, inexpensive, and (super important!) fully solid-state generic boxes out there.

So, the time had finally come. Faced with aging hardware and new consumer offerings that didn't meet my needs, I decided to build my own router. And if today's morphing connectivity landscape leaves you in a similar position, it turns out that both the building and the build are quite fast.

Why do it the hard way

A lot of you are probably muttering, "right, pfSense, sure." Some of you might even be thinking about smoothwall or untangle NG. I played with most of the firewall distros out there, but I decided to go more basic, more old school: a plain, CLI-only install of Ubuntu Server and a few iptables rules.

Admittedly, this likely isn't the most practical approach for every reader, but it made sense for me. I have quite a bit of experience finessing iptables and the Linux kernel itself for high throughput at Internet scale, and the fewer shiny features and graphics and clicky things that are put between me and the firewall table, the less fluff I have to get out of the way and the fewer new not-applicable-in-the-rest-of-my-work things I have to learn. Any rule I already know how to create in iptables to manage access to my servers, I also know how to apply to my firewall—if my firewall's running the same distro as my servers are.

Also, I work pretty heavily with OpenVPN, and I want to be able to continue setting up both its servers and clients in the way I already rely on. Some firewall distros have OpenVPN support built in and some do not, but even the ones with built-ins tend to expect things to run differently than I do. Again, the more the system stays out of my way, the happier I'll be.

As an additional bonus, I know that I can very easily keep everything completely up to date on my new and completely vanilla Ubuntu router. It's all supported directly by Canonical, and it can (and does) all have automatic updates turned on. Add the occasional cron job to reboot the router (to get new kernels), and I'm golden.

Hardware, hardware, hardware

We'll go through the how-to in a future piece, but today it's important to establish why a DIY router-build may be the best option. To do that, you first need to understand today's general landscape.

In the consumer world, routers mostly have itty-bitty little MIPS CPUs under the hood without a whole lot of RAM (to put it mildly). These routers largely differentiate themselves from one another based on the interface: How shiny is it? How many technical features does it have? Can users figure it out easily?

At the higher end of the SOHO market, you start seeing some smartphone-grade ARM CPUs and a lot more RAM. These routers—like the Nightgear Nighthawk series, one of which we'll be hammering on later—feature multiple cores, higher clock speeds, and a whole lot more RAM. They also feature much higher price tags than the cheaper competition. I picked up a Linksys EA2750 for $89, but the Netgear Nighthawk X6 I got with it was nearly three times more expensive (even on holiday sale!) at $249.

Still, I wanted to go a different route. A lot of interesting and reasonably inexpensive little x86-64 fanless machines have started showing up on the market lately. The trick for building a router is finding one with multiple NICs. You can find a couple of fairly safe bets on Amazon, but they're older Atom-based processors, and I wanted a newer Celeron. After some good old-fashioned Internet scouring and dithering, finally I took the Alibaba plunge and ordered myself a new Partaker Mini PC from Shenzhen Inctel Technology Company. After $240 for the router itself and another $48 for a 120GB Kingston SSD from Newegg, I'd spent about $40 more on the Homebrew Special than I had on the Nighthawk. Would it be worth it?

A challenger appears

Before we get testing started, let's take a quick visual look at the competitors.

That Nighthawk is, by comparison to the others, HUGE and imposing (even more so than the picture makes it appear). It's actually significantly larger than my Homebrew Special, which is a fully functional, general purpose PC you could use as a perfectly competent desktop. It's like DC Comics asked H.R. Giger to lend a hand designing a wireless router for Batman.

The Homebrew Special itself is kinda adorable. It has one blue and one red LED inside the case, and at night, the light from both spills out of its cooling vents indirectly, giving the network stack a festive party look. If there were any fans to cause a flickering it would drive me insane, but since it's a steady-state soft glow, I actually like it.





The Linksys and the Buffalo, on the other hand, look like exactly what they are—cheap routers. However, it's worth noting the styling on the Linksys is a big improvement over the brand's past. It looks more like something professional and less like a children's toy. (But enough about the styling—it's time to put these poor routers through the gauntlet.)

The obvious first challenge is a simple bandwidth test. You put one computer on the LAN side and one computer on the WAN side, and you run a nifty little tool called iperf through the middle. Simple, right?



Well, that would make for a short, boring article. The network itself measures gigabit, the three gigabit routers measure gigabit, and the 100 megabit router measures 100 megabit.

In actuality, a test this simple doesn't even begin to tell the story. The only reason to do it may be to show how pointless it is. Router manufacturers are becoming more aware that people actually test their product, and no manufacturer wants its product to be anywhere but the top of something like smallnetbuilder's router chart. In light, manufacturers are actively chasing stats these days.

The problem is, stats are just stats. Being able to hit a high number on a pure throughput test is better than nothing, but it's a far cry from the whole story. I learned that lesson the hard way while working for a T-1 vendor in the early 2000s. Their extremely expensive Adtran modems could handle 50 to 100 people's normal Internet usage just fine, but a single user running Limewire or some other P2P client would bring the whole thing down in a heartbeat. (The fix back then: put an inexpensive-but-awesome $150 Netopia router in front of that expensive Adtran modem. Problem solved.)

Even for relatively simple routing—no deep packet inspection, no streaming malware scanning or intrusion detection, no shaping—the CPU and the RAM available to the router are both important well above and beyond the ability to saturate the Internet link. Peer-to-peer filesharing is about the most brutal activity a network will see, these days (whether it's bittorrent, one of the Gnutella or eDonkey variants, or a game company's peer-to-peer download system). I was done playing WoW by the time Blizzard's P2P distribution system was introduced, but my roommate at the time wasn't. On its launch day, the new WoW peer download system unhelpfully defaulted to no throttling whatsoever. It cheerfully tried to find and maintain connections with literally thousands of clients simultaneously, and my home network went down like Gilbert Godfried getting tackled by Terry Tate. My roommate and I had words.

Based on such past experience, I don't just want to minimally "test" my challengers and call it a day, I want to really make them sweat. So to do that, I'm going to hit them with workloads that stress three problem areas: saturating the network link, making and breaking individual TCP/IP connections really quickly, and holding massive numbers of individual TCP/IP connections open at the same time.