The Little Network That Could: TLNTC’s adventures in IPv6-land

It has been far too long since my previous post introducing TLNTC. This episode will be a (hopefully!) shorter overview of TLNTC’s journey into IPv6 connectivity.

Early days

I don’t know when I started first started to think seriously about learning and implementing IPv6, but probably the earliest defining moment I can remember was Geoff Huston’s LCA2011 keynote in which he explained the IPv4 exhaustion problem, presented it as a problem for openness, and explained the IPv6 solution. I had already done some basic learning on IPv6, but this talk was what got me interested more seriously in making it work. (Huston has seemingly backed away from his earlier position on Internet openness and has become a surprising – at least to me – proponent of IPv4 longevity. I may write more about this later.)

Around this time I started testing IPv6 connectivity for myself, including some transition mechanisms like Hurricane Electric (HE) tunnels and the 6to4 anycast IP (which worked reasonably well at the time, but quickly became irrelevant). At the time I was also studying for my Cisco CCNA, so I had the opportunity to test those things on both Linux and IOS.

A significant step in my tinkering was to move to Internode, one of the earliest ISPs in Australia to make IPv6 available to retail customers. I signed up for a fixed IPv6 allocation on their business plan in mid-2012 and have been with them ever since. Despite a recent IPv6 connectivity problem to AWS which took them far too long (weeks) to resolve, Internode have provided very reliable IPv6 transit for the most part, and I’ve had a static /56 network block allocated to me the whole time.

Moving along with IPv6

A few more interesting waypoints along TLNTC’s IPv6 journey have included:

  • In March 2013 there were some great discussions on the AusNOG mailing list, which prompted Mark Newton to write a lovely little post called “IPv6: objections to sale“, along with the skeleton of a plan for how an ISP or application provider might implement IPv6.
  • The U.S. government’s Office of Management and Budget (OMB) issued a memo which set two significant deadlines:

Upgrade public/external facing servers and services (e.g. web, email, DNS, ISP services, etc) to operationally use native IPv6 by the end of FY 20121;
Upgrade internal client applications that communicate with public Internet servers and supporting enterprise networks to operationally use native IPv6 by the end of FY 2014;

Transition to IPv6

Even though it was issued in September 2010, this memo didn’t make it onto my radar until some time later; possibly it gained some IT industry press coverage when the 2014 deadline for internal connectivity to Internet IPv6 sites was looming. This was a bit of a wake-up call to me, given that I usually see government initiatives as a sure-fire way to ensure something takes a long time.

Unlike building a new network on IPv4, which usually starts with the core and transitions functionality outwards, transitioning to IPv6 usually involves starting at the edge and working towards the core. The Hurricane Electric IPv6 Sage certification was a great practical tool in this respect: it requires very little knowledge testing, but requires you to demonstrate ownership of various components of a working IPv6 network, which it tests remotely. The tests include: browsing from an IPv6-enabled browser, having an IPv6-enabled web site, having an SMTP server which can accept mail over IPv6, having a DNS server which can be queried over IPv6 for AAAA records, etc. Going through the process of setting up for all of these tests on TLNTC laid a good foundation in getting IPv6 enabled and working on all the edge and core components of the network.

How long should the transition be?

When the work to IPv6-enable the most important parts of TLNTC was complete, I had a functional dual-stack network. But a number of influences made me start asking whether I really wanted the network to stay that way:

  • In 2013 Ivan Pepelnjak published a webinar with Tore Anderson, who set up an IPv6-only data centre the previous year, skipping a large number of transition steps.
  • In November 2020, the OMB issued M-21-07, which added even stronger mandates to their previous memo:

a. At least 20% of IP-enabled assets on Federal networks are operating in IPv6-only environments by the end of FY 2023;
b. At least 50% of IP-enabled assets on Federal networks are operating in IPv6-only environments by the end of FY 2024;
c. At least 80% of IP-enabled assets on Federal networks are operating in IPv6-only environments by the end of FY 2025; and
d. Identify and justify Federal information systems that cannot be converted to use IPv6 and provide a schedule for replacing or retiring these systems;

Completing the Transition to Internet Protocol Version 6 (IPv6)

When I read the mandates in M-21-07 I asked myself, “Why am I not ahead of the U.S. government in my transition? I have a simple, limited-scope network which I fully understand, since I’m the only engineer who has ever worked on it. How many people can say that about their enterprise networks? Surely I could be more nimble than they are?”

The IPv6 Buzz podcast talked about going IPv6-only on your guest wifi. (I think it was in their “Revisiting IPv6-Only” episode, but it might have been in “Our IPv6-Only Future“.) I thought that was a great idea, so I ran up a new VLAN and a new SSID and didn’t let any IPv4 in; it worked surprisingly well on the Android and Windows systems I had at my disposal.

But the real clincher for me was when I started looking at some server upgrades and network design changes and realised that I really disliked maintaining two sets of firewall rules. It was my last round of those firewall edits which really convinced me of the wisdom of Tore Anderson’s approach: the tools already exist for connectivity from an IPv6-only network to an IPv4-only world – why not just implement them now?

So the next few posts in this series will cover the design and implementation choices involved in TLNTC’s transition to an IPv6-only network. Next stop: IPv6 addressing plans!

When I got hackernewsed

A few months ago now I got a couple of friendly alerts from OpsGenie telling me that my web server VM was down. I logged in and poked around, but things seemed to be pretty normal. The OpsGenie alert self-resolved shortly afterwards, and I thought nothing more of it.

Then I got this little message via the comments:

Link for part 4 will not load. Server timed out. Tried 4x

After a bit more conversation (thanks Ned!) I found out that my NTP blog series had been linked to on Hacker News, and my server had received the “Hug of Death” as it’s sometimes called (we used to call it “getting Slashdotted” – back when that was more of a thing).

I checked the site stats, and sure enough:

Page view statistics from this site (by weeks)

So that explained the OpsGenie alert – when I saw the size of the jump in page views, I was honestly quite surprised it self-resolved as soon as it did.

It also surprised me to learn that so few people were aware of the Derek Zoolander School for Kids Who Can’t Read Good and Who Wanna Learn to Do Other Stuff Good Too, although, at least some people got it. 😊

Anyway, one of the comments hit a little close to home, so I took the time to get it right and put this site behind AWS CloudFront. It seems to be working well, but please feel free to drop me a comment if anything seems amiss. Subjectively, the site seems a lot faster from outside my network, but that may be just wishful thinking.

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 a particular 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).

A bad runner’s journey into bad running, part 3 – pushing for the 10K

[I originally started this post several years ago, but never got around to finishing it at the time. I think this instalment is more than overdue, and I hope to finish a few more over the coming weeks.]

A big change in my running came around October 2015, when my doctor did a routine blood test, and diagnosed fatty liver (like I didn’t know that already from the shape of my waistline?). He told me I needed to lose weight. He didn’t say how much or over how long, but I needed to lose some, then come back to him for another blood test.

That was the kick I needed. With a lot of support from my wife, I fired up MyFitnessPal, changed my diet, and managed to drop from 90 kg to under 78 kg over the following 6 months. Over the same period I set myself a goal of completing a 10K race, the Bridge to Brisbane. Running a 10K road race was a lot different from the running I had done so far (which was still 99% on the beach), and I was still not up to 5K without stopping, but I felt up to the challenge.

Getting to 10K was still a mental battle for me. When I think back on it now it seems quite strange, but at the time I wanted to stop all the time. I had to distract myself from the effort of running by playing mental tricks, including:

  • observing the environment and doing things like counting how many parrot or raptor species I saw
  • rehearsing entire albums in my head, including reciting all the lyrics and humming all the guitar solos to myself
  • visualising myself doing other fun things, like singing my favourite love song to my wife, or finally standing up properly on a surfboard

In the 12 months leading up to the Bridge to Brisbane, I managed 5K without stopping, did a couple of practice 10K runs, and covered a total of 423 km in training. However, I also managed to pick up my first significant injury, some upper shin pain which was at its worst going down hills. The B2B is a relatively hilly course, and I ended up running up the hills and walking down them. I was still reasonably happy with my result, and raised $400 for my chosen charity, Destiny Rescue.

Once I knew I could do 10K, I started making bigger plans. But first, I needed to overcome the niggling shin injury from my newly-formed habit of running in shoes on hard surfaces. My brother gave me the advice I needed in this particular case, and I’ve followed it ever since: don’t try to slow down on downhill segments – fighting gravity is a waste of energy and it’s really hard on your legs. Instead, let gravity naturally speed you up, and only slow down to stay in control. Obviously, I need to take into account my skill level, my shoes, and the terrain, but generally I’ve found this to be great advice.

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.