About NeDi

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.

Through the GroundWork NeDi connector in Cloud Hub and the NetFlow and Capture containers that come standard with GroundWork 8.x, NeDi can provide in-depth traffic graphing, alerts when specific traffic patterns are detected, and alerts when particular policies are violated, such as plugging in cameras or phones. 

This document reviews the basic configuration and operation of NeDi for discovery, and links you to how-tos for setting up the more advanced features and integration with the rest of GroundWork.

GroundWork ships the NeDi application with no access to the database snapshot interface or many other useful (of advanced) modules. For an example of enabling a module, please see Docker Commands in the Advanced mode section referencing NeDi.

Also see The NeDi Guide.

Configuring NeDi

User Access

The Network Discovery web pages are provided by the NeDi web front-end. As such, users who have been granted the appropriate role-based permission to access NeDi can do so by logging into GroundWork Monitor, and selecting Configuration > Network Discovery. The NeDi package includes Single-Sign-On that automatically creates a user account in NeDi whenever a user first accesses NeDi through GroundWork Monitor. 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, but generally this is not required as alerts can be directed to the GroundWork application itself.

user access

Setting the Default SNMP Community Strings

The SNMP community strings and credentials used by NeDi to probe newly discovered devices are defined by the comm entry in the /usr/local/groundwork/config/nedi/nedi.conf configuration file.

The nedi.conf file uses a precise syntax with entries and values separated by a single TAB character, you must use this syntax when editing this 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. You can set these by editing the file directly using the procedure referred to above (see Docker Commands for an example), or more easily through the Setup screen:

  1. Go to Configuration > Network Discovery and select System > Setup.

  2. Under SNMP, you can add SNMP v1 V2c or V3 credentials by entering a Name , selecting a version, and clicking Add:
    snmp strings

  3. To add a V3 username and password, as well as the v3 apply password and auth scheme, use the Name, version selection, and Password, then the encryptions (aes or des) and the apply password. This can get confusing, so you may want to review the SNMP v3 standards for auth if you use this method. It is the most secure, and is recommended, but is often ignored in favor of the simpler v2c protocol. 

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

Some kinds of infrastructure device configuration information is retrieved by logging into the device and issuing commands through TELNET or SSH. The router backup and restore features of NeDi require this level of access. In order for NeDi to perform this task successfully, the login credentials to use for authenticating to the device must be provided.

Setting the Device CLI SSH Authentication Credentials

The authentication credentials to use are defined in the usr entry in /usr/local/groundwork/config/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, NeDi does not define any usr entries.

The user and enable credentials can be set most easily with the web interface:

  1. As above, go to Configuration > Network Discovery and select System > Setup.

  2. Under CLI, enter a User, the Password, and the Enable Password, and click Add. Repeat for as many users as necessary to allow access to all the devices you wish to manage with the system. 
    cli auth

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 comprehensive map of the network.

The discovery process itself is performed by the nedi.pl Perl script, with the desired discovery technologies being specified as command-line parameters to that script. These parameters can be added to an interactive discovery using the user interface, and optionally added to the cron job for regular discovery operations. 

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

  • Static Seedlist: 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/config/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 a device cannot be discovered with one of the specified discovery technologies, then it will not be discovered unless it is listed in the seedlist file. For example, some small routers do not support CDP or LLDP, and will not match the default OUI discovery either, so they must be specified in a seedlist file if they need to be discovered.

If you need to debug the discovery process, you can run the nedi.pl script directly from the user interface and observe the results of different discovery technologies. It is also possible to run it from the command line, using docker-compose exec. See Docker Commands for reference. 

You can also specify the -d and -v command-line parameters to the nedi.pl script in order to enable debug and verbose responses, if necessary.

NeDi discoveries with default settings are set in a cron job, and scheduled to run every hour, with the CDP and LLDP discovery methods enabled. To modify this behavior, perform the following steps:

Cron frequency of NeDi runs:

  1. Log in to your GroundWork server as the gwos user, and change to the gw8 directory: 

    cd gw8
    CODE
  2. Take a look at the current crontab: 

    docker-compose exec cron cat crontab
    CODE

    This should give you something like this: 

    SHELL=/bin/bash
    
    # NeDi
    5 * * * *	/src/run_docker_cmd.sh "monarch-data:/usr/local/groundwork/monarch/automation/data ulg:/usr/local/groundwork/config/" nedi 8.1.2-GA nedi/extract > /proc/1/fd/1 2> /proc/1/fd/2
    */5 * * * *	sleep 30; /src/run_docker_cmd.sh "nedi-rrd:/usr/local/nedi/rrd nfdump-var:/var/nfdump ulg:/usr/local/groundwork/config/" nedi 8.1.2-GA flowi > /proc/1/fd/1 2> /proc/1/fd/2
    0 0 * * *	/src/run_docker_cmd.sh "ulg:/usr/local/groundwork/config/" nedi 8.1.2-GA nodi > /proc/1/fd/1 2> /proc/1/fd/2
    */2 * * * *	/src/run_docker_cmd.sh "ulg:/usr/local/groundwork/config/" nedi 8.1.2-GA moni > /proc/1/fd/1 2> /proc/1/fd/2
    
    # RSTools
    * * * * *	/src/run_docker_cmd.sh "rstools-cache:/usr/local/rstools/var/cache ulg:/usr/local/groundwork/config/" rstools 8.1.2-GA checkStatePcntlFork > /proc/1/fd/1 2> /proc/1/fd/2
    * * * * *	/src/run_docker_cmd.sh "nagios-var:/usr/local/nagios/var nagios-etc:/usr/local/nagios/etc rstools-cache:/usr/local/rstools/var/cache ulg:/usr/local/groundwork/config/" rstools 8.1.2-GA downTimeProcess > /proc/1/fd/1 2> /proc/1/fd/2
    20 0 * * *	/src/run_docker_cmd.sh "rstools-cache:/usr/local/rstools/var/cache ulg:/usr/local/groundwork/config/" rstools 8.1.2-GA reportDatabase > /proc/1/fd/1 2> /proc/1/fd/2
    
    # Archive
    30 0 * * *	/src/run_docker_cmd.sh "archive-var:/usr/local/groundwork/archive/var ulg:/usr/local/groundwork/config/" archive 8.1.2-GA logArchiveSend  > /proc/1/fd/1 2> /proc/1/fd/2
    0 1 * * *	/src/run_docker_cmd.sh "archive-var:/usr/local/groundwork/archive/var ulg:/usr/local/groundwork/config/" archive 8.1.2-GA generateReportData > /proc/1/fd/1 2> /proc/1/fd/2

    We are concerned with the first line, the nedi/extract job. We need to modify this file every time the container starts to have our own cron schedule, for example twice a day at 6am and 6pm. In that case, we would like the first line to read: 

    0 6,18 * * *	/src/run_docker_cmd.sh "monarch-data:/usr/local/groundwork/monarch/automation/data ulg:/usr/local/groundwork/config/" nedi 8.1.2-GA nedi/extract > /proc/1/fd/1 2> /proc/1/fd/2
  3. To make this happen, you can use the sed command to edit the file automatically using an entrypoint command. Just edit the docker-compose.override.yml file and add the lines to the services: section: 

      cron:
        environment:
          - "ENTRYPOINT_CMD_15=sed -i '/nedi\\/extract/ s/5 \\* \\* \\* \\*/0 16,18 \\* \\* \\*/' crontab"

    Make sure to indent these properly in the services section and don't mix them in with the directives of any other service. The double backslashes are needed due to yaml file restrictions. 

    Any "ENTRYPOINT_CMD_{number} will be executed in order when the noted container starts. In this case, a sed script is run to modify the crontab to change the line we want. We use _15 just to stay away from any other commands that might be in the docker-compose.yml. 

  4. Restart GroundWork to make your changes effective: 

    docker-compose down
    CODE
    docker-compose up -d
    CODE
    • Any errors you make in the yaml file will inhibit restart, so be sure not to skip this step as a test. 

If you wish to manually define a seed device, you may either add it to the default /usr/local/groundwork/config/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.

Entries in the seedlist must contain an IP address or hostname of the seed device, and may also contain an explicit SNMP community string. If the SNMP community is not explicitly defined, the default SNMP community string(s) from nedi.conf will be used instead.

Restricting by IP Address

The technologies that NeDi uses for local discovery can also discover devices that are outside of your network, and unless NeDi is constrained to specific network blocks, it may even try to discover the entire Internet (though practically, it will almost always fail at the edge). The primary method of restricting NeDi's address discovery scope is with the netfilter entry in the /usr/local/groundwork/config/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 ^192\.168\.1. value. 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 ^192\.168\.1|^10\. value. Whenever an IP address is discovered that does not match the netfilter value, it will simply be discarded.

By default, the NeDi package defines the address filter of ".", which matches any IP 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/config/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/nedi/inc/oui.csv file. 

By default, the 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.

Restricting by MAC Address

Sometimes the technologies 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/config/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 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.

Including devices

Many modern small routers use Linux for their operating system, and the default filter string will automatically exclude those devices from discovery. If you have some of these devices and you wish to include them in your discovery process, you will need to remove the |Linux portion of the string (you may also need to include those devices in your static seedlist file in order for them to be discovered).

Restricting by Device Type

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

Managing Device Definitions

With NeDi, the device definition files are stored in the /usr/local/nedi/sysobj/ directory in the nedi container. 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 Defed module to build a new file from scratch.

To use the Defed module, you will first need to enable it by editing the nedi.conf file. See Docker Commands for an example of how to do this.  Then, go to the Other menu at the top of the Network Discovery screen, and then click on the Defed menu item. Once the form has been filled out to your satisfaction, click the Write button to automatically create a new device definition file.

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 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 NeDi documentation.

Each NeDi web page also provides built-in help which is accessible by clicking on the life preserver icon in the top right corner of the page.

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 you want to include in the search output. The specific search filter will differ for each field, but generally looks similar to the following.

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.

The default set of fields will be different for each resource type (infrastructure device searches return different fields by default than the VLAN search, for example).

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

infrastructure 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 numberThe 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.

  • ContactThis field shows the SNMP contact information that was discovered when the device was probed.

  • First DiscoverDate and Time device first discovered.

  • Last DiscoverDate and Time device last discovered.

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

device detail data

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

The contents of each table will vary according to the capabilities of the device and the associated definition file.

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

  • InterfacesThis table lists the interfaces 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 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.

Node List

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

This data is also provided for the infrastructure devices as well, thereby allowing you to view those devices' operational characteristics in the same way as the connected nodes.

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.

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.

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.

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. To view this data, you can either click on a node's icon in the Node 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.

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

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

Integrating NeDi Data with GroundWork Monitor

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

Exporting Host Definitions from NeDi

Administrators don't need to do anything to access the exported data from NeDi. This is done automatically with each discovery, and is always up-to-date.

GroundWork automatically exports data from the NeDi devices and nodes tables, and dumps the output into the /usr/local/groundwork/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:

Some fields are overloaded with multiple meanings, based on which NeDi table was used to populate the current row.

Field Name

Field Data

Notes

Name

Device or node name

The friendly name for the infrastructure device or node.

IP

Device or node IP address

The primary IP address associated for the infrastructure device or node.

Description

Device description

The description string for the infrastructure device.

OS/OUI

Device OS or Node OUI

The operating system in use on the infrastructure device, or the vendor name associated with the hardware address of the node.

Location

Device location

The SNMP location string for the infrastructure device.

Type

Device type

The model name of the infrastructure device.

Contact

Device contact

The SNMP contact string for the infrastructure device.

Device

Node parent device

The parent device for the current node.

Importing NeDi's Discovered Definitions

The NeDi package provides a method for importing the contents of the nedi_data.txt text file into the GroundWork Monitor configuration subsystem which is defined as a schema template for the GroundWork Monitor Automation subsystem.

The first model is the NeDi-host-import 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 Configuration > 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.

You can also monitor policies, devices and network traffic from NeDi and connect this monitoring to GroundWork using the NeDi Connector in Cloud Hub. 

Related Resources