Home Lab: The Network

A key component of any IT engineer’s toolkit is the lab. This can be at the office if you’re not the type to work from home (if you’re not, I highly recommend it – Productivity is so much better when you’re not in an office). or the ubiquitous “home lab” that most of us have (even if we don’t work from home), which can be anything from a haphazard pile of machines on a shelf, to a lovingly built rack full of gear that would look perfectly at home in any enterprise data center.

The entire purpose of the home lab is to give you an environment in which to tinker, and break stuff. It also often forms the foundation of the tech infrastructure for the other people who live with you, although the people in my house sometimes wish it was separate and insulated from my tinkering. They’ve also instituted a change freeze for 2 weeks prior to me leaving on a work trip.

The foundation to all this is the network: Routing, Switching, Firewalls, Monitoring, and Internet access.

Routing and Firewalls

One of the quickest and easiest ways to get your home lab up and running is to let pfSense handle the day to day routing – It’s easy to install, powerful enough to do what you need it to, and it will run on just about any old hardware you have lying around, or something you can buy online for cheap – NUC boxes, spare PCs, older servers, etc. My current pfSense box is a Gen7 HP DL360, which is complete freaking overkill (like using an Abrams tank for mosquito control), but it was $130 on Amazon, and it came with 4 Ethernet interfaces.

If you’re using a software-based router like pfSense, resist the temptation to virtualize it. When the virtualization host goes down, your network goes down with it, along with any ability to remotely get into the network and fix it. I don’t recommend this. It’s especially annoying when you’re literally a thousand miles from anywhere and the only other occupied man-made vehicle within sight is the International Space Station. (yes, this actually happened).

If you have access to an actual router/firewall appliance, you can also use that. There are many options from the likes of Aruba, Fortinet, Palo Alto, Barracuda, etc. Work with what you have available to you.


aka, the Internet… If your ISP offers a static IP address, or even a highly stable dynamic address, this will simplify remote access. It also helps when it comes to tech support if you have a good relationship with your ISP and they know you’re an engineer – this helps bypass the tier 1 script kiddies manning the phone firewall, and it also gives you a certain amount of grace and understanding when they see traffic patterns on your link that might otherwise raise some red flags. “No, I haven’t been hacked, I’m just trying out some new stuff!”. This may be tricky if you’re stuck with a giant cable behemoth that struggles to care about individual residential clients. I am extremely fortunate to have a locally owned ISP that offers static IPs and a direct pipeline to the support engineers.

See if your WAN provider allows multiple devices on the WAN link, and how many. Even if you’re on a cable modem, some providers will allow multiple MAC addresses to connect via a switch. I have a fiber terminal on the outside of the house that has four Ethernet ports: two of them are provisioned for my static addresses, and the other two are provisioned to allow multiple DHCP clients, which is incredibly handy when I need to lab up some of our SD-WAN stuff. I just trunk each one into the wiring enclosure and cross-connect them from there.


This is where things get fun. I currently have the LAN set up for the following:

  • Management Network
  • 3 Lab Networks
    • Used to isolate various projects from each other. Can add more as needed.
  • Home Network
    • Printer
    • TVs
    • Media server
    • Wireless connections for the people who live with me
      • Wireless uses enterprise authentication/encryption
  • IoT Network
    • Any IoT stuff goes here. That isolates it from the home and management networks. It is only able to access the internet, on a limited basis.
    • Wireless uses PSK encryption (hoping to move this to MPSK and MAC auth soon)

Because a lot of devices default to 192.168.something or 10.something, I operate in the 172.something space defined by RFC1918 – this keeps badly designed defaults from screwing things up, and also doesn’t screw me up when I am using a VPN connection to work and/or a client that uses the same address space. I’ll typically use the VLAN ID as the third (and occasionally the second) octet of the network.

I currently have 7 switches in the environment. Because of all the VLANs, these need to be managed switches, but I can’t really picture a scenario where someone with a lab would actually want to use unmanaged switches.

  • HP 1810-24G (J9450A) : Handles management interfaces like ILO, UPS management card, and a couple of IoT things that don’t require huge performance.
  • HP 1810-8G (J9802A) : Usually for spots where I need multiple ports or to break out VLANs. These are conveniently able to be powered from a PoE port on the upstream switch.
  • HP 2915 (J9562A): This is basically the “core” switch – this is where the other switches, VM hosts, and router are connected.
  • Aruba 2930F-8G (JL258A): I have two of these – these typically feed the access points. They are managed, like the APs, with Aruba Central.
  • Ruckus ICX7150-C12P: This one feeds all the stuff in the house. Managing these is a pain in the butt, but it’s a decent switch otherwise.
  • Foundry FastIron SX800: This is the great-great-great grandfather of the ICX switch. Its sole purpose right now is as ballast (it weighs around 100 lb)

Next phase of building out the lab network will be to move everything to 10-Gigabit Ethernet.


Just like in any environment, neat and tidy wiring makes management a lot easier. I have a color code I try to stick to for patch cables. I’m a big fan of the Monoprice SlimRun patch cables: They’re inexpensive, of good quality for the money, and they’re a lot easier to manage. For your wiring in the house and the lab, It’s always good to follow BICSI best practices, if for no other reason than as an engineer, you should at least be familiar with them.

Velcro is your friend. I’m a big fan of Rip-Tie’s RipWrap product. It’s slim, plays nice with the slim cables, and isn’t overly expensive.

When it comes to bulk cable, I am a big fan of Commscope Uniprise, although Superior Essex comes in a close second, especially since it’s made right here in Kansas. Don’t waste your time with any bulk cable from Amazon or Monoprice – the shipping alone for a box of Cat 6 prices them out of competing with your local supply house (I’ve been a fan of Accu-Tech for nearly 2 decades, HMU if you need a contact there)

For termination, I generally won’t use anything but Panduit’s Mini-Com stuff (major exception is anything going into a structured wiring enclosure, since Panduit doesn’t make any brackets for those. If you have some metalworking skills, you could probably adapt something, as most of the Mini-Com line is designed around the standard 1.38” x 2.71” knockout hole found on almost any modular office furniture.) The Panduit terminations are a little more expensive, but it’s easy to use and you never have to worry about it failing on you. I own a set or two of modular plug (Don’t call them “RJ45”) crimpers and probably have some plugs, but it’s been years since I’ve actually used them – Making your own patch cables is a complete waste of time, and any installed cable should always be terminated to a jack.


This starts to veer into servers (which will be covered in a future post), but you probably want to monitor your network. If for no other reason than the fact that dashboards look cool. SNMP has been the standard way of monitoring server infrastructure for decades. While there are numerous tools out there such as Cacti and LibreNMS, nothing does visualizations quite as impressively as Grafana (which isn’t really an NMS in and of itself, but merely a rendering and visualization engine that can pull all kinds of data from all kinds of places. As SNMP starts giving way to REST APIs and webhooks, This is the future.)

I currently use InfluxDB as my time-series database (RRDTool is so last century), with Grafana visualizing the data, and an assortment of things collecting data, including Telegraf for collecting SNMP. I’m gradually adding some API calls for other stuff like VMWare and Aruba.

Stay Tuned for the next installment: Servers. In the meantime, please share your home lab networking stories, tips, and comments below.

Featured Image: Reddit User u/HotSchmoe in r/homelab

0 Comments On “Home Lab: The Network”

Leave a Reply

Your email address will not be published. Required fields are marked *