I started my IT career at an ISP help desk back in the early 2000s. I remember watching the network engineers typing in what seemed like cryptic commands into a text terminal. Like magic, the network devices would then bend to their will and behave in the way they intended. In time, I got to learn and embrace these magic commands that I could type into the terminal. As network engineers, these CLI-based commands are like secret codes we share with each other in this world we call network engineering. Manually typing in the command was just something we all had to do to get the job done, no harm, no foul.

However, it was right around the year 2014 when we started to see the industry coming to a consensus about the clear need to move away from manual, human-driven CLIs toward an automatic, computer-centric automation API. Make no mistake, we still need to directly communicate with the device when making network designs, bringing up an initial proof of concept, and deploying the topology for the first time. However, once the network is deployed, the network management requirement is now to consistently make the same changes reliably across all network devices.

These changes need to be error-free, and the engineers need to repeat the steps without being distracted or feeling tired. This requirement sounds like an ideal job for computers and our favorite programming language, Python.

Of course, if the network devices can only be managed with the command line, the main challenge becomes how we can replicate the previous manual interactions between the router and the administrator automatically with a computer program. In the command line, the router will output a series of information and will expect the administrator to enter a series of manual commands based on the engineer’s interpretation of the output. For example, in a Cisco Internetwork Operating System (IOS) device, you have to type in enable to get into a privileged mode, and upon receiving the returned prompt with the # sign, you then type in configure terminal in order to go into the configuration mode. The same process can further be expanded into the interface configuration mode and routing protocol configuration mode. This is in sharp contrast to a computer-driven, programmatic mindset. When the computer wants to accomplish a single task, say, put an IP address on an interface, it wants to structurally give all the information to the router at once, and it would expect a single yes or no answer from the router to indicate the success or failure of the task.

The solution, as implemented by both Pexpect and Paramiko, is to treat the interactive process as a child process and watch over the interaction between the child process and the destination device. Based on the returned value, the parent process will decide the subsequent action, if any.

I am sure we are all anxious to get started on using the Python libraries, but first, we will need to construct our network lab in order to have a network to test our code against. We will begin by looking at different ways we can build our network labs.

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 on the first try.

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 with 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. The advantages and disadvantages of a physical lab are as follows:

• 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. The comfort level with physical devices is extremely high because of familiarity.
• Disadvantages: It is relatively expensive to pay for devices that will only be used in a lab. Also, physical devices require engineering hours to rack and stack and are not very flexible once constructed.

Virtual devices

Virtual devices are emulations or simulations of actual network devices. They are either provided by the vendors or by the open source community. The advantages and disadvantages of virtual devices are as follows:

• Advantages: Virtual devices are easier to set up, relatively cheap, and can make changes to the topology quickly.
• Disadvantages: They are usually scaled-down versions of their physical counterparts. 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 lab and production environments. In some of the places I have worked, 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 much shorter because they are 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.

For the code examples in the book, I will try to make the network topology as simple as possible while still being able to demonstrate the concept at hand. Each virtual network usually consists of not more than a few nodes, and we will reuse the same virtual network for multiple labs if possible.

For the examples in this book, I will utilize Cisco Modeling Labs, https://www.cisco.com/c/en/us/products/cloud-systems-management/modeling-labs/index.html, as well as other virtual platforms, such as Arista vEOS. As we will see in the next section, Cisco provides CML in both a paid version and a free, hosted version on Cisco DevNet (https://developer.cisco.com/site/devnet/) based on availability. The use of CML is optional. You can use any lab devices you have, but it might make it easier to follow along with the book examples. Also worth noting is that Cisco has strict software license requirements for device images, so by purchasing or using the free hosted CML, you will be less likely to violate their software license requirements.

Cisco modeling labs

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 with a used equipment discount, each router and switch still cost hundreds of US dollars. 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, and it was a pain to connect all the cables, and to introduce link failure, I would literally have to 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 trying to learn a new concept. All I needed was the IOS images from Cisco and a few carefully constructed topology files, and I could easily build a virtual network to test my knowledge on. I had a whole folder of network topologies, pre-saved configurations, and different versions of images, as called for by different scenarios. The addition of a GNS3 frontend gave 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 disadvantage of GNS3 was the tool not being officially blessed by Cisco, and the perceived lack of credibility because of it.

In 2015, the Cisco community decided to fulfill this need by releasing the Cisco Virtual Internet Routing Lab (VIRL), https://learningnetwork.cisco.com/s/virl. This quickly became my go-to tool as the network lab when developing, learning, and practicing network automation code.

A few years after the introduction of VIRL, Cisco released Cisco Modeling Labs (CML), https://developer.cisco.com/modeling-labs/. It is a great network simulation platform with an easy-to-use HTML UI and a comprehensive API.

At the time of writing, the single-user license for CML is 199 USD (keep in mind that there is a free, hosted version on Cisco DevNet). In my opinion, the CML platform offers a few advantages over other alternatives and the cost is a bargain:

• Ease of use: As mentioned, all the images for IOSv, IOS-XRv, NX-OSv, ASAv, and other images are included in a single download.
• Official: CML is a widely used tool internally at Cisco and within the network engineering community. In fact, CML is used extensively for the new Cisco DevNet Expert Lab exam. Because of its popularity, bugs get fixed quickly, new features are carefully documented, and useful knowledge is widely shared among its users.
• Third-party KVM images integration: CML permits users to upload third-party VM images, such as Windows VM, that are not bundled by default.
• Others: The CML tool offers many other features, such as dashboard list view, multiuser grouping, Ansible integration, and pyATS integration.

We will not use all of the CML features in this book, but it is nice to know the tool is so feature-rich and is constantly being updated. Again, I want to stress the importance of having a lab to follow along for the book examples but it does not need to be Cisco CML. The code examples provided in this book should work across any lab device, as long as it runs the same software type and version.

CML tips

The CML website (https://developer.cisco.com/modeling-labs/) and documentation (https://developer.cisco.com/docs/modeling-labs/) offer lots of guidance and information, from installation to usage. The lab topology will be included in the respective chapters in the book’s GitHub repository (https://github.com/PacktPublishing/Mastering-Python-Networking-Fourth-Edition). The lab images can be directly imported to the lab via the Import button:

Figure 2.1: CML Console Image Lab Image

For the labs, each of the devices will have its management interface connected to an unmanaged switch, which in turn connects to an external connection for access:

Figure 2.2: Unmanaged Switch for Management Interface Access

You will need to change the IP address of the management interface to fit your own lab’s schema. For example, in the 2_DC_Topology.yaml file in Chapter 2, the IP address of lax-edg-r1 GigabitEthernet0/0 0 is 192.168.2.51. You will need to change this IP address according to your own lab.

If you are using virtual lab software other than CML, you can open the topology file with any text editor (such as Sublime Text, shown below) and see each of the devices’ configurations. You can then copy and paste the configuration into your own lab devices:

Figure 2.3: Topology File Viewed with Text Editor

We talked about Cisco DevNet briefly earlier in this section. Let us explore more about DevNet in the next section.

Cisco DevNet

Cisco DevNet (https://developer.cisco.com/site/devnet/) is the premier, all-in-one website when it comes to network automation resources at Cisco. It is free to sign up and provides free remote labs, free video courses, guided learning tracks, documentation, and much more.

The Cisco DevNet Sandbox (https://developer.cisco.com/site/sandbox/) is a great alternative if you do not already have a lab at your own disposal or want to try out new technologies. Some of the labs are always on, while others you need to reserve. The lab availability will depend on usage.

GNS3 and others

There are a few other virtual labs that I have used and would recommend. GNS3 is one of them:

Figure 2.5: GNS3 Website

As mentioned previously, GNS3 is what a lot of us use 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. GNS3 is vendor-neutral, which can be helpful if we want to build a multi-vendor 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 KVM).

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 enough experience with the tool, but many of my colleagues and friends in the industry use it for their network labs. If you are familiar with containers, containerlab (https://containerlab.dev/) can also be an alternative for you.

There are also other standalone virtualized platforms, such as Arista vEOS (https://www.arista.com/en/cg-veos-router/veos-router-overview), Juniper vMX (https://www.juniper.net/us/en/products/routers/mx-series/vmx-virtual-router-software.html), and Nokia SR-Linux (https://www.nokia.com/networks/data-center/service-router-linux-NOS/), which you can use as standalone virtual appliances during testing.

They are great complementary tools for testing platform-specific features. Many of them are offered as paid products on public cloud provider marketplaces for easier access.

Now that we have built our network lab, we can start to experiment with Python libraries that can help with management and automation. We will begin with enabling the Python virtual environment. Then we will install and use the Pexpect library for some examples.