Vagrant for network engineer

August 5, 2018 yman

I can’t remember when I really stumble upon Vagrant, but since that I use it often in learning process. Giving that at work I face some software routers and Cumulus switches, Vagrant became one of the most useful tool in my toolbox. But it can easily goes beyond such learning purposes. And it this post I will show you why and how to start.

What is Vagrant

Vagrant is a command line utility which makes workflow with virtual machines much simpler and effective. It is not virtualization engine by itself. It uses already available software (called providers) like VirtualBox, KVM, Docker and others. Vagrant allows you to create, destroy, suspend and run VM images with simple commands from your terminal, without clicking through some GUI wizards. Want experiment with some potentially destructive shell scripts? You can spin up Ubuntu image in couple of commands. Need different distro or more machines? Just edit config file and here you go! So from first glance, Vagrant is effective way to play with VMs on you laptop (on any computer really) when you don’t need any GUI on VM, but if you really want you can get one too.

How it’s used

Most popular way to use it, which official web site [1] is conveying, is providing easy way to create development environments. It is ubiquitous software development problem to get environment which is equal to production one. And if we imagine any real world software development process there are most of the time more than one person working on a project. Vagrant helps them get identical to production environment accessible from anywhere because it is running on they laptops. One developer can create configuration file and distribute it to others, so all of them can run VM with all packages installed, and all programs configured. And by the way, most of the time that files stored in some VCS (version controll system, git is most popular right now). Such approach to develop and test software helps eliminate well-known problem “It worked on my PC!”.

What about networks

But why I am telling you about software development and such a tool? Most obvious thing is that most of us not only interested in networks. I am not supporting all that recent fuzz about “network engineers will be replaced by programmers”, but despite spending 80% of my “career developing” time on networking, I very interested in UNIX-like systems (Linux mostly), and programming (Python mostly). I am trying to advance my skills in that areas too and that’s, probably, how I learned about Vagrant in first place. But if it would be all about researching some FreeBSD specifics or testing my Python scripts, it will not be on that blog. How it can helps network engineer you ask? If your career spin mostly around some vendor blackboxes, it can help you shutter some barriers and open the doors to Linux packet forwarding for example. Playing with bird or FRR routing daemons, getting to know iptables packet filtering solution or even crank up DPDK and see where it can lead you. Not interested? Maybe trying Cumulus Linux in form of Cumulus VX [2] and see what it can give to your current network. Or your networking skills for your next interview. OK, it would be beneficial if you can supplement it with some vendor stuff. And you can! There is a way to get you hands on Arista vEOS [3] in Vagrant, Juniper vQFX [4] and even Cisco XRv [5]. And by the way, you can spin not only one VM with Vagrant (it would be boring), but create a topology.

There are other ways

Of course when we talking about building networking lab there are other software immediately pops up in our minds. Most of us already familiar with GNS3 or EVE-NG. So what’s different between them and Vagrant? First of all – ease of use. Installing Vagrant and spinning up a VM in my opinion is way easier than run GNS3, especially if we talk about Linux host. About anything other than Cisco 7200 took up some time to install and run in network emulators. Second – legal software already packaged for you. If you labbing at home trying to improve your skills or want just play with some installment in the middle of nowhere without access to your company EVE-NG-PRO your options somewhat scarce. Ever tried to run Juniper in GNS3 or attach Cumulus to your topology? I’m not a pro of GNS3 or EVE-NG, but even getting image of some Cisco router seems complicated to me. Want to try out Ansible or some other configuration management system? It’s built in Vagrant, and not so easy in emulators. In fact Vagrant can be a great starting point to acquaint CM system. What if you want to test configuration snippet before applying it to real network? You can spin up VM by Vagrant using script (Python for example), upload your config to it, test and than destroy VM. It opens up CI/CD possibilities for your network. There are real value in such a tool. Of course there are disadvantages. You have no GUI, so you probably draw you topology by yourself on a piece of paper. Because of that I can hardly imagine building really large topologies in Vagrant. And I know no way of getting Cisco 7200 router into. But I believe there is a way to convert CSRv image to compatible one.

Trying it out

Alright, with all that talk out of our way, let’s see how it works. As always good starting point is official documentation [6], but if you find it too boring there is a book [7], but keep in mind that it is somewhat outdated. First, you need to install some packages. I using Arch Linux, but because it’s not so popular distro I will provide you with Ubuntu command. Of course there are not so many differences.

apt install vagrant virtualbox

We will use virtualbox as Vagrant provider, so in background Vagrant will spin up Virtualbox VMs. Now create project directory like

mkdir vagrant-test

And than you can do inside it

vagrant init

This command will create Vagrantfile – configuration file for your project which describe all your VMs, network between
them, shared folders and some more. At this point of time you can do just

vagrant up

Wait for a while and than

vagrant ssh

Now you are inside virtual machine running Ubuntu image. You can do whatever you want inside and when you exit you will found yourself in your project directory. So what happened? When you issue vagrant up, Vagrant will read up your Vagrantfile, download any VM image that it doesn’t have already, spin up all configured VMs by means of provider (Virtualbox in our case). Than it will get ready and put temporary SSH keys so you can smoothly access you VM by vagrant ssh. Cool, but what if we want some other distro? Let’s open up that Vagrantfile and look inside. If you familiar with Ruby programming language you probably feel at home now. But if you not, there are nothing to fear. Just treat that file as config file (what it really is). Taking out all that comments it really boils down to this:

Vagrant.configure("2") do |config|
    config.vm.box = "base"
end

That base word is telling Vagrant to use default VM image, which is special version of Ubuntu distro. Try to change it to something else. What to choose? generic/centos7 or generic/arch for example. Want more? There are tons of images on Vagrant Cloud [8]. “Official” distro images is in generic branch. You can even prepackage you own images and use them. Why? Imagine you create VM with Debian running FRR and your own Django-based web interface to control it. You can wrap it up in Vagrant image, put it on you company Gitlab and spread it between colleagues! But let’s return to our VM, exit from it doesn’t mean it’s stop! You can see it’s status (and all of that project VMs) with vagrant status, destroy it with vagrant destroy or just suspend to save you progress with vagrant suspend. If you didn’t specify VM, Vagrant will choose default one.

Topology

But one VM is not fun, is it? Let’s build something more interesting! Take a look at next Vagrantfile (totally new, not additive to previous one).

Vagrant.configure("2") do |config|
    config.vm.define "cmvx1" do |cmvx1|
        cmvx1.vm.box = "CumulusCommunity/cumulus-vx"
        cmvx1.vm.network "private_network", ip: "192.168.13.1", virtualbox_intnet: "swp1", auto_config: false
        cmvx1.vm.network "private_network", ip: "192.168.12.1", virtualbox_intnet: "swp2", auto_config: false
    end
    config.vm.define "cmvx2" do |cmvx2|
        cmvx2.vm.box = "CumulusCommunity/cumulus-vx"
        cmvx2.vm.network "private_network", ip: "192.168.12.2", virtualbox_intnet: "swp2", auto_config: false
        cmvx2.vm.network "private_network", ip: "192.168.23.2", virtualbox_intnet: "swp3", auto_config: false
    end
    config.vm.define "cmvx3" do |cmvx3|
        cmvx3.vm.box = "CumulusCommunity/cumulus-vx"
        cmvx3.vm.network "private_network", ip: "192.168.23.3", virtualbox_intnet: "swp3", auto_config: false
        cmvx3.vm.network "private_network", ip: "192.168.13.3", virtualbox_intnet: "swp1", auto_config: false
    end
end

That config file will provide you with 3 Cumulus VX VMs connected in triangle like that:

Network topology with 3 Cumulus VX machines

Let’s get through it quickly. As you now can imagine CumulusCommunity/cumulus-vx is an image name, easy one. But what’s going on with that ‘network’ lines? For every VM Vagrant will create one network interface which looks like physical one and have private address (RFC1918). That’s how you getting in, not without NAT help. If you want to connect your VMs to one another you need to create more interfaces, which is done in ‘network’ part of VM configuration. There are some options to go with, but we interested in ‘private_network’. Vagrant want you to provide IP address for VM (or go with DHCP), so we put some addresses for every interface. ‘virtualbox_intnet’ will create new interface, naming are crucial here, because names is what connects your VMs. Setting ‘auto_config’ to false will disable automatic configuration of IP address if you don’t want give away that fun to Vagrant. Now you have something really interesting to play with! Just run vagrant up and than SSH to any machine (or to all from different terminals). And of course you can use that config to define some topology by yourself.

Conclusion

That’s just small introduction in what you can do with Vagrant, but it can help you start up something really interesting! Test your scripts, play with provisioning [9], or spin up some simple topology to experiment with. In next blog posts I plan to dive into some Linux routing and Vagrant is really helps me out in such a task.

DVJourney

endless quest for knowledge