Prepare Infrastructure for Device Management

This section contains the following topics:

Credential profiles

Credential profiles are collections that store credentials for various network protocols such as SNMP, Telnet, SSH, and HTTP that have been set at the device level. These profiles allow you to easily apply credentials consistently when adding new devices or providers. You can include as many protocols and their corresponding credentials as needed within a profile. The profiles must match what is already on the device. By using credential profiles, you can automate device configuration changes, streamline monitoring, and facilitate communication with providers.

Credential Profiles page

From the Credential Profiles page, you can create a new credential profile, update the settings configured for an existing profile, or delete a profile. To open this page, choose Device Management > Credential Profiles.

Figure 1. Credentials Profile window
Credentials Profile window
Item Description

1

Click Add icon to add a credential profile. See Create credential profiles.

Click Edit icon to edit the settings for the selected credential profile. See Edit credential profiles.

Click Delete icon to delete the selected credential profile. See Delete credential profiles.

Click Import icon to import new credential profiles from a CSV file. You can also download a CSV file template by clicking this icon. The template includes sample data that you can use as a guide for building your own CSV file. See Import credential profiles using a CSV file.

Click Export icon to export credential profiles to a CSV file. See Export credential profiles.

2

Click Refresh icon to refresh the Credential Profiles window.

Click Settings icon to choose the columns to make visible in the Credential Profiles window.

Click Set Filter icon to set filter criteria on one or more columns in the Credential Profiles window.

To clear a filter, click the corresponding [X] in the Filters menu.

Create credential profiles

Import several credential profiles at one time

If you have many credential profiles to add, you may find it more efficient to put the information in a CSV file and import the file. See Import credential profiles using a CSV file.

Follow these steps to create a new credential profile.

Procedure


Step 1

Choose Device Management > Credential Profiles > Add icon.

Step 2

Enter a descriptive profile name to ensure it is easily distinguishable from other credential profiles. The name can contain a maximum of 128 alphanumeric characters. You can use letters, numbers, dots (.), underscores (_), and hyphens (-).

Step 3

Select a protocol from the Connectivity type drop down list. Confirm what connection types must be configured in a credential profile for specific providers. See Provider families.

Step 4

Complete applicable credentials and ensure they match what is already on the device.

Step 5

To add more protocols, click + Add Another and repeat the previous steps.

Step 6

Click Save.


Import credential profiles using a CSV file

If you have many credential profiles to add, you may find it more efficient to put the information in a CSV file and import the file. Importing credential profiles from a CSV file adds new profiles to the database. It will overwrite any duplicate profiles that already exist.

Additional security

To maintain network security, use asterisks in place of real passwords, and community strings in any CSV file you plan to import. After the import, follow the steps in Edit credential profiles to replace the asterisks with actual passwords and community strings.

Considerations when replacing an existing CSV file

When re-importing a credential profile CSV file that you have exported and edited, keep in mind that all passwords and community strings in the exported file are replaced with asterisks (*). You cannot re-import an exported credential profile CSV file with blank passwords.

Follow these steps to import credential profiles using a CSV file.

Procedure


Step 1

Choose Device Management > Credential Profiles > Import icon.

Step 2

If you have not already created a credential profile CSV file to import:

  1. Click the Download sample 'Credential template (*.csv)' file link and save the CSV file template to your local disk.

  2. Open the template using your preferred tool and edit one row for each credential profile. See Credential profile template guidelines.

  3. When you are finished, save the new CSV file.

Step 3

Click Browse to navigate and open the CSV file.

Step 4

With the CSV file selected, click Import.

The credential profiles you imported should now be displayed in the Credential Profiles window.


Credential profile template guidelines

Follow these guidelines when editing the credential template:

  • Use a semicolon to separate multiple entries in the same field. Use two semicolons with no space between them to indicate that you are leaving the field blank. When you separate multiple entries with semicolons, remember that the order in which you enter values in each field is important. For example, if you enter SSH;NETCONF;TELNET in the Connectivity Type field and you enter UserTom;UserDick;UserHarry; in the User Name field, the order of entry determines the mapping between the two fields:

    • SSH: UserTom

    • NETCONF: UserDick

    • TELNET: UserHarry

  • Enter SNMP community string information exactly as currently entered on your devices. Failure to do so will result in loss of device connectivity, and inability to collect certain KPI data or execute configured Playbooks on devices associated with the credential profile.

  • Password and community string information associated with a user ID are stored in plain text in the CSV file you prepare. Be aware of the security implications of this, and apply appropriate safeguards.

  • Delete the sample data rows before saving the file or they will be imported along with the data you want. The column header rows are ignored during import.

  • Each row defines a credential profile. You can use this table to help you populate each credential profile.

    Field Entries Required or Optional

    Credential Profile

    The name of the credential profile. For example: nso, srpce.

    Required

    Connectivity Type

    Valid values are: SSH, SNMPv2, NETCONF, TELNET, HTTP, HTTPS, GNMI, SNMPv3, or TL1.

    Required

    • Devices—SNMP and SSH (to avoid operational errors due to clock synchronization checks) are required.

    • SR-PCE—Since SR-PCE is considered a provider and a device, SSH, and HTTP are required.

    • NSO—NETCONF is required.

    Note

     

    SSH and SNMP credentials are mandatory for onboarding devices and synchronizing with the NSO provider.

    User Name

    For example: NSOUser

    Required if Connectivity Type is SSH, NETCONF, TELNET, HTTP, HTTPS, SNMPv3, or GRPC.

    Password

    The password for the preceding User Name.

    Required

    Enable Password

    Use an Enable password. Valid values are: ENABLE, DISABLE, or leave blank (unselected)

    Required if Connectivity Type is SSH or TELNET. Otherwise leave blank.

    Enable Password Value

    Specify the Enable password to use.

    Required if Connectivity Type is SSH or TELNET, and Enable Password is set to ENABLE. Otherwise leave blank.

    SNMPV2 Read Community

    For example: readprivate

    Required if Connectivity Type is SNMPv2

    SNMPV2 Write Community

    For example: writeprivate

    Required if Connectivity Type is SNMPv2

    SNMPV3 User Name

    For example: DemoUser

    Required if Connectivity Type is SNMPv3

    SNMPV3 Security Level

    Valid values are noAuthNoPriv, AuthNoPriv or AuthPriv

    Required if Connectivity Type is SNMPv3

    SNMPV3 Auth Type

    Valid values are

    • HMAC_SHA2-512

    • HMAC_SHA2_384

    • HMAC_SHA2_256

    • HMAC_SHA2_224

    • HMAC_MD5

    • HMAC_SHA

    Required if Connectivity Type is SNMPv3 and SnmpV3 Security Level is AuthNoPriv or AuthPriv

    SNMPV3 Auth Password

    The password for this authorization type.

    Required if Connectivity Type is SNMPv3 and SnmpV3 Security Level is AuthNoPriv or AuthPriv

    SNMPV3 Priv Type

    The following SNMPv3 Privacy Types are supported:

    • CFB_AES_128

    • CBC_DES_56

    • AES-192

    • AES-256

    • 3-DES

    Required if Connectivity Type is SNMPv3 and SnmpV3 Security Level is AuthPriv

    SNMPV3 Priv Password

    The password for this privilege type.

    Required if Connectivity Type is SNMPv3 and SnmpV3 Security Level is AuthPriv

Edit credential profiles

Follow these steps to edit credential profiles.


Warning


Changing the settings in a credential profile without first changing the settings on the device associated with the profile may result in a loss of connectivity, inability to collect certain KPI data, or an inability to execute configured playbooks on devices associated with the modified profile. For example: If the SNMP community string on the device no longer matches what is in the credential profile, SNMP-based KPIs will not function.


Before you begin

  • Before editing any credential profile, it is always good practice to export a CSV backup of the profiles you want to change (see Export credential profiles).

  • Change settings on any associated devices before you make changes to the credential profile.

Procedure


Step 1

Choose Device Management > Credentials.

Step 2

Check the profile check box you want to update, and click Edit icon.

Step 3

Make the necessary changes and then click Save.

Note

 

If the device is not updated within 30 seconds when you modify connectivity or credential profile information, move the device state to DOWN and then UP. The CLI reachability is triggered and the updated values are displayed.


Export credential profiles

Exporting credential profiles stores all the profiles you selected in a CSV file. This is a quick way to make backup copies of your credential profiles. You can also edit the CSV file as needed, and re-import it to add new or modify credential profile data.

The exported credential profiles CSV file does not contain real passwords or community strings. All the characters in the passwords and community strings entries in the credential profiles are replaced with asterisks in the exported CSV file. If you plan on modifying your exported CSV file and then re-importing it, Cisco recommends that you use asterisks in place of real passwords and community strings. After the import, follow the steps in Edit credential profiles to replace the asterisks with actual passwords and community strings.

Procedure


Step 1

Choose Device Management > Credential Profiles.

Step 2

(Optional) In the Credential Profiles window, filter the credential profile list as needed.

Step 3

Check the profile check boxes for the profiles you want to export.

Step 4

Click Export icon. Depending on your browser, you will be prompted to select a path and file name to use when saving the CSV file, or to open it immediately


Delete credential profiles

Follow the steps below to delete a credential profile.


Note


You cannot delete a credential profile that is associated with one or more devices or providers.


Procedure


Step 1

Export a backup CSV file containing the credential profile you plan to delete (see Export credential profiles).

Step 2

Check whether any devices or providers are using the credential profile you plan to delete. You can do this by filtering on the Credential Profile column, which is available on both the Devices window (choose Device Management > Credential Profiles) and the Providers window (choose Administration > Manage Provider Access).

Step 3

Reassign the devices or providers to a different credential profile (for help with this task, see Change the credential profile for multiple network devices and Edit Providers).

Step 4

After all devices and providers have had their credential profiles reassigned: From the main menu, choose Device Management > Credential Profiles.

Step 5

In the Credential Profiles window, choose the profile that you want to delete and then click Delete icon.


Change the credential profile for multiple network devices

If you want to change the credential profile for a large number of network devices, you may find it more efficient to make the change by editing devices in the CSV file. In summary, the process is:

  1. Export a CSV file containing the devices whose credential profiles you want to change (see Export Device Information to a CSV File).

  2. Edit the CSV file, changing the credential profile for each device (this credential profile must already exist).

  3. Save the edited file.

The credential profile linked to these devices must include the authorization credentials for each protocol configured during onboarding. If any protocol-specific credentials are missing or incorrect in the profile, the CSV import will succeed, but reachability checks for these devices will fail.

Before you begin

Ensure that the credential profile you intend to switch to already exists; otherwise, the CSV import will fail. If you haven't created the necessary credential profile, do so before proceeding.

Procedure


Step 1

From the main menu, choose Device Management > Devices. The Network Devices tab is displayed by default.

Step 2

Choose the devices whose credential profiles you want to change. Your options are:

  • Click Export icon to include all devices.
  • Filter the device list by entering text in the Search field or by filtering specific columns. Then click Export icon to include only the filtered list of devices.
  • Check the boxes next to the device records you want to change. Then click Export icon to include only the devices that have been checked.

Step 3

Edit and save the new CSV file using the tool of your choice. Be sure to enter the correct credential profile name in the Credential Profile field for each device.

Step 4

Click Import icon.

Step 5

In the Import dialog box, click Browse, choose the new CSV file, and click Import.


Providers

Crosswork Network Controller components depend on external services such as the Cisco Crosswork Network Services Orchestrator (NSO) and the Segment Routing Path Computation Element (SR-PCE) for operations like configuration modifications and segment routing path calculations. To facilitate access management and information sharing among Crosswork Network Controller components, each external service requires a configured provider, such as NSO or SR-PCE. The provider family specifies the type of service offered to the Crosswork Network Controller and the specific parameters that need configuration. The system stores the provider connectivity details and makes that information available to applications. For more information, see Before You Begin.

Provider families

Cisco Crosswork supports different types, or families, of providers. Each provider family supplies its own mix of special services, and each comes with unique requirements and options.

Table 1. Supported provider families

Provider Family

Description

NSO

Instances of Cisco Network Services Orchestrator (Cisco NSO), used to configure network devices. See Add a Cisco NSO provider.

SR-PCE

Instances of Cisco Segment Routing Path Computation Elements (Cisco SR-PCE) containing the configuration information needed to allow Cisco Crosswork applications to communicate with and retrieve segment routing information for the network. See Add SR-PCE providers.

WAE

Instances of Cisco WAN Automation Engine (Cisco WAE) provide "what if" analysis used to evaluate network changes. See Add Cisco WAE providers .

Syslog Storage

Instances of storage servers (remote or on the Cisco Crosswork application VM itself) where you want to store syslogs and other data retrieved from devices by KPIs and playbooks. See Add Syslog Storage providers.

Alert

Instances of providers (such as Cisco Crosswork Situation Manager) to which alerts collected during KPI monitoring are to be forwarded. See Add an Alert Provider

Proxy

Instances of proxy providers. See Add Proxy Providers

Accedian (ACCEDIAN_PROXY)

Instances of Accedian Skylight providers. See Add Accedian Skylight as Provider for more details.

Provider dependency

This section explains the provider configurations required for each system component.

Table 2. Provider dependency matrix

Cisco Crosswork Network Controller Component

Provider Type

NSO

SR-PCE

WAE

Syslog Storage

Alert

Proxy

Element Management Functions

Optional

Optional

Optional

Optional

Optional

Optional

Optimization Engine

Optional

Mandatory

Required protocol is HTTP.

Optional

Optional

Optional

Optional

Active Topology

Mandatory

Required protocols are HTTPS and SSH (for NSO backup)

Mandatory

Required protocol is HTTP.

Optional

Optional

Optional

Optional

Service Health

Mandatory

Required protocols are HTTPS and SSH (for NSO backup)

Mandatory

Required protocol is HTTP.

Optional

Optional

Optional

Optional

Change Automation

Mandatory

Required protocols are HTTPS and SSH (for NSO backup)

Optional

Optional

Optional

Optional

Optional

Health Insights

Mandatory

Required protocols are HTTPS and SSH (for NSO backup)

Optional

Optional

Optional

Optional

Optional


Note


Configuring a syslog storage provider with Change Automation and an alert provider with Health Insights is beneficial but not mandatory.


Providers page

The Providers page allows you to easily access tasks to create and manage providers. To navigate to this page, choose Administration > Manage Provider Access.

Figure 2. Providers page
Providers Window
Item Description

1

The icon shown next to the provider in this column indicates the provider's Reachability.

2

Click Add icon to add a provider. See Add a provider.

Click Edit icon to edit the settings for the selected provider. See Edit Providers.

Click Delete icon to delete the selected provider. See Delete providers.

Click Import icon to import new providers or update existing providers from a CSV file. You can also download a CSV file template by clicking this icon. The template includes sample data that you can use as a guide for building your own CSV file. See Import multiple providers using a CSV file.

Click Export icon to export a provider to a CSV file. See Export Providers.

3

Click Details icon next to the provider in the Provider Name column to open the Properties pop-up window, showing the details of any startup session key/value pairs for the provider.

4

Click Details icon next to the provider in the Connectivity Type column to open the Connectivity Details pop-up window, showing the protocol, IP, and other connection information for the provider.

5

Click Refresh icon to refresh the Providers window.

Click Settings icon to choose the columns to make visible in the Providers window (see ).

6

Click Set Filter icon to set filter criteria on one or more columns in the Providers window.

To clear a filter, click the corresponding [X] in the Filters menu.

Avoid topology sync issues during provider updates

Wait until the system responds between performing a succession of provider updates. For example, wait for some time between adding, deleting, or reading providers. Topology services may not receive these changes if you perform these actions too quickly. However, if you find that topology is out of sync, restart the topology service.

Add a provider

Follow these general steps to add a new external provider. For specific configuration considerations and requirements for different provider families, see Provider families.

You can then map the provider to devices.

Procedure


Step 1

Choose Administration > Manage Provider Access > Add icon.

Step 2

Enter required fields. See Table 1

Step 3

Click Save to add the new provider.

Step 4

(Optional) Repeat to add more providers.


Table 3. Provider fields
Field Description

* Provider Name

The name for the provider that will be used to refer to it in the Cisco Crosswork application. For example: Linux_Server. The name can contain a maximum of 128 alphanumeric characters, plus dots (.), underscores ("_") or hyphens ("-"). No other special characters are allowed.

* Credential Profile

Select the name of the credential profile that is used by the Cisco Crosswork application to connect to the provider.

* Family

Select the provider family.

Connection Type(s)

* Protocol

Select the principal protocol to be used to connect to the provider.

To add more connectivity protocols for this provider, click Add icon at the end of the first row. To delete a protocol you have entered, click Delete iconshown next to that row.

You can enter as many sets of connectivity details as you want, including multiple sets for the same protocol.

* Server Details

Select and provide one of the options:

  • IP Address (IPv4 or IPv6) and subnet mask of the provider's server.

  • FQDN (Domain name and Host name)

* Port

Enter the port number to use to connect to the provider's server. This is the port corresponding to the protocol being configured. For example, if the protocol used to communicate with the provider server is SSH, the port number is usually 22.

Timeout

Enter the amount of time (in seconds) to wait before the connection times out. The default is 30 seconds.

Model Prefix Info

Note

 

The Model and Version fields do not apply to single VM deployments of Crosswork Network Controller.

* Model

Required if you are adding a Cisco NSO provider: Select the model prefix that matches the NED CLI used by Cisco NSO. Valid values are:

Cisco-IOS-XR

Cisco-NX-OS

Cisco-IOS-XE

For telemetry, only Cisco-IOS-XR is supported.

To add more model prefix information for this Cisco NSO provider, click the Add icon at the end of any row in the Model Prefix Info section. To delete a model prefix you have entered, click the Delete icon shown next to that row.

* Version

Required only if you are adding a Cisco NSO provider: Enter the Cisco NSO NED driver version used on the NSO server.

Provider Properties

Property Key

Enter the name of the key for the special provider property you want to configure.

Provider properties control how the Cisco Crosswork Network Controller component interacts with the provider. Not all providers need them, and the number and type of properties vary with the provider family. These properties are documented in topics about adding specific providers elsewhere in this Guide. The system does not validate provider properties. Make sure the properties you enter are valid for the provider.

Note

 

In a two network interface configuration, the Cisco Crosswork applications default to communicating with providers using the Management Network Interface (eth0). You can change this behavior by adding Property Key and Property Value as outgoing-internal and eth1 respectively. This is most often necessary when creating the SR-PCE provider, as its management interface may reside on the data network instead of the management network.

Property Value

Enter the value to assign to the property key.

To add more special properties for this provider, click Add icon at the end of any key/value pair in the Provider Properties section. To delete a key/value pair you have entered, click Delete icon shown next to that pair.

Import multiple providers using a CSV file

Complete the steps below to create a CSV file that specifies providers and then import it into the Cisco Crosswork application.

Importing providers from a CSV file adds any providers not already in the database, and updates any providers with the same name as an imported provider. For this reason, it is a good idea to export a backup copy of all your current providers before an import (see Export Providers).

Procedure


Step 1

From the main menu, choose Administration > Manage Provider Access.

Step 2

Click Import icon to open the Import CSV File dialog box.

Step 3

If you have not already created a provider CSV file to import:

  1. Click the Download sample 'Provider template (*.csv)' file link and save the CSV file template to a local storage resource.

  2. Open the template using your preferred tool. Begin adding rows to the file, one row for each provider.

    Use a semicolon to separate multiple entries in the same field. Use two semicolons with no space between them to indicate that you are leaving the field blank. When you separate entries with semicolons, the order in which you enter values is important. For example, if you enter SSH;SNMP;NETCONF;TELNET in the connectivity_type field and you enter 22;161;830;23 in the connectivity_port field, the order of entry determines the mapping between the two fields:

    • SSH: port 22

    • SNMP: port 161

    • NETCONF: port 830

    • Telnet: port 23

    Be sure to delete the sample data rows before saving the file, or they will be imported along with the data you want. The column header row can stay, as it is ignored during import.

  3. When you are finished, save the new CSV file.

Step 4

Click Browse to navigate to the CSV file you just created and then click Open to select it.

Step 5

With the CSV file selected, click Import.

The provider information you imported should now be displayed in the Providers window.

Step 6

Resolve any errors reported during the import and check provider details to confirm connection.


Cisco NSO providers

The Cisco Network Services Orchestrator (Cisco NSO) provider functions as the provider for Cisco Crosswork to configure the devices according to their expected functions, including optionally configuring MDT sensor paths for data collection. Cisco NSO provides the important functions of device management, configuration, and maintenance services.

NSO function packs

The Cisco NSO sample function packs are provided as a starting point for VPN service provisioning functionality in Cisco Crosswork Network Controller. While the samples can be used “as is” in some limited network configurations, they are intended to demonstrate the extensible design of Cisco Crosswork Network Controller. Answers to common questions can be found on Cisco Devnet and Cisco Customer Experience representatives can provide answers to general questions about the samples. Support for customization of the samples for your specific use cases can be arranged through your Cisco account team. See View Installed NSO Function Packs to monitor the state of the installed NSO function packs.

The NSO Function Pack deployment via Crosswork UI is supported for NSO system installation and as a root user. See the Cisco Crosswork Network Controller 7.1 Installation Guide.

Requirements for adding NSO providers

Required configurations for adding NSO providers

Ensure these configuration requirements are met prior to adding an SR-PCE provider.

Required information for adding NSO providers

You must have this information when adding a SR-PCE provider.

  • The name you want to assign to the Cisco NSO provider.

  • The Cisco NSO NED device models and driver versions used in your topology. You can find the Cisco NSO version using the version command.

  • The Cisco NSO server IP address or FQDN (Domain name and host name). When NSO is configured with HA, the IP address would be management VIP address.

  • The NSO cross launch feature is not available for user roles with read-only permissions.

NSO Layered Service Architecture (LSA) deployment

Crosswork Network Controller supports the deployment of Cisco NSO Layered Service Architecture (LSA). Cisco NSO LSA adds arbitrarily many device nodes for improved memory and provisioning throughput. In an LSA deployment, multiple NSO providers are utilized, including the customer-facing service (CFS) NSO, which encompasses all the services, and the resource-facing service (RFS), which manages the devices. The system automatically determines whether an NSO provider is designated as CFS or RFS. Only one CFS is allowed. On the Manager Provider Access page, the Type column identifies the NSO provider as CFS.

Key considerations for NSO LSA deployment
  • If you plan to add a NSO LSA provider, you must first enable LSA settings. See Enable Layered Service Architecture (LSA) for details.

  • If you forgot to enable the LSA setting or misconfigures the provider property values, please perform the recovery steps mentioned in NSO LSA setup recovery.

  • The RFS node IP addresses used on the CFS must match with the IP addresses on the UI. A mismatch will generate the error "LSA cluster is missing RFS providers".

  • In case of the CFS node, only the forward property key is used.

Enable Layered Service Architecture (LSA)

Follow these steps to enable LSA.

Procedure

Step 1

From the main menu, choose Administration > Settings > System Settings > Layered Service Architecture.

Figure 3. Enabling Layered Service Architecture Window
Enabling Layered Service Architecture

Step 2

Select Enable.

Step 3

Select the method to spread the devices across multiple NSO instances:

  • Round Robin—Even distribution of devices to RFS nodes in a cyclical manner (for example, Device 1 to RFS1, Device 2 to RFS2, and so on).

  • Capacity—The number of devices are assigned to each RFS instance based on its total capacity.

  • User Defined—Devices are assigned to the NSO providers specified for the device in the device settings. For more information, see Add devices through the UI.

Step 4

Click Save.

Note

 
Once you have saved the settings, you cannot disable it without removing all the NSO providers.

NSO LSA setup recovery

This topic explains the steps for NSO LSA setup recovery in case of any misconfigurations.

Procedure

Step 1

Remove the NSO providers and associated devices on Device Management window.

Step 2

Clean up the associated services on the Cisco NSO application.

Step 3

Enable the LSA settings and add the NSO LSA provider with correct property values.

Step 4

Add the NSO providers and devices again to Crosswork Network Controller, and map them to the Crosswork Data Gateway.

Step 5

Perform the sync operation on the NSO nodes (RFS and CFS) again to sync the devices correctly.

This will recover the functionality as expected.


Embedded NSO for single VM deployment

Crosswork Network Controller, deployed on a single VM with the Advantage package, uses an embedded NSO instead of an external NSO. The embedded NSO is part of the Advantage package and is automatically installed when the Crosswork Network Controller Advantage package is deployed on a single VM.

When the embedded NSO is installed on the Crosswork Network Controller:

  • An NSO provider entry is automatically onboarded on the Providers page.

  • An SSO service provider entry with NSO cross-launch support is automatically added on the SSO page.

The embedded NSO provider and the SSO service provider entries cannot be edited or deleted.

Add a Cisco NSO provider

Follow these steps to add a Cisco NSO provider.


Attention


Crosswork Network Controller does not scan NSO continuously for NSO device status changes. New device addition to NSO is discovered by Crosswork only when there is an explicit action from Crosswork towards NSO.

To onboard newly added devices from NSO to Crosswork:

  • Perform any NSO action for a device (from Device Management > Network Devices).

  • Edit and save the policy details of an existing NSO Provider (select Actions > Edit Policy Details > set Onboard from to TRUE > Save) to trigger Crosswork to rescan NSO.


Before you begin
Ensure you have met all requirements listed in Requirements for adding NSO providers.
Procedure

Step 1

Choose Administration > Manage Provider Access.

Step 2

Click Add icon.

Step 3

Enter these Cisco NSO provider field values:

  1. Required fields:

    • Provider Name: Enter a name for the provider.

    • Credential Profile: Select the previously created Cisco NSO credential profile.

    • Family: Select NSO.

    • Protocol: Select HTTPS and/or SSH. For more information, see Provider dependency.

      Note

       

      To use the Backup NSO option during backup, you must configure the SSH connectivity protocol in the NSO provider; otherwise, the backup will fail.

    • Server Details: Enter either the IP address (IPv4 or IPv6) or FQDN (Domain name and Host name) of the server.

    • Port: For HTTPS, enter the port that corresponds with what is configured on the NSO VM in etc/ncs/ncs.conf to access NSO using HTTPS. NSO uses 8888 as default port.

    • Model: Select the model (Cisco-IOS-XR, Cisco-NX-OS, or Cisco-IOS-XE). Add a model for each type of device that will be used in the topology. If you have more than one, add another supported model.

    • Version: Enter the NED software version installed for the device model in NSO.

    Note

     

    If you set the Site location parameter in NSO, you can determine if geo-fencing is violated during testing when Crosswork and the active NSO are not in the same site location. Crosswork will also raise and clear alarms if a geo-fence violation is detected.

    Important

     

    When you modify or update the NSO provider IP address or FQDN, you need to detach devices from corresponding virtual data gateway, and reattach them. If you fail to do this, the provider changes will not be reflected in MDT collection jobs.

  2. Optional values:

    • Timeout: The amount of time (in seconds) to wait before timing out the connection to the Cisco NSO server. The default is 30 seconds.

  3. Provider Properties: Enter one of the following key/value pairs in the first set of fields:

    Property Key

    Value

    forward

    true

    This property is necessary when using the Cisco Crosswork Network Controller solution to allow provisioning operations within the UI and to enable the northbound interface to NSO via the Crosswork API gateway.

    Note

     

    The default value of forward is "false". If this is not changed, the devices added to Crosswork will not be added to NSO. This setting is used in conjuction with the Edit Policy option (see Edit NSO provider policy).

    nso_crosslaunch_url

    Note

     

    This property is used only for NSO standalone provider.

    Enter the URL for cross-launching NSO in the format: https://<NSO IP address/FQDN>: port number

    To enable cross-launch of the NSO application from the Crosswork UI. Requires a valid protocol (HTTP or HTTPS), and the provider must be reachable.

    The cross launch icon (Close Panel icon) is displayed in the Provider Name column. Alternately, you can cross launch the NSO application using the launch icon located at the top right corner of the window.

    input_url_prefix

    Note

     

    This property is used only for NSO LSA provider.

    Enter the RFS ID in the format: /rfc-x, where x refers to the number of the RFS node.

    Example (for RFS node 1): 
    input_url_prefix: /rfc-1

Step 4

When you have completed entries in all of the required fields, click Save to add Cisco NSO as a provider.


What to do next

(Optional) The site name can be configured for NSO from the NCS backend, and it will be displayed as a read-only value on the NSO provider in the Crosswork Network Controller UI.

To configure the NSO site name:

  1. Login into ncs_cli in config mode.

  2. Set hcc dns member master ip-address nso1-mgmt-IP location site1-location

  3. Set hcc dns member standby ip-address nso2-mgmt-IP location site2-location

  4. Commit

View Installed NSO Function Packs

Cisco Crosswork allows you to monitor the status of the installed NSO Function Packs.

Procedure

Step 1

From the main menu, choose Administration > Crosswork Manager.

Step 2

On the Crosswork Manager window, select the NSO Deployment Manager tab.

The Installed NSO Function Packs, NSO Function Pack Bundles, and Job History tabs are displayed.

Note

 

You can also navigate here from the NSO provider entries in the Providers window (click Actions > View Function Packs).

The Installed NSO Function Packs tab displays a list of NSO function pack bundles deployed on the configured NSO server.

Figure 4. Installed NSO Function Packs

Step 3

Expand the bundles to view the number of function packs within each bundle, the function pack name, operational state as Up or Down, description, and version.


Edit NSO provider policy

To edit an NSO provider policy, do the following:

Procedure

Step 1

Choose Administration > Manage Provider Access.

Step 2

On a NSO provider, click Actions > Edit policy details.

The NSO: Edit policy details window for the selected NSO provider is displayed.

Step 3

Edit the configuration fields to meet the specific requirements of your environment, ensuring the values align with your discovered devices. You can modify each criteria to define a targeted subset of devices and fine-tune the actions that DLM will perform. The NSO policy rules are applied every time DLM synchronizes with NSO. For example:

When a device's configuration is changed, DLM will attempt to sync with NSO and apply all relevant rules, such as MatchRule, OnboardToNSO, OnboardToRule.

The different attributes you can edit within the NSO policy are:

Attribute

Description

Match

Select True to have DLM match the devices in Crosswork with those in NSO based on their IP address. Select False if you do not want this matching.

MatchRule

Enter an expression defining the subset of devices.

Onboard To NSO

Select True to add devices that are missing in NSO. Select False if you do not want to add missing devices to NSO.

Onboard To Rule

Enter an expression for onboarding a subset of devices.

Onboard From

Select True to add devices from NSO to Crosswork if they are missing. Select False if you do not want to add missing devices from NSO.

Onboard From Rule

Enter an expression for onboarding devices from NSO.

Sync From

Select True to perform a sync-from operation on the NSO device after onboarding it. Select False if you do not want to perform this sync operation.

Sync From Rule

Enter an expression defining the subset of devices for sync-from.

Check Sync

Select True to check the sync status of an existing NSO device. Select False if you do not want to check the sync status.

Check Sync Rule

Enter an expression for the subset of devices for check-sync.

NED

Specify the Network Element Driver (NED) to be used. By default, the latest CLI NED on NSO is used.

Rule

Enter an expression to define which devices should use a specific NED.

Example: Specifying a NED for IOS-XR devices

The following image shows the policy attributes that set the cisco-iosxr-cli-7.52 NED for IOS-XR devices with a software version 6.23.

The entry for defining Rule is partially visible. Here is the complete text for your reference:

product_info.softwaretype='IOS XR' and product_info.softwareversion='6.23'

You can specify different criteria such as hostname, software type, and IP address and use operators like Eq (=), Neq (!=), GT (>), LT (<), GTEQ (>=), LTEQ (<=) and EqA (= =) to define the comparisons. Here are few more examples of expressions you can use to edit provider details:

  • host_name='host1'

  • product_info.software_type = 'IOS XR'

  • routing_info.router_loopback.inet_addr = '10.10.10.10'

  • product_info.softwareversion='6.23'

  • product_info.manufacturer='Cisco Systems'

  • product_info.producttype='Cisco IOS XRv 9000 Router'

  • product_info.productfamily='Routers'

  • product_info.productseries='Cisco ASR 9000 Series Aggregation Services Routers'

  • routing_info.te_router_id='10.8.8.52'

  • profile!='simulators'

  • You can also use the AND, OR commands to combine criteria. For example:

    product_info.software_type = 'IOS XR' OR product_info.software_type = 'IOS XE'

    product_info.software_type = 'IOS XR' AND product_info.software_version = '7.0.1'

  • You can use the * symbol as a wildcard.

    For example, to match any IOS device, you can use IOS*. If no wildcard expression is used, the system performs an exact match of the string.

    • Exact match example:

      If product_info.software_type = 'IOS XR' is specified, DLM matches only the devices where the software_type is exactly 'IOS XR'.

    • Wildcard example:

      If product_info.software_type = 'IOS XR*' is specified, DLM matches all devices where the software_type starts with 'IOS XR'. This includes values such as 'IOS XR 1', 'IOS XRv'.

Note

 

For more information about editing NSO provider details and forming expressions using the attributes available in the Crosswork Inventory API, refer to the link DLM Inventory APIs.


Cisco SR-PCE providers

Cisco Segment Routing Path Computation Elements (Cisco SR-PCE) providers

  • supply device discovery, management, configuration maintenance, and route calculation services to Cisco Crosswork Network Controller components

  • enable system access as part of SDN controllers in the management domain, and

  • support multi-AS topology and path calculations.

Requirements and additional information

Multi-AS topology and path calculations are supported if the complete topology is accessible to both the Crosswork Network Controller and each PCE. A single PCE cannot view a specific AS topology while another PCE views a different topology. Each PCE must have access to the entire topology view.

To learn and discover SR policies, Layer 3 links, and devices, at least one SR-PCE provider is required. Additionally, a second SR-PCE can be configured as a backup.

Requirements for adding SR-PCE providers

Required configurations for adding SR-PCE providers

Ensure these configuration requirements are met prior to adding an SR-PCE provider.

  • Configure a device to act as the SR-PCE. See SR configuration documentation for your specific device platform to enable SR (for IS-IS or OSPF protocols) and configure an SR-PCE. For example: Segment Routing Configuration Guide for Cisco NCS 540 Series Routers).


    Note


    SR-PCE is not supported on the ASR 9000 hardware platform.


  • Create a credential profile for the Cisco SR-PCE provider (see Create credential profiles) with these connection types:

    • gRPC—Required to discover topology, SR-MPLS, and SRv6 policies. See Sample PCE configuration for enabling gRPC API on XR for configuration examples.

    • Basic HTTP text-authentication— Required to process for RSVP, TreeSID and PCEP sessions. MD5 authentication is currently not supported.

      If the Cisco SR-PCE server you are adding does not require authentication, you must still supply a credential profile for the provider. The credential profile can be any profile that does not use the HTTP protocol.

  • If you plan to set up gRPC with Transport Layer Security (TLS), a certificate must be generated and added with the Secure gRPC communication role. The certificate is used to secure communication through TLS between gRPC clients and the EMS server. The client should use ems.pem and ca.cert to initiate the TLS authentication. To update the certificate, ensure to copy the new certificate that has been generated earlier to the location and restart the server. See Manage Certificates.

  • For high availability, ensure that you set up two separate Cisco SR-PCE providers with unique names and IP addresses, but with matching configurations.

Required information for adding SR-PCE providers

You must have this information when adding a SR-PCE provider.

  • The name you want to assign to the Cisco SR-PCE provider. This is usually the DNS hostname of the Cisco SR-PCE server.

  • The Cisco SR-PCE server IP address.

  • The interface you want to use to communicate between Cisco SR-PCE and the Cisco Crosswork application server.

  • The SSH credentials for the PCE device to enable gRPC communication. Note that PCE API credentials are used exclusively for HTTP-based communication.

  • Determine whether you want to auto-onboard the devices that Cisco SR-PCE discovers and, if so, whether you want the new devices to have their management status set to off, managed or unmanaged when added.

  • If you plan to auto-onboard devices that the Cisco SR-PCE provider discovers, and set them to a managed state when they are added to the database:

    • Assign an existing credential profile for communication with the new managed devices.

    • The credential profile must be configured with an SNMP protocol.

Add SR-PCE providers

Follow these steps to add one or more Cisco SR-PCE providers.

Procedure

Step 1

Choose Administration > Manage Provider Access > Add icon .

Step 2

Enter these SR-PCE provider field values:

  1. Required fields:

    • Provider Name: Name of the SR-PCE provider.

    • Credential Profile: Select the previously created SR-PCE credential profile.

    • Family: Select SR_PCE.

    • Connection type(s) > Protocol:

      • Select HTTP and enter required fields. HTTP is required to process RSVP, TreeSID and PCEP sessions. The default port is 8080.

      • Select GRPC or GRPC_SECURE (gRPC with Transport Layer Security (TLS)) and enter required fields. These settings are required to process topology, SR-MPLS, and SRv6 policies. Only one of these options can be used. If GRPC_SECURE is selected, you must provide the trusted certificate in the Certificate profile field.

    • Provider Properties: Enter property keys and values:

      Table 4. Property keys

      When the property key is..

      And the value is..

      Then..

      auto-onboard

      off

      when devices are discovered, the device data is recorded in the Cisco SR-PCE database, but is not registered in the Crosswork Network Controller Inventory Management database

      Note

       

      Use this option if you plan to manually (via UI or CSV import) enter all of your network devices.

      unmanaged

      all devices that Crosswork Network Controller discovers will be registered in the Crosswork Network Controller Inventory Management database, with their configured state set to unmanaged. SNMP polling will be disabled for these devices, and no management IP information will be included. To get these devices into the managed state later, you will need to either edit them via the UI or export them to a CSV, make modifications and then import the updated CSV. You can also assign credential profiles by adding them to the device CSV file before import (the credential profiles must already exist).

      managed

      all devices that Cisco SR-PCE discovers will be registered in the Crosswork Network Controller Inventory Management database with their configured state set to managed.

      Typically suitable for an environment that has same device profiles, devices are managed by their TE router-ID, and all devices can be discovered by the Cisco SR-PCE.

      SNMP polling will be enabled for these devices, and Cisco SR-PCE will also report the management IP address (TE Router ID for IPv4, or IPv6 Router ID for IPv6 deployment). The devices will be added with the credential profile associated with the device-profile key in the SR-PCE provider configuration.

      Important considerations

      If you enable this option for IPv6 deployment, devices will still register as unmanaged in the inventory.

      When you delete an onboarded device that was added via SR-PCE discovery with auto-onboard set to managed, the topology service adds it again as unmanaged. This ensures that devices that have been removed are not automatically managed again unless they acquire a new TE-ID. To manage a rediscovered device, update its status manually.

      device-profile

      a credential profile name

      if the auto-onboard is set to managed and there is no valid device-profile set, the device will instead be onboarded as unmanaged.

      outgoing-interface

      eth1

      this enables Crosswork Network Controller access to SR-PCE via the data network interface when using a two NIC configuration.

      preferred-stack

      ipv4

      indicates a dual stack is present and IPv4 is preferred

      ipv6

      indicates dual stack is present and IPv6 is preferred

      NOT SET

      indicates no dual stack

      pce

      off

      discovery of RSVP-TE tunnels and PCEP sessions (required for all LSP provisioning) is disabled.

      on

      discovery of RSVP-TE tunnels and PCEP sessions (required for all LSP provisioning) is enabled. This option is enabled by default.

      topology

      any value

      there is no impact.

      This property key is deprecated and should be manually removed if it still appears as an option. This property key is ignored, regardless if it is configured.

      Important considerations when using property keys:

      • Topology can be visualized even with auto-onboard as off and a device-profile is not specified.

      • If managed or unmanaged options are set and you want to delete a device later, you must either:

        • Reconfigure and remove the devices from the network before deleting the device from Crosswork Network Controller. This avoids Crosswork Network Controller from rediscovering and adding the device back.

        • Set auto-onboard to off, and then delete the device from Crosswork Network Controller. However, doing so will not allow Crosswork Network Controller to detect or auto-onboard any new devices in the network.

      • It is not recommended to modify auto-onboard options once set. If you need to modify them:

        1. Delete the provider and wait until deletion confirmation is displayed in the Events window.

        2. Re-add the provider with the updated auto-onboard option.

        3. Confirm the provider has been added with the correct auto-onboard option in the Events window.

  2. Optional values:

    • Timeout—The amount of time (in seconds) to wait before timing out the connection to the SR-PCE server. The default is 30 seconds.

Step 3

Click Save to add the SR-PCE provider.

Step 4

Confirm that the SR-PCE provider shows a green Reachability status without any errors. You can also view the Events window to see if the provider has been configured correctly.

Step 5

Repeat this process for each SR-PCE provider.


What to do next
  • If auto-onboard is set to off, start onboarding devices.

  • If you opted to automatically onboard devices, choose Device Management > Network Devices to view the device list. To add more node information such as geographical location details, export the device list (.csv), update it, and import it back. If geographical location data is missing, you will only be able to see device topology using the logical map.

Cisco SR-PCE Reachability Issues

You can find reachability issues raised in the Events table and reachability status in the Providers window (see Get Provider Details). If the SR-PCE goes down, all links in the topology will display with the last known state since the SR-PCE cannot send any notification updates. When the SR-PCE becomes reachable again, a message will show in the Events table (Show Events icon) that SR-PCE is reconnected and the topology will be updated accordingly. If you find that the SR-PCE goes down for an extended amount of time, it is not syncing, updates are not happening, then delete the SR-PCE and add it back (when connectivity returns) using the UI:

  1. Execute the following command:
    # process restart pce_server
  2. From the UI, navigate to Administration > Manage Provider Access and delete the SR-PCE provider and then add it back again.

You can also troubleshoot reachability as follows:

Procedure

Step 1

Check device credentials.

Step 2

Ping the provider host.

Step 3

Attempt a connection using the protocols specified in the connectivity settings for the provider. For an SR-PCE provider, it is typically HTTP and port 8080.

Step 4

Check your firewall setting and network configuration.

Step 5

Check the Cisco SR-PCE host or intervening devices for Access Control List settings that might limit who can connect.


Multiple Cisco SR-PCE HA pairs

You can set up to eight Cisco SR-PCE HA pairs (total of 16 SR-PCEs) to ensure high availability (HA). Each HA pair of Cisco SR-PCE providers must have matching configurations, supporting the same network topology. In HA, if the primary SR-PCE becomes unreachable, the system uses the secondary SR-PCE to discover the network topology. If this pair fails, then the next HA pair takes over and so forth. The network topology will continue to be updated correctly and you can view SR-PCE connectivity events in the Events table (Show Events icon).

Multiple HA pair behavior

In the case of multiple SR-PCE HA pairs, each SR-PCE pair sees the same topology but manages and only knows about tunnels created from its Path Computation Clients (PCCs). The following figure is a sample of a three SR-PCE HA pair topology. Note the following:

  • HA Pair 1—PCE iosxrv-1 and iosxrv-2 only provisions and discovers tunnels whose headends are iosxrv-7 and iosxrv-8. Note that iosxrv-9 and iosxrv-10 are not PCC routers.

  • HA Pair 2—PCE iosxrv-3 and iosxrv-4 only provisions and discovers tunnels whose headends are iosxrv-11, iosxrv-12, iosxrv-17, and iosxrv-18. Note that iosxrv-13, iosxrv-14, iosxrv-15, and iosxrv-16 are not PCC routers.

  • HA Pair 3—PCE iosxrv-5 and iosxrv-6 only provision and discover tunnels whose headends are iosxrv-21, and iosxrv-22. Note that iosxrv-19 and iosxrv-20 are not PCC routers.

Figure 5. Sample 3 HA pair topology
Sample 3 HA Pair Topology

Note


If any of the SR-PCEs are included in a subset of the main network topology, then that SR-PCE provider must be added with the Property Key as topology and the Property Value as off. When this value is set, then this SR-PCE will not be used to learn the topology.


Configure HA

The following configurations must be done to enable each pair of HA Cisco SR-PCE providers to be added in Crosswork Network Controller.


Note


There must be resilient IPv4 connectivity between both SR-PCEs to enable HA. The PCE IP address of the other SR-PCE should be reachable by the peer at all times.


Issue the following commands on each of the Cisco SR-PCE devices:

Enable the interface:
# interface <interface><slot>/<port>
ipv4 address <sync-link-interface-ip-address> <subnet-mask>
no shut

Enable HA:


# pce api sibling ipv4 <other-node-pce-address>
Establish a sync link between the two SR-PCEs:
# router static
address-family ipv4 unicast
<other-node-pce-ip-address>/<subnet-mask-length> <remote-sync-link-ip-address>

(Optional) # pce segment-routing traffic-eng peer ipv4 <other-node-pce-ip-address>

It should be entered for each PCC and not for other PCE nodes.

Issue the following command on the PCC:

For SR Policies: # segment-routing traffic-eng pcc redundancy pcc-centric

For RSVP-TE Tunnels: # mpls traffic-eng pce stateful-client redundancy pcc-centric

Confirm sibling SR-PCE configuration

From the SR-PCE, enter the show tcp brief command to verify synchronization between SR-PCEs in HA are intact:

#show tcp brief | include <remote-SR-PCE-router-id>

Confirm that following information is correct:

Local Address Foreign Address

State

<local-SR-PCE-router-id>:8080

<remote-SR-PCE-router-id>:<any-port-id>

ESTAB

<local-SR-PCE-router-id>:<any-port-id>

<remote-SR-PCE-router-id>:8080

ESTAB

For example:

RP/0/0/CPU0:iosxrv-1#sh tcp brief | i 192.168.0.2:
Mon Jun 22 18:43:09.044 UTC
0x153af340 0x60000000 0 0 192.168.0.1:47230 192.168.0.2:8080 ESTAB
0x153aaa6c 0x60000000 0 0 192.168.0.1:8080 192.168.0.2:16765 ESTAB

In this example, 192.168.0.2 is the remote SR-PCE IP.

SR-PCE delegation

Depending on where an SR-TE policy is created, the following SR-PCE delegation occurs:

  • SR-PCE initiated—Policies configured on a PCE. SR-TE policies are delegated back to the source SR-PCE.


    Note


    • The policy can be PCE initiated even if it is created using the UI, but in that case it is not configured explicitly on SR-PCE.

    • RSVP-TE tunnels cannot be configured directly on a PCE.


  • PCC initiated—An SR-TE policy or RSVP-TE tunnel that is configured directly on a device. The SR-PCE configured with the lowest precedence is the delegated SR-PCE. If precedence is not set, then SR-PCE with the lowest PCE IP address is the delegated SR-PCE. The following configuration example, shows that 10.0.0.1 is assigned a precedence value of 10 and will be the delegated SR-PCE.

    segment-routing
      traffic-eng
        pcc
          source-address ipv4 10.0.0.2
          pce address ipv4 10.0.0.1
            precedence 10
           !
          pce address ipv4 10.0.0.8
            precedence 20
           !
           report-all
           redundancy pcc-centric

    For RSVP-TE Tunnel:

    mpls traffic-eng
    interface GigabitEthernet0/0/0/0
    !
    interface GigabitEthernet0/0/0/1
    !
    interface GigabitEthernet0/0/0/2
    !
    pce
      peer source ipv4 192.168.0.02
      peer ipv4 192.168.0.9
        precedence 10
      !
      peer ipv4 192.168.0.10
        precedence 20
      !
      stateful-client
       instantiation
       report
       redundancy pcc-centric
       autoroute-announce
      !
    !
    auto-tunnel pcc
      tunnel-id min 1000 max 5000
  • Crosswork Network Controller SR-PCE initiated—An SR-TE policy that is configured using Crosswork Network Controller. SR-PCE delegation is random per policy.


    Note


    Only SR-TE policies or RSVP-TE tunnels created by Crosswork Network Controller can be modified or deleted by Crosswork Network Controller.
HA notes and limitations
  • It is assumed that all PCCs are PCEP connected to both SR-PCEs.

  • When an SR-PCE is disconnected only from Cisco Crosswork, the following occurs:

    • SR-PCE delegation assignments remain, but the SR-PCE that has been disconnected will not appear in Crosswork Network Controller.

    • You are not able to modify Cisco Crosswork SR-PCE initiated SR-TE policies if the disconnected SR-PCE is the delegated PCE.

  • In some cases, when an SR-TE policy that was created via the UI is automatically deleted (intentional and expected) from Crosswork Network Controller, a warning message does not appear. For example, if the source PCC is reloaded, the UI created SR policy disappears and the user is not informed.

  • In an extreme case where one SR-PCE fails on all links (to PCCs/topology devices) except the up-link to Crosswork Network Controller, topology information will not be accurate in Crosswork Network Controller. To resolve this, fix the connectivity issue or delete both SR-PCEs from the Provider page and re-add the reachable one.

  • PCE HA failover: After a PCE HA failover, when Crosswork Network Controller connects to the next available PCE, the Topology Service could take up to 2 hours to re-learn all L3 links and LSPs depending on the scale. During this time, newly created LSPs will remain in the queue and only appear in the UI after re-learning is complete.

  • When an SR-PCE goes down, Local Congestion Mitigation (LCM) enters a dormant stage. To exit this state, all SR-PCEs must be connected, and their associated topologies fully synchronized with the topology service. LCM will remain dormant until these conditions are met. It is important to note that LCM does not have visibility into the state of the SR-PCE redundancy set.

SR-PCE configuration examples

The following configurations are examples to guide you in a multiple SR-PCE setup for HA. Please modify accordingly.

Sample SR-PCE configurations

Sample redundant SR-PCE configuration (on PCE with Cisco IOS-XR 7.x.x)


pce
 address ipv4 192.168.0.7
 state-sync ipv4 192.168.0.6
 api
  sibling ipv4 192.168.0.6

Sample PCE configuration for enabling gRPC API on XR 25.2.1.x (IPv4 deployment)


conf t
  lslib-server
  !
  grpc
    port 57400
    no-tls
    address-family ipv4
    service-layer
    !
!
pce
  distribute link-state
  !
!
linux networking
  vrf default
    address-family ipv4
      default-route software-forwarding
    !
    address-family ipv6
      default-route software-forwarding
    !
  !
!
commit

Note


For secure gRPC deployment, remove no-tls.

Configure distribute link-state on all PCEs to inject SR policies into BGP-LS.

.


Sample PCE configuration for enabling gRPC API on XR 25.2.1.x (IPv6 deployment)


conf t
  lslib-server
  !
  grpc
    port 57400
    no-tls
    address-family ipv6
    service-layer
    !
!
pce
  distribute link-state
  !
!
linux networking
  vrf default
    address-family ipv4
      default-route software-forwarding
    !
    address-family ipv6
      default-route software-forwarding
    !
  !
!
commit

Note


For secure gRPC deployment, remove no-tls.

Configure distribute link-state on all PCEs to inject SR policies into BGP-LS.


To verify whether the topology is published in gRPC

sh lslib server topology-db

To verify the SR-MPLS LSP published in gRPC

show lslib server topology-db detail protocol sr

Sample redundant SR-PCE configuration (PCC)

segment-routing
 traffic-eng
  pcc
   source-address ipv4 192.0.2.1
   pce address ipv4 192.0.2.6
    precedence 200
   !
   pce address ipv4 192.0.2.7
    precedence 100
   !
   report-all
   redundancy pcc-centric

Sample redundant SR-PCE configuration (on PCC) for RSVP-TE


Note


Loopback0 represents the TE router ID.



ipv4 unnumbered mpls traffic-eng Loopback0
!
mpls traffic-eng
 pce
  peer source ipv4 209.165.255.1
  peer ipv4 209.165.0.6
   precedence 200
  !
  peer ipv4 209.165.0.7
   precedence 100
  !
  stateful-client
   instantiation
   report
   redundancy pcc-centric
   autoroute-announce
  !
 !
 auto-tunnel pcc
  tunnel-id min 1000 max 1999
 !
!
Telemetry configuations

Sample SR-TM configuation

telemetry model-driven
 destination-group crosswork
  address-family ipv4 198.18.1.219 port 9010
   encoding self-describing-gpb
   protocol tcp
  !
 !
 sensor-group SRTM
  sensor-path Cisco-IOS-XR-infra-tc-oper:traffic-collector/afs/af/counters/tunnels
  sensor-path Cisco-IOS-XR-infra-tc-oper:traffic-collector/vrf-table/default-vrf/afs/af/counters/prefixes
 !
 subscription OE
  sensor-group-id SRTM sample-interval 60000
  destination-id crosswork
  source-interface Loopback0
!
traffic-collector
 interface GigabitEthernet0/0/0/3
 !
 statistics
  history-size 10

Note


The destination address uses the southbound data interface (eth1) address of the Crosswork Data Gateway VM.


It is required to push sensor path on telemetry configuration via NSO to get prefix and tunnel counters. It is assumed that the Traffic Collector has been configured with all the traffic ingress interface. This configuration is needed for demands in the Bandwidth on Demand feature pack to work.

Telemetry sensor path

sensor-path Cisco-IOS-XR-infra-tc-oper:traffic-collector/afs/af/counters/tunnels/tunnel
sensor-path Cisco-IOS-XR-infra-tc-oper:traffic-collector/vrf-table/default-vrf/afs/af/counters/prefixes/prefix
 

Telemetry configuration pushed by Crosswork Network Controller to all the headend routers via NSO

telemetry model-driven
  destination-group CW_43dc8a5ea99529715899b4f5218408a785e40fce
    vrf default
    address-family ipv4 172. 19.68.206 port 31500
      encoding self-describing-gpb
      protocol top
    !
  !
destination-group CW_4b3c69a200668b0a8dc155caff295645c684a8f8
  vrf default
  address-family ipv4 172. 19.68.206 port 31500
    encoding self-describing-gpb
    protocol top
  !
!
sensor-group CW_43dc8a5ea99529715899b4f5218408a785e40fce
  sensor-path Cisco-IOS-XR-infra-tc-oper:traffic-collector/afs/af/counters/tunnels/tunnel
!
sensor-group CW_4b3c69a200668b0a8dc155caff295645c684a8f8
  sensor-path Cisco-IOS-XR-infra-tc-oper:traffic-collector/vrf-table/default-vrf/afs/af/counters/prefixes/prefix
!
subscription CW_43dc8a5ea99529715899b4f5218408a785e40fce
  sensor-group-id CW_43dc8a5ea99529715899b4f5218408a785e40fce sample-interval 300000
  destination-id CW_43dc8a5ea99529715899b4f5218408a785e40fce
!
subscription CW_4b3c69a200668b0a8dc155caff295645c684a8f8
  sensor-group-id CW_4b3c69a200668b%a8dc155caff295645c684a8f8 sample-interval 300000
  destination-id CW_463c69a200668b0a8dc155caff295645c684a8f8
  !
!
Traffic Collector configurations

Traffic Collector configurations (all Ingress traffic interface to be added below in the Traffic Collector)

RP/0/RSP0/CPU0:PE1-ASR9k#sh running-config traffic-collector
Fri May 22 01:14:35.845 PDT
traffic-collector
  interface GigabitEthernet0/0/0/0
  !
  statistics
    history-size 1
    collection-interval 1
    history-timeout 1
    history-minute-timeout
  !  
!
Add BGP neighbor next-hop-self for all the prefix (to show TM rate counters)
bgp router-id 5.5.5.5
address-family ipv4 unicast
  network 5.5.5.5/32
  redistribute static
!
address-family link-state link-state
!
neighbor 1.1.1.1
  remote-as 65000
  update-source Loopback0
  address-family ipv4 unicast
   next-hop-self
  !
!

Traffic collector tunnel and prefix counters

RP/0/RSP0/CPU0:PE1-ASR9k#show traffic-collector ipv4 counters prefix
Fri May 22 01:13:51.458 PDT
Prefix              Label         Base rate         TM rate        State
                                  (Bytes/sec)       (Bytes/sec)
-----------------  -------------  ---------------  --------------  -----------------
1.1.1.1/32          650001         3                0              Active
2.2.2.2/32          650002         3                0              Active
3.3.3.3/32          650003         6                0              Active
4.4.4.4/32          650004         1                0              Active
6.6.6.6/32          650200         6326338          6326234        Active
7.7.7.7/32          650007         62763285         62764006       Active
8.8.8.8/32          650008         31129168         31130488       Active
9.9.9.9/32          650009         1                0              Active
10.10.10.10/32      650010         1                0              Active
RP/0/RSP0/CPU0:PE1-ASR9k#stt
RP/0/RSP0/CPU0:PE1-ASR9k#show traffic-collector ipv4 counters tunnel
Fri May 22 01:13:52.169 PDT
RP/0/RSP0/CPU0:PE1-ASR9k#]

Path Computation Client (PCC) Support

PCCs can support delegation and reporting of both RSVP-TE tunnels and SR policies to SR-PCE. In order for both to be supported on the same PCC, two separate PCEP connections must be established with the SR-PCEs. Each PCEP connection must have a distinct source IP address (Loopback) on the PCC.

The following is a Cisco IOS-XR configuration example of PCEP connections for RSVP-TE, where 192.168.0.2 is the PCEP session source IP for RSVP-TE tunnels delegated and reported to SR-PCE. It is a loopback address on the router. Two SR-PCEs are configured for PCEP sessions, where the first will be preferred for delegation of RSVP-TE tunnels due to precedence. Auto-tunnel PCC is configured with a range of tunnel IDs that will be used for assignment to PCE-initiated RSVP-TE tunnels like those created in Cisco Crosswork Optimization Engine.


mpls traffic-eng
interface GigabitEthernet0/0/0/2
admin-weight 1
!
interface GigabitEthernet0/0/0/3
admin-weight 1
  pce
    peer source ipv4 192.168.0.2
    peer ipv4 192.168.0.1
      precedence 10
     !    
    peer ipv4 192.168.0.8
      precedence 11
     !
    stateful-client
      instantiation
      report
     ! 
   !
   auto-tunnel pcc
    tunnel-id min 10 max 1000
   !
!
ipv4 unnumbered mpls traffic-eng Loopback0

rsvp
interface GigabitEthernet0/0/0/2
bandwidth 1000000
!
interface GigabitEthernet0/0/0/3
bandwidth 1000000
!
!

Add Cisco WAE providers

Cisco WAN Automation Engine (Cisco WAE) providers supply traffic and topology analysis to the Crosswork Network Controller components. The foundation software is Cisco WAE Planning, which provides a cross-sectional view of traffic, topology, and equipment state. It takes advantage of a predictive model that performs "what if" analysis of failure impacts.

Follow the steps below to use the UI to add one or more instances of Cisco WAE as providers. You can also add providers using CSV files (see Import multiple providers using a CSV file).

Before you begin

You will need to:
  • Create a credential profile for the Cisco WAE provider (see Create credential profiles). This should be a basic HTTP/HTTPS text-authentication credential (currently, MD5 authentication is not supported). If the Cisco WAE server you are adding does not require authentication, you must still supply a credential profile for the provider, but it can be any profile that does not use the HTTP/HTTPS protocol.

  • Know the name you want to assign to the provider. This is usually the DNS hostname of the Cisco WAE server.

  • Know the Cisco WAE server IP address and port. The connection protocol will be HTTP or HTTPS.

Procedure


Step 1

From the main menu, choose Administration > Manage Provider Access.

Step 2

Click Add icon.

Step 3

Enter the following values for the provider fields:

  1. Required fields:

    • Provider Name: Name of the Cisco WAE provider.

    • Credential Profile: Select the previously created credential profile.

    • Family: Select WAE.

    • Protocol: Select HTTP or HTTPS respectively as per the credential profile you are using.

    • IP Address/ Subnet Mask: Enter the IP address (IPv4 or IPv6) and subnet mask of the server.

    • Port: Enter the port number (usually, 8080 for HTTP, and 8843 for HTTPS).

  2. Optional values:

    • Timeout: The amount of time (in seconds) to wait before timing out the connection to the server. The default is 30 seconds.

Step 4

When you have completed entries in all of the required fields, click Save to add the provider.


Add Syslog Storage providers

Follow the steps below to use the UI to add one or more storage providers. See also Import multiple providers using a CSV file.

Before you begin

  • Create a credential profile for the storage provider (see Create credential profiles). This should be an SSH credential.

  • Know the name you want to assign to the storage provider. This is usually the DNS hostname of the server.

  • Know the storage provider's server IPv4 address and port. The connection protocol will be SSH.

  • Know the destination directory on the storage provider's server. You will need to specify this using the Provider Properties fields.

Procedure


Step 1

Choose Administration > Manage Provider Access > Add icon.

Step 2

Enter these provider field values:

  1. Required fields:

    • Provider Name: Name of the storage provider.

    • Credential Profile: Select the previously created storage credential profile.

    • Family: Select SYSLOG_STORAGE.

    • Protocol: Select SSH to be protocol that Cisco Crosswork application will use to connect to the provider.

    • IP Address/ Subnet Mask: Enter the IP address (IPv4 or IPv6) and subnet mask of the server.

    • Port: Enter the port number (usually, 22 for SSH.

    • Provider Properties: Enter the following key/value pair in these fields:

      Property Key

      Property Value

      DestinationDirectory

      The absolute path where the collected data will be stored on the server. For example: /root/cw-syslogs

  2. Optional values:

    • Timeout: The amount of time (in seconds) to wait before timing out the connection to the storage server.

Step 3

Click Save to add the Syslog Storage provider.


Add an Alert Provider

An Alert provider is a destination to which you want to forward alerts collected during KPI monitoring (such as Cisco Crosswork Situation Manager). An alert provider must be capable of receiving and processing incoming alert packages.

Follow the steps below to use the UI to add an alert provider. You can also add the alert provider by importing a CSV file (see Import multiple providers using a CSV file).

Currently, only one alert provider is supported.

Before you begin

  • Create a credential profile for the alert provider (see Create credential profiles). This should be a basic HTTP text-authentication credential (currently, MD5 authentication is not supported). If the provider does not require authentication, you must still supply a credential profile for the provider, but it can be any profile that does not use the HTTP protocol.

  • Know the name you want to assign to the alert provider. This is usually the DNS hostname of the server.

  • Know the alert server IPv4 address and port. The connection protocol will be HTTP.

  • Know the URL of the alert server endpoint. You will need to specify this using the Property Value field.

Procedure


Step 1

Choose Administration > Manage Provider Access.

Step 2

Click Add icon.

Step 3

Enter these provider field values:

  1. Required fields:

    • Provider Name—Name of the alert provider.

    • Credential Profile—Select the previously created alert provider credential profile.

    • Family—Select ALERT.

    • ProtocolHTTP is pre-selected.

    • IP Address/ Subnet Mask—Enter the IP Address (IPv4 or IPv6) and subnet mask of the alert server.

    • Port—Enter the port number (usually, 80 for HTTP).

    • Provider Properties—The alertEndpointUrl property key name is pre-entered. In the Property Value field, enter the alert server endpoint only. For example, if the complete path to the endpoint is http://aws.amazon.com:80/myendpoint/bar1/, you would enter /myendpoint/bar1/ only.

  2. Optional values:

    • Timeout—The amount of time (in seconds) to wait before timing out the connection to the alert server.

Step 4

When you have completed entries in all of the required fields, click Save to add the alert provider.


Add Proxy Providers

Follow these steps to add a proxy provider. Crosswork Network Controller supports the addition of these proxy providers:
  • Cisco NSO

  • Cisco Optical Network Controller (ONC) version 1.0

The NSO APIs can be directly accessed if NSO is configured with an externally accessible IP address. However, if NSO is deployed in the same private network as the Crosswork network, then it will be reachable only through the Crosswork interface. Proxy providers enables you to use Crosswork interface to perform service provisioning with NSO.

Before you begin

  • Create a credential profile for the Proxy provider (see Create credential profiles). This should be a basic HTTP or HTTPS text-authentication credential.

  • Know the name of the Resource Facing Service (RFS) node added to the Customer Facing Service (CFS) node in your LSA cluster.

  • Know the name you want to assign to the provider. This is usually the DNS hostname of the Proxy server.

  • Know the Proxy server IP address and port. The connection protocol will be HTTP or HTTPS.

  • Ensure that the Cisco NSO providers are added. For more information, see Add a Cisco NSO provider.

  • In case of NSO proxy provider, please create a credential profile with HTTP/HTTPS with Basic Authentication.

  • In case of ONC 1.0 proxy provider, please create a credential profile with HTTPS with Basic Authentication.

Procedure


Step 1

Choose Administration > Manage Provider Access > Add icon.

Step 2

Enter these provider field values:

  • Provider Name—Name of the Proxy provider.

  • Credential Profile—Select the previously created credential profile.

    Note

     

    In case of ONC provider, please select the credential profile configured with ONC TAPI APIs. This is not the ONC UI credentials.

  • Family—Select PROXY.

  • Protocol—Select HTTP or HTTPS.

  • IP Address/ Subnet Mask—Enter the IP address (IPv4 or IPv6) and subnet mask of the NSO cluster or the ONC 1.0 cluster VIP.

  • Port—Enter the port number (usually, 30603 for HTTPS).

  • Timeout—(Optional) The amount of time (in seconds) to wait before timing out the connection to the server. The default is 30 seconds.

Step 3

Under Provider Properties, enter these properties:

Table 5. Provider Properties for NSO proxy provider

Property Key

Property Value

forward true
input_url_prefix

Note

 

This property is required only in case of RFS nodes.

/<rfs-node-name>

<rfs-node-name> refers to the name of the RFS node added to the CFS node in the LSA cluster.

Table 6. Provider Properties for ONC 1.0 proxy provider

Property Key

Property Value

forward true
input_url_prefix /onc-tapi
output_url_prefix /crosswork/onc-tapi

Step 4

When you have completed entries in all of the required fields, click Save to add the provider.


Get Provider Details

Use the Providers window to get details about your providers and to check on their reachability.

Procedure


Step 1

Choose Administration > Manage Provider Access.

For each provider configured in the Cisco Crosswork application, the Providers window lists information such as the provider's name, universally unique identifier (UUID), associated credential profile and more, as shown in the figure below.
Figure 6. Providers Window
Providers Window

Step 2

The icons in the Reachability column indicate whether a provider is reachable via the listed connectivity protocols.

Cisco Crosswork application checks provider reachability immediately after a provider is added or modified. Other than these events, Change Automation and Health Insights checks reachability every 5 minutes and Optimization Engine checks SR-PCE reachability about every 10 seconds.

Note

 

Change Automation events and Health Insights events are only applicable to cluster deployments of the Crosswork Network Controller. Optimization Engine events apply to all scenarios, except for single VM deployments of the Crosswork Network Controller Essentials tier.

Step 3

Get additional details for any provider, as follows:

  1. In the Provider Name column, click the Details icon to view provider-specific key/value properties.

  2. In the Connectivity Type column, click the Details icon to view detailed connectivity information for the provider, such as provider-specific protocol, IP format, IP address, port, and timeout information.

  3. In the Model Prefix column, click the Details icon to view the supported NED version(s) for a Cisco Network Services Orchestrator (Cisco NSO) provider's configured NED model prefix(es).

  4. When you are finished, click Close icon to close the details window.

If you are running into Cisco SR-PCE reachability problems, see Cisco SR-PCE Reachability Issues. Check that HTTP and port 8080 is set.

For general provider reachability problems, you can troubleshoot as follows:

  1. Ping the provider host.

  2. Attempt a connection using the protocols specified in the connectivity settings for the provider. .

    The following CLI command can be used to perform this check:

    curl -v -H "X-Subscribe: stream" "http://<ip-address>:8080/
    bwod/subscribe/json?keepalive-30&priority=5"
  3. Check your firewall setting and network configuration.

  4. Check the provider host or intervening devices for Access Control List settings that might limit who can connect.


Edit Providers

When editing provider settings, be aware that a provider can be mapped to many devices, even thousands of devices in a large network.


Note


  • Before making any changes to a provider configuration you should be certain that you understand the full impact of the change. If you are unsure about the potential risk of making a change, contact Cisco services for guidance.

  • See Add SR-PCE providers before modifying an SR-PCE provider. There are additional steps that must be done when editing an SR-PCE provider.

.

Before editing any provider, it is always good practice to export a CSV backup of the providers you want to change (see Export Providers).

Procedure


Step 1

Choose Administration > Manage Provider Access.

Step 2

In the Providers window, choose the provider you want to update and click Edit icon.

Step 3

Make the necessary changes and then click Save.

Step 4

Resolve any errors and confirm provider reachability.


Delete providers

Follow the steps below to delete a provider.

You are alerted when you try to delete a provider that is associated with one or more devices or credential profiles.

Procedure


Step 1

Export a backup CSV file containing the provider you plan to delete (see Export Providers).

Step 2

(Optional) Check whether any devices are mapped to the provider and change the provider before deletion.

  1. Choose Device Management > Network Devices. The Network Devices tab is displayed by default.

  2. In the Network Devices window, enter the obsolete provider name in the Search field.

  3. Check the check box for the device that is mapped to the obsolete provider, and click Edit icon.

  4. Choose a different provider from the Provider drop-down list.

  5. Click Save.

Step 3

Delete the provider as follows:

  1. From the main menu, choose Administration > Manage Provider Access.

  2. In the Providers window, choose the provider(s) that you want to delete and click Delete icon.

  3. In the confirmation dialog box, click Delete.


Export Providers

You can quickly export provider data to a CSV file. This is a handy way to keep backup copies of your provider information.


Note


You cannot edit a CSV file and then re-import it to update existing providers.


Procedure


Step 1

Choose Administration > Manage Provider Access.

Step 2

(Optional) In the Providers window, filter the provider list as needed.

Step 3

Check the check boxes for the providers you want to export. Check the check box at the top of the column to select all the providers for export.

Step 4

Click Export icon. Depending on your browser, you will be prompted to select a path and file name to use when saving the CSV file, or to open it immediately.


Tags

Tags are simple text strings that you can attach to objects to help group them. Crosswork Network Controller comes with a short list of ready-made tags used to group network devices. You can create your own tags and use them to identify, find, and group devices for a variety of purposes. For example, in addition to type and geo-location, you may want to identify and group devices by their location in your network topology (spine vs. leaf), or the function they serve in your network (Provider vs. Provider Edge).

The system automatically creates a default set of tags and assigns them to every device they manage:

  • cli

  • mdt

  • reach-check

  • snmp

  • clock-drift-check

You cannot select, edit, delete, or manually associate these default tags with any device.

Tags Management page

The Tags Management page allows you to easily create and manage providers. To navigate to this page, choose Administration > Manage Provider Access.

Tags can provide information such as the device’s physical location and its administrator’s email ID, and are used to group devices. Use the Tag Management page to manage the tags available for assignment to the devices in your network.

To open this page, choose Administration > Tag Management.

Figure 7. Tag Management page
Tag Management
Item Description

1

Click Add icon to create new device tags. See Create tags.

2

Click Delete icon to delete currently selected device tags. See Delete tags.

3

Click Import icon to import the device tags defined in a CSV file into the Cisco Crosswork application. See Import multiple tags using a CSV file. You can also download a CSV file template by clicking this icon. The template includes sample data that you can use as a guide for building your own CSV file.

4

Click Export icon to export a CSV file that lists the tags that are currently configured and their attributes. You can update this file and import it back into the Cisco Crosswork application to quickly add or edit multiple tags. See Export tags.

5

Displays the tags and their attributes currently available in the Cisco Crosswork application.

6

Indicates the number of tags that are currently selected in the table.

7

Click Refresh icon to refresh the Tag Management window.

8

Click Settings icon to choose the columns to make visible in the Tag Management window.

9

Click Set Filter icon to set filter criteria on one or more columns in the Tag Management window.

To clear a filter, click the corresponding [X] in the Filters menu.

Create tags

You can create as many tags and tag categories as you want. See also Import multiple tags using a CSV file.


Note


  • Tag and tag category names are case-insensitive and can contain a maximum of 128 alphanumeric characters, plus dots (.), underscores ("_") or hyphens ("-"). No other special characters are allowed.

  • The maximum number of tags that you can create is 100.


Procedure


Step 1

Choose Administration > Tag Management. The Tag Management page opens.

Step 2

Click Add icon. The Create New Tags pane opens.

Step 3

In the Category area:

  • To associate your new tags with an existing category: Choose the category from the drop-down list.

  • To associate your new tags with a new category: Click the New Category link, enter the new category's name in the text field, and click Save.

All the new tags you create after this step will be assigned to the category you selected or created.

Step 4

In the Tags area: Start entering the names of the new tags that you want to create. Press Enter after you type each tag.

The Create New Tags window will list only the tags that already exist in your currently selected category.

Step 5

When you are finished entering new tags, click Save.

Note

 

If you enter a duplicate tag, the Save button remains disabled.


What to do next

Add tags to devices. See Apply or Remove Device Tags.

Import multiple tags using a CSV file

Complete the steps below to create a CSV file that lists the tags you want to apply to your devices, and then import it into the Cisco Crosswork applications. This is the easiest way to create a lot of new tags and tag categories quickly.

When you import the CSV file, any tags not already in the database will be added. Tags with the same name as an imported tag will be overwritten. For this reason, it is a good idea to export a backup copy of all your current tags before import. See Export tags).

Procedure


Step 1

From the main menu, choose Administration > Tag Management > Import icon.

Step 2

If you have not already created a CSV file to import:

  1. Click the Download sample 'Tags template (*.csv)' file link and save the CSV file template to a local storage resource.

  2. Open the template using your preferred tool. Begin adding rows to the file, one row for each tag. Use a comma to delimit each field within a row. Use a semicolon to separate multiple entries in the same field.

    Field Description

    Required or Optional

    Tag Name

    Enter the name of the tag. For example: SanFrancisco or Spine/Leaf.

    Required

    Tag Category

    Enter the tag category. For example: City or Network Role.

    Required

    Note

     

    Tag Name and Tag Category fields are case-insensitive and can contain a maximum of 128 alphanumeric characters, plus dots (.), underscores ("_") or hyphens ("-"). No other special characters are allowed.

    Be sure to delete the sample data rows before saving the file, or they will be imported along with the data you want. The column header row can stay, as it is ignored during import.

  3. When you are finished, save the new CSV file.

Step 3

Click Browse to navigate to the CSV file you just created and then click Open to select it.

Step 4

With the CSV file selected, click Import.

The tags and tag categories that you imported should now be displayed in the Tag Management window.


What to do next

Add tags to devices. See Apply or Remove Device Tags.

Apply or Remove Device Tags

Tags and their categories are your main tool for grouping devices. Once you have tagged a set of devices with the same tag, they are considered part of a group, and you can manage them more easily.

In order to apply a tag to a device or group of devices, the tag must already exist. See Create tags for more information.

For efficiency, Cisco Crosswork automatically updates inventory data, including topology, for all the devices in a tagged group, as a single set of inventory collection jobs. But please note that tag-group membership is static for other functions. For example, if you add or remove a device from a tagged group after applying a KPI, the KPI will monitor only the original group members. If you change group membership and want the KPI to monitor all the members of the group, re-apply the KPI to the changed group.

You can apply a maximum of 15 tags to any one device.

To apply tags to a device or set of devices, do the following:

Procedure


Step 1

Choose Device Management > Network Devices. The Network Devices tab is displayed, showing the list of devices.

Step 2

(Optional) If the list is long, click Set Filter icon to set one or more filters and narrow the list to only those devices you want to tag.

Step 3

Check the check box next to the device(s) you want to tag. If you select multiple devices, any changes you make will be applied to all the devices you selected.

Step 4

Click Edit Tags icon. The Modify Tags window opens, showing the tags currently applied to the device(s) you selected.

Step 5

Click in the Type to autocomplete item field to display the list of existing tags, or begin typing the name of the tag you want.

Step 6

Click on individual tags in the list to add them to the list of tags applied to the device(s). To delete an applied tag, click the X icon shown next to that tag.


Delete tags

Use caution when deleting existing tags. They are used to group devices and deleting them can affect which KPIs are being monitored and the Playbooks run on them when using Change Automation.

Follow these steps to delete device tags:


Note


If the tag is mapped to any devices, then the tag cannot be deleted.


Procedure


Step 1

Export a backup CSV file containing the tags you plan to delete (see Export tags).

Step 2

Choose Administration > Tag Management. The Tag Management page is displayed.

Step 3

Check the check box next to the tags you want to delete and click Delete icon.

Step 4

The confirmation dialog box will list the number of devices currently using the tag(s) you are about to delete. Click Delete to confirm deletion.


Export tags

You can quickly export tags and tag categories to a CSV file. This will allow you to keep backup copies of your tags. You can also edit the CSV file as needed, and re-import it to overwrite existing tags. Note that you will need to re-associate devices and tags in some cases.

Procedure


Step 1

Choose Administration > Tag Management.

Step 2

(Optional) In the Tag Management page, filter the tag list as needed.

Step 3

Check the check boxes for the tags you want to export. Check the check box at the top of the column to select all the tags for export.

Step 4

Click Export icon. Depending on your browser, you will be prompted to select a path and file name to use when saving the CSV file, or to open it immediately.