As you may know, I am currently writing a series on BGP and how the Internet works, from my perspective as the operator of a small autonomous system, AS200351. While we haven’t really exhausted the theoretical material, I think I’ve covered enough to enable readers to set up their own basic autonomous system. Rather than forcing you to do your own research based on outdated and potentially incorrect information on the Internet, or allowing you to fall victim to scams, I think it would be wise to talk about the process of getting your own ASN.

For readers who haven’t read the previous parts of the series and are unfamiliar with why one might want an ASN, here’s a brief explanation:

An autonomous system (AS) is a constituent part of the Internet that can define its own routing to the remainder of the Internet, and ASes exchange routes with each other over Border Gateway Protocol (BGP) to form the Internet itself. By receiving a globally unique identifier, an AS number (ASN), which in my case is 200351, I can exchange routes over BGP with other ASes, announce my own IP addresses to the Internet, and control how traffic flows in and out of my network, as opposed to simply exchanging traffic from a default gateway to reach the Internet with an IP address assigned by my ISP. This comes with several advantages, such as being able to switch upstream ISPs at will (or when such an ISP fails) without changing my IP addresses or breaking a single connection; or to advertise the same IP addresses from multiple locations (anycasting) to allow users to reach my services with lower latency than otherwise permissible by the speed of light with automatic failover.

I will now share what I wish I knew when I impulsively decided to apply for an ASN at 3 a.m. on a cold December night last year, now that I’ve been doing this for a while. I’ll walk through the process as objectively and thoroughly as possible, demystifying the role of any player in this space. I would like you to go into this with full knowledge of the risks and a full understanding of where your money is going. In the end, I will offer some subjective suggestions on providers, but those can be ignored if you would rather do your own research.

In the first part of this series, we had a brief overview of what BGP is. Then last time, we dived into what autonomous systems (ASes) are and the relationships that can exist between them, as well as the existence of Tier 1 networks and Internet Exchange Points (IXPs). That provided a broad overview of the Internet’s structure.

However, so far in this series, we’ve talked about IP addresses—or really, IP prefixes and CIDRs—as if they are something that just exists. This mental model is no longer sufficient. Before we can truly understand routing, we must first understand how IP addresses really work—how they are assigned and who is authorized to announce them.

Last time, we introduced BGP as a protocol, but introduced the concept of autonomous systems (AS for short) and gave some examples. This time, we’ll dive deeper into the concept, which hopefully will give you a better understanding of the various types of ASes and how the Internet is organized on a global level.

But first, let’s start with how the numerical identifiers—the autonomous system numbers (ASNs)—work.

Border Gateway Protocol (often abbreviated BGP) is a critical protocol that makes the modern Internet possible, yet remains one of its most poorly understood parts even among its long-time users. At the same time, it has played a significant role in several high-profile outages on the Internet. As someone who has been running my “own piece of the Internet”—AS200351—for half a year now, I think the time has come to write a piece explaining exactly what BGP is, what AS200351 is, and how the Internet truly functions behind the scenes. We’ll start with the basics.

To understand BGP, we must first understand why it is called the “Internet” in the first place. To simplify greatly, the Internet is called that because it’s an interconnected network of networks (more precisely, autonomous systems, or ASes) glued together by BGP. Since this sounds like a nonsensical sequence of words, let’s dive a bit deeper.

In January, I upgraded my home Internet connection to 3 Gbps symmetric, because, strangely enough, it was cheaper than the package I already had at the time (1500 Mbps down, 940 Mbps up). This was connected to the second port on my ConnectX-3, allowing my home server to achieve the full speed where 2.5 Gbps Ethernet would have failed. Unfortunately, nothing I was doing could have harnessed the full speed of this Internet connection, or anywhere near it, so I started thinking…

In February, I realized that I could run a mirroring service for open-source software to serve the community at basically no additional cost—I am already paying for this 3 Gbps Internet connection and I have some spare disk space on my SSD. So I decided to do exactly that.

Today, I am happy to announce that this mirror, mirror.quantum5.ca, has been tested for a few months and is fully ready for production. If you find the service helpful, please feel free to support me via GitHub Sponsors, Ko-fi, Liberapay, or directly with credit card or bank through Stripe (CAD), though this is of course strictly optional.

If you are interested in how it’s all set up, please read on:

Last time, I built a stratum 1 NTP server with a PPS signal from a GPS receiver, synchronizing my server’s clock to within 10 microseconds of UTC. However, NTP was designed to synchronize clocks within a few tens of milliseconds over the Internet, and I’d be lucky to achieve millisecond accuracy on a LAN. I mentioned that PTP was the alternative that could achieve accuracy in the sub-microsecond range. Well, this time I’ll be setting up PTP between my server and my PC with the hardware timestamping on the ConnectX-3s.

If you are following along at home, don’t despair if your hardware can’t do timestamping or PTP. I will also attempt to set up PTP with software timestamping later for my other devices.

Naturally, I first turned to the gpsd documentation, since that was a decent reference for setting up NTP with the PPS signal. Well, this is what it says for PTP with hardware timestamping:

Sadly, theory and practice diverge here. I have never succeeded in making hardware timestamping work. I have successfully trashed my host system clock. Tread carefully. If you make progress please pass on some clue.

That didn’t sound encouraging at all. “Oh well, I guess I am on my own here,” I thought to myself. “How bad could digging through a few man pages and random online documentation be? Worst case, there is the source code, right?”

These days, it seems like everyone is posting about turning Raspberry Pis into a stratum 1 NTP server by hooking up a cheap GPS module, most often the GT-U7 u-blox 7 clone with a PPS (pulse-per-second) signal output, whose rising edge indicates exactly the start of a second.

While this seems like a cool idea, it suffers from one flaw—while the Raspberry Pi itself almost certainly has very accurate time, getting accurate time to the rest of the network would be problematic. This is because the Ethernet adapter on Raspberry Pis before the Pi 4 was hooked up via USB, and the polling nature of USB introduces jitter, preventing the accurate signal from reaching the rest of the network. Unfortunately, I only have a Raspberry Pi 3 model B in my possession, which suffers from the problem.

Now, I could have gotten a Raspberry Pi 4, but those aren’t priced sanely at the moment and it would be just an exercise in copying. Instead, I looked at the various alternatives. The traditional way of doing this kind of thing involves hooking up a GPS receiver into a serial port, which generates an interrupt. If the PPS signal is delivered to the DCD (data carrier detect) signal (as described in RFC 2783), then the in-tree Linux driver pps_ldisc is able to do the timestamping in kernel mode for the highest possible accuracy.

I found out that my server’s X570 motherboard came with a serial port header (labelled COM). This meant that I could buy some fancy GPS receiver with a serial port and hook it up. Unfortunately, those aren’t priced sanely either, so I decided to build my own with the GT-U7 module and a driver module for RS-232 (the common serial port standard).

This was late last year. I ordered the components on AliExpress and they all arrived in January, so I finally started this project.

2022 was certainly an interesting year. While the world events were rather depressing, we are not here to talk about them. Instead, let us explore what I did this year—if just to help me remember it years down the line.

In January, I ended up messing around with my domains. I wrote about this in a previous blog post, but here’s a summary: To improve email delivery, I moved this website from quantum2.xyz to quantum5.ca. Furthermore, I saw qt.ax was open for registration, and registered it to use as my URL shortener. While switching to quantum5.ca was a relatively straightforward procedure, registering qt.ax at a rather steep price of €32/year would bring about a rather interesting sequence of events, as we shall see later.

I also talked earlier about my globally distributed backend, which in January consisted of three nodes: Montréal, Amsterdam, and Sydney. By the end of the year, this would change significantly.

In February, I implemented my own version of the French Republican Calendar for fun, which spawned a whole series of posts on the subject. At the end of the month, AMD dropped the retail price of the Ryzen 9 5950X, at which point I impulsively bought one to replace my 3900X, which would have some interesting consequences.

Last time, we discussed how we might add a real GPU to our Windows virtual machine. Today, we’ll discuss how to view this virtual machine without using a dedicated monitor or switching inputs, but instead integrating it into the Linux desktop like a normal application.

There are three steps:

1. Configuring the virtual machine.
2. Installing the Looking Glass client on the host machine.
3. Setting up Looking Glass host application on the virtual machine.

Without further ado, let’s begin.

Last time, we discussed how we might create a Windows virtual machine as part of a series on running a Windows VM with native-level graphics performance via GPU passthrough and integrating it seamlessly into your Linux desktop via Looking Glass. Today, we shall turn that normal Windows virtual machine into something far more interesting by giving it a real GPU.

As far as Windows is concerned, the GPU is real hardware and can be treated as normal, so we will not go into too much depth. Most of the work lies on the Linux side, where we must do some work to make sure the GPU is free for the VM to use, and then instruct the hypervisor to use it. Again, we will be using the standard QEMU/KVM setup, managing our virtual machines with libvirt.

Naturally, the same procedure here can be used for any other PCIe device, such as NVMe SSDs. Let’s begin!