The Little Network That Could

(Credit: Flickr)

Gather ’round, folks – Grandpa has a story to tell. (OK, I’m not a grandpa and I don’t expect to be one any time soon, but as I’ve journeyed back in my memory to write this post, I sure feel old…)

For as long as it has been possible to have a full-time Internet in a residential home, I’ve been running my own home network, and I want to share its story: it’s The Little Network That Could, or TLNTC, as I sometimes call it.

(This will be the first in a series of posts covering design and implementation of a range of technologies in the Linux and networking space. I expect it to take me a while to finish. If you like this part of the story and want to read another network’s story while you’re waiting, check out Tom Eastep’s Shorewall documentation. Tom has done a great job over many years in providing detailed documentation of his configuration and design choices, and teaching a lot of people about networking in the process.)


Back in the bad old days (the late 1980s and early 1990s, in my case), those of us who were technical enough would connect to the Internet (which was only used for research and development purposes at the time) by a dial-up modem for long enough to download our emails and news spools into our offline text-based readers. This is because access was billed by the hour (or hours per month) at prices which meant that almost no one could have a full-time Internet connection – most connections were maintained by universities and commercial research labs. So my knowledge about networking was gained at work where I administered large commercial Unix systems, and mostly from the Unix host side (the network infrastructure was handled by another team).

In the early-to-mid 1990s, the Internet was opened for use by commercial organisations. This sparked a burst of growth which resulted in commercial ISPs providing more affordable Internet access (although it was still really only usable for people with reasonable technical skills), which eventually got to the point where it was affordable to have a full-time Internet connection over 56K modem. If my memory serves me correctly, this was around 1998, and I think my first full-time connection was via APANA.

I had been using Linux since around kernel version 0.97 (on the long-defunct SLS), and my gateway machine at the time when I first connected full-time was probably running Red Hat Linux 5.x (not to be confused with Red Hat Enterprise Linux 5.x, which was about 9 years later). I’m a little hazy on the details of this, although I do distinctly remember in 2000 deciding to upgrade from Pinstripe (6.9.5) to Guinness (7.0) without downloading the whole distribution first – it took 3 days of continuous downloading over my 56K modem, and failed in the middle twice, but eventually worked!

Around 2001-2002, Linux became well-enough accepted in the enterprise that I was able to shift my focus at work from what I considered to be increasingly unwieldy commercial Unix (and its overpriced proprietary hardware) to the much more frequently-updated and flexible Linux distributions – mostly Red Hat Enterprise Linux and SUSE Linux Enterprise Server in my work life, and Debian at home (Ubuntu was still a gleam in Mark Shuttleworth’s eye). Around the same time, Internet connectivity options were improving, and at home we switched from 56K dialup to cable modem and later to ADSL (which was actually a bit slower, but gave us a wider selection of ISPs).

Once our family had downstream connectivity in the order of megabits per second and upstream in the order of hundreds of kilobits per second, the benefits of local network infrastructure really showed themselves: we could have a local HTTP proxy (squid) and DNS cache/forwarder (BIND), which significantly improved web browsing performance (especially when multiple users were browsing), whilst still having enough bandwidth to receive and send email to and from our local server behind the scenes.

Raison d’être

A change in my home network’s role came in late 2006, when I went into business for myself – what had been a fairly organic start became a rather more focused strategy, and the first part of my thinking around TLNTC was born. I was consulting on Linux, networking, and software development, and I dedicated around 15-20% of my time to research and professional development in order to keep my skills sharp. I needed more from my network than just a gateway for faster Internet and email access for my family – it had to be a proving ground for the technologies I was recommending, installing, troubleshooting, and maintaining for my clients. What was needed on site had to be demonstrated at home first, and workable over the long term.

Even though I’m not doing independent consulting at the moment, TLNTC still fills this role in my technical professional development, and this is why I’ve continued pondering its purpose and characteristics.

More than a home lab

Home labs are discussed regularly on various blogs, forums, dedicated sites, and on the various podcasts to which I listen, especially those on the Packet Pushers Network:

A lot of engineers who work with Cisco, Juniper, Microsoft, or VMware products at work tend to have a bunch of gear at home, which they fire up when needed to study for a certification or build a proof-of-concept. Such home labs are often composed of retired enterprise equipment pulled out of a data centre rack or acquired on eBay from second hand vendors, although depending on budget and type of equipment, so more dedicated labbers might buy new gear. They often live in a full 42RU 19-inch rack in the garage, and are so noisy as to make other members of the household complain about jet engines and such when they are fired up. So their configurations can be short-lived and don’t necessarily need to be practical to maintain in the medium-to-long term.

I do use TLNTC as a test lab and I have some equipment that only gets turned on when I need it, but my focus is on applying learning to create a usable, reliable infrastructure rather than learning for its own sake. In short, it is designed to be an enterprise network in miniature. To that end, I’ve implemented a number of components which I generally encounter in enterprises, but would never recommend to home users unless they have similar goals:

  • 802.1X authentication for wireless networks
  • multiple layers of packet filtering firewalls, with OSPF and BGP for routing
  • OpenVPN and IPsec VPNs
  • IDS using full packet capture from a monitor port
  • GPS-synced stratum 1 NTP server
  • IPv6 through most of the network (more on this later in the series)
  • URL filtering using a dedicated proxy server
  • Network Monitoring System (LibreNMS) integrated with Opsgenie for alerting

Despite these similarities with enterprise networks, there are also differences:

  • I strive as much as possible to only use well-maintained Free Software. I do run some proprietary software, including Junos on my main EX2200-C switch and Ruckus Unleashed for wireless, but these are the exception rather than the rule. When I first started consulting, this was sometimes a limitation, but it’s becoming less and less so. Nowadays I can usually find an Open Source technology for almost any enterprise software niche if I look hard enough.
  • Performance and availability are generally lower priority for me than cost and noise. That’s not to say I don’t care about them at all, but there’s a balance to be struck. All my servers run RAID and some of those RAID sets are on SSD for speed, but generally I aim for small, quiet, and cheap. If I need more storage space, I’ll generally go for a spinning rust drive, due to the lower cost per TB. If a piece of server or network hardware dies, my family waits until I can get it repaired or replaced. If they urgently need Internet access, they use the hotspot on their phone. If they need email, they fall back to their gmail account temporarily.
  • Core routing and firewalling happens in software rather than hardware. This is partially because VMs and containers are easy to modify and adapt, but also because firewall and router vendors have so consistently failed to produce platforms which are easily and frequently updated. I may take this point up in a later post in the series, but for now I’ll just say that I have found image-based software distribution such as that used by Cisco and Juniper much harder to manage and update than standard Linux distributions based on dpkg/apt or rpm/yum. Because of this, I don’t use dedicated firewall appliances, but build them from standard Linux distributions.

But it’s great for learning, too

I think there is also a learning benefit to taking the “mini-enterprise” approach to the home network: not only does the learning serve the infrastructure, but the process of implementing the infrastructure cements the learning. This means when I put technology on my resume, I do so knowing that I can confidently answer questions about it from experience rather than rote learning.

How mini is my mini-enterprise network?

To give an idea of scale, here’s a quick overview of what comprises TLNTC:

  • 23 VMs or containers running across 3 dual-core VM/container hosts; 36 GB RAM total
  • 3 small switches (all routing-capable, but running as L2 switches), total of 27 ports
  • About 10 VLANs, each of which (for the most part) maps to an IPv4 and an IPv6 subnet and thence to a firewall zone

So clearly this is not a large network, but it’s considerably more complex than the average home network. Based on my experience during my time in consulting, it’s probably similar in size and complexity to the network of a small business with 25-100 employees, depending on how technical their work is.

Why not cloud?

A big question I’ve recently asked myself (and been asked many times, particularly when I tell people I run my own mail server) is: why aren’t you just putting this all in the cloud? Given that my day job involves working with AWS & Azure public clouds and container technologies like Docker and Kubernetes, I did seriously consider doing this, but decided against it on two grounds:

  1. I would still need most of the same on-premises hardware, and
  2. cost.

I used the AWS and Azure pricing tools to work out how much my infrastructure would cost to run in their respective clouds. Azure’s pricing tool told me that my virtualised workloads would cost $60K to run in their cloud over 5 years, and $11K on-prem. AWS’ tool told me that I would save $273K over 5 years by moving my workload to their cloud. In reality, I’ve spent less than $7K on hardware in the past 10 years, and if I’m generous, maybe $5K on power over the same period.

Obviously this is not an apples-to-apples comparison since public clouds offer many features and services which my network doesn’t, but clearly if I don’t need all those services and I continue to prioritise cost over availability and performance, cloud is not the right answer. VMs and containers work pretty much the same on-prem as they do in cloud, so I’m not backing myself into a corner if one day I end up putting some of my home network’s workloads in public cloud. (This web site would likely be one of the prime candidates.)

[Edit: I couldn’t resist throwing this in – I just listened to IPv6 Buzz episode 055, where (around 49:30) Geoff Huston was heard to utter: “Folks who are running computers in their basement … are the dinosaurs of today’s age, and the enterprise networks that go with it are equally … dinosaur-reptilian-based bits of infrastructure.” I may circle around and respond to Geoff’s views in a future post, but in the meantime I only hope I can be a thoughtful, well-informed dinosaur. Triceratops is my favourite – can I be one of those?]

So that’s the beginning of the story of TLNTC – I hope it was informative. The next part of the story will be about TLNTC’s adventures in IPv6-land.

I’m happy to receive questions and comments in the section below, or via the usual social media channels (over on the right).

VyOS Certified Network Engineer

This morning before work I sat for (and passed) my attempt at the newly-minted
VyOS Certified Network Engineer certification. Mostly this post is just to let folks know that the certification is out there and encourage them to take it, but also I want to compare it to another certification I recently passed, the AWS Certified Solutions Architect Associate.

I’ve liked VyOS (and its predecessor Vyatta Core) for a long time. It’s always my first choice when I want to test a new BGP or OSPF scenario or set up an IPsec VPN. Its compelling value proposition to me is that it turns Debian Linux into a network appliance with a Juniper-like CLI. Or to put it another way, VyOS is to routing as Cumulus Linux is to switching – a router that makes sense to both network engineers and Linux geeks.

The certification is different from most others I’ve done, being 100% practical. There are no written examination requirements, no multiple-choice questions. It presents a practical scenario with a number of broken configurations, which need to be fixed in order to pass the certification. (I’ve been told this is how the Red Hat Certified Engineer test is structured as well, though I haven’t experienced it first-hand.) It uses a browser-based VNC client to hook up to a dedicated training/certification scenario platform (find all the details in their blog announcing the certification).

The announcement claimed:

We tried to avoid obscure options so that an experienced VyOS user and network admin can pass it without preparing specially for that certification, but it still requires a pretty broad experience.

I think the exam stands up pretty well to that claim. To prepare, I read through the blueprint, made sure I could get at least 90% of the sample questions right without additional study, labbed up a BGP + IPsec/VTI scenario between my home network and AWS (learning a little about compatibility between IKEv1 and IKEv2 along the way!), and then booked the exam. Experienced network and Linux admins should find the certification relatively straightforward, and easily achievable within the two hours finish time allotted.

I had a couple of administrative difficulties (mostly due to my time zone being a long way from theirs) and a couple of very minor technical gotchas in the exam. (I never realised I was so dependent upon Ctrl-W when it comes to VyOS command-line editing, and this doesn’t work in a browser-based emulator.) The VyOS team were very apologetic about the administrative dramas, but honestly they were not really even an inconvenience. Typos and errors and failed technology are quite common in certification exams, but because the VCNE exam is based on actual VyOS running in a VM, there’s not a lot of text to get wrong, and you don’t get the level of quirkiness that simulations offer.

Contrast this with the AWS Certified Solutions Architect – Associate, which is a traditional multiple-choice exam administered by Pearson. I studied it from a paper book (I’ve never really learned well from the video training that many people swear by) for about 3 months off & on, and although I passed well, I never felt that it tested my knowledge in the right ways. And the multiple-choice format has given rise to the whole question-dumping industry which lurks in the shadows of many vendor certification studies.

On the negative side for the VyOS exam, there was no IPv6, which I think is a serious gap in any network-oriented certification nowadays. I also found the IPsec problem a little on the easy side. It’s hard for me to judge, but I think that the difficulty might be on the low end of intermediate level, which is where this certification is aimed.

Overall I think the VyOS CNE exam was my most pleasant certification experience yet, and one which demonstrates skills which actually matter in real life. I’m really glad to see Sentrium getting enough traction in the marketplace that a certification platform is commercially viable, and I’m keen to keep going with the certifications they offer.

Filtering tshark and tcpdump with packet size as a capture filter

I recently wanted to look at some packet captures on my NTP pool servers and find out if any NTP clients hitting my servers use extension fields or legacy MACs.  Because the overall number of NTP packets is quite large, I didn’t want to spool all NTP packets to disk then later filter with a Wireshark display filter – I wanted to filter at the capture stage.

I started searching and found that not many quick guides exist to do this in the capture filter.  However, the capability is there in both tcpdump and tshark, using either indexing into the UDP header, or using the overall captured frame length.  Here’s an example of tcpdump doing the former (displaying it to the terminal), and tshark doing the latter (writing it to a file):

tcpdump -i eth0 -n -s 0 -vv 'udp port 123 and udp[4:2] > 56'
tshark -i eth0 -n -f 'udp port 123 and greater 91' -w file.pcap

Both of the above filters are designed to capture NTP packets greater than the most common 48-byte UDP payload.  In the case of udp[4:2], we’re using the UDP header’s 16-bit length field, which includes the header itself.  In the case of greater, it uses the overall captured frame length, and actually means greater-than-or-equal-to (i.e. the same as the >= operator); see the pcap-filter(7) man page for more details.

Don’t believe the non-programming hype


This will be a shorter, less-polished post than usual.  It’s really just a way to start to bring a bit of structure to my thoughts.  Feel free to add some comments or weigh in on the linked Twitter thread.

I came away from a recent PacketPushers episode, “Don’t Believe The Programming Hype” a bit disappointed that the discussion didn’t get to the heart of the matter.  Then there was this tweet from  which kicked off some interesting discussion about the place of programming:

Why shouldn’t we believe the non-programming crowd?

So here are my propositions (and some corresponding anti-propositions):

  1. Programming isn’t hype; programming is a fundamental IT skill.  If you don’t understand the basics of computer architecture (e.g. CPU instruction pointers, registers, RAM, stacks, cache, etc.) and how to create instructions which make computers do useful things (i.e. coding), you’re not an IT professional.
    • This doesn’t mean you must understand exactly how every computer architecture works, or know how to code in assembly language (or directly in hexadecimal like Mel the Real Programmer).  But it does mean that if you’re confronted with a problem, you know enough fundamentals to peel back the layers, and work through the elements in each layer methodically (with the help of the documentation) to determine the component in error.
  2. There is no fundamental distinction between scripting and programming.  Both are designed to accomplish basically the same things, at different levels of abstraction.  Suggesting that someone who writes scripts to automate his or her infrastructure is not a programmer confuses the issue and does not progress the discussion.
    • This doesn’t mean that vendor-originated code isn’t better than in-house scripts (sometimes it is; sometimes it isn’t), but it does mean that the value of the local process and infrastructure knowledge contained within in-house scripts mustn’t be sidelined.  No off-the-shelf software “just works” without configuration or customisation of some sort, so in-house scripts are fundamentally necessary.
  3. The above distinction is probably just a specific instance of the generalisation that there’s a difference between builders and non-builders.  This is also a non-real distinction.  Every enterprise IT organisation is building something, whether they use code they’ve written themselves or rely solely on vendors.  You can’t compile a data centre contract into existence or code up a WAN link; working IT systems are built both by those who create the individual components, and those who build on those components.  It’s turtles all the way down; not many software vendors assemble their own motherboards or run their own chip fabs…

How did we get here?

So how did we get to this point where the concept of learning programming seems so intolerable to networking folks?

In my mind the main factor is the normalisation of proprietary software – that is, the widespread acceptance that it’s OK for software to be closed to scrutiny and not fully controlled by those who depend upon it.  (On the contrary, I hold that Open Source is essential for the operational safety of functioning IT systems.)  The dominance in their respective markets of Microsoft Windows on the corporate desktop & server and Apple iOS on consumer devices are no doubt the most common examples of this, but other, more egregious examples pop up routinely.

This has led to a generation of IT folks for whom the fundamentals were something akin to magic.  “If I press here it does this…”  The pushback against programming is only one example of this.  (Another is the cargo-culting/guessing troubleshooting culture that many of us in operational roles have encountered.)

My plea to those who are pushing back against the programming trend is simply this: have a go!  Programming is just building things – like you already do – just at a different level of abstraction.  You might find that you like it, and it opens up a whole new range of possibilities for you.


I recognise that I write this from a biased perspective:

  1. When I started in IT, there were no “IT” qualifications.  When I went to university, the course was still called Applied Science with a major in computing.
  2. My first job (while still in uni) was a programmer.  After that, I was a Unix sysadmin.  Back then, Unix sysadmins were expected to know C in addition to the usual scripting tools.  Network engineering was a relatively late addition in my career; I didn’t start being the primary networking resource in my job until 2003, and didn’t get my CCNA until 2012.  So I always approached networking from a slightly different perspective to the “average” network engineer who did his/her CCNA straight out of school.
  3. I’m a Free Software “true believer”; I first installed Linux from floppy disks with a distro which used kernel version 0.97.  I’ve been using Linux on the desktop for almost 20 years.  You can’t survive that long in the Open Source world without being able to compile (and sometimes fix!) software on a semi-regular basis.


Feel free to discuss!  Either in the comments below, or shoot me some thoughts on Twitter.