GWNMS NeDi. About NeDi. Configuring the NeDi Package. Managing User Access. Managing User Accounts

Transcription

1 GWNMS NeDi This section reviews the GroundWork Monitor NMS NeDi. About NeDi NeDi is an open source toolkit for managing network infrastructure devices such as switches and routers, and is integrated into GroundWork Monitor as an optional component of the GroundWork Network Management Suite (NMS). When the GroundWork NMS NeDi package has been installed, a "NeDi" menu item will be present in the main drop-down menu. 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. For more detailed discussion, refer to the online NeDi setup documentation and the online NeDi GUI documentation. Configuring the NeDi Package The GroundWork NMS NeDi package is installed separately from GroundWork Monitor and other applications, and also has its own unique configuration process. 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 the "NeDi" entry from the main drop-down menu. However, NeDi also has its own separate user accounts and access controls, which are independent of the GroundWork Monitor controls. More specifically, NeDi only has a single predefined administrative user account, with the username of "admin" and the password of "admin". Furthermore, most of the built-in web pages are unrestricted, and do not require any authentication. If you want to restrict access to the NeDi web server or some of its web pages, you may need to create the appropriate user accounts and access controls within NeDi. This process is separate from the process of determining which users have access to the "NeDi" item in the GroundWork Monitor main menu. For information on configuring user access to the "NeDi" menu item, refer to the "Configuring Roles" section of the Administration documentation. 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. However, it may sometimes be necessary to manage the user accounts directly. To manage the NeDi user accounts, login to NeDi with administrative credentials, then mouse-over the "User" menu at the top of the screen, and then click on the "Accounts" menu item. You will then be presented with a screen that lists the currently defined user accounts, similar to the following:

2 To add a new user account, type the desired username into the "User" edit box in the upper right corner, and click on the "Add" button next to it. The current screen will be reloaded, with the new user at the bottom of the list. Once a user account has been created, the account can be associated with any of the pre-defined NeDi groups by clicking on the small icons in the "Groups" column. Refer to the Managing Access Controls section below for more information about NeDi groups. You can also reset a user's password by clicking the key icon to the right of the desired account. This will delete the user's current password, leaving it empty until it is reset by the user account in question. 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 from the GroundWork main menu, mouse-over the "User" menu at the top of the screen, and then click on the "Profile" menu item. You will then be presented with a screen that shows the account details for the current user, similar to the following: The address and phone number fields are used for some alerting operations, and must be defined if this user will be receiving NeDi alerts. If you want this user to be excluded from these activities, they must be removed from the associated groups, or the contact data must be removed. To delete a user account, return to the main user account page and click the red "X" icon to the right of the desired account. You will be prompted to confirm the deletion. Managing Access Controls NeDi access controls are essentially group-based activity filters. Users who belong to a specified group are automatically granted access to the Web pages associated with that group, and may also be included in some automated tasks that are tied to a group. For example, NeDi provides a device monitoring script that will issue and SMS messages to members of the "Monitoring" group whenever a critical event is detected. The pre-defined NeDi groups are as follows: Admin - Members of this group can access the menu items and Web pages that modify settings and devices. This includes the ability to add and delete user accounts, modify device monitoring controls, issue raw commands to infrastructure devices, and perform other potentially-destructive tasks. Network - Members of this group can access the Devices and Topology menus and related Web pages. Helpdesk - Members of this group can access the Nodes menu and related Web pages. Monitoring - Members of this group can access the Monitoring menu and related Web pages, and be notified whenever a critical event has been detected by a monitoring process. Manager - Members of this group can access the Reports menu and related Web pages. Other - Members of this group can access the Other menu and related Web pages. To modify the group memberships of an account, mouse-over the "User" menu at the top of the screen, and then click on the "Accounts" menu item. Once the list of currently defined user accounts has been displayed, click on the appropriate small icons in the "Groups" column to enable

3 and disable membership in the affected group. You can hold your mouse cursor over the icons to get balloon help for that group. If you wish to change the group that is allowed to use a specific module, you can do so by editing the nedi.conf configuration file, as discussed further ahead. 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 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 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 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. 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. 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

4 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. 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". 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 the nedi.conf file. 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. 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 the nedi.conf file. 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 * 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 * 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. 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 the nedi.conf file. 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.

5 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 the nedi.conf file. 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. 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). 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 the nedi.conf file. 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. The files created by Defgen are automatically stored in the /usr/local/groundwork/nms/applications/nedi/html/log/ directory, and the file must be copied to the /usr/local/groundwork/nms/applications/nedi/sysobj/ directory before it will be used by the nedi.pl discovery script. Also note that the nedi.pl discovery script reads the device definition files on every discovery run, so any changes you make will be automatically incorporated the next time the device is discovered. The files in this directory must be readable by the nagios user account in order for this to work properly. 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.

6 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 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: 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). 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, mouse-over the "Devices" menu at the top of the screen, and then click on the "List" menu item. 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: By default, NeDi displays the following data for each of the discovered infrastructure devices: 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.

7 that the device icon is a hyperlink that will redirect you to the detailed web page for that device, as described in the next section. Primary 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. Device serial number - The 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. Platform description - This field typically shows the model number of the device, although some devices do not provide this information. SNMP contact - This field shows the SNMP contact information that was discovered when the device was probed. 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. 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 mouse-over the "Devices" menu at the top of the screen, then click on the "Status" menu item, 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: 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

8 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. Modules - This table lists the hardware modules that were discovered on the device via SNMP queries, using an OID that is specified in the device definition file. Some high-end devices may have multiple hardware components, while some smaller devices may not show any modules. To view the full list of all known modules, click on the "Devices" menu at the top of the screen, and then click on the "Modules" menu item. 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. 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, click on the "Topology" menu at the top of the screen, and then click on the "Linked" menu item. 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, click on the "Devices" menu at the top of the screen, and then click on the "Interfaces" menu item. 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, 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 other nodes. To view this data, mouse-over the "Nodes" menu at the top of the screen, and then click on the "List" menu item. 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

9 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: By default, NeDi displays the following data for each of the discovered nodes: 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. 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. First Seen and Last Seen - 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 Seen field reflects the amount of time since the device was first added. 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 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.

10 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 other 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 mouse-over the "Nodes" menu at the top of the screen, then click on the "Status" menu item, and then enter the hardware address into the edit field that is presented. A screen similar to the following will then be presented, with detailed information about the selected node: 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, click on the "Devices" menu at the top of the screen, and then click on the "Modules" menu item. 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. 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.

11 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: 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. The extract_nedi.pl Perl script is automatically executed as part of the nagios user's crontab file immediately after the nedi.pl discovery script is executed (once every four hours, by default), which ensures that the output file always contains the most recent version of the discovery data. 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: Open the Auto Discovery application from the main GroundWork Monitor menu. Click the Automation menu item in the top menu bar to manage the automation schema definitions. Click the New Schema button to create a new schema definition. Give the new schema definition the exact name of "NeDi-host-import". Choose the "NeDi-host-import" template from the bottom drop-down box. Click the "Add" button to finish creating the new schema definition. 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. 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,

12 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: Open the Auto-Discovery application from the main GroundWork menu. Click the Automation menu item in the top menu bar to manage the automation schema definitions. Click the New Schema button to create a new schema definition. Give the new schema definition the exact name of "NeDi-parent-child-sync". Choose the "NeDi-parent-child-sync" template from the bottom drop-down box. Click the "Add" button to finish creating the new schema definition. 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. 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.