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
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').
-
- 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
-
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
-
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.
- 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.
-
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.
-
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.