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.\u00a0 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 \u2013 no complexity added at all.\u00a0 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.\u00a0 I like to start somewhere in the middle, where there is some flexibility to get complicated if needed, but simple enough that I don\u2019t spend all my time managing networking.\u00a0 I also like to logically separate the \u2018home\u2019 network from the \u2018lab\u2019 network.\u00a0 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.<\/p>\n\n\n\n
I\u2019ve seen a lot of folks build logically separated networks for their labs. I\u2019ve seen others do stuff that I\u2019d consider crazy. Sure, you could make your internal network 1.1.1.0\/24 so that its very few characters to type, but don\u2019t try using Cloudflare\u2019s DNS service. Instead of re-using internet routable blocks of traffic, RFC 1918<\/a> dedicates three different ranges of IP Addresses for private\/internal use that you can pick from. They are:<\/p>\n\n\n\n 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\u2019ve 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\u2019d find in a real production environment. <\/p>\n\n\n\n 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.<\/p>\n","protected":false},"excerpt":{"rendered":" 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.\u00a0 If we are looking to gain a bit of experience with … Continue reading