Overview

In simple terms, NeDi is an integrated toolkit for managing infrastructure devices like routers and switches. Whereas most of the components in GroundWork Monitor are designed for the purpose of monitoring the devices on a network (such as measuring the available resources on a host and then generating alarms when conditions require it), NeDi is designed to help administrators manage their infrastructure devices in particular (such as discovering and monitoring changes to the network topology, or manipulating the configuration of the network switches and routers).

More specifically, NeDi uses a variety of discovery technologies to locate the infrastructure devices across a network, then uses another set of technologies to probe and query the discovered devices for additional details, and finally stores the discovery data in a set of dynamic databases. From there, administrators can use the NeDi web interface to display information about the network devices and their relationships with each other, perform some basic management tasks, and be alerted to unexpected changes on the network. In addition, NeDi also provides configuration backup and editing tools and inventory management features which further contribute to the device management feature set.

This document discusses the basic configuration and operation of NeDi.

CONTENTS 1.0 Configuring the NeDi Package 2.0 Performing Common NeDi Tasks 3.0 Integrating NeDi Data with GroundWork Monitor

RELATED RESOURCES NeDi Website: https://www.nedi.ch/ Auto Discovery

WAS THIS PAGE HELPFUL? Leave Feedback

1.0 Configuring the NeDi Package

1.1 Managing User Access

The NeDi web pages are provided by a NMS-specific instance of Apache, although the NeDi web front-end is also integrated into GroundWork Monitor through the use of the JBoss Portal. As such, users who have been granted the appropriate role-based permission to access the NeDi object can do so by logging into GroundWork Monitor, and then choosing Advanced > Network Discovery.

Managing User Accounts

The GroundWork NMS NeDi package includes technology that automatically creates a user account in NeDi whenever that user first accesses NeDi through GroundWork Monitor. As such, user accounts do not need to be explicitly created in NeDi in order for users to access those pages.

If you wish to modify the user-specific details such as the password and full name, you must login to GroundWork Monitor with that user account, launch the NeDi application,  and select User > Profile. You will then be presented with a screen that shows the account details for the current user, similar to the following.
The email address and phone number fields are used for alerting operations and must be defined if this user will be receiving NeDi alerts.

Figure: User Profile

1.2 Configuring Discovery Methods

As stated earlier, NeDi uses a variety of discovery technologies to locate the infrastructure devices across a network. In general terms, NeDi first attempts to locate one or more starting devices, and then uses one of the specified discovery technologies to determine the neighboring devices. This approach allows NeDi to get up and running quickly, while also allowing it to build a fairly comprehensive map of the network.

The discovery process itself is performed by the /usr/local/groundwork/nms/applications/nedi/nedi.pl Perl script, with the desired discovery technologies being specified as command-line parameters to that script.

The discovery technologies that are supported by NeDi are as follows:

• Static Seedlists - If an administrator needs to manually specify one or more starting devices, they can be itemized in a seedlist file. The default seedlist file is /usr/local/groundwork/nms/applications/nedi/seedlist, although a different file can be specified as an argument to the -u command-line parameter if needed.
• Default Gateway - If a seedlist file is not defined or does not contain any entries, then NeDi attempts to locate the default gateway device for the current host, and uses that device's IP address as an implicit seedlist.
• Cisco Discovery Protocol (CDP) - CDP is a propriety discovery technology that was developed by Cisco to allow their devices to locate each other across a variety of layer-2 networks. As a result, CDP-enabled devices are aware of other CDP-enabled devices, and can provide a good initial map of the network if most or all of the devices on the network are CDP-enabled. CDP discovery is enabled with the -c command-line parameter.
• Link Layer Discovery Protocol (LLDP) - LLDP is a standardized layer-2 discovery technology that is managed by the IEEE. It is similar to CDP, but is implemented on a broader range of manufacturer's infrastructure devices. LLDP discovery is enabled with the -l command-line parameter.
• OUI Discovery - Once NeDi has located a device, it is able to use SNMP to query for the ARP table entries on that device. If the OUI discovery mechanism is enabled, NeDi will examine the ARP table for network hardware addresses that belong to some well-known networking equipment vendors, and then attempt to continue discovery with those systems. OUI discovery is enabled with the -o command-line parameter.
• Route Table Discovery - Once NeDi has located a device, it is able to use SNMP to query for the routing table on that device. If the route table discovery option is enabled, NeDi will attempt to continue discovery with the next-hop routers that are returned. Route table discovery is enabled with the  -r command-line parameter.

If you need to debug the discovery process, you can run the nedi.pl script directly and observe the results of different discovery technologies. However, the nedi.pl script should be executed under the nagios user account in order to ensure that the file and database permissions are not modified. Therefore, you must first login to the GroundWork server interactively, and then use the su nagios command to switch to the nagios user account before executing the script.

The GroundWork NMS NeDi package automatically adds the nedi.pl script to the nagios user account's private crontab file, and schedules it to run every four hours, with the CDP, LLDP and OUI discovery methods enabled (a separate crontab entry runs the script at midnight in order to create a backup of the running configurations, and is documented separately below). To modify this behavior, perform the following steps:

1. Login to the GroundWork server with root privileges.
2. From a command prompt, issue the crontab -u nagios -e command to edit the crontab file associated with the nagios account.
3. Locate the crontab entry for nedi.pl -clo, and modify it as necessary. If you change the scheduler time interval, you need to inform NeDi of the new interval so that the graphs show the correct time values. To do this, open the /usr/local/groundwork/nms/applications/nedi/nedi.conf file in a text editor, set the rrdstep value to the new value, and then save the file.
4. Save the crontab file and exit the editor. The cron daemon will automatically incorporate the new command-line parameters into its current schedule.

If you wish to manually define a seed device, you may either use the default /usr/local/groundwork/nms/applications/nedi/seedlist file, or you may define your own seedlist file(s). If you define your own, you must tell the nedi.pl discovery script about them by adding the -u parameter and a file path value to the crontab entry described above.

1.3 Setting the Default SNMP Community Strings

The SNMP community strings that are used by NeDi to probe newly discovered devices are defined by the comm entry in the /usr/local/groundwork/nms/applications/nedi/nedi.conf configuration file. Multiple comm entries can be defined, with one entry and value per line, each of which will be tried in successive order with every discovered device.

By default, the GroundWork NMS NeDi package defines the single community string value of public.

1.4 Setting the Default CLI Authentication Credentials

As mentioned earlier, some kinds of infrastructure device configuration information is retrieved by logging into the device and issuing commands through TELNET or SSH. In order for NeDi to perform this task successfully, the login credentials to use for authenticating to the device must be provided.

The authentication credentials to use are defined in the usr entry in /usr/local/groundwork/nms/applications/nedi/nedi.conf configuration file. Each usr entry contains between one and three fields: the first field specifies the username, the second field contains the access password, while the third field contains the enable password that is used with Cisco devices to grant additional access. Multiple usr entries can be defined, with one entry per line, each of which will be tried in successive order with every discovered device.

By default, the GroundWork NMS NeDi package does not define any usr entries.

1.5 Restricting Discovery by IP Address

The technologies that NeDi uses for local discovery can also discover devices that are outside of your network, and unless NeDi in constrained to specific network blocks it may even try to discover the entire Internet. The primary method of restricting NeDi's address discovery scope is with the netfilter entry in the /usr/local/groundwork/nms/applications/nedi/nedi.conf configuration file. The value for this entry is a regular expression that will be compared against discovered IP addresses, with NeDi discarding any IP addresses that do not match the regular expression.

For example, if you would like to restrict NeDi to IP addresses in the 192.168.1. network, you could define a netfilter entry with the value of ^192\.168\.1. Meanwhile, if you wanted to restrict NeDi to IP address in the 192.168.1. and 10...* networks, you could define a netfilter entry with the value of ^192\.168\.1|^10\.. Whenever an IP address was discovered that did not match the netfilter value, it would simply be discarded.

By default, the GroundWork NMS NeDi package defines the address filter of ., which matches any IP address.

1.6 Restricting Discovery by MAC Address

If you are using the OUI discovery method, you can restrict the hardware addresses that NeDi will use by editing the ouidev entry in the /usr/local/groundwork/nms/applications/nedi/nedi.conf configuration file. The value for this entry is a regular expression that will be compared against the friendly name of discovered hardware addresses, with NeDi discarding any hardware addresses that do not match the regular expression. The friendly names for hardware addresses are listed in the /usr/local/groundwork/nms/applications/nedi/inc/oui.txt file.

By default, the GroundWork NMS NeDi package defines the hardware filter of bay|nortel|netics|xylogics|foundry|XYLAN|Netgear|RUBY, which are some of the more common infrastructure platforms that may not otherwise be discovered.

1.7 Restricting Discovery by Device Type

Sometimes the technologies that NeDi uses for discovering network devices can also discover devices that are not infrastructure related (such as printers), which you may wish to ignore. The primary method of restricting NeDi's platform discovery scope is with the descfilter entry in the /usr/local/groundwork/nms/applications/nedi/nedi.conf configuration file. The value for this entry is a regular expression that will be compared against the SNMP description string of discovered devices, with NeDi discarding any devices that match the regular expression.

By default, the GroundWork NMS NeDi package defines the platform filter of LaserJet|JETDIRECT|HP-UX|Linux, which matches most of the printers and Unix platforms that may otherwise be detected as infrastructure equipment.

1.8 Managing Device Definitions

Whenever NeDi has discovered an infrastructure device, it will use a variety of secondary queries to obtain additional information about that device (this includes information such as the modules that are installed, the VLANs in use, and so forth). However, each vendor stores this information in different places, and in order for NeDi to know how to retrieve this data it must fist be able to determine the device type.

This is achieved by issuing an SNMP query for the device's System Object ID, and then matching the result against a collection of device definition files. Essentially, the device definition files tell NeDi about the features that should be available on a specific device, and also provides the information that NeDi needs to query for that data. This includes high-level data such as the device icon and operating system, management data such as the SNMP OID to query for CPU and memory utilization, and discrete data such as the SNMP OID to query for interface descriptions and VLAN identifiers.

With the GroundWork NMS NeDi package, the device definition files are stored in the /usr/local/groundwork/nms/applications/nedi/sysobj/ directory. Each device definition is managed in a separate file, with the file names being the known SNMP OID values. Over 150 device definition files are provided with NeDi, however this is not an exhaustive collection of every possible device, and you may need to create your own definition file in order to fully utilize an old or relatively obscure device.

If you wish to create your own device definition file, you can either copy an existing definition that is similar to the desired device (such as copying a similar HP ProCurve switch definition file to another SNMP OID filename) and edit the resulting file, or you can use the Web-based Defgen tool to build a new file from scratch.

To use the Defgen tool, mouse-over the Other menu at the top of the screen, and then click on the Defgen menu item. Once the form has been filled out to your satisfaction, click the Write button to automatically create a new device definition file.

2.0 Performing Common NeDi Tasks

As was discussed in the introduction, NeDi uses a variety of discovery technologies to locate the infrastructure devices across a network, then uses another set of technologies to probe and query the discovered devices for additional details, and then stores the discovery data in a set of dynamic databases which are then made available to administrators through the NeDi web interface.

A brief description of the most used web pages are provided in the remainder of this section. For more detailed discussion, refer to the [online NeDi documentation http://www.nedi.ch/documentation/.

2.1 Using the Search and Display Filters

Every NeDi web page that provides a list view will initially present a search filter dialog that allows the user to limit the amount of data returned in the list results, and which also allows you to specify the fields that you want to include in the search output. The specific search filter will differ for each field, but generally looks similar to the following.

Figure: Search and Display Filters

The default search filters do not filter anything, so if you do not want to limit the search results you can simply click the Show button at the right of the dialog, and all of the known entries for the current resource type will be returned.
If you do want to filter the results, the search filter dialog allows you to define two different filters (these are the Condition A and Condition B inputs shown above), which can also be combined in a number of ways (this is controlled by the Combination input). By default, the Condition A filter is empty (meaning that it matches all entries), and the Condition B filter is completely ignored (this is indicated by the Combination input which shows only Condition A).

Apart from the search filter criteria, the dialog box also contains a listbox of the known database fields for the current resource type, which allows the user to determine the fields that are returned.

2.2 Infrastructure Device List

NeDi provides a simple table view of the discovered infrastructure devices, which allows you to quickly survey the network infrastructure. To view this data, select Devices > List. A search screen similar to the one described in the Using the Search and Display Filters section above will be displayed, which allows you to define any filters you may want to apply. If you want to view all of the discovered infrastructure devices, simply click on the Show button to the right, which will cause the screen to be reloaded with all of the known devices listed in a new table below the search filter, similar to the following.

Figure: Device List

By default, NeDi displays the following data for each of the discovered infrastructure devices, (you can change the fields that are displayed by modifying the selected items in the Display filter input at the right of the search filter dialog box, if you wish):

• Device name and icon - The device name is determined from various lookup techniques, while the device icon is controlled by the device definition file that was chosen during the discovery process.

  The device icon is a hyperlink that will redirect you to the detailed web page for that device, as described in the next section.

• Main IP address - All routers and some switches typically have more than one IP address, and this field displays the device' primary address, as determined through a variety of algorithms. For some devices, the IP address will be a Telnet or SSH hyperlink that allows you to open an interactive terminal session with the primary address. The hyperlink is only available when the nedi.pl Perl script was able to successfully login to the device during discovery. However, the discovery script will only attempt to connect with the device if NeDi knows how to use the platform's command-line interface, so some devices will not have a hyperlink even though they support Telnet and/or SSH access.
• Serial number - The device serial number provides a unique tracking method for infrastructure devices, and allows you to determine if a device has been replaced with another similar unit.

  Some devices do not have unique serial numbers, and this field will be empty in that scenario.

• Device Type - Type of device discovered.
• Contact - This field shows the SNMP contact information that was discovered when the device was probed.
• First Discover - Date and Time device first discovered.
• Last Discover - Date and Time device last discovered.

2.3 Infrastructure Device Detail Data

NeDi provides a detailed view for each of the discovered infrastructure devices, which allows you to examine the configuration and operational aspects of the devices. To view this data, you can either click on a device' icon in the Device List web page (as was discussed in the preceding section), or you can select Devices > Status, and then choose the desired device from the drop-down list that is presented. A screen similar to the following will then be presented, with detailed information about the selected device.

Figure: Device Detail

The NeDi device status page displays a set of tables, each of which contain different types of data about the selected device.

The tables that are presented are as follows:

• Summary - This table contains information about the device itself, such as its main IP address, the operating system in use, the SNMP version in use, and so forth. If the device definition describes how to gather the relevant data, this table will also contain thumbnail charts for CPU and memory utilization, as well as the operating temperature, with the thumbnail charts being hyperlinked to full-sized versions of those same charts.

  The very top row in this table contains a set of icons, each of which are hyperlinked to specific functions. You can hold the mouse cursor over each of the icons to get balloon help for what the icon represents. Meanwhile, the IP address is a hyperlink that opens a Telnet or SSH terminal session with the target IP address (assuming that your Web browser is able to use the URLs). Also note that the SNMP and CLI fields may have clickable icons on the right, both of which allow you to retest the SNMP version and terminal emulation protocols that may be available on the device.

• Links - This table lists all of the known connections between this device and other infrastructure devices. These connections are automatically determined by NeDi during the discovery process, but static connections can also be created if needed (such as when a remote network is connected to the local network via PPP, and is not discoverable with the usual techniques). To browse through all of the known connections or to manage your own static connections, select the menu items Topology > Linked. You will then be presented with a Link Editor which allows you to view, create, and manage links between the known infrastructure devices.
• VLANs - If the selected device implements support for virtual LANs, and if the device definition file describes a way to retrieve VLAN configuration data via SNMP, then NeDi will report the configured VLANs and their friendly names.
• Interfaces - This table lists the interfaces that were discovered on the device, along with the supporting data was able to be retrieved. Most of this data is read from the standard SNMP OIDs for interfaces, but some of it is sourced from platform-specific SNMP OIDs that are listed in the device definition file.

  The interface icon background color indicates whether or not a specific interface is active (green), inactive (yellow), or disabled (red). Also note that the network addresses in the right-most column are hyperlinked, and redirect to a dynamic mapping page that allows the administrator to manipulate a visual representation of that network. To view the full list of all known interfaces, select the menu items Devices > Interfaces. You will then be presented with a search filter dialog screen, similar to the one described in the _Using the Search and Display Filters _section above.

As stated above, the data that is used to populate these tables mostly comes from SNMP queries, and depends on the capabilities of the selected device, as well as the completeness of the device definition file. In some cases, a device may not implement a specific technology (such as a low-end switch that does not implement VLANs), or there may not be any known method for retrieving the data via SNMP.

2.4 Node List

NeDi provides a simple table view of the network nodes that have been discovered, which allows you to quickly survey the network as a whole.

To view this data, select the menu items Nodes > List. A search screen similar to the one described in the Using the Search and Display Filters section above will be displayed, which allows you to define any filters you may want to apply. If you want to view all of the discovered network nodes, simply click on the Show button to the right, which will cause the screen to be reloaded with all of the known nodes listed in a new table below the search filter, similar to the following.

Figure: Node List

By default, NeDi displays the following data for each of the discovered nodes, (you can change the fields that are displayed by modifying the selected items in the Display filter input at the right of the search filter dialog box):

• Node name and icon - The name of the node is determined from various lookup techniques, while the node icon is determined by a hardware address mapping table that indicates the manufacturer who has been assigned that address.

  The node icon is a hyperlink that will redirect you to the detailed web page for that node, as described in the next section.

• Primary IP address - The IP address associated with the hardware address.

  The IP address is a hyperlink that will reload the node list with the selected IP address as a search filter, which allows the administrator to search for devices with duplicate addresses.

• First and Last - The date and time when the device was first added to the database without having since been expired from the database, and the date and time when traffic from the device was last detected.

  The brightness of the green background behind the First field reflects the amount of time since the device was first added.

• Device name and interface name - The name and interface of the infrastructure device that the node is attached to.

  The device name is a hyperlink that will reload the node list with the selected device as a search filter, while the interface name is a hyperlink that will reload the node list with the selected interface as a search filter.

• VLAN - The VLAN identifier for the target device.

  The VLAN ID is a hyperlink that will reload the node list with the selected VLAN ID as a search filter.

2.5 Node Detail Data

NeDi provides a detailed view for each of the discovered network nodes that allows an administrator to examine the operational aspects of the nodes.

To view this data, you can either click on a device' icon in the Device List web page (as was discussed in the preceding section), or you can select the menu items Nodes > Status, and then enter the hardware address into the edit field that is presented.

The NeDi node status page displays a set of tables, each of which contain different types of data about the selected node. This data is mostly collected from the infrastructure devices, although some parts of it are collected from the node itself. The tables that are presented are as follows:

• Summary - Overview information about the node itself, such as its hardware address, the hardware manufacturer that was assigned with that address, the primary IP address that corresponds with the hardware address, and so forth. Most of these fields are identical to the fields that are available in the node list page, as described in the preceding section.

  The very top row in this table contains a set of icons, each of which are hyperlinked to specific functions. You can hold the mouse cursor over each of the icons to get balloon help for what the icon represents. Also note that the NIC vendor field is a hyperlink that will query Google for the full business name and then redirect the Web browser to the first response.

• Service - These entries indicate whether or not the node is running a variety of common network services. The data in this table is populated by tests that are executed whenever the page is loaded. To view the full list of all known modules, select the menu items Devices > Modules. You will then be presented with a search filter dialog screen, similar to the one described in the Using the Search and Display Filters section above.
• Interface Traffic and Errors - The first graph shows the network utilization of the node, while the second graph shows the number of errors that were recorded. These values are retrieved from the upstream infrastructure device with SNMP queries
• IP Address Changes - If the node has changed to a different IP address since it was first seen, the recorded change(s) will be displayed in this table.
• Interface Changes - If the node has been moved to a different port or a different upstream infrastructure device since it was first seen, the recorded change(s) will be displayed in this table.

As stated earlier, this data is also available for the infrastructure devices that have been discovered. As such, you can use the node detail page to view the information about the switches and routers too.

3.0 Integrating NeDi Data with GroundWork Monitor

The GroundWork NMS NeDi package provides scripts and automation schema definitions that allow administrators to export the host definition data out of NeDi and import that data into the GroundWork Monitor Configuration database. This process can be performed manually or automatically, as the administrator sees fit.

3.1 Exporting Host Definitions from NeDi

Administrators have two options for exporting data out of NeDi. First, you can use the NeDi Export web page to manually create text files containing all of the data from a specific table. If you wish to use this method, mouse-over the Other menu at the top of the screen, and then click on the Export menu item. For more information on using this tool, click the life-preserver icon in the top right corner of the screen.

The second method for exporting data, and the one that is preferred, is to use the /usr/local/groundwork/nms/tools/automation/scripts/extract_nedi.pl Perl script included with the GroundWork NMS NeDi package, which exports data from the NeDi devices and nodes tables, and dumps the output into the /usr/local/groundwork/core/monarch/automation/data/nedi_data.txt text file. This script generates a file with the following fields, each of which are separated from their neighbors by a pair of semi-colon characters:

3.2 Importing Host Definitions into GroundWork Monitor

The GroundWork NMS NeDi package provides two different models for importing the contents of the nedi_data.txt text file into GroundWork Monitor's configuration subsystem, both of which are defined as schema templates for GroundWork Monitor's Auto-Discovery subsystem.

The first model is defined in the /usr/local/groundwork/core/monarch/automation/templates/schema-template-NeDi-host-import.xml schema template, and integrates NeDi devices and nodes into the configuration subsystem by either adding new host entries or modifying existing host entries, depending on whether or not a host entry already exists in the configuration database for the device or node in question. If you wish to use this schema template, you must create an appropriate schema definition using the following steps:

1. Select Auto Discovery > Automation from the main GroundWork Monitor menu to manage the automation schema definitions.
2. Click the New Schema button to create a new schema definition.
3. For the Automation schema name field, enter the exact name of NeDi-host-import.
4. For the Create from template field, choose the NeDi-host-import template.
5. Click Add to finish creating the new schema definition.
6. From the schema editor screen, verify that the data file contains the output from the NeDi database tables by clicking the  View button in the Data source row, and then close the pop-up window when you are finished.
7. If you wish to process the records now, click the Process Records button at the top of the schema editor screen, otherwise click the Close button to return to the schema definition window.

The GroundWork NMS NeDi package also provides the /usr/local/groundwork/nms/tools/automation/scripts/auto_import_nedi_host.pl Perl script, which can be used to automate the import process. This script looks for a schema definition entry with the name of NeDi-host-import and then executes that schema definition automatically. However, this script does not automatically commit the changes to the configuration database, so the changes will not be recognized until they are manually committed.

The second import model in the GroundWork NMS NeDi package is defined in the /usr/local/groundwork/core/monarch/automation/templates/ schema-template-NeDi-parent-child-sync.xml schema template, which is designed to simply update the existing host entries with information about the host's parent device. If you wish to use this schema template, you must create an appropriate schema definition using the following steps:

1. Select Auto Discovery > Automation from the main GroundWork Monitor menu to manage the automation schema definitions.
2. Click the New Schema button to create a new schema definition.
3. For the Automation schema name field, enter the exact name of NeDi-parent-child-sync.
4. For the Create from template field, choose the NeDi-parent-child-sync template.
5. Click Add to finish creating the new schema definition.
6. From the schema editor screen, verify that the data file contains the output from the NeDi database tables by clicking the  View button in the Data source row, and then close the pop-up window when you are finished.
7. If you wish to process the records now, click the Process Records button at the top of the schema editor screen, otherwise click the Close button to return to the schema definition window.

The GroundWork NMS NeDi package also provides the /usr/local/groundwork/nms/tools/automation/scripts/auto_import_nedi_sync.pl Perl script which can be used to automate the synchronization process. This script looks for a schema definition entry with the name of NeDi-parent-child-sync and then executes that schema definition automatically. However, this script does not automatically commit the changes to the configuration database, so the changes will not be recognized until they are manually committed.