Home Lab Networking

When building a lab network, it is helpful to put in a little time upfront and consider your learning objectives versus the complexity you can add into the system.  If we are looking to gain a bit of experience with products like vSphere or vRealize Operations, its possible we could deploy a handful of components into our existing home network, assign them static IP addresses and be done – no complexity added at all.  However, if we plan to dive deep into NSX-T, build overlay networks and configure routing, and we want to BGP peer with our physical network, we are going to be adding a bit of complexity.  I like to start somewhere in the middle, where there is some flexibility to get complicated if needed, but simple enough that I don’t spend all my time managing networking.  I also like to logically separate the ‘home’ network from the ‘lab’ network.  The last thing I want to do is make some DHCP or name resolution changes in my lab and the family can no longer watch TV.

I’ve seen a lot of folks build logically separated networks for their labs.  I’ve seen others do stuff that I’d consider crazy.  Sure, you could make your internal network so that its very few characters to type, but don’t try using Cloudflare’s DNS service.  Instead of re-using internet routable blocks of traffic, RFC 1918 dedicates three different ranges of IP Addresses for private/internal use that you can pick from.  They are:

  • [ through]
  • [ through]
  • [ through]

If you connect to a VPN for a large enterprise, it is very common for them to assign an IP from the or blocks.  When this happens, the VPN provided route statements may prevent you from accessing those same IP ranges if they are in use in your home network.  Because of this, I’ve historically leaned towards the range for home lab purposes.  This still gives you the ability to segment/subnet into smaller networks.  For example, I have a VLAN 10 that maps to and is only used for temporary lab VMs.  I have another VLAN 32 that maps to and is used for a handful of separate lab gear to represent a disaster recovery site.  All in I have about a dozen networks with 24-bit masks for various purposes, some routed and others not.  Some of these have very valid reasons, like logically separating storage traffic from guest traffic.  In other cases there is a bit of unnecessary separation for the production management workload VMs for things like vROps and Log Insight and virtual desktops.  At the scale of my lab this separation is not really required, I maintain the extra complexity for the sake of having extra complexity like you’d find in a real production environment. 

Once we have selected the IP address range(s) we will be using its time to start considering name resolution.  I have some thoughts on that as well, so be on the look out for a future post where we will dive into that.

This entry was posted in Lab Infrastructure. Bookmark the permalink.

One Response to Home Lab Networking

  1. Pingback: Simplified Home Lab Domain Name Resolution – Enterprise Admins.org

Leave a Reply

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


Notify me of followup comments via e-mail. You can also subscribe without commenting.