Building Your Own Virtual Lab

Last week we published Matt Oswalt’s thoughts on using virtual labs in training and testing. In the second part of his interview with Christoph Jaggi he talked about building a virtual lab.

Matt will cover the same topic in way more details in his guest speaker presentation in Spring 2019 Building Network Automation Solutions online course. Register here.

What are the musthaves if you want to build a reasonably large network topology in a virtual lab?

Remember that virtual network devices are effectively appliances you run in a virtual machine, and the desired system requirements are usually fairly heavy. Many network operating systems require at least 4GB of RAM and 2 cores. If you’re looking to run a handful of devices, most modern laptops should support this.

However, for very complicated topologies, you’re going to quickly run out of available RAM. For this case, it might be better to either invest in a dedicated server with many more resources, or look at a hosted option like Networktocode’s Labs, or Juniper’s Cloud CCL.

How would a relative newbie build a virtual lab?

I’d start small. The concepts of virtual machines and their connectivity don’t change too much between topologies of two nodes vs topologies of 20 nodes. Start with a tool like Vagrant, and search for your favorite vendor to publish Vagrantfiles containing prebuilt topologies that you can simply run with “vagrant up” and start a functional lab on your laptop. Once you have it all running, you can start to reverse engineer how its built and think about how you might customize it.

Which tools do you recommend for setting up a virtual lab?

On the lowend, Vagrant is a good tool for being able to easily spin up a simple lab topology on your laptop. If you want to dedicate some beefier hardware, tools like Wistar, GNS3, and EVENG are good for simplifying the process of instantiating a virtual lab and ensuring a complex topology is connected in the right way. Finally, you can also pay for hosted options I already mentioned to take away the burden of maintaining the lab, so you can just focus on learning.

How does a relative newbie best approach the use of a lab?

Similar to a previous answer, start small, and first understand why you’re building a lab, whether it’s physical or virtual. Know what you’re trying to do, such as learning a specific platform or technology, or if you’re building some automation tooling and need a valid target to test against. Understand that no lab environment can perfectly mimic production, so also don’t view it as a panacea, or a replacement.

6 comments:

  1. Is this content sponsored by Juniper?
    Replies
    1. I used to use JUNOS based VM to build PoC labs many times.
      It was a failure when I switched to the real HW - the behavior of failure & recovery scenarios, BFD timing, multicast implementation is different.
      To my understanding: too many features rely on hw (slow path vs fast path packet processing). There differences in implementation & optimization between HW and VM.

      Probably there are rare case where the effort in the virtual lab is worth the time spent on. Even the education is questionable - I prefer learning "real" behavior of the devices...
    2. @Anonymous: you're slipping. I know it's hard figuring out a snarky remark or insult for every day of the week, but you should really try something more intelligent.

      @Gogus: Agreed. Management- and Control plane features usually work as expected, data plane (in particular packet forwarding) is a hit-or-miss, more so in devices that do hardware-based forwarding in real life.
  2. Can a participant without access to hardware devices benefit from your course as much as someone with a hardware lab thanks to this virtual lab? Will there be some fees required to build the virtual lab?
    Replies
    1. Most participants build their own virtual lab using whatever virtual devices from $vendors they use in production networks.
  3. Been building virtual labs for years for passing exams or to demo to our customers how automation can change their lifes. Nowaydays i build everything in EVE-NG, vMX, CSR1k, Fortigate, Arista, Ostinato, etc, etc. The control plane behaves the same and even the dataplane is quite robust if the vendor supports it.

    1) Build a webportal
    2) Use netconf/restconf to do network wide transactions
    3) Demo / POC
    4) Build in production
Add comment
Sidebar