Network Discovery in Cisco IAC consists of choosing what type of device you want Cisco IAC to go out and look for (discover) and return information on, and then registering the devices you want to use. The high level workflow for Cisco IAC Network Discovery is as follows:
Initiate the Discovery Process
Select the Discovery Type
Ping Sweep or
Neighbor & Ping Sweep
Enter Credentials and Seed Device and/or Subnet Information
Register Discovered Devices
Assign Registered Devices to Network PODs
Cisco IAC Network Discovery Activity Diagram
Cisco IAC can discover existing networks / objects through Network Discovery.
Location of Network Discovery configuration and log resources
Make sure that the Network Discovery Web application, xmp-disc.war, has been successfully deployed at $XMP_HOME/apache-tomcat-7.0.40/webapps.
Check $XMP_HOME/instances/instance1/logs/Startup.log for Web application deployment errors.
Check Apache Tomcat debug level, $XMP_HOME/conf/logConfig/xmpmain_log4j.xml (modify the configuration to meet your needs, restart Network Discovery module after making the modifications):
Verify that Network Discovery module is up and running by doing:
service xmp status
Start it if necessary:
service xmp start
Tomcat server on the management appliance should be up and listening to port 8080.
Verify that Network Discovery module has started without errors by checking the log file $XMP_HOME/instances/instance1/logs/Startup.log.
IAC Wrapper to Process Orchestrator connectivity issue
The IAC network discovery wrapper sends processes discovery results and sends them over to the Process Orchestrator. Service items are then created in the Service Catalog.
Make sure the configuration in the $XMP_HOME/discovery/conf/iac.properties file is correct:
Process Orchestrator hostname
Port name and connection protocol (differ depending on either HTTP or HTTPS is being used)
Authentication type (basic or windows)
Authentication domain if the authentication type is windows
The Process Orchestrator machine must be reachable from the Management.
SSL configuration must be correct if SSL is used between the Management Appliance and Process Orchestrator. Since the direction of communication is different, this is not the same as the Process Orchestrator to Management Appliance configuration, and should be configured and verified separately.
Any communication errors sending messages from the Managed Appliance will be logged into $XMP_HOME/instances/instance1/logs/iac/discovery.log.
Process Orchestrator cannot create Service Catalog – Service Items
Process Orchestrator analyzes data sent by the management appliance and existing data from network devices service items, and then creates or updates service items in the Service Catalog. Normally any communication problem between Process Orchestrator and Service Catalog is not specific to network discovery. However, if creation of a service item fails, it may cause the Network Discovery module database and Service Catalog become out of sync. Best way to fix this is to clean up the Network Discovery module database (restart Network Discovery module as the DB is currently not persistent), and then perform full re-discovery once the communication problem has been fixed. Missing service items will be created, and existing ones will be updated with the latest information from the network.
If restarting Network Discovery module is not possible:
Perform full re-discovery of the network.
Call http://<management_appliance>:8080/xmp-disc/disc/resync-topo in a browser. All topological links in the Network Discovery module repository will be re-sent to the Process Orchestrator, and then to the Service Catalog.
If no devices have been discovered
Check the existence discovery log file $XMP_HOME/instances/instance1/logs/existenceDiscovery.log for errors.
Check the directory $XMP_HOME/discovery/output:
devices.xml – all successfully discovered devices along with matching credentials and other information.
unreachable.xml – list all devices an attempt to discover has been made but failed. Check for failure reasons (<filterReason>).
Every time existence discovery runs, a temporary configuration file is created in $XMP_HOME/discovery/conf/upload. Make sure the directory exists and is writable. Check configuration files in this directory to verify that the network discovery configuration and input arguments are correct (see “Make sure the input parameters are correct”).
Check the discovery configuration files in $XMP_HOME/discovery/conf. The template files must match the ones in the IAC source repository.
The snmpwalk utility on Mac or Linux can be used to check validity of SNMP credentials before running automated discovery.
e.g. SNMP v2c: snmpwalk -v 3 -l authPriv -u snmpadmin -a MD5 -A $PASSWORD -x AES128 -X $PASSWORD 10.10.10.10 18.104.22.168.22.214.171.124
e.g. SNMP v3: snmpwalk -v 3 -l authPriv -u admin -a MD5 -A $PASSWORD -x DES -X $PASSWORD 10.10.10.10 126.96.36.199.188.8.131.52
Network discovery based on neighbor discovery requires CDP or LLDP to be enabled on all devices you wish to discover, otherwise only a seed device will be discovered.
Ping sweep discovery requires ICMP:
Make sure ICMP is enabled and the devices are pingable.
Make sure that the IAC user on the management appliance has permissions to execute the fping utilities in $XMP_HOME/discovery/bin.
Inventory Discovery: If additional inventory information (device type, series, etc.) cannot be pulled out from a discovered device:
Make sure a device package for the target device type is installed. See $XMP_HOME/instances/instance1/logs/devicePackageLoader.log for the list of installed packages.
Check $XMP_HOME/instances/instance1/logs/inventory.log for errors.
Make sure that $XMP_HOME/conf/mdfdata.xml contains an entry for each device type.
Verify that the device is accessible via SSH, and via SNMP either v2c or v3, and the credentials are correct.
Keep in mind that in certain cases it is normal that a device has been discovered, but its inventory has been not. This usually means that the device is not supported yet, i.e. no device package is available/installed for the device type. It may also mean that the device is partially reachable.
If INFO log is enabled (default configuration), and a device inventory has been read successfully.
If additional inventory information can be found, the following line should be printed out at $XMP_HOME/instances/instance1/logs/iac/discovery.log:
e.g. [INFO] [XMPIceEventListener] Inventory collected for device 2010
In order for a topological link to be discovered, both its termination point devices must be discovered, and their inventories must have been successfully queried.
Make sure that either CDP or LLDP is enabled on the devices, and the information about neighbors via SNMP is working. One common issue is that SNMP may by out of sync, even "show cdp neighbours" may show correction information.