Configuring the network discovery services

The Agile Service Manager network discovery service is installed together with the other core components. Once you have configured it, Agile Service Manager can discover network data.

Before you begin

OCP requirement: On the OCP hosts, network discovery requires that pids_limit be set at least to 44406 inside the crio.conf file.
For information about changing the values in the crio.conf file using Machine Configs, see Creating a ContainerRuntimeConfig CR to edit CRI-O parameters
For reference information about Machine Configs, see Red Hat Enterprise Linux CoreOS (RHCOS)
Ensure you have the required network data available before you configure the Agile Service Manager network discovery service. When creating a discovery profile, you may need information about the following:
Scope
You can specify subnet ranges or specific devices for the discovery as a 'zone'. A zone can be as granular as an individual router.
You can specify zones within zones to include or exclude them from the discovery.
Seeds
Seeds specify the locations from which to begin discovering devices. Discovery seeds can be IP addresses or subnet addresses.
Collector discovery
You can further configure a discovery with the included Alcatel5620Sam Java collector, which collects topology data from Element Management Systems (EMS) and integrates this data into the discovered topology.
Collector discovery is activated using the collector tag (by default, set to 'null').
Note: When network discovery is enabled, so is the collector service, which will fail to start unless the SFTP secret is created, as described in the Configuring EMS and SSH File Transfer Protocol (SFTP) Network Connectivity for Collector Discovery on OCP topic.
A Java Virtual Machine must be available on the target machine, and your EMS devices must be within the configured discovery scope.
For configuration information pertaining to this specific collector, see the IBM Network Manager IP Edition documentation here: https://www.ibm.com/support/knowledgecenter/en/SSSHRK_4.2.0/disco/task/dsc_confalcatel5620samjava.html
Remember: You configure the deployed network service after installing the core Agile Service Manager containers, and after starting them.

About this task

You first upload the configuration details in a commonconfig.json file via POST /file command. You then run the POST /config command for the Network Discovery observer, which first validates the files, and then saves them.

Network discovery service discovers configuration information about the entire network infrastructure, identifying deployed software components, physical servers, network devices, virtual systems, and host data. It then saves the information in the provided database. The Network Discovery Observer then retrieves network topology data from the database via REST API, which it uses to create topologies within the Agile Service Manager topology service.

Procedure

  1. Edit the example configuration file included with the network discovery installation, or create a new configuration file.
    For on-prem
    Edit the included configuration file:
    ASM_HOME/data/netdisco-observer/ExampleCommonconfig.json
    Save the file as commonconfig.json
    Alternatively, in the ASM_HOME/bin directory, generate the configuration file using the generate_common_config.sh script:
    ./generate_common_config.sh -d
    Expected output includes:
    ...Successfully generated commonconfig.json in /opt/ibm/netcool/asm/bin/../data/netdisco-observer folder...
    For OCP
    Copy the text from the following example file: Network discovery service configuration template
    Save the file as commonconfig.json
  2. Populate the following required properties in the configurations file for Network Discovery observer.
    See the related links for the full text of the included example configuration file.
    configId
    Discovery profile ID
    username
    Network Discovery username
    The default is admin
    To use a new default user, you must first create the user using POST /user. The following default users, passwords and roles are available:
    Table 1. Default network discovery users and roles
    User Password Role
    admin admin@123 ADMIN
    superuser superuser@123 ADMIN
    operator operator@123 OPERATOR
    password
    Network Discovery encrypted password
    For on-prem: Run the encrypt_password.sh script in the ASM_HOME/bin directory to encrypt the parameter:
    ./bin/encrypt_password.sh 
    Enter and then confirm the parameters to be encrypted, in turn. The encryption utility will return encrypted versions.
    For OCP: Run the following command to encrypt the parameters:
    kubectl exec -ti asm-topology-pods -- java -jar /opt/ibm/topology-service/topology-service.jar encrypt_password --password '<password to encrypt>'
    snmppasswords
    SNMP community strings, which must be in encrypted form
    For on-prem: Run the encrypt_password.sh script in the ASM_HOME/bin directory to encrypt the parameter:
    ./bin/encrypt_password.sh 
    Enter and then confirm the parameters to be encrypted, in turn. The encryption utility will return encrypted versions.
    For OCP: Run the following command to encrypt the parameters:
    kubectl exec -ti asm-topology-pods -- java -jar /opt/ibm/topology-service/topology-service.jar encrypt_password --password '<password to encrypt>'
    scope
    Network Discovery scope for IP-based devices and subnets
    Uses host and subnet
    You must supply the netmask for both host and subnet
    seeds
    Provides the starting points from which to look for devices
    telnetaccess
    By default set to null. You must supply the password in encrypted form.
    dns
    By default set to null.
    collector
    By default set to null.
    Collector configuration is used only during a collector discovery.
    You must supply the password in encrypted form.
    Note: When network discovery is enabled, so is the collector service, which will fail to start unless the SFTP secret is created, as described in the Configuring EMS and SSH File Transfer Protocol (SFTP) Network Connectivity for Collector Discovery on OCP topic.
  3. Optional: Configure automatic restarting of discovery.

    The network discovery service polls active discovery processes at intervals to check that they are still running. If a running discovery fails (for example, because the worker on which it is running stops), the discovery is run again from the beginning when the worker is restarted and any other active discoveries running on that worker have finished.

    Use the ISO 8601 standard notation when defining durations.

    • To configure the polling and discovery restart intervals:
      On-prem
      Edit the $ASM_HOME/etc/nasm-net-disco-status.yml file.
      Change the values for the SHERPA_STATUS_SERVICE_WORKER_CHECK_DURATION property.
      OCP
      Edit the ${releaseName}-nasm-net-disco-status pod for Kubernetes and OCP.
      Change the values for the SHERPA_STATUS_SERVICE_WORKER_CHECK_DURATION property.
    • To configure the intervals at which discovery attempts to restart:
      On-prem
      Edit the $ASM_HOME/etc/nasm-net-disco-status.yml file.
      Change the value for the SHERPA_RETRY_INTERVALS property.
      OCP
      Edit the ${releaseName}-nasm-net-disco-status pod for Kubernetes and OCP.
      Change the value for the SHERPA_RETRY_INTERVALS property.
  4. Upload the configurations file (that is, 'commonconfig.json') via the Network Discovery Observer's Swagger UI POST /file command, or cURL command.
    Example cURL command:
    curl --insecure --header 'Content-Type: multipart/form-data' --header 'Accept: application/json' --header 'X-TenantID: cfd95b7e-3bc7-4006-a4a8-a73a79c71255' --header 'Authorization: Basic YXNtOmFzbQ==' --request POST --url 'https://localhost/1.0/netdisco-observer/files' --form 'job_file=@/tmp/commonconfig.json'
    The configurations file will be saved in the ASM_HOME/data/netdisco-observer/{tenant-id} directory.
  5. Run POST /config via Swagger UI or cURL command to create the discovery details from the configurations file to the topology management artifact and Network Discovery.
    Example cURL command:
    curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'X-TenantID: cfd95b7e-3bc7-4006-a4a8-a73a79c71255' --header 'Authorization: Basic YXNtOmFzbQ==' 'https://localhost/1.0/netdisco-observer/config?filename=commonconfig.json'
    Tip: When you need to update or replace the discovery details, use PUT /config via the Swagger UI, or use the cURL command, as in the following example:
    curl --insecure --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'X-TenantID: cfd95b7e-3bc7-4006-a4a8-a73a79c71255' --header 'Authorization: Basic YXNtOmFzbQ==' --request PUT --url 'https://localhost/1.0/netdisco-observer/config?filename=commonconfig.json'
    Success notice: The file undergoes validation, and has been successfully saved when you receive response code 200 in the Swagger UI.
    Note: To view the discovery configuration, you can run GET /config/{configId} via Swagger UI or cURL command. Example cURL command:
    curl --insecure --header 'Accept: application/json' --header 'X-TenantID: cfd95b7e-3bc7-4006-a4a8-a73a79c71255' --header 'Authorization: Basic YXNtOmFzbQ==' 'https://localhost/1.0/netdisco-observer/config/default'

Results

The discovery configurations are saved and you can now run the full load job.

A Response code 400 error can occur when the incorrect scope has been provided:
Example error message:
{
  "_error": {
    "message": "Invalid netmask",
    "level": "error",
    "description": "Netmask cannot be null or empty"
  }
}
Workaround
Correct the configuration file, then re-upload it, and then rerun the PUT /config command.

What to do next

Next, you define a Network Discovery Observer job.