Cisco Blogs
Share

Cisco Crosswork – Part 1: Change Automation

In February, Cisco announced its latest innovation – Cisco Crosswork Network Automation – a new network automation portfolio for Service Providers.  Read Jonathan Davidson’s blog for an overview to understand its comprehensive approach in enabling a closed-loop, mass-scale automation solution. Follow this blog series over the coming weeks to learn more about each new solution in the Cisco Crosswork portfolio.

In this multi-part blog series, we will be describing in detail the five new pillars of the Cisco Crosswork automation solution – designed to help solve our customers’ challenges in planning, designing, implementing, operating, and optimizing their networks. Let’s start by taking a closer look at Cisco Crosswork Change Automation.

Cisco Crosswork Network Solution

 

Cisco Crosswork Change Automation is a platform which enables customers to create a closed-loop automation system. Traditional methods for managing a network include manual execution of a Method of Procedure or scripting existing Method of Procedures.

A method of procedure (MOP) is used to perform network changes as part of day-two operations. The playbook typically involves steps to execute during pre-maintenance, maintenance, and post-maintenance windows. Common tasks such as creating new circuits, upgrading software, and adding capacity to bundles require considerable preparation and take hours to complete. In the compute world, most of these tasks are performed via automation and programmatic access to devices. What if we could bring the automation used in the compute world to network infrastructure?

Cisco Crosswork Change Automation (CCCA) is significantly different from other scripted automation frameworks. CCCA enables a closed-loop framework with two main components: a configuration change manager and an alerting/validation engine.  The configuration change manager makes use of device programmatic interfaces and provides transactional capabilities for device configuration. The alert/validation engine makes use of real-time telemetry data to validate configuration intent and monitor device state using alerts.

Cisco Crosswork Change Automation is unique in its ability to construct and execute custom plays for large-scale network change. Network changes are described in YAML which makes them simple to create and use. CCCA provides scalability of changes using a microservices architecture, in addition, it provides advanced verification of state throughout the execution of the change. The result is a powerful tool for building a closed-loop Change Automation solution that drives consistent service intent.

Cisco Crosswork Change Automation

Cisco Crosswork Change Automation comes with a robust library of atomic configuration and verification plays. Plays can be stitched together to create a playbook for a specific action like software upgrade etc.

One use case for CCCA is the challenge of automating the often troublesome task of a basic upgrade. We like to think of this as having a “Smart Upgrade” playbook. There are three steps to this playbook inclusive of Pre-Maintenance, the Maintenance itself, and Post-Maintenance.

Pre-Maintenance – This section of the playbook includes any non-disruptive checks and any other operations on the router that prepare it for traffic-impacting changes.

  • (Optional) Callout to Crosswork WAE to understand traffic impact to the network due to cost out of the node.
  • Take snapshots of various routing protocol states.
  • Take snapshots of memory, CPU, and system health parameters.
  • Validate the disk capacity on active and standby route processors for the new software patch upgrade.
  • Validate the path compatibility with the existing release.
  • (Optional) Copy the software image to the router.

Maintenance – This section of the playbook includes any task that disrupts traffic flowing through the router or impacts neighboring routers.

  • Cost out the router and wait until traffic drains out completely.
  • (Optional) Verify that the redundant router is healthy and carrying traffic.
  • Perform the upgrade procedure on the device.

Post-Maintenance – This section of the playbook includes verification tasks to perform on the router after any disruptive operation.

  • Verify that the current state matches the original state.
  • (Optional) Cost in the router and wait for traffic to return to normal levels.

In our next version of CCCA, we will be enhancing the Smart Upgrade Playbook to include dynamic topology considerations and service levels before costing out a device.

We are very excited about the transformations we are seeing inside of our Service Provider customers and how Cisco Crosswork can help them accelerate their journey to a fully self-healing infrastructure. Please leave comments or questions below so we can continue the conversation.

Stay tuned for the next blog in this series to see how Cisco Crosswork can help Service Providers accelerate their journey to a fully self-healing infrastructure. If you plan to attend the MPLS+SDN+NFV World Congress in Paris or Automation Everywhere in Dallas, both in April, you can also meet with an expert to discuss Cisco Crosswork in person.

 



In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.

4 Comments

  1. Runs on CentOS Linux 7 and Ubuntu 14.04 LTS "Artificial intelligence for IT and network operations" Source: Cisco Crosswork Situation Manager Data Sheet

  2. I hope it also includes capabilities where if things go wrong it can go back to original state and restore all previous data

  3. Plays, yaml and playbooks are familiar terms with Ansible. With the plethora of open source tools such as Ansible, Salt etc, how different will CCCA be to those. Can CCCA integrate with any of the above mentioned tools which have started to gain adoption. Is there going to be multivendor support with CCCA.

    • hi, CCCA internally uses Ansible to orchestrate the configuration changes to the network via NSO or other config providers. Verification of the state is done via telemetry, typically Ansible plays run in a sequence we have enhanced with capabilities like continuous checks based on eventing.. Since we use a config provider with transactional capabilities we can rollback or do dry run etc..