Another year has gone by, and another VCF has happened. This was the largest VCF in history, occupying the entire 100,000 square foot Discovery Hall at the Schaumburg convention center in Schaumberg, Illinois. It featured an unprecidented number of exhibits, guests, and talks, and ran from September 11th through the 13th. In this post, I’d like to talk a look at the IP network, and the technologies that supported this massive show.

This is the third year I have stood up SneakyNet, my fake telephone company at the Southwest Vintage Computer Festival. SneakyNet supplies dial-tone and IP transit to exhibitors around the show, and does so with a mix of period correct and modern hardware. I thought it would be fun to take a step back and talk about how this whole network is put together, and how things actually work.

Before we dive too deeply, more documentation than you could ever want can be found on the main SneakyNet docs site: https://docs.sneaky.nonroutable.network/.

I have recently been doing a lot of work with Cisco IOS Interactive Voice applications written in TCL. This is a dated technology at this point, but still a very stable one. In my application, I wanted to be able to have a duration spoken aloud. Getting the duration itself is not hard, IOS provides a robust timer system to meter calls and set deadlines for actions. Speaking the duration on the other hand is much harder because the Cisco ISR platform lacks the hardware for real-time speech synthesis.

In the last post I showed how my cluster is maintained day to day and using various industry standard tools. This is a fairly robust process as I build out the cluster, but just having a cluster isn’t particularly useful. To build upon this we need to put up a means for outside network traffic to come into the cluster and become inside network traffic. This traffic might be HTTP destined for a service, TCP as a lower level application protocol, or some kind of UDP ingress to a specialized application.

In the last post, I talked about how I setup my Nomad cluster running on bare metal using Void Linux and Ansible. I talked a lot about the basic design, but not how I actually executed on that design. That’s what we’ll get into in this post.

There are 3 main elements to configure in the cluster. First, the network, routing, and data-plane needs to be configured as a foundation that can be used to PXE boot the rest of the fleet, and then managed on an ongoing basis. Second, the Operating System (OS) on the servers needs to be configured to run the services that will make this selection of machines into a Nomad cluster. Finally, Nomad itself needs to be configured with security policies and other runtime tweaks to suit the applications that I want to install into the cluster.