Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

9 module online course

Start now!
back to overview

Using Virtual Labs When Developing Network Automation Solutions

One of the fundamentals I always emphasize in introductory parts of my network automation workshops and online courses is the fact that we’re about to develop software that will control the most-mission-critical part of IT infrastructure, and should therefore use software development methodologies like version control, testing…

However, there’s a “small” glitch. While it’s perfectly possible to test most software in some virtual environment you can spin up on-the-fly using Vagrant, Docker, Jenkins, Travis, or some other CI/CD tool, testing a network automation solution requires access to network devices.

Using virtual labs seems like the only viable approach in most cases, and while we covered all sorts of error handling, data validation, testing and CI/CD topics in the network automation course, we never focused on virtual labs.

We’ll fix that in Spring 2019 course in which two guest speakers (Matt Oswalt and Kristian Larsson) will focus on using virtual labs. This is what Matt had to say about the topic in an interview with Christoph Jaggi:

What is the main purpose of building a virtual lab instead of a physical one?

Physical labs require a lot of power, space, and cooling. They’re difficult and timeconsuming to change and are usually quite costly to initially acquire as well as maintain longterm. Virtual labs can take advantage of the consolidation brought about by server virtualization by running network devices as virtual machines, connected with virtual “wires”. If you’re not trying to validate actual hardware, running a virtual lab can be a more flexible, less costly alternative.

Would you use a virtual lab for learning, or can it also be used for testing or validation?

Learning is definitely the biggest use case for a virtual lab either learning the platforms themselves, or as a target for learning automation tools on top.

In terms of validation or testing, this largely depends on what you’re trying to test or validate. If you’re making configuration changes, or writing a script to gather data from all your network devices, this usually only involves the management plane. In this case, a virtual lab is perfectly appropriate for testing, because the differences between a physical and virtual lab with respect to management functionality is usually minimal or nothing.

However, if you’re trying to validate anything to do with the data plane, such as trying to replicate a hardware bug, or make certain performance benchmarks, you’re likely to run into significant differences that make this testing less valuable. In this case, it might be worth considering a physical lab, if exact realworld testing is what you’re after.

Virtualization in combination with virtual appliances makes it possible to run complex setups with different elements on a single machine. Can such a virtualized environment provide the same functionality and the same results as an environment that uses dedicated hardware appliances?

Again, in many ways, yes, but it still depends on what you’re using the lab for. There are some use cases that just simply can’t be faithfully replicated with virtualized hardware. Other use cases don’t really depend on hardware features or performance, so for those use cases, virtualized is just fine.

Does a virtual lab also support the addition of a packet analyzer for realtime network analysis at linerate?

Absolutely, and any other tools you might think of. The benefit of standing things up virtually is that you’re not limited to just using network devices; you can absolutely add tools like packet analysis to get used to how they integrate together. Again, the performance characteristics shouldn’t be expected to be consistent between a virtualized and a physical topology, but building out a proofofconcept in a virtual lab first will go a long way towards making sure that a physical PoC goes well.

Want to know more? Register for the Spring 2019 Building Network Automation Solutions online course.

Please read our Blog Commenting Policy before writing a comment.

4 comments:

  1. Proper initialization of interfaces and handling of different naming are the two biggest challenges I face when going from Virtual POC to Physical Appliances

    ReplyDelete
    Replies
    1. Totally agree - and Cumulus is (AFAIK) the only one that doesn't have this challenge.

      However, that applies primarily when you try to simulate your production network in a virtual lab. Even without that, the virtual lab might still be useful to test your automation solution.

      Delete
  2. This is exactly what I ran into last week. In trying to set up a new lab environment for various automation tests I thought I'd revisit the various vendors' virtual offerings. Cumulus VX and Arista vEOS are pretty easy, both in getting a (free) download and booting up some virtual appliances. Kudos. But e.g. JunOS, IOS-* and NX-OS on the other hand are a challenge (read: I gave up, especially on a vendor who claims they provide a 'free' edition that nonetheless requires a maintenance contract ?!).

    I don't understand why vendors don't seem to get that labbing shouldn't be a business model. It's in everyone's best interest to be able to run infrastructure deployment pipelines with daily builds, CI/CD, etc. For that we need access to easy to set up virtual labs. Yes, there are cloud and hosted offerings but that rather limits automation and CI/CD use cases. If vendors are afraid I'm going to use their virtual appliance in production environments: by all means, limit a free edition in e.g. throughput or number of ports. Don't limit the feature set though. (which reminds me of a certain vendor where OSPFv2 is included in the standard license and OSPFv3 - IPv6, requires an expensive license. WTH?).

    But I guess the cloudy pay-as-you-go and subscription era only brought us new business models, not more cloud-native-software-like benefits.
    Real SDN should also include thinking and acting like cloud native software (delivery teams).

    ReplyDelete

Constructive courteous comments are most welcome. Anonymous trolling will be removed with prejudice.

Sidebar