• Enhanced ability to create custom plays to customize playbooks for Cisco and non-Cisco devices.

• Added ability to store output from a verb into register so it can be used by a subsequent play in the playbook.

• Added ability to control the playbook execution workflow using conditionals.

• Device override credentials added to provide additional authentication during Playbook execution.

• Added the ability for Change Automation to integrate into Crosswork Network Controller 2.0.

• Added support for Health Insights KPIs to use GNMI transport and Openconfig YANG models.

• Added ability to store KPI sensor data for a period of 24 hours.

• Added the ability to export Health Insights KPI sensor data to user-specified external applications.

• Added the ability for Health Insights to integrate into Crosswork Network Controller 2.0.

For information on how to use Change Automation see the "Automate Network Changes" chapter in the Cisco Crosswork Change Automation and Health Insights User Guide.

• For information about using flexible Playbook development tools, see "Custom Playbooks" tutorial in the Change Automation Developer Guide on Cisco DevNet.

• When using dynamic tags to run a playbook on a set of devices, the playbook will be executed on groups of 20 devices at a time until the playbook has been run on all of the tagged devices.

For information on how to use Health Insights, see the "Monitor Network Health and KPIs" chapter in the Cisco Crosswork Change Automation and Health Insights User Guide.

• Group the KPIs within a KPI Profile for monitoring relevant device metrics. For best results, limit to adding 10 KPIs per KPI Profile. Maximum number of KPIs that can be supported within a KPI profile is 50.

• For optimal performance, enable a KPI Profile in batches of no more than 100 devices.

• For best system performance, use the default KPI cadence.

• Sometimes, under certain load conditions, the execution of a Playbook times out. If it continues to fail for a specific device, try changing the time out for the job, or changing the device state to DOWN and UP again.

• While scheduling playbooks across a dynamic group tag, the corresponding job set screen for the job in the Job History page will not display the relevant devices, until the job is scheduled for execution.

• Running a Playbook on multiple devices at the same time with different collection_type parameter values may result in failure. Re-executing the failed Playbook will resolve the issue.

• Under extreme load conditions, Change Automation may fail to cleanup the collection jobs that were created. These stale collections jobs can be deleted using API.

• If you try to access Change Automation UI after restarting the robot-nca pod, you may get a temporary error message (pstream host lookup failed) for 5 minutes.

• Setting the alert flag as ON for an enabled KPI Profile is not displayed on the corresponding Health Insights job details page as the update operation is an internal system transaction. If the job completes successfully, the alerts triggered can be viewed on the alert dashboard.

• After a KPI Profile is enabled, editing cadence & threshold parameter for any of the associated KPIs can be achieved using one of the three procedures detailed below:

  • Create a custom KPI with the required cadence & threshold parameters and associate with the existing KPI Profile.

  • Create a new KPI Profile with the relevant KPIs associated. Update the cadence & alert parameters before enabling this new KPI Profile.

  • Disable the KPI Profile & perform the modifications on relevant associated KPIs and re-enable the KPI Profile.

• Multiple active KPIs cannot use the same sensor path on the same device.

• For custom KPIs:

  • While creating custom KPI, user is restricted to selecting leaf sensors only upto a certain hierarchy (gather path).

  • All leaf sensor paths are reserved for that KPI use only.

• Any Health Insights job stuck in the processing state and does not complete within the stipulated time out of 60 minutes will be marked as "failed". After addressing any underlying issues (e.g. device connectivity, credentials or NSO sync etc.), the same job must be reapplied.

• Filtering is case sensitive for the Manage KPIs and Enable-Disable KPI Profiles pages.

• For using Health Insights alert forwarding functionality, you need to setup one Alert provider with correct credentials.

• You can view KPI graphical data in the Cisco Crosswork UI only for time slots that has alerts triggered. To view the alerts for the last 24 hours, go to the grafana dashboard (https://<IPaddress:port>/robot-grafana/) and select the desired KPI.

• Starting with the 4.0 release, only the infrastructure components will be installed on the target machines. Each Cisco Crosswork application will be available as a separate installable package.

• Node-level High Availability (HA) is provided for the Cisco Crosswork applications.

• Ability to scale the Cisco Crosswork applications as per your business requirements.

• Added license compliance check for non-Crosswork active collection jobs.

• Support provided for an Alert Framework.

• New certificate management architecture to support secure communication between Cisco Crosswork Data Gateway and devices. Includes device TLS certificate management from the Cisco Crosswork UI.

• Support for secure GNMI telemetry.

• Added extensibility framework that supports:

  • Installing the Cisco Crosswork infrastructure without any applications.

  • Dynamic integration of Cisco Crosswork applications after day 0.

  • Managing (install, activate, upgrade, and uninstall) a purchased application in Cisco Crosswork.

• Cisco Crosswork deployment is supported on Cisco CSP 5K devices.

• Support for applications to send standard syslog events from Cisco Crosswork to external syslog servers.

• Support for display of system alarms and events for troubleshooting scenarios.

• It is recommended to deploy Cisco Crosswork on a highly available cluster (vSphere HA) with shared storage.

• When manually installing the cluster nodes, use VMware vCenter and vSphere Web Client (flash mode) for OVA deployment.

• Managed devices, VM host and the VMs should use the same NTP source to avoid time synchronization issues.

• Confirm that the DNS and NTP servers are properly configured.

• Use Terminal Access-Control System Plus (TACACS+), Lightweight Directory Access Protocol (LDAP) or Role-Based Access Control (RBAC) for auditing purposes.

• During configuration, note the Cisco Crosswork UI and CLI user names and passwords. Due to added security, the only way to recover the administrator password is to re-install the software.

• In situations where it is expected to work with SR-PCE (for L3 topology discovery), we recommend the use of dual SR-PCEs.

• Use CSV files to quickly import and onboard device, credential, and provider information.