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 1.1.1.0/24 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:

• 10.0.0.0/8 [10.0.0.0 through 10.255.255.255]
• 172.16.0.0/12 [172.16.0.0 through 172.31.255.255]
• 192.168.0.0/16 [192.168.0.0 through 192.168.255.255]

If you connect to a VPN for a large enterprise, it is very common for them to assign an IP from the 10.0.0.0/8 or 172.16.0.0/12 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 192.168.0.0/16 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 192.168.10.0/24 and is only used for temporary lab VMs.  I have another VLAN 32 that maps to 192.168.32.0/24 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.