• Upgrade support from release version 3.1 to version 3.2.

• IPv6-only deployment mode support.

• TE Router ID added for device management.

• Zero Touch Provisioning capability added to allow for automated software download and configuration of new devices.

• Support for alert forwarding to an IPv6 end point.

• Optical stock KPIs are updated with new sensor paths.

• External data destination support for third party applications (Kafka) is secured with encryption.

For configuration and installation procedures, see the Cisco Crosswork Change Automation and Health Insights Installation Guide.

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

• 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.

• If the UI does not appear within 30 minutes after installation, log into the VM and check the installation logs for configuration errors. If necessary, collect logs to give to Cisco TAC (see the "Perform Administrative Tasks" chapter of the Cisco Crosswork Change Automation and Health Insights User Guide).

• 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 Change Automation and Health Insights 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 Cisco Crosswork Change Automation and Health Insights is expected to work with SR-PCE (SR-PCE is used for L3 topology discovery) we recommend the use of dual SR-PCEs.

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 50 devices.

• Link the playbook with KPI before enabling the corresponding KPI Profile on a device.

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

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.

• Use the scheduling feature to perform planned maintenance operations.

• Use the Install and Uninstall packages to upgrade or downgrade software patches.

• 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 untill the playbook has been run on all of the tagged devices.

• Mapping of devices to Cisco Crosswork Data Gateway is recommended to be done in batches of no more than 250 devices to ensure optimal performance.

• Use tags to select a group of devices when enabling collection jobs for better operational efficiency.

For administrative and monitoring tasks see the "Perform Adminstrative Tasks" chapter in the Cisco Crosswork Change Automation and Health Insights Installation Guide.

• Contact the Cisco Customer Experience team to when troubleshooting Cisco Crosswork Change Automation and Health Insights, before restarting services (via UI or CLI).

• Monitor and view application state, health, performance, and summary details from the Crosswork Manager window.

• Use custom certificates signed by your local CA to avoid browser warning messages. To manage certificates, go to the Certificate Management application.

• Dual stack deployment modes are not supported in version 3.2. Only single stack deployment modes (IPv4 only or IPv6 only) are supported.

• Without adequate resources (storage, memory and disk), the upgrade operation cannot load the services successfully, and will fail in the first boot.

• After upgrade to version 3.2, all historical alerts will be available only for an hour. Future alerts will be available once devices are mapped to Cisco Crosswork Data Gateway for the enabled KPIs.

• 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.

Sometimes, NETCONF reachability times out for IOS XE devices. To recover, try increasing the NETCONF reachability timer to a higher timeout value (for example, 120 seconds).

• 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.

• For custom KPIs:

  • Only one gather path should be specified when creating custom KPIs.

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

  • Multiple KPIs cannot use the same sensor path. Therefore, custom KPIs cannot share a sensor path with each other or with an existing default KPI that is active on a device.

• Any Health Insights job stuck in the processing state and does not complete within the stipulated time out of 60 minutes, will fail.

• L2 links are discovered on topology utilizing either Customer Data Platform (CDP) or Link Layer Discovery Protocol (LLDP).

• Point-to-point CDP or LLDP is supported in topology.

• PCE is required for L3 link topology mapping.

• Enable traps on routers to receive L2 link down and up status changes quickly. Otherwise, it may take one SNMP poll cadence (default is 5 minutes) to see the L2 link status change.

• The collection job creation can be less than optimal on a system that contains more than 250 devices due to the increase in the number of notifications.

• The JSON Web Token is only valid up to 8 hours.

In rare cases, after the successful registration, the License Authorization Status in the Smart Licensing page is not changed and will continue to display as being in EVALUATION mode. As a consequence, the evaluation timer will be started and incorrect messages will be displayed to the user. As a workaround, please de-register and register the product again.