Herding Packets

For at least the last decade, something that experiences extraordinary popularity on the Internet has been said to go “viral.” Was Cisco anticipating the potential for enormous popularity when coming up with the name for the Virtual Internet Routing Labs? After getting a chance to try it out at Cisco Live, I’m thinking so.

This year’s Cisco Live saw a number of interesting product announcements, but one that made a lot of buzz among serious geeks was VIRL. In a nutshell, it’s a software-based lab environment which can run a number of Cisco routing and switching platforms. Think GNS3, but official, without licensing concerns, and capable of running current-generation software. VIRL actually goes far beyond what GNS3 is capable of, as I describe in this article.

Under the Hood

There’s an important difference between VIRL and Dynamips (which is the underlying engine behind GNS3): while Dynamips emulates Cisco hardware and runs the actual binaries that are loaded on real equipment, VIRL takes advantage of the fact that Cisco has recently been producing native X86 builds for several platforms either for internal use or for virtualization purposes. Those familiar with the current version of the CCIE R&S lab may have experienced “IOU” (IOS on Unix) or heard of “IOL” (IOS on Linux), which is along these same lines. This has several consequences.

First, this means that hardware-specific features such as some QoS features or commands that examine hardware resources are not available. Second, these binaries are not the *exact* same binaries as those that run on real gear (though they are compiled from the same code) so there is the potential for slightly different behavior. Third, because these native builds are not dependent on instruction-level emulation, they are comparatively less-CPU intensive than Dynamips. As anyone who has ever built a Dynamips study lab knows, balancing good behavior with reasonable CPU utilization can be a fine art. VIRL doesn’t have this as the code is native to the platform it is running on and thus you don’t have to burn CPU cycles emulating idle loops and things of that nature.

So what tools are Cisco using for VIRL? The entire system runs on something called VM Maestro, which provides a UI for setting up the lab and doing some configuration. Within this framework, several flavors of Cisco software platforms can be run. They include:

• vIOS, which certainly appears to be IOU/IOL (for those familiar with that)
• vNXOS, which seems to be Titanium (for those familiar with it)
• IOS XE via the CSR1000V (I’ve also seen this referred to as ‘Ultra’ in the UI)
• IOS XR via something I’ve seen called ‘XR4U’, or ‘XRVR’ (I’ve never heard of anything like this “in the wild”)

Note there is no vCatalyst or anything like that. You should get some switching configuration capability through the NXOS piece, but since Catalyst switches are so completely dependent on their hardware, trying to make a software version of that code just doesn’t fly. Anyone who has seen/touched L2IOU knows that even that is a pretty rough switching emulation.

Behind the Wheel

At Cisco’s Walk-In Self-Paced Labs booth in the World of Solutions at Cisco Live, there was a table set up with a couple of VIRL workstations. I think earlier in the week these were used for more for walk-through type demos, but when I visited on Thursday morning shortly before the WOS closed to try to get my hands on VIRL, I had relatively free reign to play with the software for a bit. I also had a great conversation with Joel Obstfeld, a Director of Engineering who is heavily engaged with (leading?) the VIRL project within Cisco regarding how the platform could be used and what I thought of some of the features. Joel was so interested in getting my complete feedback back to the devs that he took video of our conversation to send to them!

The short version: I was blown away. It’s awesome.

The long version (unfortunately without any screenshots): Once VIRL is loaded up, you have a multipaned workspace in which you can drag different device types around and connect them with Ethernet links (no serial link support at this time). On the left is a narrow pane with your set of saved topologies that can be loaded up. These looked like they could be organized into folders. The large middle pane provides the workspace to arrange your devices, drag links between devices and that sort of thing. The right-hand pane is split horizontally and shows details on the devices in the topology, lets you select devices for console access, offers the AutoNetKit dialog (explained below), and is where the console windows appear by default. I’m pretty certain the Cisco staff said you can redirect console output to other terminal programs.

One thing I thought was really nice was that the tools for building your layout were very helpful. There were alignment buttons and things of that nature to make a nice looking diagram, which anyone who has spent too long trying to make a nicely aligned topology in GNS3 knows is a nice touch.

Topologies can be saved and loaded from a library on the left. Apparently these will also be shareable in some manner, at least in some delivery options.

In addition to the “network diagram” layout, you can hit a toggle button to switch to a geographic view. This lays down a map background from OpenStreetMap and allows you to drop your devices on the map to depict physical location if you’re prototyping or simulating a real life network. The cool thing is that the coordinates used to locate the device when in geo view are latitude and longitude, while in diagram view it’s a simple X/Y. But both sets are stored with the object, so you can easily toggle back and forth between a nicely aligned logical view, and a geographic location view and the devices slide into the correct positions for each view. Very slick.

Much like the “cloud” function in GNS3, you can connect these virtual devices to the real world in a couple ways. One is simply with NAT through the host. This would give your virtual device the ability to reach the real world, but not necessarily provide full L2 connectivity. There was also an object type in the drag-and-drop toolbox called “Actual Hardware Asset” and I believe this will be for bridging in a connection from real gear (that would make sense based on the name!). I stressed the importance of these hybrid topologies while talking to Mr. Obstfeld, for connecting either traditional Catalyst switches to the mix (like I had to do for my CCIE study lab), or connecting other devices that may not be easily emulated such a wireless access point for prototyping or lab validation.

I asked Mr. Obstfeld whether “generic” VMs of some kind would be supported in this environment as well, and he said they could be. Here, I’m thinking how handy it can be to boot up a tinycore Linux image to act as a test host, or even other virtual appliances that we may want to experiment with such as a vWLC or a vAppliance from other vendors like F5, A10, Vyatta, or anyone else.

Once you’ve instantiated a few devices, you can choose to boot them right up and access their console port, or you can use a very cool feature called AutoNetKit. AutoNetKit is designed to speed up the basic (and some not-so-basic) configuration of the devices. This feature allows you, through the VIRL UI, to set IP parameters for interfaces and even configure routing protocol parameters. So rather than manually configuring IP addresses and OSPF on all your lab devices at the CLI, you can use the GUI to set the IP interfaces, identify the OSPF parameters, and generate/apply a configuration. You can even configure BGP AS and peering info. I see this as a potential time-saver when trying to get a lab topology laid down quickly to test something or look at an advanced feature. If I’m trying to find out how IOS reacts when I modify a specific BGP peer parameter, I don’t necessarily need to spend 30 minutes laying down IP addresses, IGP setup, BGP peerings, etc., just to check and see whether marking a BGP peer as a route-reflector-client resets the peering.

Once your lab is booted, it works like you’d expect. You can console into each device and work with it just like you’d expect. But another interesting feature was called the NeXt GUI. This was a browser-based view of the network, very nicely rendered, which provided advanced filtering options for the view of the topology. So it would start with a view of the network diagram topology from the VIRL UI, but then you could open up filtering categories, like IGP, BGP, MPLS, etc., and then pick filtering options beneath those. For example, you could filter for nodes that are OSPF routers in areas 0 or 4. I think you could even select to filter for OSPF ABRs. Or within MPLS, you could filter by role (CE, PE, P), or nodes that carried a specific VRF. When you applied the filter, the nodes meeting your filter criteria would remain rendered brightly. The rest of the topology would be dimmed. I see this as a very useful tool for trainers who might be trying to direct students attention to a subset of the topology for discussion. I also wonder if this may eventually be worked into the CCIE lab in the massive troubleshooting section so they can easily highlight the specific devices involved in a “ticket.” I could even see it being useful if trying to troubleshoot a modeled network by letting the user hone in on potential trouble spots as they dig deeper until they narrow the issue down to just one or a couple devices that meet some set of criteria.

Getting the Keys

Unfortunately, VIRL has not been released yet, but the rumor mill seems to be settling on an early 2014 release. My understanding from several resources at Cisco Live is that it will be available in several flavors:

1. A hosted version integrated with the Cisco Learning Labs offering, where you buy a number of rack hours. This is the “bring your own topology” option for Cisco Learning Labs that many people have been asking for.
2. An appliance (probably a UCS server or similar) to use on-premise for large organizations that may need multi-user access.
3. A virtual appliance that could run on a laptop/workstation.

Many people at Cisco Live seemed most interested in #3, of course, for the flexibility that it offers.

Cost seemed to be an open question. Rumors were flying at Live that VIRL’s virtual appliance option would be free. I heard the VIRL team was trying to pull back on that rumor, but on the other hand I heard one of the people at the VIRL desk also claim it would be free. It sounds to me like that hasn’t quite been decided yet, but Cisco does seem to understand clearly that there is enormous demand for an attainable virtual labbing system for individuals to train with.

Closing Thoughts

Some may say that VIRL is long overdue, and I wouldn’t disagree, but I’m very happy to see what Cisco has come up with. This truly looks like it could be a killer lab platform. I suspect it will have a big impact on network engineers’ ability to do efficient lab study, model network environments, improve procedures, and more. A big use of lab platforms in my daily work is validating procedures that I intend to execute on customers’ equipment, and having an easy to use option to do that validation will be extremely helpful, especially when wrapped in a number of well-executed tools. I’m really looking forward to seeing Cisco’s VIRL hit the public, and I suspect it will indeed “go viral” with popularity.

Finally, I should really point out that all the information contained in this blog post is based on what I saw of the tool and what I heard at Cisco Live US in June 2013. Of course, just about all of it is subject to change as the product develops. If the early-2014 predictions are true, there is plenty of time for major alterations before release, so please take all the info in this post as my personal observations from that specific time. At present I have no special access or insider info regarding VIRL so this is just a recap of my observations stemming from my excitement about the platform.

More Information About VIRL

Here are a couple more articles on the net regarding VIRL that you may find interesting:

A Cisco blog about VIRL

Tom Kacprzynski’s blog post – This post has some additional info, and a screenshot taken with a camera phone (something I was not thoughtful enough to grab!)