Network Simulation – Cisco VIRL Now Available in the Cloud

There has been a lot happening around VIRL the last few weeks. A new release of VIRL just got released and today the VIRL team announced that they are adding support for running VIRL in the cloud.

Cisco has chosen to work together with Packet, a bare metal cloud provider. This is how Packet describes themselves.

At Packet, we're out to build a better internet by supercharging the container revolution with smart, API-driven bare metal. Our platform brings the price and performance benefits of bare metal servers to the cloud, powering highly-available performance workloads through a unique, never-congested network.

The following picture summarizes why Cisco has chosen Packet.

Compared to Amazon AWS, Packet is a bare metal cloud provider which means that the resources you rent will be dedicated to you. Packet does not run any hypervisors, meaning that the workloads are not virtualized.

If you have an existing install of VIRL, you can use Terraform by Hashicorp to provision your new VIRL server at Packet. I had never heard of Terraform before, this is how Hashicorp describes Terraform.

Today we announce Terraform, a tool for safely and efficiently building, combining, and launching infrastructure. From physical servers to containers to SaaS products, Terraform is able to create and compose all the components necessary to run any service or application.

With Terraform, you describe your complete infrastructure as code, even as it spans multiple service providers. Your servers may come from AWS, your DNS may come from CloudFlare, and your database may come from Heroku. Terraform will build all these resources across all these providers in parallel.

Terraform codifies knowledge about your infrastructure unlike any other tool before, and provides the workflow and tooling for safely changing and updating infrastructure.

There is currently a promo at Packet, if you sign up you will get 25$ of credit accredited to your account.

The following picture shows the pricing of Packet’s services.

It’s likely that you will want to have the Type 1 install to run a decently sized topology. One nice thing about running VIRL in the cloud is that Cisco will double your allowed nodes according to the following quote.

We are also DOUBLING your node limit for free when you use VIRL on Packet.

I want to make something very clear about running VIRL at Packet. This is a bare metal solution, your workload is not virtualized. The resources you rent are dedicated to you. From the moment you start the install of VIRL until the moment you destroy your build, you will be billed for the usage. This means that it is not enough to simply shutdown the server and then resume it at a later time. You MUST destroy the build or you will be charged! The Type 1 install is 0.40$/hour and it takes roughly 30 minutes to install VIRL. I communicated with the VIRL team and they are working on reducing this to around 15 minutes. If you want to lab 4h, this means that you will be billed at least 4.5h including the install. This means that you can lab 2h each day for around 30$ per month. That is pretty competitive pricing for dedicated resources. Keep in mind though that if you forget to remove your build so it has been running a month, you would in theory be charged 24*0,4*30$ = 288$ which might not be what you expected. Luckily though there is something called the “Dead mans timer” which is by default set to 4h. This means that the server will be terminated after 4h. I’m not sure if the server will always terminate after 4h or if it’s after 4h of inactivity, my guess is the former. Here is how Cisco describes the “Dead mans timer”.

When a VIRL server is initialised, a 'dead man's timer' value is set. The purpose of the timer is to avoid a server instance being left running on the platform for an indefinite period.

The timer value is set by default to four (4) hours and can be changed by modifying the 'dead mans timer' value in the settings.tf file before you start your server instance. The value you set will be applied each time you start up a server instance until you next modify the value.

If your server is running at the point where the timer expires, your server instance will be terminated automatically. Any information held on the server will be lost.

You are able to see when the timer will expire by logging in (via ssh) to the server instance and issuing the command sudo atq. You can remove the timer, leaving the server to run indefinitely, by issuing the command sudo atrm 1.

It is possible to disable it but I wouldn’t recommend that. If 4h is too low, then try setting it to 6h or 8h or for the amount of hours you expect your longest lab sessions to last.

Always check in your Packet account that your build has been terminated even if Terraform reports that it has!

To get started with Packet, Cisco provides two detailed step by step instructions. The first instruction is for users with an existing VIRL server. The second instruction is for users that want to run VIRL without an existing server. There is also a video that describes the steps involved.

The basic idea is to install Terraform, register with Packet, spin up the server and the connect to it via OpenVPN. Do keep in mind that the install takes around 30 minutes so you should start the install before you need access to it.

I really like the idea of hosting VIRL in the cloud. My main concern is with the install time and the risk of people getting large bills when they keep their server running. The dead mans timer should take care of the second issue though. The Cisco VIRL team is working on making a faster install which is needed in my opinion. I would also like to see some form of tool where the server would get deployed for you to be ready at a certain time. Let’s say that you want to start labbing at 20.00, then the install would start 19.30 at the latest to be ready for you at 20.00. I’m sure this could be scripted together with a cronjob but it may be better if the VIRL team comes up with an official solution than for individual users to reinvent the wheel.

Cisco VIRL is making a lot of progress. This was the next natural step. The GUI is getting better and better and the new web GUI is a welcomed addition to start to get away from the VM Maestro client. Tools like packet capture are now available and the increased node limit has made it a much more useful product. My only wish for now is that some of the Cisco BU’s would commit to developing the images that are included in VIRL. The Nexus BU is lagging behind the teams supplying the IOS and IOS-XR images. Do keep in mind that VIRL only runs the images, the BU’s are reponsible for supplying them. If you want to see more and better images in the future, put pressure on your account team.