When I started out writing books for IT professionals many years ago, I knew I needed lots of hands-on experience to make them useful. I gained some of that experience firsthand working as a LAN admin and webmaster and doing consulting. I gained additional experience second-hand from the on-the-job experience of other IT pros I had contact within our community and as I traveled around. But most of the experience I had with new products was gained in the lab I built, which was originally located in one of the guest bedrooms of our home. By using computers and networking gear I bought or scrounged, mostly second-hand to keep expenses down, I built physical networks that mirrored the kinds of production networks used for deployments, messaging, clustering, load-balancing, and even WAN links. Then along came VMware and Hyper-V and pretty soon I retired most of my physical systems for a couple of high-end RAM-heavy servers. By using these servers as virtualization hosts, I could now create complex virtual networks quickly and easily instead of having to lug heavy boxes around the room or crawl under tables untangling network cabling. Gone were most of the computers, Ethernet switches, routers, KVM boxes, and other hardware. Gone too were the dust bunnies that relentlessly collected inside them. My allergies improved a lot after that!
Advantages of a virtual network lab
Simulating physical networks by creating virtual environments that mirror them has some definite advantages, but also has some limitations you need to be aware of. The main advantage is their usefulness for testing network design concepts, and you can do this in basically two different ways: you can build a virtual network that simulates an entire physical network — or a large portion of it — though at a lower resolution of the actual physical network. Or you can build a virtual network that simulates a small portion of a physical network at a very high resolution. And while these are not theoretical limitations — in principle, you could build a virtual network that exactly mirrors the physical network you’re planning to build — the reality is that practically speaking you won’t be able to do this because of the cost of the compute and storage resources you’ll need, even though that cost will still be far less than what it would cost to build a suitable physical lab for your project.
Virtual labs are also a great way of fleshing out an emerging idea you have for network design. You can experiment with various subnetting arrangements and protocols, you can test various topologies and try out different approaches to managing your network.
Limitations of a virtual network lab
Once you’ve set up your virtual network lab you can use it to study things like the traffic patterns that your planned physical network is expected to experience. Virtual network labs are really good for doing that, they let you see what happens to the traffic flow when your design changes or when you add new systems and networks
What virtual network labs are generally not good for, however, is for performance testing, because the actual hardware used for the physical network comes into play here in a major way. For example, the firmware version of a network device may be a factor in its performance, and virtual devices can’t mirror this aspect of physical hardware. They’re also not very good when it comes to scale testing, that is, for determining how many routes or sessions you need to support different types of traffic.
Orchestration also becomes an issue if you’ve set up a home-grown virtual network lab and you’re trying to simulate a complex physical network. Assuming that your lab has the compute resources needed to run lots of routers, firewalls, and switches along with various hosts and clients, reconfiguring such an arrangement to test different scenarios will be a headache without proper orchestration tools. Once your virtual network contains several dozen nodes, using a home-grown lab solution is generally going to be impractical.
You also can’t use a virtual network to ferret out code bugs or quirks of network devices from different vendors. You usually need to use real physical hardware if you want to do that sort of thing.
Tools for network simulation
Fortunately, you don’t even have to roll your own virtual network lab anymore. There are some tools out there that are available that you can use to easily create and work with virtual simulated networks. One tool I highly recommend is GNS3 which is used by several of my colleagues for simulating and testing networks of all shapes and sizes. GNS3 is open source, free software and is actively supported and being developed by a growing community of network engineers around the world. By using GNS3 you can virtualize real physical hardware devices to an amazing extent, including network hardware from companies like Cisco and Brocade and even various Linux appliances. GSN3 even includes a well-documented JSON-based API you can make use of for scripting such things as the various kinds of connections in your network. This capability makes it relatively easy for you to programmatically generate different kinds of network lab scenarios you want to test or study.
EVE-NG is another great product for multivendor network emulation. And since it’s a clientless solution it can be run in a completely isolated environment without problems even if your corporate security policies place restrictions on building testbed networks. EVE-NV is used by a wide range of enterprises, e-learning providers, and collaborators to create virtual proof of concept networks and for building solutions for training environments. Individuals seeking various networking certifications can use it to train themselves in how to use networking hardware from vendors like Cisco, Juniper, CheckPoint, F5, and others.
One more thing
Let me end with one final tip about building virtual network environments. A good approach to follow is to have at least two different environments handy for use at any time. Your first virtual environment can closely resemble your production environment. This can be useful on a daily basis for testing purposes when you want to make small changes to the design or operation of your production network. Your second virtual environment can be one where your architects can plan and try out strategic changes to your production network. For example, you might be planning a large migration project or considering the integration of two different networks. Your second virtual environment will be a good place to start working on these projects.
Featured image: Shutterstock
