September 28, 2023

Cisco IOS XR Version 7.9.2 (SR-PCE and PCC) support has been added.

Cisco Crosswork Change Automation

An application that automates the process of deploying changes to the network. Orchestration is defined via an embedded Ansible Playbook and then configuration changes are pushed to Cisco Network Services Orchestrator (NSO) to be deployed to the network.

5.0

Cisco Crosswork Health Insights

An application that performs real-time Key Performance Indicator (KPI) monitoring, alerting, and troubleshooting. Cisco Crosswork Health Insights enables programmable monitoring and analytics, and builds dynamic detection and analytics modules that allow operators to monitor and alert on network events based on user-defined logic.

5.0

Cisco Crosswork Zero Touch Provisioning

An application that streamlines on-boarding and provisioning of Day 0 configuration resulting in faster deployment IOS-XR and IOS-XE devices at a lower operating cost.

5.0

The CS SR-TE feature pack provides a bandwidth-aware Path Computation Element (PCE) to compute CS SR policy paths that you can visualize in your network. CS SR policies guarantee allocated bandwidth services with predictable latency and persistent bidirectional path protection of critical traffic. Unlike Bandwidth on Demand, where SR policies with requested bandwidth are created on a best effort basis, CS SR-TE reserves a percentage of bandwidth in the network and computes CS SR policy bidirectional failover paths with the requested bandwidth. CS SR-TE also maintains the accounting of all CS SR reserved bandwidth in the network. CS SR policies are typically used for high priority services, such as crucial monetary transactions or important live video feed, which require committed bandwidth with fast and fail-safe connections.

Crosswork Network Controller enables you to provision CS SR-TE policy configurations and easily edit policies, as needed. In addition, the ability to visualize CS SR policies in your network topology allows you to easily verify CS SR policy configurations, details, and path states. With a few clicks you can view Active and Protective paths, operational status, reserved bandwidth pool size, and monitor path failover behavior for individual CS SR policies.

Tree Segment Identifier (Tree-SID) policy provisioning and L3VPN service model association

Tree-SID is used to implement multicast trees in segment routed transport networks. Using Crosswork Network Controller, the provisioning of static Tree-SID policies and the visualization of policies are rendered using the UI. Dynamic Tree-SID policies may be created directly on a device using an API. In addition, using Crosswork Network Controller, the ability to associate static Tree-SID policies with existing or newly created L3VPN service models is now available.

• Static mVPN Tree-SID policies associated with existing, or newly created, L3VPN service models (SR MPLS point-to-multipoint) using the Crosswork Network Controller that can also be visualized and analyzed to assist in efficient management and troubleshooting of your multicast network.

  Note	Dynamic Tree-SID policies can be visualized using the Traffic Engineering page. However, there will be no mapping on the Transport tab if it is attached to an L3 point-to-multipoint VPN service.

• Configuring link affinities used to specify the link attributes that determine which links are suitable to form a path for the Tree-SID policy and maps each bit position or attribute with a color (making it easier to refer to specific link attributes).

• Modifying existing static Tree-SID policies and mVPN Tree-SID policies associated with an L3VPN service model – both edit and delete – using the UI.

Crosswork UI Improvements

• Traffic Engineering Dashboard, which includes the TE Dashlet that provides:

  • A high-level summary of RSVP-TE tunnel, SR-MPLS, SRv6, and Tree-SID policy information (total policy count, policy state, metric types for all TE services, and specific data that is filtered upon a one-click selection).

  • Policies and Tunnels under traffic threshold for historical data by displaying RSVP-TE tunnels and SR-MPLS policies that have traffic below the defined threshold in the selected time period. This information may be used to find and filter the unused policies or tunnels.

  • Filtering the data on the dashlet based on the time range you want to view (date, 1 month, 1 week, 1 day, and 1 hour).

  • Policy and Tunnel Change Events: Displays all the policies and tunnels that have had a path or state change event ordered by the event count, within the selected time range. This information helps identify the unstable policies and tunnels.

• Traffic Engineering event and historical data information associated with a device when viewing details for a policy or tunnel. For example, the traffic rate and event history for an SR-MPLS policy can be viewed by selecting the Historical Data tab and clicking on an event. By doing so, you can view the state of the policy or tunnel at that point in time and view additional details, such as Admin and Operational state, Segment type, accumulated metric, delegated PCE, and more so to drill down on the event details.

• Enable/Disable Alarm Status Badge slider: The system allows you to enable or disable the Alarm Status Badge slider for devices and links across various topology views. Using the Alarm Status Badge, you can better focus the overlay on an area of interest when troubleshooting.

• Configuration of the Traffic Engineering Data Dashboard Settings (and historical data) for the collection of policy and tunnel metrics, state and path changes, data retention intervals, and the utilization threshold for underutilized LSPs.

• Global search in UI topology: You can now search within the Crosswork Network Controller topology map in the UI. This feature allows you to quickly locate devices based on the following criteria:

  • Civic Location (for example, San Jose)

  • Host/Device name (for example, NAT-01)

  • IP address (for example, 121.10.10.1.1)

• Import and Export geographical objects using Keyhole Markup Language (KML) format:

  • Using the Crosswork Network Controller UI, you can import and export KML files to exam, change, or add device geographical information and see the updates in the UI map. For example, you may use the export function to download your device’s data in KML format to your system, exam and/or change the device details, and upload it into a map generator (such as Google Maps) to view your updated device information and coordinates outside of Crosswork Network Controller. You can then use the import function to upload the updated, or browse for a new, KML file back into Crosswork Network Controller. If changes were made, they will now appear in the geographical map after it refreshes. When using the import function, Crosswork Network Controller also provides a sample KML template. The sample KML template provides information on where to identify devices and their coordinates, an optional device name, and the IP address (IPv4 or IPv6) of a device with corresponding coordinates. This template can be used on your system before importing back into Crosswork Network Controller.

• Traffic Engineering device details improvements that will provide options, after selecting a device from the topology map, to select different TE tabs (such as Links, Alarms, SR-MPLS, SRv6, RSVP-TE and others) that provide associated data for the selected device’s policies and prefixes.

  Note	For more information on Crosswork UI improvements, see the Crosswork Optimization Engine 5.0 User Guide section, Visualize Traffic Engineering Services.

• Dry Run for a deleted service: When decommissioning a service, only the configuration related to a service is deleted on the device. By implementing Dry Run, it shows the user the configuration that is deleted from multiple devices.

• Edit in json configuration editor: Using the json configuration editor, you can highlight different details that make up the service configuration and edit them directly in the json editor before committing the configuration.

• Clone existing services: Clone existing services and policies and utilize the json configuration editor to make changes to your cloned configuration. By cloning existing services and policies, you save time and ensure consistency across configurations.

• Show all fields toggle option: When editing a service configuration, you can either hide multiple fields that do not pertain to the editable service configuration or you can view all fields by using the Show all fields toggle option.

• Due to NSO Core Function Pack (CFP) model version upgrade, L2VPN, L3VPN or RSVP-TE upgrade is not supported from 4.x to 5.0. SR-TE upgrade from 4.x to 5.0 is supported. Direct upgrade from 3.x to 5.0 is not supported.

• Mutual-Auth: Authenticates external server and the CDG collector after the CA certificate, and Intermediate certificate or Key is uploaded to the Crosswork UI.

• Server-Auth: Authenticates external server and the CDG collector after the CA certificate is uploaded to the Crosswork UI.

• RADIUS: Support provided for user authentication with RADIUS (Remote Authentication Dial-In User Service) servers.

• Support for offline licenses, solution-based licenses, and lab licenses

• Support for user authentication via single sign-on (SSO)

• Ability to log the user’s source IP address for auditing and accounting

• High Availability support for Common Licensing Management Service (CLMS)

• High Availability support for Element Management Functions (Inventory, Notification, Fault, and SWIM)

• Support for visualization of device alarms and events

• API and Notification support for alarms/events OSS integration

• Ability to enable SMU configurations

• Ability to configure timezone during installation of the Crosswork cluster

Ability to select Basic View or Extended View when visualizing a service overlay. The Basic View is a minimalistic view of your network services with no additional details, edge directions, router targets, or EVI/PW IDs. The Extended View includes all details, including edge directions, router targets, and EVI/PW IDs. The services overlay visualization enhancements apply to:

• Point-to-Point Service Visualization

• Any-to-Any Service Visualization (L2VPN and L3VPN)

• Hub and Spoke Service Visualization (L2VPN and L3VPN)

• Custom Service Visualization (L2VPN and L3VPN)

• Service Health monitoring is available for both Basic Monitoring and Advanced Monitoring.

  Note	In total, Basic + Advanced Monitoring provides up to 52,000 services that can be monitored.

• Heuristic Package improvements include:

  • IPv6 support that enhances and extends the SRv6 feature support

  • New Basic and Advanced rules for L2VPN (E-LAN and E-Tree) for monitoring (including multipoint feature for E-LAN and E-Tree)

• High Availability for all Service Health containers.

• Assurance Graph improvements that include node aggregation and expand/collapse capabilities to view subservice summary information and associated subservices.

• New subservices, such as:

  • Dynamic subservices implementation (also includes SR-ODN policy)

  • Reservation Protocol for Traffic Engineering (RSVP-TE) Tunnel

  • Bridge Domain

  • Mac Learning

• Device badge feature displays an orange badge on a device in the topological view indicating there are down and/or degraded subservices underneath that should be identified and symptoms inspected.

• Summary node feature summarizes the aggregated health status of child subservices and reports one consolidated health status to a service node. The Summary node feature is available in both L2VPN multipoint Basic and Advanced monitoring models.

  • Basic monitoring subservices:

    • Device – Summarizes the health status of all underlying Devices participating in the given L2VPN service.

    • Bridge Domain – Summarizes the L2VPN Service’s Bridge Domain health status across all participating devices.

  • Advanced monitoring subservices (in addition to what is also available with Basic monitoring)

    • EVPN –  Summarizes the health status of all underlying subservices – BGP Neighbor Health & MacLearning Health across all participating PE endpoints and provides a consolidated overall EVPN health summary status.

    • Transport –  Summarizes the health status of all underlying subservices – SR-ODN (dynamic), SR Policy (statically configured) and RSVP TE Tunnel, across all participating PE endpoints and provides a consolidated overall Transport health summary status.

    • SR-PCEP –  Summarizes the health status of all the underlying subservices that are monitoring the PCEP sessions. Each underlying subservice monitors the PCEP session health on a particular device participating in the given VPN service.

• Extended CLI support using new Service Health system device packages, that can derive exact sensor paths for metric health calculation, that can now be installed as a bundle when the Service Health application is deployed.

Documentation

• An Information Portal is now available for Crosswork Network Controller 5.0. Information is categorized per functional area, making it easy to find and easy to access.

• The Cisco Crosswork Network Controller 5.0 Installation Guide covers installation of the cluster and installation of Crosswork applications on top of the infrastructure. This guide includes Cisco Crosswork Data Gateway installation.

• The Cisco Crosswork Network Controller 5.0 Administration Guide covers setup and maintenance of the Crosswork system. There is no longer a Getting Started Guide for Cisco Crosswork Network Controller. This guide includes Cisco Crosswork Data Gateway and ZTP information.

• The Cisco Crosswork Network Controller 5.0.x Solution Workflow Guide provides an overview of the solution and its supported use cases. It walks users step-by-step through various common usage scenarios to illustrate how users can work with the solution components to achieve the desired benefits.

IOS-XR

6.7.2

7.0.2

7.1.2

7.2.1

7.3.1

7.3.2

7.4.1

7.4.2

7.5.2

7.6.1

7.7.1²

7.8.1

7.8.2

17.6.3

17.7.1

17.8.1

17.9.1

Cisco Operating System

• Cisco IOS XR: 6.7.2, 7.0.2, 7.1.2, 7.2.1, 7.3.1, 7.3.2, 7.4.1, 7.4.2, 7.5.2, 7.6.1, 7.7.1, 7.8.1, 7.8.2, 7.9.1, 7.9.2

• Cisco IOS XE: 17.6.3, 17.7.1, 17.8.1, 17.9.1

• Cisco NX-OS: 9.2.1, 9.3.1, 10.2(3)

Hypervisor and vCenter

• VMware vSphere 6.7 or above.

• VMware vCenter Server 7.0 and ESXi 7.0.

• VMware vCenter Server 6.7 (Update 3g or later) and ESXi 6.7 (Update 1 or later).

Browsers

• Google Chrome—92 or later

• Mozilla Firefox—70 or later

Cisco Crosswork Data Gateway

5.0

Cisco Network Services Orchestrator (Cisco NSO)

• 6.1.0

Cisco Network Element Driver (NED)

• Cisco IOS XR:

  • CLI: 7.46.3

  • NETCONF: 7.3.2, 7.315, 7.4.2, 7.5.2, 7.6.2, 7.7.2, 7.8, 7.9

• Cisco IOS:

  • CLI: 6.86.6

Cisco Segment Routing Path Computation Element (SR-PCE)

• Cisco IOS XR 7.9.1

• Cisco IOS XR 7.9.2

Crosswork cluster uses the following IP ranges for internal communications. This cannot be changed. As a result, these subnets cannot be used for devices or other purposes within your network.

You are recommended to isolate your Crosswork cluster to ensure all the communications stay within the cluster. Please also ensure that address spaces do not overlap for any of the external integration points (e.g. connections to devices, connections to external servers that Crosswork is sending data to, connections to the NSO server, etc.).

IPv4:

• 172.17.0.0/16: Docker Subnet (Infrastructure)

• 169.254.0.0/16: Link local address block

• 127.0.0.0/8: Loopback addresses

• 192.88.99.0/24: Reserved, previously used for relay servers to do IPv6 over IPv4

• 240.0.0.0/4: Reserved for future use (previously class E block)

• 224.0.0.0/4: MCAST-TEST-NET

• 0.0.0.0/8: Current network, valid as source address only

IPv6:

• 2001:db8:1::/64: Docker Subnet (Infrastructure)

• fdfb:85ef:26ff::/48: Pod Subnet (Infrastructure)

• fd08:2eef:c2ee::/110: Service Subnet (Infrastructure)

• fe80::/10: Link local

• ::1/128: Loopback addresses

• ff00::/8: IPv6 Multicast

• 2002::/16: Reserved, previously used for relay servers to do IPv6 over IPv4

• 2001:0000::/32: Terredo tunnel and relay

• 2001:20::/28: Used by ORCHID and not IPv6 routable

• 100::/64: Discard prefix, used in specific use-cases not applicable to Crosswork Zero Touch Provisioning

• ::/128: Unspecified address, cannot be assigned to hosts

• ::ffff:0:0/96: IPv4 mapped addresses

• ::ffff:0:0:0/96: IPv4 translated addresses

Installation

During the initial installation of Crosswork, the zookeeper instance may go into crashbackoff state continuously. At first, the UI health for one zookeeper pod will show down/degraded resulting in the zookeeper pod constantly restarting. The zookeeper_stdout.log logs for the pod will show the following (example of details): [main] ERROR org.apache.zookeeper.server.quorum.QuorumPeer - Unable to load database on disk. As a workaround, go to the node where the zookeeper pod is crashing and do the following:

cd /mnt/cw_ddatafs/robot-zookeeper

rm -rf data/version-2

rm -rf log/version-2

kubectl delete pod robot-zookeeper-X --force --grace-period=0

This removes the bad data and restarts the zookeeper pod so that it replicates from the two running instances.

Installation

• The number of nodes installed in Cisco Crosswork 5.0 must be equal or more than the number of nodes in earlier version of Cisco Crosswork.

• Third-party device configuration in Device Management and Cisco NSO is not migrated and needs to be re-applied on the new version post migration.

• Custom user roles (Read-Write/Read) created in earlier version of Cisco Crosswork are not migrated and need to be recreated manually on the new Cisco Crosswork version post migration.

• Any user roles with administrative privileges in the earlier version of Cisco Crosswork must be assigned new permissions after the upgrade to continue being administrative users. 

• Crosswork Health Insights KPI alert history is not preserved as part of the migration. The system will need to be given some time to establish a new baseline for some KPIs. This may result in false alarms until the new base line is established.

For more information, see the Upgrade Cisco Crosswork chapter in the Crosswork Network Controller 5.0 Installation Guide.

Upgrade

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

• While retrieving device inventory via API from Cisco Crosswork, use page size of 200.

• In case of Cisco NSO Layered Service Architecture (LSA), the migration of devices between Resource Facing Service (RFS) nodes is not supported. If you try to move the devices between RFS nodes, it creates a duplicate device entry in Cisco NSO. See the Onboard and Manage Devices chapter in Cisco Crosswork Network Controller 5.0 Administration Guide for details and instructions on removing duplicates.

• Although the integration between Cisco NSO and Device Lifecycle Management (DLM) is automated, manual action is needed after a Cisco NSO recovery when the device admin status must go through DOWN/UP states. In this case, you must manually listen to NSO notifications that notify degradation within NSO and retry the action while NSO is up.

Device Management

• Each time the job list (located on the left side) is refreshed in the Collection Jobs window, the corresponding job details pane (located on the right side) must be manually refreshed.

• A user session will not be terminated when you close the tab or the browser. The only way to remove a user session is to either log out from Crosswork or terminate the session from the User window (Administration > User and Roles > Active Sessions).

UI

• Alarms, faults, errors, or any status indications for Cisco Crosswork Data Gateway will not be reflected on the VM node or its operational state.

• Alerting service can become unresponsive during stress testing. Alerts related to Crosswork applications may not be generated during this time. If this happens, Cisco Crosswork will recover the alerting by automatically restarting the service.

• If the node containing the Cisco Crosswork orchestrator is restarted, it might take up to 10 minutes before the health of the cluster can be viewed.

Alerts

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

• If you have configured only GNMI-based collection and the bandwidth value on the interface is modified, the UI displays the original interface bandwidth rather than the updated or reduced bandwidth. However, the feature pack's (CSM, BWoD, LCM) back end computes the bandwidth using the revised value from SR-PCE for that interface.

Topology

Cisco Crosswork will not allow you to power off two hybrid nodes at the same time. If a system loses a hybrid node due to any faults, it must be replaced as soon as possible.

High Availability

If you restart microservices for a Crosswork application, the microservice may appear removed upon restart, but the application will continue to show a healthy status.

Crosswork Manager

• Fault service does not generate the SWT_SWITCH_DOWN alarm when a device becomes unreachable.

• Localization of the ospfIfStateChange, ospfIfConfigError, ospfIfAuthFailure, ospfIfRxBadPacket, and ospfTxRetransmit alarms happens to loopback() from day 1.

Element Management Functions

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.

Smart Licensing

After importing a new custom Heuristic Package, if you then select Editing Monitoring Settings for an existing service to switch between monitoring levels (Basic/Advanced), the request to edit the settings will fail. Instead, after importing a new custom Heuristic Package, you must next stop or start an existing service. 

Service Health

L2VPN MPLS-EVPN over ODN-based policy monitoring is only supported for multi-point and not point-to-point. If, in this situation, point-to-point is selected, there will be no subservices for the associated ODN policies in Service Health Assurance Graph even though, on the device, the service is up (good health) and the ODN policies that are instantiated are up (good health).

Service Health L2VPN over ODN

If you shut down an SR Policy (L2VPN EVPN SR-TE service with fallback enable with Y1731 configured) at one endpoint, it results in packet loss and the Y1731 peer MEP check fails with symptoms flapping between up and peer-mep-failed and cross-check-missing in the device.

If service monitoring fails due to transient errors, such as HPM “nats time out”, stop and then restart service monitoring.

Service Health

Only enable one discovery protocol (CDP or LLDP) on an ethernet link when enabling protocols in the Layer 2 (L2) discovery settings. If you enable both CDP and LLDP on the same ethernet link and enable both protocols in the L2 discovery settings, it will result in duplicate links in the UI.

Layer 2 Discovery

After monitoring fails in one of the worker nodes in a cluster, stopping and restarting the monitoring again does not resolve the issue and the service remains in error state while Assurance Graph remains unavailable. After the node is recovered and is again up (with all CAPPs and pods in a healthy state), the service remains in error state.

Service Health

• Explicit Circuit Style policy creation in Crosswork Network Controller through NSO CFP is not supported.

• With NSO CFP, Circuit Style policies are only supported with L2VPN VPWS.

• NSO CFP does not check existing Circuit Style/Segment Routing (SR) policies that have the same Headend/Tailend color combination.

Crosswork Network Controller/Circuit Style provisioning though NSO Core Function Pack (CFP)

With Circuit Style, IOS XE and IPv6 are not supported.

Circuit Style

NSO service pack implementation should support proper handling of zombies and ensure that the delete service-state-change notifications be sent when a zombies for the service are removed for a proper integration with Cisco Crosswork Network Controller UI. Without this support, deleting or redeploy of a service from Cisco Crosswork Network Controller UI may not work as expected.

NSO service pack implementation

Service Health’s corresponding VPN remains in a healthy state (it does not fail or move to a degraded state) after the user powers off Cisco Data Gateway (CDG) and the collection jobs become degraded as expected. In this scenario, a user onboards devices attached to a CDG with no spare on the pool. An L3VPN service is created and is enabled to monitor with Advanced/gold profile. Once the Service Health service shows a healthy state, CDG is powered off and collection jobs become degraded. Because Service Health is live monitoring, the user would expect the corresponding VPNs to also become degraded or fail and not remain in a healthy state.

Service Health

Service Health subservices end up in initialization state or monitoring failed state after the following scenario: Load devices with JSON IETF, with one device being version 17.9.1 OS and the other device being version 17.6.3 OS, and then increase the timeout for both ASR920s. Create a L3VPN service with Loopback, enable a device to monitor service health, and then review the status for all subservices. In result, only interface health is supported and collection jobs scheduled. In addition, other subservices get scheduled but end up in initialization state or monitoring failed state.

Service Health

Route Policy

Secure ZTP image upgrade from 7.5.2 to 7.8.1, or 7.9.1 for IOS-XR NCS 55xx platforms, will fail due to a defect. This defect is resolved and fix is available on newer releases (7.9.2 and 7.10.1 IOS-XR version). Users cannot perform secure ZTP image install on versions 7.8.1 and 7.9.1, but can still perform the Day0 configuration upgrade operation without the image upgrade on the above IOS-XR versions.

Zero Touch Provisioning (ZTP)

Configuration upgrade fails with large files for IOS-XE ASR920 devices in 17.9.1 version.

Zero Touch Provisioning (ZTP)

• Associating an SR-TE policy with L2VPN-MPLS-EVPN is not supported.

• SR-TE policies are not supported with the following: L2VPN-ETREE-hub-spoke, L2VPN-ELAN-p2mp, L2VPN-ELAN-any-any.

Explicit path is not supported for SRv6 policy. However, when provisioning an SRv6 policy, if the candidate path is configured prior to enabling SRv6, the Explicit Path option is visible and can be committed with no warning and the explicit path configuration is ignored when SRv6 policy is pushed to the devices. If SRv6 is enabled first, before configuring the path, the Explicit Path option is not visible due to no SRv6 explicit path support.

Provisioning an SRv6 policy and configuring the Path

SR-ODN policy is not created on Traffic Engineering (TE) and Transport tabs even though the device’s policy has an operational UP status. This occurs if the router-id of any device is updated. In result, the topology must be rebuilt by re-importing the PCE and restarting the topo-svc service so that functionality works as expected.

SR-ODN Policy

L2VPN services may get stuck in an “in-progress” state after provisioning from the NSO UI. After loading different types of services from the NSO UI and cleaning them up, if you then reprovision those cleaned up services, those services will become stuck in an in-progress state. In this case, re-deploy the services stuck in-progress state so services regain a success state.

L2VPN Services

For the brownfield or greenfield customized service models that have schema with node type instance-identifier in the yang model, the Edit In Json Editor and Clone operation might not always work as expected.

Provisioning UI

Custom templates cannot be created using the UI, nor can their contents be visualized in the UI. Custom templates created offline can be applied to service models via UI and API. However, topology map overlays and service configuration views will not display custom template configuration.

Provisioning UI

Services can be provisioned to devices when devices are not mapped to Cisco Crosswork Network Controller or are operationally down, provided they are reachable and in sync with NSO.

Provisioning UI

This document

Shared installation guide for all the Cisco Crosswork applications and their common infrastructure. Covers:

• System requirements

• Installation prerequisites

• Installation instructions

• Upgrade instructions

Shared administration guide for all the Cisco Crosswork applications and their common infrastructure. Covers:

• Managing clusters and data gateway

• Data collection

• High availability

• Backup and restore

• Onboard and manage devices

• Zero touch provisioning

• Set up maps

• Managing users, access and security

• Maintain system health

• Solution overview

• Supported use cases and their benefits.

• Procedures for achieving the desired outcome for real-life usage scenarios using the Cisco Crosswork Network Controller UI.

Lists of licenses and notices for open source software used in Cisco Crosswork Network Controller 5.0.x.

API Documentation

Advanced users can extend the Cisco Crosswork functionality using the APIs. API documentation is available on Cisco Devnet.