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. 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, see the Inventory Management APIs On Cisco Devnet.

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

    • Create the provider(s) that will be associated with the devices. See About Adding Providers.

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

    • Create tags for use in grouping the new devices. See Create Tags.

    • Download the CSV template file from Crosswork and populate it with all the devices you will need.

  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 User Interface.

  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. After onboarding devices from this source, you will need to edit each device to add device information that is not automatically discovered. For more information, see the provider properties in Add Cisco SR-PCE Providers.

  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. For more information, see the Zero Touch Provisioningchapter in the Cisco Crosswork Network Controller 7.0 Device Lifecycle Management Guide.


Note

As Cisco Crosswork 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.

If a device onboarded in Cisco Crosswork is on the same subnet as a Crosswork Data Gateway interface, then it must be on the data gateway's southbound network. This is because Crosswork 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 the Set Up and Use Your Topology Map for Network Visualization chapter in the Cisco Crosswork Network Controller 7.0 Administration Guide.

The following sections provide sample configurations for several protocols, including SNMP, NETCONF, SSH, gNMI and syslog.

Use them as a guide to configuring the devices that you plan to manage.


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

In the event of a failover, the standby data gateway within the same data gateway pool automatically inherits the virtual IP address of the active data gateway. You do not require any additional configuration, allowing for a simplified and efficient failover strategy.

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

The ZTP users must define the events they want the device to send to Crosswork in the pre-configuration, day-zero, or post-configuration files. Non-ZTP users should establish which events the device must send to Crosswork and decide on the method of communication for these events.

For example, you can configure a device to forward events to the Crosswork 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 rate limits. The NETCONF setting is only needed if the device is MDT-capable.


Note

When collecting interface MIB data from IOS XR and XE devices, collectors may receive two split column sets for the same interface index, causing one set to overwrite the other and resulting in the loss of column data. To address this issue, it is recommended to add a configuration to the device's Day 0 setup that sets the SNMP packet size to 4096 bytes. This configuration prevents splits in column sets, thereby improving the reliability of data collection. 

logging console debugging
logging monitor debugging
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

Note that, for traps to be received, the node_ip field for the device as listed in the Cisco Crosswork inventory must match the IP address of the device interface from which the traps are sent. If they do not, Cisco Crosswork rejects the traps. Also, the device must be in ADMIN_UP state for traps to be received.

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 ssh
transport output ssh
vty-pool default 0 99 line-template default
SSH Settings: 

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 for alarm and event management. NTP settings ensure that Crosswork 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 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 ssh (requird only if ssh is used)
transport output ssh (required only if ssh isused)
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 Crosswork for alarm and event management. NTP settings ensure that Crosswork 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 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 EPNM
 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 EPNM

    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 User Interface

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 the table below.

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.

Table 1. Add New Device Window (*=Required)
Field Description

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

* Credential Profile

The name of the credential profile to be used to access the device for data collection and configuration changes. For example: nso23 or srpce123.

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

Host Name

The hostname 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.

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.

Serial Number

Serial number for the device.

MAC Address

MAC address of the device.

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

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.

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

Connectivity Details

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. You must 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

 

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.

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.

* Port

The port used for this connectivity protocol. Each protocol is mapped to a port, so be sure to enter the port number that corresponds to the protocol you chose. The standard port assignments for each protocol are:

  • SSH: 22

  • SNMP: 161

  • NETCONF: 830

  • TELNET: 23

  • HTTP: 80

  • HTTPS: 443

GNMI and GNMI_SECURE: 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 will time out. The default value is 30 seconds.

For XE devices using NETCONF, the recommended minimum timeout value is 90 seconds. 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 menu 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.

For non-Cisco devices, select "None" in the Encryption field.

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.

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.

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.

*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 in the device type. This field is optional.

Note

 

This field can be edited only when the device is in 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 needs to 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.

Longitude, Latitude

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

Altitude

The altitude at which the device is located. For example, 123.

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 host name used for the provider.

Add Devices by Importing from CSV File

Complete the steps below to create a CSV file that specifies multiple devices and then import it into Crosswork Network Controller. This allows you to add multiple devices at once instead of adding each device individually.

Importing devices from a CSV file adds any devices not already in the database, and overwrites the data in any device record with an Inventory Key Type field value that matches those of an imported device (this excludes the UUID, which is set by the system and not affected by import). For this reason, it is a good idea to export a backup copy of all your current devices before an import.


Note

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.

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

    For a list of the fields and the mandatory values you must enter, see the "Add New Device" field table in Add Devices Through the User Interface.

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

  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.