Automating your network testing has never been easier

Automating your network testing has never been easier!

Welcome back to our NetDevOps series. Today we will move forward and cover some more examples on how to easily get started with pyATS and Genie. If you missed the first two parts of this pyATS and Genie demo you can find them here:

Develop your own tests with an interactive shell

In my last post we went through a couple of simple examples of what can be done with pyATS and Genie, so by now you might want to start developing your own tests. But instead of iterating through the process of “writing a complete script, trying to run it, failing and rewriting“, we would rather have a more interactive way of developing tests. Something that allows us to check the results of each step during the test and debug it by exploring the results at any point in the flow.

As you may have noticed pyATS feels really pythonic, so wouldn’t it be great to have something similar to the interactive Python shell? Something that would give us the option to execute individual steps interactively while developing our tests? Say no more fam, we got you covered!

Genie has a function called “shell”, which can be invoked from the Bash command line. When invoking “shell”, Genie will load the correct testbed file and initiate the required libraries for the python interactive shell.

Please remember you must have a reserved sandbox with your VIRL simulations running and be connected to it via VPN. Please see my previous post for further information on how to complete the environment setup.

For our examples today we will start a pyATS container and ask it to start an interactive shell (bash) so we can run Genie Shell in it.

$ docker run -it --rm \
  -v $PWD:/pyats/demos/ \
  --env-file env.list \
  ciscotestautomation/pyats:latest bash

You may invoke the interactive Genie Shell and use your local VIRL testbed file, available via the container volume mapping, with the following command:

root@bfaa28c3faf3:/pyats# genie shell --testbed-file 
demos/default_testbed.yaml

The great thing about being able to define a certain testbed for testing is that you can reuse your python script in multiple different environments (eg. production, testing, datacenter 1, datacenter 2) by pointing to different testbed files.

You can see the devices included in your own testbed:

>>> testbed.devices
TopologyDict({'csr1000v-1': <Device csr1000v-1 at 0x7f8fa13e9438>, 'nx-osv-1': <Device nx-osv-1 at 0x7f8fa141f0f0>})

Create aliases for your devices:

>>> nx = testbed.devices['nx-osv-1']
>>> csr = testbed.devices['csr1000v-1']

You can now connect to your device:

>>> csr.connect()

As long as everything is an object in python, you may find a method showing for example if there are any links going from csr to nx:

>>> csr.find_links(nx)
{<Link object 'flat' at 0x7fd48b490f60>, <Link object 'csr1000v-1-to-nx-osv-1#1' at 0x7fd48b490eb8>, <Link object 'csr1000v-1-to-nx-osv-1' at 0x7fd48b490d68>}

Or another method to execute a command in the device:

>>> csr.execute('show version')

Probably by now you are thinking…

“When do we get to the interesting stuff?”

… and you are right!

Let’s start by exploring what can be done with genie.ops libraries. Genie Ops libraries are at the heart of parsing features on devices and returning structured data. The models are based on OpenConfig and IETF YANG models. For the full list of models please go to Genie Models.

How about easily obtaining from a device the complete table of routes in a structured format?

>>> routes = csr.learn('routing')

This request will execute a number of commands in the device, compile all the received routing info and parse it into a structured format. Check the resulting dictionary:

>>> routes.info

It is structured data that you can now easily query and process in your scripting!
For example, let’s say you have a tool that needs to verify that a specific route (eg. 172.16.30.0/24) exists on your Nexus switch.

>>> routes.info['vrf']['default']['address_family']['ipv4']['routes']['172.16.30.0/24']
{'route': '172.16.30.0/24', 'active': True, 'source_protocol': 'connected', 'source_protocol_codes': 'C', 'next_hop': {'outgoing_interface': {'GigabitEthernet1': {'outgoing_interface': 'GigabitEthernet1'}}}}

Wow, that was easy! Think about the kind of processing and parsing you would have had to do in the past to go through the text output of all those commands. And that parsing would be different for each platform/OS CLI … ouch! Now pyATS is compiling the information from all those commands and giving you a consolidated, structured view that you can easily work with.

Now let’s try a different task, and learn about all-things BGP in the csr device:

>>> bgp = csr.learn('bgp')

Again, this task will run multiple BGP-related commands, iterating through all detected BGP neighbors, and provide you with a consolidated view that includes all relevant information in a structured format, so you can easily extract and process the specific data you require.

>>> bgp.info

Now let’s explore what can be done with genie.conf libraries. For example, in order to work with BGP configurations we need to import the required library:

>>> from genie.libs.conf.bgp import Bgp

And then we could use yet another method to learn the BGP configuration in our Nexus switch:

>>> nx.connect()
>>> bgps_nx = Bgp.learn_config(nx)

As long as for other routing protocols (not BGP) there might be several instances we receive a list, and we need to refer to its first entry, numbered 0:

>>> bgp_nx = bgps_nx[0]

We can also apply configurations, like this or a different one, to our device:

>>> bgp_nx.build_config()

Or remove all BGP configuration:

>>> bgp_nx.build_unconfig()

You can check it’s all gone with the same command we used in the genie.ops section:

>>> bgp = nx.learn('bgp')
>>> bgp.info
{}

And easily apply all BGP configuration back again:

>>> bgp_nx.build_config()

When you are done exploring Genie interactive shell, you can exit with:

>>> exit()
root@bfaa28c3faf3:/pyats# exit

The Genie interactive shell makes it really easy to develop and debug your tests step-by-step, in the classic interactive pythonic way!

See you in a couple of weeks for our next set of pyATS demos, stay tuned!
Any questions or comments please let me know in the comments section below, Twitter or LinkedIn.