Crosswork Infrastructure

6.0

A resilient and scalable platform on which all of the Cisco Crosswork applications can be deployed. The infrastructure is based on a cluster architecture for extensibility, scalability, and high availability.

For installation, configuration and administration procedures, refer to the following documents:

• Cisco Crosswork Network Controller 6.0 Installation Guide

• Cisco Crosswork Network Controller 6.0 Administration Guide

Optimization Engine

6.0

Provides closed-loop tracking of the network state and real-time network optimization in response to changes in network state, allowing operators to effectively maximize network capacity utilization, as well as increase service velocity.

Provides traffic engineering visualization of SR-MPLS, SRv6, and RSVP-TE policies.

Active Topology

6.0

Enables VPN (L2VPN, L3VPN) service provisioning, service oriented transport (SR-MPLS, SRv6, CS-SR, RSVP-TE) provisioning and topology visualization of the provisioned services with the ability to customize the service provisioning and visualization through service model extensibility.

Service Health

6.0

Overlays a service level view of the environment and allows operators to monitor the health of services (for example, L2/L3 VPN) based on rules established by the operator.

Health Insights

6.0

Performs real-time Key Performance Indicator (KPI) monitoring, alerting, and troubleshooting. It builds dynamic detection and analytics modules that allow operators to monitor and alert on network events based on user-defined logic.

Change Automation

6.0

Automates the process of deploying changes to the network.

Crosswork Data Gateway

6.0

A secure, common collection platform for gathering network data from multi-vendor devices that supports multiple data collection protocols including MDT, SNMP, CLI, standards-based gNMI (dial-in), and syslog.

Zero Touch Provisioning

6.0

Automatic onboarding of new IOS-XR and IOS-XE devices and provisioning of Day0 configuration, resulting in faster deployment of new hardware at a lower operating cost.

Cisco Network Services Orchestrator

6.1.4

An orchestration platform that makes use of pluggable function packs to translate network-wide service intent into device-specific configuration. Cisco NSO provides flexible service orchestration and lifecycle management across physical network elements and cloud-based virtual network functions (VNFs), fulfilling the role of the Network Orchestrator (NFVO) within the ETSI architecture. It provides complete support for physical and virtual network elements, with a consistent operational model across both. It can orchestrate across multi-vendor environments and support multiple technology stacks, enabling extension of end-to-end automation to virtually any use case or device.

Cisco Segment Routing Path Computation Element (SR-PCE)

7.11.1

An IOS-XR multi-domain stateful PCE supporting both segment routing (SR) and Resource Reservation Protocol (RSVP). Cisco SR-PCE builds on the native Path Computation Engine (PCE) abilities within IOS-XR devices, and provides the ability to collect topology and segment routing IDs through BGP-LS, calculate paths that adhere to service SLAs, and program them into the source router as an ordered list of segments.

Local Congestion Mitigation (LCM) feature pack

• Automated Mode—This option allows LCM to automatically deploy TE tunnel recommendations based on thresholds that you configure.

  Note	Automated mode is accessible through Limited Availability. Engage your account team for further details.

• Manual Mode (default)—This option, which was available in previous releases, requires a user to view the LCM Operational Dashboard and decide whether to commit TE tunnel recommendations.

• Pause Mode—This option can pause LCM operations on a particular interface when LCM is in either Automated or Manual mode. Pausing operations in Automated mode are necessary in cases where deployed solutions do not result in the intended resolution, there is uneven ECMP traffic, there are policies that are not carrying traffic, or when an interface is continuously throttling between different solutions.

  Note	Pausing LCM operations removes all existing TE policies that were deployed for that interface.

• Hop count is now available as a metric type when computing SR-TE Circuit Style policies.

• In response to feedback from customers, we have changed some events to alarms. For example, an alarm is triggered when policy traffic exceeds the reserved bandwidth pool size or threshold.

• APIs:

  • RESTCONF APIs—Manually re-optimize (single or multiple) SR-TE Circuit Style policies. These APIs can be initiated after network topology changes.

  • CSPolicyPathsOnLinks—Lists Circuit Style SR-TE policies on a specified link and filtered by its operational state (up,down,active, and unknown) of the specified policies.

  • AllCSPolicyPaths—Lists Circuit Style SR-TE policies filtered by its operational state and if it has hops (segment lists).

  • CSPolicyPathsonNode—Lists all Circuit Style SR-TE policies on specified nodes filtered by its operational state (up,down,active, and unknown).

  To view API documentation, see Cisco Devnet.

Bandwidth on Demand feature pack

• In previous releases, BWoD required protected adjacency SID constraints. Now user can elect BWoD to prefer to use protected (default option) or unprotected adjacency SIDs.

• The Policy Violation now has two options: Strict or Loose.

• The process of changing delegation from one PCE to another has been improved to guarantee a clean transfer of PCE roles.

• Enhanced batch processing of queued BWoD policy computations. The queue is initially cleared prior to running a list of new pending delegations/undelegations instead of running each delegation one at a time.

Flexible Algorithm

• You can now view Application-Specific Link Attribute ASLA Flexible Algorithm metrics (TE and Delay) in the link details:

  Note	ASLA is supported on PCC and core routers that are Cisco IOS XR 7.4.1 or later versions.

  1. From the Traffic Engineering topology map, click on a participating Flex Algorithm link.

  2. From the Links page, click Link_Type_entry > Traffic Engineering tab > General. For example:

     
     
     

• An overlay on the topology map has been added when Flexible Algorithms are selected. This is to help identify which Flexible Algorithms are selected more easily. For example:

  
  
  

Tree-SID

PCE warnings and path compute elements are displayed in Tree-SID policy details:

Performance Metrics of TE policies

When Service Health is installed and SR-PM collection is enabled, you can view KPI metrics (Delay, Jitter, and Liveness) from the Traffic Engineering table or from the TE tunnel details.

To view the KPI metrics for the policy:

1. Configure SR-PM on the device from the policy provisioning page (Services & Traffic Engineering > Traffic Engineering > SR-MPLS or RSVP tab. Locate the policy you are interested in from the policy table and click
   
   > performance metrics).

   Note	You can configure Delay or Liveness (not both) manually on the device. See the device platform documentation for information. For example: Segment Routing Configuration Guide for NCS 540 Series Routers.

2. Enable SR-PM collection in Performance Metrics Settings (Administration > Settings > System Settings tab > Performance Metrics).

SR-MPLS policies

KPI metrics contain Delay, Delay Variance (Jitter) or Liveness (Boolean value) along with traffic utilization. For example:

RSVP-TE Tunnel

KPI metrics include Delay and Delay Variance (Jitter) along with Utilization. For example:

In previous releases, only one side of the link delay value for an interface was considered during computation. When you configure delays on both remote and local nodes, the calculation of each delay on each interface is now taken into consideration when computing a path.

TE tunnel or device details are now assigned unique URLs that can be shared. The URL sends the user to the Policy or Device Details page after logging in.

• SR-MPLS, SRv6, Tree-SID, and RSVP-TE tunnels —From the Traffic Engineering table, click Actions > View Details for a particular row.

• Devices—From the Traffic Engineering topology map, click on a device.

Improvements made in topology discovery time, network model building, and processing cache, bandwidth, metric, and TE tunnel type information.

Transport Slicing

Cisco Crosswork Network Controller offers direct support for network slicing at the transport level. This slice “instance” is a unique slice provisioned in the network but with a set of Service Level Requirements chosen from a set of pre-created Network Slice Templates (NST). The Slice Management Function (SMF) in turn communicates with each sub-domain controller, called a Network Slice Subnet Management Function (NSSMF) which in turn provisions the corresponding domain specific slice instance across its own sub-domain boundaries (called a Network Slice Subnet Instance (NSSI)) using a similar set of domain specific Network Slice Subnet Templates (NSST).

Cisco Crosswork Network Controller also offers:

• Slice design and deployment from the perspective of two user persona: Slice Designer and Slice Instance Requester.

• Deploying the Slice Catalog using the new slice template UI.

  • Adding Service Assurance into the catalog using the NSO CLI.

• Requesting a new Slice Instance by picking intent from the catalog using IETG Slice YANG model, select endpoints and submit.

  • You can deploy a slice instance after providing information, in the UI, after following four easy steps.

• Automated slice instance deployment:

  • QoS: The Slicing CFP will apply input and output QoS policy maps on all slice endpoint interfaces (policy-maps pre-deployed). Both L2 & L3 QoS supported.

  • Path Forwarding: The Slicing CFP will deploy SR-TE ODN templates on all head-ends (metrics= latency, igp, TE, BWoD, FA, etc). Additionally, it will set BGP color community accordingly on all slice advertised VPN prefixes.

  • Service Assurance: The Slicing CFP will setup:

    1. Cisco Crosswork Network Controller Heuristic packages for Cisco Crosswork Network Controller Automated Assurance/Service Health.

    2. Configure Y1731 probing for P2P L2 slices.

    3. Configure SR-PM probing for delay and liveness on all slice SR-TE tunnels.

  • Connectivity: The Slicing CFP will use the L2/L3VPN IETF NM to setup L3 or L2 connectivity automatically across defined slice endpoints. All VPN parameters inferred and abstracted.

    • Setup eVPN VPWS for P2P L2 slices.

    • Setup eVPN any-to-any or hub-spoke for L2 multipoint or L3 multipoint slices.

    • Setup up “extranet” connectivity between dedicated and shared slice types. (more on this later).

    • Setup PE-CE eBGP for L3 based slices.

  Note

  If you are creating an L2 point-to-point transport slice, prerequisites include the following: (a) The route-policy needs to be configured on the PE nodes (for example: L2-ATTACH). (b) In global-settings on NSO, configure this sample command: set network-slice-services global-settings parent-rr-route-policy L2-ATTACH.

• Using the UI, visualize the slice components: VPN, Transport, Health:

  • Display a slice on the map.

  • View Slice and VPN view along with Shared Slices and CE (Neighbor) connected in Logical View.

  • Visualize Shared Slices associated to dedicated slice.

  • From the VPN list, display VPN details including Assurance data if monitoring is enabled.

  • From the Transport list, display SR TE details including SR-PM data if SR-PM is enabled.

  • Using Health details, view symptom details and any failed subexpressions and metrics (which will provide information on any active symptoms and root causes).

Errors due to a component failures, operational errors or device errors are now displayed as Monitoring Errors on the UI. You can filter these errors using the mini-dashboard or the filters.

Ability to rate-limit monitoring requests

To efficiently manage service monitoring requests, Service Health has implemented a rate-limiting process. This means that there may be a delay in publishing service monitoring requests if the number of requests raised per minute exceeds a specific threshold. The thresholds are defined as follows:

• Basic monitoring requests – 50 services per minute

• Advanced monitoring requests – 5 services per minute

• Delete monitoring requests – 30 services per minute

The rate-limiting process also extends to the monitoring data, that is metrics and Events of Significance (EOS), sent by Crosswork Data Gateways to the Crosswork Tracker component. For example, during a restore process, when all Crosswork Data Gateways send metrics again to the Crosswork Tracker component, the rate at which the Crosswork Tracker processes this data and forwards it to Assurance Graph Manager is regulated. This may lead to a delayed reporting of Events of Significance (EOS) following the restore.

In the event of delays, an event is triggered with a severity level of 'Warning' and a corresponding description to notify you of the delay. The event is cleared once Service Health resumes normal publishing of monitoring requests.

Ability to monitor performance metrics of TE policies using SR-PM

To measure the performance metrics of VPN services using the SR-MPLS or RSVP-TE Traffic Engineering policies, Service Health leverages Segment Routing Performance Measurement (SR-PM). This feature enables measuring metrics on the underlay SR-TE policy to enforce Service Level Agreements in VPN services.

Crosswork Network Controller can leverage external probing, provided by Accedian Skylight, to measure metrics of the network services. The metrics are compared with the contracted SLA (defined in the Heuristic package), and the results are made available on the Crosswork Network Controller UI.

After an L3VPN service is provisioned and service monitoring is enabled, the probe intent and probe topology are learned (from provisioned service) and a probe session to monitor the service starts automatically by invoking relevant RESTConf APIs. Service Health processes the metrics and raises symptoms as needed to be displayed on the UI. You can view historical data for upto 24 hours from the Probe Sessions.

The maximum number of probe sessions per service are capped at 200 (for all connection types).

Simplified Topology Rebuild Tool

If the topology is not displaying status as expected, you can now place the system into maintenance mode and then choose to rebuild the topology. This will force the system to create a new topology model and avoid the complicated steps from previous versions.

Ability to reattempt the import of Controller Certificate file

When Crosswork Infrastructure and Crosswork Data Gateway are deployed simultaneously, on the first reboot Data Gateway attempts to the download the Controller Certificate file from Crosswork Infrastructure. If the Infrastructure deployment is in-progress, Crosswork Data Gateway may not find the certificate. In the past, you had to wait for the Data Gateway VM to restart before downloading the certificate through the Interactive Console menu.

With Crosswork Data Gateway's latest release, you can let Data Gateway retry the certificate download multiple times. If the file download fails, the Crosswork Data Gateway will now retry automatically.

For information on importing the certificate, see the Import Controller Signing Certificate File section in Cisco Crosswork Network Controller 6.0 Installation Guide.

Parameter to configure the CLI session timeouts for devices

The SSH Session Timeout parameter is implemented to indicate the duration of the CLI connection on a device.

For information on how to configure the SSH Session Timeout parameter, see the Configure Crosswork Data Gateway Global Parameters section in Cisco Crosswork Network Controller 6.0 Administration Guide.

Changes to the Crosswork Data Gateway APIs

The Crosswork Data Gateway APIs have been altered in the following ways:

• The new dg-manager APIs are compatible with the OpenAPI v2/v3 specification.

• The change logs include the deprecated APIs. In the subsequent release, the deprecated APIs are removed.

• A change log is created for each modified API. The change log includes the APIs that have been deprecated, removed, or updated.

For information on change logs, see Cisco Devnet.

NETCONF Collector support is decommissioned

The NETCONF collector enabled data collection over the NETCONF protocol.

Support for the NETCONF collector has been discontinued in configurations, such as the base VM, application layer, Docker, and dg-manager.

Device Level RBAC

This release introduces role-based access control (RBAC) at a device granularity for provisioning and device configuration workflows. Each user must be assigned a role that determines what functions they can access along with a Device Group that determines on which devices they can manage or deploy services. For more information, see the Manage Device Access Groups section in the Cisco Crosswork Network Controller 6.0 Administration Guide.

Geo Redundancy

This release introduces the first phase of the geo redundancy solution for Crosswork Network Controller and its components in case of a region or data center failure. For more information, see the Enable Geo Redundancy section in the Cisco Crosswork Network Controller 6.0 Installation Guide.

Documentation

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

• Cisco Crosswork Network Controller 6.0 Service Health Monitoring is a new Crosswork Network Controller specific guide that provides information on monitoring the health of L2VPN and L3VPN services. It provides insights into analyzing and troubleshooting degraded services, as well as visualizing service health status and logical dependency trees.

• Cisco Crosswork Network Controller 6.0 Traffic Engineering and Optimization is a new Crosswork Network Controller specific guide that provides information on how to visualize and configure traffic engineering in Crosswork Network Controller.

• Cisco Crosswork Network Controller 6.0 Network Bandwidth Management is a new Crosswork Network Controller specific guide that provides information on how to use Crosswork Network Controller feature packs. Feature packs are tools that tackle congestion mitigation and the management of SR-TE policies to find and maintain intent based bandwidth requirements.

7.3.1

7.3.2

7.4.1

7.4.2

7.5.2

7.6.1

7.7.1

7.7.2

7.8.1 + SMU (CSCwc93705)

7.8.2

7.9.1

7.9.2

7.10.2

7.11.1

17.4.1¹²

17.5.1

17.6.3

17.7.1

17.8.1

17.9.1

17.12.1

Devices

25,000

Total Interfaces¹³

500,000¹⁴

Provision of SR-TE policies and RSVP-TE tunnel (PCE-initiated)

150,000

IGP links

200,000

VPN Services (L2VPN, L3VPN)

300,000