pyATS on DevNet

For more than 20 years, Cisco has invested in automated testing. As part of this on-going effort, countless great libraries and scripts were created for internal use. Unfortunately this meant they weren't shared with Cisco customers.

Today, pyATS is here to break this status quo. With the core framework released and available to our customers through DevNet, it means:

• development teams and customers can collaborate with total transparency in test automation
• customers can use any test libraries generated during product development for their own DevOps & automation

pyATS is available to everyone under Apache License Version 2.0

Possibilities

The industry is embracing Software-Defined Networking (SDN). The dynamic nature of SDN means networks have scalability and elasticity that was previously unimagined. pyATS helps network engineers test, maintain, and diagnose the operational state of their agile SDN network.

pyATS can be used for both test automation and DevOps automation. From monitoring daily status quo to verifying feature and configuration changes, pyATS is there with reusable libraries that let you complete your job with confidence.

The framework standardizes on:

• how network topologies are defined and modeled
• how to programmatically interact with devices (eg, connection libraries)
• how test scripts are defined and executed
• how test runs are performed and how reports are generated

And provides:

• an easy to use Linux style command-line interface (CLI)
• ready-to-use, multi-vendor device libraries (eg, parsers, APIs)
• reusable test cases in the form of triggers & verifications
• the ability to build test suite elastically through the use of YAML-based data files
• a mechanism of modeling network device features

With pyATS, you have now a set of ready-to-use automation libraries built by the same engineering teams that built the Cisco product that you're using. Take advantage of it to your liking, eg:

• certification test automation
• Network DevOps automation
• stateful monitoring (through polling)
• etc

Stateful Validation

Many products on the market today focus on configuration management, but few can perform stateful validation.

When configuration is applied (or when the network goes into disarray), often a series of operational state changes occur as a result, such as:

• interface status, counters
• network routes, neighbors, next-hops
• cpu usage, memory, HA states, etc

Traditionally, validation of such changes relied on individual engineer expertise. But pyATS can learn and profile an entire feature's configuration & operational status, enabling users to build business logic on top. For example, with just a few Genie commands you can profile your system before and after a configuration change and get a detailed summary of exactly what changed.

Here's an example a that makes quick use of pyATS at your command line:

# take a snapshop of your current operational states (BGP, OSPF, interface)
$ pyats learn ospf bgp interface platform --testbed-file working-tb.yaml

Learning '['ospf', 'bgp', 'interface', 'platform']' on devices '['nx-osv-1', 'csr1000v-1']'
100%|███████████████████████████████████████████████████████████| 4/4 [00:26<00:00,  6.57s/it]

+==============================================================================+
| Genie Learn Summary for device csr1000v-1                                    |
+==============================================================================+
|  Learnt feature 'ospf'                                                       |
|  -  Ops structure:  initial/ospf_iosxe_csr1000v-1_ops.txt                    |
|  -  Device Console: initial/ospf_iosxe_csr1000v-1_console.txt                |
|------------------------------------------------------------------------------|
|  Learnt feature 'bgp'                                                        |
|  -  Ops structure:  initial/bgp_iosxe_csr1000v-1_ops.txt                     |
|  -  Device Console: initial/bgp_iosxe_csr1000v-1_console.txt                 |
|------------------------------------------------------------------------------|
|  Learnt feature 'interface'                                                  |
|  -  Ops structure:  initial/interface_iosxe_csr1000v-1_ops.txt               |
|  -  Device Console: initial/interface_iosxe_csr1000v-1_console.txt           |
|==============================================================================|

# when disaster strikes, or when you've made configuration changes
# let the infrastructure tell you what changed operationally:
#   -> be able to pin-point and identify exactly the thing you are looking for
$ pyats diff yesterday today
--- yesterday/ospf_iosxe_csr1000v-1_ops.txt
+++ today/ospf_iosxe_csr1000v-1_ops.txt
info:
 vrf:
  default:
   address_family:
    ipv4:
     instance:
      1:
       areas:
        0.0.0.0:
         interfaces:
          GigabitEthernet2:
-           neighbors:
-            10.2.2.2:
-             address: 10.0.1.2
-             bdr_ip_addr: 10.0.1.2
-             dead_timer: 00:00:38
-             dr_ip_addr: 10.0.1.1
-             neighbor_router_id: 10.2.2.2
-             state: full
-             statistics:
-              nbr_event_count: 6
-              nbr_retrans_qlen: 0%