Onboard Devices

This section contains the following topics:

Add devices to the inventory

There are different ways to add devices to Crosswork. Each has its own set of prerequisites, which you must fulfill if the device addition is to succeed. As Cisco Crosswork Network Controller supports dual-stack deployment, you can onboard devices with both IPv4 and IPv6 addresses. It is recommended to onboard such devices only once, selecting either the IPv4 or IPv6 address.

Ensure that your devices are configured properly for communication and telemetry. See guidelines and example configurations in Configuration prerequisites for new devices and Sample Configuration for Cisco NSO Devices.

In order of preference for most users, the methods and their prerequisites are:

  1. Importing devices using the Crosswork APIs: This is the fastest and most efficient of all the methods, but requires programming skills and API knowledge.

    For more information, see the CNC 7.1 API documentation.

  2. Importing devices from a Devices CSV file: This method can be time-consuming. To succeed with this method, you must first:

    • Create corresponding credential profiles for all of the devices and providers listed in the CSV file.

    • Create the provider(s) that will be associated with the devices.

    • Create tags for use in grouping the new devices.

    • Download the CSV template file from Crosswork and populate it with all the devices you plan to add.

    For information about adding devices using a CVS file, see Add devices by importing from CSV file.

  3. Adding them via the UI: This method is the least error-prone of the three methods, as all data is validated during entry. It is also the most time-consuming, being suitable only for adding a few devices at a time. Note that the providers, credential profiles and tags you want to apply to them must exist beforehand. For more information, see Add devices through the UI.

  4. Auto-onboarding from a Cisco SR-PCE provider: This method is highly automated and relatively simple. Note that the device and provider credential profiles and tags you want to apply to these devices must exist beforehand. The auto-onboarding method does not create or assign this information automatically. Devices are initially discovered and added with partial information. To complete the onboarding process, you will need to supplement the missing details. You can provide the additional information by uploading a CSV file or manually adding it using the API or UI.

  5. Auto-onboarding using Zero Touch Provisioning: This method is automated, but requires that you create device entries first and modify your installation's DHCP server. Note that the device and provider credential profiles and tags you want to apply to these devices must exist beforehand. After provisioning and onboarding devices using this method, you will need to edit each device to add information that is not automatically supplied.

Add onboarded devices to Data Gateway

After onboarding your devices, add them to Data Gateway to enable data collection from multivendor devices. This process ensures your devices can communicate with Crosswork Network Controller to gather network data.


Note

If a device onboarded in Cisco Crosswork is on the same subnet as a Data Gateway interface, then it must be on the data gateway's southbound network. This is because Data Gateway implements Reverse Path Forwarding (RPF) checks and the source address of devices cannot be on the management or northbound networks if multitple NICs (2 or 3 NIC) are deployed.

Configuration prerequisites for new devices

Before you on board the new devices, ensure that the devices are properly configured in order to be managed by the Cisco Crosswork Network Controller.

For SR-PM configurations, refer to the Segment Routing Configuration documentation specific to your platform and release. Configuration requirements may vary between platforms.

For configurations related to LLDP, CDP, and LAG protocols, see Set Up and Use Your Topology Map for Network Visualization. The link discovery process is closely related to the onboarding process, though it is not strictly required for onboarding. However, we recommend that you plan for link discovery as part of the onboarding workflow. This approach allows you to complete all necessary configuration work upfront, rather than addressing it incrementally. This is especially important if you want to leverage configuration templates. You can onboard devices without all the desired configurations initially and later push a standardized configuration to the devices. This ensures they are fully compatible with Crosswork Network Controller.

The following sections provide sample configurations for several protocols, including SNMP, NETCONF, SSH, gNMI, syslog and TELNET. Use them as a guide to configuring the devices that you plan to manage.


Note

If you are using TELNET in your network environments, we recommend implementing security measures, such as firewall protections and ACLs to reduce any potential risks.


Note

  • SNMPv2 and SNMPv3 (Auth/Priv) traps are supported.

  • The SNMP EngineID generated or configured in the device should be unique in the network.

  • For the credentials to work, SNMP users should be re-created if the SNMP EngineID is reconfigured in the device.

  • In the sample configurations, cdg_virtualIP denotes the virtual IP address of the Data Gateway in a Data Gateway pool. The cdg_virtualIP varies for each pool.

  • When devices are onboarded with Sys Object ID contact the Cisco Customer Experience team as the platform may not be certified by Cisco.

Configure Devices To Forward Events to Crosswork Network Controller

To ensure that the Crosswork Network Controller can receive events and notifications from devices, configure the devices to forward events to the Crosswork server. For most devices, this means you must configure the devices to forward SNMP traps and syslogs to the Data Gateway using its virtual IP as the receiver IP.

If you have a geo high availability deployment, configure devices to forward events to both Data Gateway on the primary and secondary data center.


Note

When you configure a Data Gateway pool with spare Data Gateway, failover is handled without changing the IP address that devices use for forwarding traffic:

  • If a Data Gateway fails, the spare Data Gateway automatically inherits the IP address of the failed Data Gateway.

  • If your configuration uses an FQDN, traffic continues to route without disruption even if a Data Gateway in the pool fails because the FQDN remains unchanged.

We recommend using a common configuration file for all your devices to allow Crosswork Network Controller to perform a reachability check and collect trap information.

For example, you can configure a device to forward events to the Crosswork Network Controller server using the snmp-server host command. 

snmp-server host 192.168.90.135 traps version 2c public udp-port 1062
snmp-server community public RO
snmp-server community private RW
snmp-server traps snmp linkup
snmp-server traps snmp linkdown
To set the SNMP view:
snmp-server view { group name } include

Configure Devices for Pre-Onboarding Tasks

The following commands provide a sample pre-onboarding device configuration that sets the correct SNMPv2 and NETCONF configuration, and SSH and TELNET rate limits. The NETCONF setting is only needed if the device is MDT-capable. 

logging console debugging
logging monitor debugging
telnet vrf default ipv4 server max-servers 100
telnet vrf default ipv6 server max-servers 100
crypto key generate rsa
 exec-timeout 0 0
 width 107
 length 37
 absolute-timeout 0
!
snmp-server community public RO
snmp-server community robot-demo2 RO
snmp-server ifindex persist
ntp
 server NTPServerIPAddress
!
ssh server v2
ssh server vrf default
ssh server netconf vrf default
ssh server logging
ssh server rate-limit 100
ssh server session-limit 100
!         
netconf-yang agent
 ssh
!
netconf agent tty
!
xml agent tty
!

Configure SNMPv3 Devices

If you want to enable SNMPv3 data collection, repeat the SNMPv2 configuration commands in the previous section, and add the following commands: 

snmp-server group grpauthpriv v3 priv notify v1default
snmp-server user <user-ID> grpauthpriv v3 auth md5 password priv aes 128 password

Configure SNMPv2 and SNMPv3 traps

To configure the device to send SNMP traps, use the following commands:

For SNMP v2 traps: 

snmp-server trap link ietf
snmp-server host cdg_virtualIP traps version 2c Community String udp-port 1062
snmp-server community Community String
snmp-server traps snmp linkup
snmp-server traps snmp linkdown

For SNMP v3 traps: 

snmp-server trap link ietf
snmp-server host cdg_virtualIP traps version 3 Community String udp-port 1062
snmp-server community Community String
snmp-server traps snmp linkup
snmp-server traps snmp linkdown

Configure MDT sensor groups

telemetry model-driven
!
destination-group Crosswork
  vrf mgmt
  address-family ipv4 x.x.x.x port 9010
   encoding self-describing-gpb
   protocol tcp
  !
sensor-group Crosswork
  sensor-path Cisco-IOS-XR-infra-tc-oper:traffic-collector/afs/af/counters/tunnels/tunnel
!
subscription Crosswork
  sensor-group-id Crosswork
  destination-id Crosswork
!
!

Configure gNMI or gRPC

grpc
vrf mgmt
port 57500
no-tls
max-streams 128
max-streams-per-user 128
address-family dual
max-request-total 256
max-request-per-user 32
!
 
tpa
vrf mgmt
  address-family ipv4
   default-route mgmt
  !
  address-family ipv6
   default-route mgmt
  !
!
!

Configure required settings for Cisco IOS XR device operating system

Note that <SystemOwner> is a user-supplied variable.

snmp-server community community_name SystemOwner
snmp-server community community_name RO
snmp-server entityindex persist
snmp-server ifindex persist

logging cdg_virtualIP
logging on
logging buffered 307200-125000000

logging source-interface interface_name

logging trap informational
logging events level informational
logging events link-status
logging events link-status software-interfaces

no cli whitespace completion
domain ipv4 host server_name cdg_virtualIP

Set up VTY options: 

line default
exec-timeout 10 
session-limit 10
session-timeout 100
transport input all
transport output all
vty-pool default 0 99 line-template default
TELNET and SSH Settings: 

telnet ipv4 server max-servers no-limit
telnet vrf default ipv4 server max-servers 100
ssh server v2
ssh server rate-limit 60
cinetd rate-limit 60
Configure the NetConf and XML agents: 
xml agent tty
netconf agent tty
Monitor device with Virtual IP address : 
ipv4 virtual address use-as-src-addr
ipv4 virtual address Virtual_IP_Address/Subnet_Mask
Enable CFM modeling:
snmp-server view all 1.3.111.2.802.1.1.8 included
For SNMPv2 only, configure the community string: 
snmp-server community ReadonlyCommunityName RO SystemOwner
For SNMPv3 only, configure the following settings: 
snmp-server user User Group v3 auth sha encrypted Password priv des56 encrypted
Password SystemOwner
snmp-server view Group 1.3.6 included	
snmp-server view Group 1.0.8802.1.1.2 included
snmp-server group Group v3 priv notify Group read Group
snmp-server group Group v3 priv read v1default write v1default notify v1default
Configure the following to improve the SNMP interface stats response time:
snmp-server ifmib stats cache
Configure SNMP traps for physical interfaces to ensure that link-down scenarios are captured:
snmp-server interface subset 2 regular-expression Forty*
notification linkupdown
!
snmp-server interface subset 3 regular-expression Ten*
notification linkupdown
!
snmp-server interface subset 1 regular-expression Hun*
notification linkupdown
!
snmp-server interface subset 1 regular-expression TwoHun*
notification linkupdown
!
snmp-server interface subset 1 regular-expression FourHun*
notification linkupdown
Enable SNMP entity field replaceable unit (FRU) control traps:
snmp-server traps fru-ctrl
Syslogs are used by Crosswork Network Controller for alarm and event management. NTP settings ensure that Crosswork Network Controller receives the correct timestamps for events. To configure syslogs on the device, add the following settings:
clock timezone TimeZone
service timestamps log datetime show-timezone msec year
ntp server NTP_Server
logging facility local7
logging cdg_virtualIP vrf name

Configure Required Settings for Cisco IOS and IOS-XE Device Operating System


snmp-server host cdg_virtualIP
snmp-server community public-cmty RO
snmp-server community private-cmty RW
snmp-server ifindex persist

logging cdg_virtualIP
logging on
logging buffered 64000 informational

logging source-interface interface_name
logging trap informational
logging event link-status default
Disable domain lookups to avoid delay in TELNET/ SSH command response: 
no ip domain-lookup
Enable SSH 
crypto key generate rsa
ip ssh rsa keypair-name keypair-name
crypto key generate rsa usage-keys label key-label modulus modulus-size
ip ssh version [1 | 2]
Setup VTY options: 
line vty <number of vty>
exec-timeout
session-timeout
transport input all (requird only if ssh is used)
transport output all (required only if ssh is used)
For SNMPv2 only, configure the community string:
snmp-server community ReadonlyCommunityName RO
For SNMPv3 only, configure the following settings:
snmp-server user User Group v3 auth sha Password priv des Password
snmp-server view Group 1.3.6 included
snmp-server view Group 1.0.8802.1.1.2 included
snmp-server group Group v3 priv notify Group read Group

snmp-server group Group v3 priv read v1default write v1default notify v1default
snmp-server group Group v3 priv
snmp-server group Group v3 priv notify crosswork read crosswork
Configure the cache settings at a global level to improve the SNMP interface response time using the configuration: 
snmp-server cache
Syslogs are used by the Crosswork Network Controller for alarm and event management. NTP settings ensure that Crosswork Network Controller receives the correct timestamps for events. To configure syslogs on the device, add the following settings:
clock timezone TimeZone
service timestamps log datetime show-timezone msec year
ntp server NTP_Server
update-calendar
logging facility local7
logging cdg_virtualIP vrf default severity info [port default]

Configure Required Settings for Nexus Operating System

The following commands provide a sample pre-onboarding device configuration for Nexus devices that sets the correct SNMPv2 and NETCONF configuration, and SSH rate limits. The NETCONF setting is only needed if the device is MDT-capable.

logging console 7
logging monitor 7
!
ntp server <NTPServerIPAddress>
ntp server <10.10.10.11> use-vrf <management or configured vrf>.   
!
ssh idle-timeout
logging level security
!
feature netconf
feature openconfig
!
snmp-server user <User>  auth md5 <String> priv aes-256 <String>
!
snmp-server enable traps link linkDown
snmp-server enable traps link linkUp

snmp-server community community_name RO
!
logging server <IP>
logging source-interface interface_name
logging event link-status default
logging event link-status enable

  • User privileges can be configured as either network-admin or network-operator

  • In Nexus OS, the ifIndex for an interface is persistent.

  • To retrieve the SNMP interface index (ifmib index), use the following command:
    show interface snmp-index
  • To configure logging for link status or trunk status changes, use the following command in configuration mode:
    logging event link-status default
logging event link-status enable

Set up VTY options: 

line vty
exec-timeout 10
session-limit 10
Forward events to the Crosswork Network Controller server using the snmp-server host command:
snmp-server host <192.168.90.135> traps version 2c public udp-port 1062
snmp-server community public RO
snmp-server community private RW
snmp-server enable traps link linkDown
snmp-server enable traps link linkUp
Configure the following to improve the SNMP interface stats response time:
snmp-server counter cache enable
snmp-server counter cache timeout <1-3600>
Enable SNMP entity field replaceable unit (FRU) control traps:
snmp-server enable traps entity
Syslogs are used by Crosswork Network Controller for alarm and event management. NTP settings ensure that Crosswork Network Controller receives the correct timestamps for events. To configure syslogs on the device, add the following settings:
clock timezone TimeZone
ntp server NTP_Server
logging level ntp 7
logging server <IP> use-vrf <vrf name>
The service timestamps feature is not supported in Nexus OS. To set the logging level for a specific facility (e.g., NTP), use the following command:
logging level ntp 7

Configure IGP Protocol to Generate the Router ID

Based on your device configuration, use the appropriate sample configuration for either ISIS or OSPF. For detailed configurations, see the platform-specific documentation.

ISIS router ID: 
router isis 1
 net 49.0010.0100.0004.00
 distribute link-state instance-id 100
 log adjacency changes
 affinity-map top bit-position 101
 affinity-map bottom bit-position 102
 address-family ipv4 unicast
  metric-style wide
  mpls traffic-eng level-2-only
  mpls traffic-eng router-id Loopback0
  router-id 198.19.1.4
  segment-routing mpls 
#show mpls traffic-eng igp-areas
Fri Oct  4 03:53:16.117 UTC

MPLS-TE IGP Areas

Global router-id:         198.19.1.4
Global optical router-id: Not available

IS-IS 1

    IGP ID:                      0010.0100.0004
    TE router ID configured:     198.19.1.4
                 in use:         198.19.1.4
    Connection:                  up

OSPF router ID:

router ospf
 distribute link-state instance-id 6
 router-id 1.1.1.20
 segment-routing global-block 16000 17999
 segment-routing forwarding mpls
 segment-routing sr-prefer  
#show mpls traffic-eng igp-areas
Fri Oct  4 03:53:28.091 UTC

MPLS-TE IGP Areas

Global router-id:         1.1.1.20
Global optical router-id: Not available

OSPF

    IGP ID:                      1.1.1.20
    TE router ID configured:     1.1.1.20
                 in use:         1.1.1.20
    Connection:                  up

Sample Configuration for Cisco NSO Devices

When using Cisco Network Services Orchestrator (Cisco NSO) as a provider to configure devices managed by Cisco Crosswork, make sure that the Cisco NSO device configurations observe the guidelines in the following example.

This example shows a Cisco NSO configuration that uses the hostname as the device ID. If you are using a CSV file to import devices, use ROBOT_PROVDEVKEY_HOST_NAME as the enum value for the provider_node_key field. The example hostname RouterFremont used here must match the hostname for the device in the CSV file. 


configure
set devices device RouterFremont address 198.18.1.11 port 22

In the following example, we are creating an authgroup called "cisco", with a remote name and password of "cisco". Next, we are setting all the devices that have a name starting with "Router" to a device type of "netconf" using the ned-id "cisco-iosxr-nc-6.6". Finally, we are assigning all of the devices with a name starting with "Router" to the "cisco" authgroup. Edit these settings to match your environment: 


set devices authgroups group cisco default-map remote-name cisco remote-password cisco
set devices device Router* device-type netconf ned-id cisco-iosxr-nc-6.6
set devices device Router* authgroup cisco

The following CLI commands unlock and retrieve the SSH keys from all of the devices. Cisco NSO synchronizes itself with the devices by uploading each device's current configuration and then storing the present configuration. It is important to use these commands to ensure that the devices, Cisco NSO, and your Cisco Crosswork applications are starting from a common configuration: 


set devices device Router* state admin-state unlocked
request devices device Router* ssh fetch-host-keys
request devices device Router* sync-from
commit

Add devices through the UI

Follow the steps below to add devices one by one, using the user interface. This method is mostly used when adding a few devices only.

Procedure

Step 1

From the main menu, choose Device Management > Network Devices.

Step 2

Click Add icon.

Step 3

Enter the values for the new device, as listed in Table 1.

Step 4

Click Save. The Save button is disabled until all mandatory fields are completed.

Step 5

(Optional) Repeat these steps to add more devices.

Attention

 

The Device type field is deprecated in Crosswork Network Controller version 7.1.

Table 1. Add new device Window (*=Required)
Field Description

Device info

* Admin state

The management state of the device. Options are

  • UNMANAGED—Crosswork Network Controller is not monitoring the device.

  • DOWN—The device is being managed and is down.

  • UP—The device is being managed and is up.

* Reachability check

Determines whether Crosswork Network Controller performs reachability checks on the device. Options are:

  • ENABLE (In CSV: REACH_CHECK_ENABLE)—Checks for reachability and then updates the Reachability State in the user interface automatically.

  • DISABLE (In CSV: REACH_CHECK_DISABLE)—The device reachability check is disabled.

Cisco recommends that you always set this to ENABLE. This field is optional if Configured State is marked as UNMANAGED.

Serial number

Serial number for the device.

Host name

The hostname of the device.

Tags

The available tags to assign to the device for identification and grouping purposes.

Use device tags to group devices for monitoring, and to provide additional information that might be of interest to other users, such as the device’s physical location or its administrator’s email ID.

Software type

Software type of the device.

Note

 

Some third-party vendor devices require a specific string to be entered as part of the Software Type field. These are the required strings for different vendors:

  • Juniper devices: JUNOS

  • Huawei devices: VRP

  • Nokia devices: TIMOS

Software version

Software version of the operating system.

UUID

Universally unique identifier (UUID) for the device.

MAC address

MAC address of the device.

Inventory ID

Inventory ID value for the device. The value can contain a maximum of 128 alphanumeric characters, and can include dots (.), underscores ("_"), colons (":"), or hyphens ("-"). No other special characters are allowed.

Choose the device host name or an easily identifiable name for Inventory ID as this will be used to sync the device to Crosswork Network Controller with the Inventory ID used as the device name.

Product type

Product type of the device.

Syslog format

The format in which syslog events received from the device should be parsed by the syslog collector. The options are:

  • UNKNOWN - Choose this option if you are uncertain or if you do not want any parsing to be done by the syslog collector. The Syslog Collection Job output contains syslog events as received from the device.

  • RFC5424 - Choose this option to parse syslog events received from the device in RFC5424 format.

  • RFC3164 - Choose this option to parse syslog events received from the device in RFC3164 format.

Refer to Section: Syslog Collection Job Output for more details

CLI cache enabled

Click the checkbox if you wish to enable CLI cache.

Connectivity details

* Credential Profile

The name of the credential profile to be used to access the device for data collection and configuration changes. Select the profile for which the device is configured from the dropdown list. For example: nso23 or srpce123.

This field is optional if Administration State is marked as UNMANAGED.

Protocol

The connectivity protocols used by the device. Choices are: SNMP, NETCONF, TELNET,HTTP, HTTPS, GNMI, TL1, and GRPC.

Note

 

Toggle the Secure Connection slider to secure the GNMI protocol that you have selected.

In this documentation, the secured gNMI protocol is referred to as GNMI_Secure.

To add more connectivity protocols for this device, click Add icon at the end of the first row in the Connectivity Details panel. To delete a protocol you have entered, click Delete icon shown next to that row in the panel.

You can enter as many sets of connectivity details as you want, including multiple sets for the same protocol. Enter details for at least SSH and SNMP. If you do not configure SNMP, the device will not be added. If you want to manage the device (or you are managing XR devices), you must enter details for NETCONF. TELNET connectivity is optional.

* IP Address / Subnet Mask

Enter the device's IP address (IPv4 or IPv6) and subnet mask.

Note

 

If you have multiple protocols with the same IP address and subnet mask, you can instruct Crosswork Network Controller to autofill the details in the other fields.

Note

 

Please ensure that the subnets chosen for the IP networks (including devices and destinations) do not have overlapping address space (subnets/supernets) as it may result in unpredictable connectivity issues.

* Port

The port used for this connectivity protocol.

For each protocol enabled on the device, the default port is automatically provided. This default value works correctly in most cases. However, if your network uses non-standard ports, you must update the port settings to match the ones configured in your network.

GNMI and GNMI_SECURE: When using gNMI the value is not automatically populated. You must instead enter the value configured on your network devices. The port values range between 57344 to 57999. Ensure that the port number you enter here matches with the port number configured on the device.

Timeout

The elapsed time (in seconds) before communication attempts using this protocol times out. The default value is 30 seconds.

While the default value is 30 seconds, a minimum timeout value of 90 seconds is recommended for XE devices using NETCONF. For all other devices and protocols, the recommended minimum timeout value is 60 seconds.

Encoding Type

This field is only applicable for GNMI and GNMI_SECURE protocols. The options are JSON, BYTES, PROTO, ASCII, and JSON IETF.

Based on device capability, only one encoding format is supported at a time in a device.

Encryption

This field is applicable only to the SNMP protocol. From the drop-down list, choose the appropriate SNMPv3 protocol supported by the device. The default value is NONE.

The drop-down list presents several Advanced Encryption Standard (AES) options, including Counter mode (CTR), Galois/Counter mode (GCM), and Cipher Block Chaining mode (CBC), each supporting various key lengths (128-bit, 192-bit, and 256-bit).

The credential profile supports the generic privacy types such as AES-192 and AES-256. For Cisco devices, these are specified as CiscoAES192 and CiscoAES256 protocols.

On Cisco devices, the protocols appear as aes256-ctr, aes256-gcm@openssh.com, aes256-cbc, aes192-ctr, and aes192-cbc. To ensure compatibility with Crosswork Network Controller polling, Cisco devices must use these updated protocol variations.

On non-Cisco devices, select the encryption that the device supports or use NONE if the device does not use encryption for SNMP.

Trap source IP

This field is available only when the SNMP protocol is selected.

Use this field to specify the source IP address that the device will use to report SNMP traps if it differs from the default management interface IP address.

For consistent trap collection, ensure that the IP address entered in the Trap source IP field matches the trap-source parameter configured on the network device to avoid any issues with SNMP trap handling.

Note

 

  • If the Trap source IP field is not specified, Crosswork defaults to using the management interface IP address. For devices added via CSV or API, this field also defaults to the management interface IP address unless explicitly specified.

  • Ensure that the trap source uses the same IP stack (IPv4 or IPv6) as the device connectivity protocol to maintain consistent communication and avoid mismatches.

SNMP Disable Trap Check

This check box appears when the protocol field is set to SNMP. Selecting this check box disables the SNMPv2 community string validation between the network device and Data Gateway.

Disabling the SNMPv2 community string validation might be a requirement when you want to use a different community string for traps than the one in the credential profile.

* Capability

The capabilities that allow collection of device data and that are configured on the device. You must select at least SNMP as this is a required capability. The device will not be onboarded if SNMP is not configured. Other options are YANG_MDT, YANG_CLI, TL1, and GNMI. The capabilities that you select will depend on the device software type and version.

Note

 

  • For devices with MDT capability, do not select YANG_MDT at this stage.

  • To enable Crosswork Network Controller to receive the syslog-based data, select YANG_CLI.

Providers and access

Provide the provider information.

Provider family

Provider type used for topology computation. Choose a provider from the list.

Provider name

Provider name used for topology computation. Choose a provider from the list.

Note

 
For Cisco NSO LSA deployment, select the resource-facing service (RFS) node to which you want to assign the device.

Credential

The credential profile used for the provider. This field is read-only and is autopopulated based on the provider you select.

Device key

The hostname used to link this device record to its corresponding record on the provider. This is typically the device's full hostname, including the domain.

Routing info

ISIS system ID

The device's IS-IS system ID. This ID identifies the router in an IS-IS topology, and is required for SR-PCE integration.

This field is a configurable parameter, and cannot be autodiscovered by Crosswork Network Controller.

OSPF router ID

The device's OSPF router ID. This ID identifies the router in an OSPF topology, and is required for SR-PCE integration.

This field is a configurable parameter, and cannot be autodiscovered by Crosswork Network Controller.

*TE router ID

The traffic engineering router ID for the respective IGP.

Note

 

For visualizing L3 links in topology, devices should be onboarded to Crosswork Network Controller with the TE Router ID field populated.

IPv6 router ID

IPv6 router ID for the device.

This field is a configurable parameter, and cannot be autodiscovered by Crosswork Network Controller.

Streaming telemetry config

VRF

Name of the VRF within which Model Driven Telemetry (MDT) traffic is routed.

Source interface

The range of loopback address for the device type. This field is optional. However, we recommend specifying the loopback associated with the VRF by using the selector in the adjacent box.

Note

 

This field can be edited only when the device is in a DOWN or UNMANAGED state.

Opt out MDT config

When enabled, Crosswork Network Controller will not push telemetry configuration to the device via NSO. The default setting state is Disabled (which allows Crosswork Network Controller to push telemetry configuration to the device via NSO).

The device must be in ADMIN DOWN state to toggle this setting. Any out of band configuration setup must be cleared before moving the setting from Enabled to Disabled.

Location

Provide location information if you want to see your devices on the geographical map.

Building

Enter the name of the building.

Street

Enter the name of the street.

City

Enter the name of the city.

State

Enter the name of the state.

Country

Enter the name of the country.

Region

Enter the name of the region.

Zip

Enter the zip code of the region.

Longitude

Longitude value is required so that the geographical map can present the correct geographical location of the device and its links to other devices. Enter the longitude in Decimal Degrees (DD) format.

Latitude

Latitude value is required so that the geographical map can present the correct geographical location of the device and its links to other devices. Enter the latitude in Decimal Degrees (DD) format.

Altitude

The altitude at which the device is located.

If you do not know the altitude or do not wish to track it, you can leave this field blank. Alternatively, you may use this field to specify the floor of the building where the device is installed. The value must be a numeric entry.

Add devices by importing from CSV file

To add multiple devices to the Crosswork Network Controller, you can create and import a CSV file. This approach allows you to add several devices at once, avoiding the need to add each device individually.

Understanding the behavior of CSV import:

  • Importing devices from a CSV file adds the devices that are not already present in the database.

  • You can use more than one CSV file for importing devices. However, ensure that duplicate devices are not included in the new CSV file.

  • If a device in the CSV matches an existing device's Inventory key type field (excluding the UUID, which is system generated), the existing record is overwritten with data from the CSV.

  • If certain fields require unique values such as VRF, router loopback, or loopback ID, you must explicitly include these values in the CSV. This helps prevent any unintended configurations.

  • To avoid accidental data loss, we recommend to export a backup copy of your current device list before performing an import.

Handling non-required fields: For fields that are not required in the CSV, the following can occur:

  • The field may be left blank.

  • The field may be set to a default value.

  • The field may be populated with values retrieved from the device once communication is established, such as model, type, or software version.

Before adding devices from a CSV file, we recommend that you:

  • Add a few devices using the Crosswork Network Controller UI and confirm they are functioning properly.

  • Export the current device configuration to generate a CSV file. This serves as a template tailored to your environment.

  • Use this exported CSV file as a baseline for adding additional devices to ensure compatibility and reduce errors.


Attention

  • You cannot directly import a file that was just exported from the Crosswork Network Controller UI without making edits to it first.

  • If there are any errors in the import file, they are not reported all at once. Instead, the system identifies and displays errors one at a time, starting with the first error it encounters.

  • Importing devices using CSV or API methods will fail if the CSV file contains data gateway information. To successfully import the devices, ensure that the Crosswork Data Gateway and UUID columns in the CSV file are empty before you proceed.

  • The CSV file used to import devices differs between cluster deployments and single VM deployments.

To add devices by importing from CSV file, follow these steps:

Procedure

Step 1

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

Step 2

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

Step 3

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

  1. Click the Download sample 'Device Management 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 device.

    Note

     

    • Ensure that the TE router ID value for each device is populated. This value uniquely identifies the device within the topology as provided by SR-PCE.

    • The CSV files created on a Windows machine should contain a new line (marked with a 'newline' character) for the file to be processed as expected. Any newline created using the "carriage return" option will not work.

    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;SNMP;NETCONF in the Connectivity Type field and you enter 22;161;830 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

  3. Delete the sample data rows before saving the file, or they will be imported along with your data. You can keep the column header row, as it is ignored during the import process.

  4. Save the new CSV file.

Step 4

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

Step 5

With the CSV file selected, click Import and wait for the import to complete.

Step 6

Resolve any errors and confirm device reachability.

It is normal for devices to show as unreachable or not operational when they are first imported. However, if they are still displayed as unreachable or not operational after 30 minutes, there may be an issue that needs to be investigated. To investigate, select Device Management > Job History and click on any error icon you see in the Status column. Common issues include failure to ensure the associated credential profile contains the correct credentials. You can test this by opening a terminal window on the server and then trying to access the device using the protocol and credentials specified in the associated credential profile.

Step 7

Once you have successfully onboarded the devices, you must map them to a data gateway instance.

Export Device Information to a CSV File

Exporting the device list is a handy way to keep a record of all devices in the system at one time. You can also edit the CSV file as needed, and re-import it to overwrite existing device data.

Procedure

Step 1

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

Step 2

(Optional) Filter the device list as needed.

Step 3

Check the check boxes for the devices you want to export.

Step 4

Click Export icon. Your browser will prompt you to select a path and the file name to use when saving the CSV file, or to open it immediately.