Constructing a virtual lab
Before we dive into the Python libraries and frameworks, let's examine the options of putting together a lab for the benefit of learning. As the old saying goes, "practice makes perfect" – we need an isolated sandbox to safely make mistakes, try out new ways of doing things, and repeat some of the steps to reinforce concepts that were not clear in the first try. It is easy enough to install Python and the necessary packages for the management host, but what about those routers and switches that we want to simulate?
To put together a network lab, we basically have two options: physical devices or virtual devices. Let's look at the advantages and disadvantages of the respective options.
Physical devices
This option consists of putting together a lab consisting of physical network devices that you can see and touch. If you are lucky enough, you might even be able to construct a lab that is an exact replication of your production environment:
- Advantages: It is an easy transition from lab to production. The topology is easier to understand for managers and fellow engineers who can look at and work on the devices if need be. In short, the comfort level with physical devices is extremely high because of familiarity.
- Disadvantages: It is relatively expensive to pay for a device that is only used in the lab. Physical devices require engineering hours to rack and stack and are not very flexible once constructed.
Virtual devices
These are emulations or simulations of actual network devices. They are either provided by the vendors or by the open source community:
- Advantages: Virtual devices are easier to set up, relatively cheap, and can make changes to the topology quickly.
- Disadvantages: They are usually a scaled-down version of their physical counterpart. Sometimes there are feature gaps between the virtual and the physical device.
Of course, deciding on a virtual or physical lab is a personal decision derived from a trade-off between the cost, ease of implementation, and the risk of having a gap between the lab and production. In some of the environments I have worked on, the virtual lab was used when doing an initial proof-of-concept while the physical lab was used when we moved closer to the final design.
In my opinion, as more and more vendors decide to produce virtual appliances, the virtual lab is the way to proceed in a learning environment. The feature gap of the virtual appliance is relatively small and specifically documented, especially when the virtual instance is provided by the vendor. The cost of the virtual appliance is relatively small compared to buying physical devices. The time-to-build using virtual devices is quicker because they are usually just software programs.
For this book, I will use a combination of physical and virtual devices for concept demonstration with a preference for virtual devices. For the examples we will see, the differences should be transparent. If there are any known differences between the virtual and physical devices pertaining to our objectives, I will make sure to list them.
You will see that for the examples in the book, I will always try to make the network topology as simple as possible while still able to demonstrate the concept at hand. Each virtual network usually consists of not more than a few nodes and often we will reuse the same virtual network for multiple labs.
As such, in previous editions, readers have been able to use many of the popular virtual network labs such as GNS3, Eve-NG, and other virtual machines.
For the examples in this book, I am using virtual machines from various vendors such as Juniper and Arista. At the time of writing, Arista vEOS can be downloaded for free from the Arista site. Juniper JunOS Olive, which I use, is not an official supported platform, but Juniper offers a free trial license for vMX that can be substituted. I am also using a network lab program from Cisco called Virtual Internet Routing Lab (VIRL), https://learningnetworkstore.cisco.com/virtual-internet-routing-lab-virl/cisco-personal-edition-pe-20-nodes-virl-20. It is a paid program, but in the following sections I will explain why I think it is a good option for virtual network labs.
Again, I want to point out that the use of the VIRL program is entirely optional; you can use the free alternatives if you'd like. It is strongly recommended that you have some lab equipment to follow along with the examples in this book.
Cisco VIRL
I remember when I first started to study for my Cisco Certified Internetwork Expert (CCIE) lab exam, I purchased some used Cisco equipment from eBay to study with. Even at a discount, each router and switch cost hundreds of US dollars, so to save money, I purchased some really outdated Cisco routers from the 1980s (search for Cisco AGS routers in your favorite search engine for a good chuckle), which significantly lacked features and horsepower, even for lab standards. As much as it made for an interesting conversation with family members when I turned them on (they were really loud), putting the physical devices together was not fun. They were heavy and clunky, it was a pain to connect all the cables, and to introduce link failure, I would literally unplug a cable.
Fast-forward a few years. Dynamips was created and I fell in love with how easy it was to create different network scenarios. This was especially important when I tried to learn a new concept. All you need is the IOS images from Cisco, a few carefully constructed topology files, and you can easily build a virtual network that you can test your knowledge on. I had a whole folder of network topologies, pre-saved configurations, and different version of images, as called for by different scenarios. The addition of a GNS3 frontend gives the whole setup a beautiful GUI facelift. With GNS3, you can just click and drop your links and devices; you can even print out the network topology for your manager or client right out of the GNS3 design panel.
The only thing that was lacking was the tool not being officially blessed by the vendor, that is Cisco, and the perceived lack of credibility because of it.
In 2015, the Cisco community decided to fulfill this need by releasing the Cisco VIRL. This is my preferred method of developing and trying out much of the Python code, both for this book and my own production use.
As of November 14, 2019, the personal edition 20-Node license is available for purchase for only USD $199.99 per year.
Even at a monetary cost, in my opinion, the VIRL platform offers a few advantages over other alternatives:
- Ease of use: As mentioned, all the images for IOSv, IOS-XRv, CSR1000v, NX-OSv, and ASAv are included in a single download.
- Official (kind of): Although support is community-driven, it is a widely used tool internally at Cisco. Because of its popularity, bugs get fixed quickly, new features are carefully documented, and useful knowledge is widely shared among its users.
- The cloud migration path: The project offers a logical migration path when your emulation grows out of the hardware power you have, such as Cisco dCloud (https://dcloud.cisco.com/), VIRL on Packet (http://virl.cisco.com/cloud/), and Cisco DevNet (https://developer.cisco.com/). This is an important feature that sometimes gets overlooked.
- The link and control-plane simulation: The tool can simulate latency, jitter, and packet loss on a per-link basis for real-world link characteristics. There is also a control-plane traffic generator for external route injection.
- Others: The tool offers some nice features, such as VM Maestro topology design and simulation control, AutoNetKit for automatic config generation, and user workspace management if the server is shared. There are also open source projects such as virlutils (https://github.com/CiscoDevNet/virlutils), which are actively worked on by the community to enhance the workability of the tool.
We will not use all of the features in VIRL in this book. But since this is a relatively new tool that is worth your consideration, if you do decide this is the tool you would like to use, I want to offer some of the setups I used.
Again, I want to stress the importance of having a lab to follow along for the book examples. It does not need to be the Cisco VIRL lab. The code examples provided in this book should work across any lab device, as long as it runs the same software type and version.
VIRL tips
The VIRL website (http://virl.cisco.com/) offers lots of guidance, preparation, and documentation. I also find that the VIRL user community generally offers quick and accurate help. I will not repeat information already offered in those two places; however, some of the setups I use for the lab in this book follow.
My VIRL lab uses two virtual Ethernet interfaces for connections. The first interface is set up as network address translation (NAT) for the host machine's internet connection, and the second is used for local management interface connectivity (VMnet2 in the following example). I use a separate virtual machine with a similar network setup in order to run my Python code, with the first primary Ethernet used for internet connectivity and the second Ethernet connection to VMnet2 for lab device management network:
Figure 2: VIRL Ethernet adapter 1 changed to NAT
- VMnet2 is a custom network created to connect the Ubuntu host with the VIRL virtual machine:
Figure 3: VIRL Ethernet adapter 2 connects to VMNet2
In the Topology design option, I set the Management Network option to Shared flat network in order to use VMnet2 as the management network on the virtual routers:
Figure 4: Use Shared flat network for the VIRL management network
- Under the Node configuration, you have the option to statically configure the management IP. I try to statically set the management IP addresses instead of having them dynamically assigned by the software. This allows for more deterministic accessibility:
Figure 5: IOSv1 with static management IP
The VIRL lab topology will be provided with each chapter's code examples.
Cisco DevNet and dCloud
Cisco provides two other excellent, at the time of writing, free methods for practicing network automation with various Cisco gear. Both of the tools require a Cisco Connection Online (CCO) login. They are both really good, especially for the price point (they are free!).
The first tool is the Cisco DevNet (https://developer.cisco.com/) sandbox, which includes guided learning tracks, complete documentation, and sandbox remote labs, among other benefits. Some of the labs are always on, while others you need to reserve. The lab availability will depend on usage. It is a great alternative if you do not already have a lab at your own disposal. DevNet is certainly a tool that you should take full advantage of, regardless of whether you have a locally run VIRL host or not:
Figure 6: Cisco DevNet
Since its inception, Cisco DevNet has become the defacto destination for all things related to network programmability and automation at Cisco. In fact, in June 2019, Cisco announced many new tracks of DevNet certifications, https://developers.cisco.com/certification/
Another free online lab option for Cisco is https://dcloud.cisco.com/. You can think of dCloud as running VIRL on other people's servers without having to manage or pay for those resources. It seems that Cisco is treating dCloud as both a standalone product as well as an extension to VIRL. For example, in the use case of when you are unable to run more than a few IOS-XR or NX-OS instances locally, you can use dCloud to extend your local lab.
It is a relatively new tool, but it is definitely worth a look:
Figure 7: Cisco dCloud
GNS3
There are a few other virtual labs that I have used for other projects. The GNS3 tool is one of them:
Figure 8: GNS3 Website
As mentioned previously, GNS3 is what a lot of us used to study for certification tests and to practice for labs. The tool has really grown up from the early days of being the simple frontend for Dynamips into a viable commercial product. One of the downsides for Cisco-sponsored tools, such as VIRL, DevNet, and dCloud, is that they only contain Cisco technologies. Even though they provide ways for virtual lab devices to communicate with the outside world and to communicate with other vendor equipment, the steps are not very intuitive. GNS3 is vendor-neutral and can include a multi-vendor virtualized platform directly in the lab. This is typically done either by making a clone of the image (such as Arista vEOS) or by directly launching the network device image via other hypervisors (such as Juniper Olive emulation). GNS3 is useful when there is a need to incorporate multi-vendor technologies into the same lab.
Another multi-vendor network emulation environment that has gotten a lot of great reviews is the Emulated Virtual Environment Next Generation (Eve-NG): http://www.eve-ng.net/. I personally do not have much experience with the tool, but many of my colleagues and friends in the industry use it for their network labs.
There are also other virtualized platforms, such as Arista vEOS (https://eos.arista.com/tag/veos/), Juniper vMX (http://www.juniper.net/us/en/products-services/routing/mx-series/vmx/), and vSRX (http://www.juniper.net/us/en/products-services/security/srx-series/vsrx/), which you can use as a standalone virtual appliance during testing. They are great complementary tools for testing platform-specific features, such as the differences between the API versions on the platform. Many of them are offered as paid products on public cloud provider marketplaces for easier access. They often offer the identical feature as their physical counterpart.
Now that we have built our network lab, we can start to experiment with the Python libraries that can help with management and automation. We will begin with the Pexpect library.
