Page tree

Contents

NetMRI discovery depends on a collection of under-the-hood features to ensure that polling and addition of devices in the network proceed smoothly and accurately. This chapter describes three critical tasks:

Defining Data Collection and Device Groups–You must define important settings for network polling. Emphasis in this topic area involves the processes of data collection and polling of devices across the network, including polling of switched Ethernet devices. Definition of device and interface groups is discussed in other topics later in this Guide. The topic Defining Group Data Collection Settings provides more information.


Note: See Creating Device Groups for information on the Groups tab and its associated functions.


Managing SNMP and CLI Credentials – Credentials are a critical component for discovery and Configuration Management. Define global default values for admin account logins and enable passwords, and also define admin account logins and enable passwords on individual devices. The topic Adding and Editing Device Credentials provides more information.

Debugging and Managing Collection Results – When data collection and polling stops for any reason, NetMRI provides methods for determining the cause of the failure and ways to fix it. See Debugging Issues in Discovery and Data Collection and Running Discovery Diagnostics for more information.

Defining Group Data Collection Settings


Note: Global data collection settings in this panel can be overridden by Device Group and Interface Group settings specified in the Groups tab portion of this page.


Group data collection settings (Settings icon –> Setup –> Collection and Groups) settings define global NetMRI settings for discovery and configuration management:

  • Polling networks during the discovery process and collecting configuration files from network devices;
  • Editing group rankings, adding or deleting groups;
  • Setting groups' discovery data collection settings.

Global tab settings in the Network Polling panel (Settings icon –> Setup –> Collection and Groups –> Global tab –> Network Polling side tab) provide system-level control over NetMRI's SNMP and discovery data collection operations.

  • Port Scanning: If enabled, NetMRI probes the TCP and UDP ports listed at Settings icon –> Setup –> Port List, to determine whether they are open. See the results of this scanning action at Network Explorer –> Summaries –> Ports for the entire network, and Device Viewer –> Device/Network Explorer –> Open Services for an individual network device.
    If Port Scanning is disabled, NetMRI attempts no port probes other than SNMP on any device. 
  • Fingerprinting: (Available in full NetMRI license) If enabled, NetMRI attempts to identify each network device based on the response characteristics of its TCP stack. This information is used to determine the device type. In the absence of SNMP access, fingerprinting is usually the only way to identify non-network devices. If disabled, devices accessible via SNMP are identified correctly; all other devices are assigned a device type of Unknown.
    Fingerprinting is disabled by default for network p olling. You must enable fingerprinting to use the Automation Change Manager's Rogue DHCP Detection feature.

Note: If you enable Configuration Collection (see below), NetMRI attempts Telnet and SSH access only on network devices.


  • SNMP Collection: If enabled, all data collectors start after this page is saved. If you disable SNMP collection in this tab (i.e., globally), data already collected by NetMRI remains available for viewing; no new data is added and no existing data is removed; this also disables group and device SNMP collection.
    SNMP Collection is disabled, for example, when NetMRI is used for offline assessments. By disabling SNMP Collection before removing NetMRI from the network, data can be examined later without any data expiring. SNMP collection can also be enabled/disabled for groups and devices.
    Performance Collection: If enabled, performance data such as CPU and memory statistics are collected.
    Use Vendor Community Strings: If enabled, NetMRI uses vendor default community strings when determining a device's community string. If disabled, NetMRI uses community strings with an Origination of User.
  • NetBIOS Scanning: Global setting to enable NetMRI to collect the NetBIOS name for endpoint devices in the network. Device groups also enable NetBIOS scanning. The device group setting is dependent on the global setting; without enabling the NetBIOS Scanning check box, scanning at the device group will not take place. This feature can be enabled only by users with SysAdmin privileges. This feature is globally disabled by default (and also for device groups) to prevent unexpected scanning of the network by a new collector.
  • Smart Subnet Ping Sweep (IPv4 only): Check box to enable subnet Ping sweeps on IPv4 networks, using a range of packets to detect the presence of a system on each IP in the specified range, using ports that are generally open across the network. Performs probes across ICMP Echo, ICMP Timestamp, TCP SYN to port 80, and TCP SYN to port 443. Subnet ping sweeps are used as a last resort in the discovery process. A subnet ping sweep is performed if NetMRI is unable to identify any network devices in a given subnet. Subnet ping sweeps are performed no more that once per day, and will stop on a given subnet once NetMRI discovers a network device and is able to collect data.
    Smart Subnet ping sweep is most useful for complete discovery of end-host network segments. Ping sweeps are a tool to aid in discovery, but most discovery operations take place through ARP tables and routing tables collected from infrastructure devices. Avoid using ping sweeps on a large number of discovery ranges, or discovery ranges that are too large (more than a /22 in size) as devices discovered through this method may expire from NetMRI's database before they are refreshed by another discovery cycle.

Note: Smart subnet ping sweeps should not be attempted on subnets larger than /22. Ping sweeps are not used on IPv6 networks because of the dramatically greater scale of network addresses in the IPv6 realm. Smart subnet ping sweeps also have several differences from the discovery ping sweeps that can be enabled under Discovery Settings, which can be found under Settings icon –> Setup –> Discovery Settings.


  • Refresh device caches before collecting switch port data: Check box to enable refreshing of ARP caches on switches and switch-routers in the managed network before NetMRI performs polling of switch ports. Enabling this feature will not produce an automatic ping sweep of the managed network. The benefit of this feature is that it enables more accurate detection of all endpoint devices on switches. Without ARP refresh, some endpoint devices may not be detected. This feature is globally disabled by default. With this setting globally enabled, individual device groups can also be set to enable or disable this feature.

Note: See the section Global Switch Port Management Polling Settings for more information on global settings for switch port polling.


  • ARP Collection Priority: (Available in full NetMRI license) Defines the collection method for collecting ARP databases from devices. When set to CLI with SNMP Fallback, NetMRI collects ARP data from devices with the CLI when NetMRI has the appropriate access credentials for the active network device. This mode of collection works only for Cisco devices, and will fall back to SNMP if CLI access does not work. SNMP data collection is used for active devices from all other vendors.
  • Route Collection Priority: (Available in full NetMRI product license) This setting controls which collection method is attempted first when collecting route tables. Should the Route Collection Priority setting be set to SNMP (default), you will also need to pay attention to the Route Limit setting under Advanced Settings (see NetMRI Advanced Settings). If NetMRI encounters a routing table with a table of entries beyond the Route Limit setting, SNMP collection for the current device will be stopped and CLI collection for the routing table will be tried instead. When set to CLI with SNMP Fallback, NetMRI will try to use CLI commands to collect route tables from devices instead of immediately using SNMP. The CLI option may reduce data collection performance problems for routers with large route tables.

Configuration Collection Settings

The Collection and Groups feature set also specifies the protocols allowed for configuration collection. You specify the Collectors of network data for NetMRI through the Config Manage ment section of the Global page (Settings icon –> Setup –> Collection and Groups –> Global –> Config Management).


Note: Disabling the Config Collection check box will disable configuration data collection for the current NetMRI appliance.


The protocols are listed as check boxes under Config Management:

  • Config Collection: If enabled, the current NetMRI virtual is able to collect configuration data from network devices using enabled protocols.
  • Config Locked — Devices with collected information that show changes during subsequent config collections can be reported as showing "Unauthorized Changes;"
  • Use Telnet Protocol — NetMRI opens Telnet terminal sessions with devices that support this option and reads the configurations. Individual devices can make use of Telnet login credentials;
  • Use SSH Protocol — NetMRI opens SSH terminal sessions with devices that support this option and reads the configurations. Individual devices can make use of SSH login credentials;
  • Use HTTP Protocol — NetMRI opens HTTP browser sessions with devices that support this option and reads the configurations. Individual devices can make use of HTTP login credentials;
  • Use Vendor Default Credentials — Enables NetMRI to use its library of vendor-default credentials as part of the process of collecting configuration data.

Note: See Adding and Editing Device Credentials for more information on adding logins for specific devices in the Device Viewer.


  • Script Execution: If enabled, Configuration Command Scripts or Perl scripts can be executed by NetMRI users with the correct privileges.
  • Vendor Default Credential Collection: If enabled, NetMRI will automatically check for default vendor credentials at the interval specified in Frequency (Daily or Weekly). Checking for vendor default credentials ensures that the network meets compliance standards.

Note: The topics under Configuration Management provide more information about configuration collection and related operations.

Global Switch Port Management Polling Settings


Note: For NetMRI appliances with a Switch Port Management license, polling offers some flexibility. For NetMRI installations, switchport connectivity polling rates remain at the default rate of 90 minutes, but this value can be changed. In all cases, you are limited to no fewer than 30 minutes per polling cycle.


NetMRI carries out Switch Port Management polling after discovering the relevant devices and adds them to a Switch Port Management device license count. NetMRI offers several polling options from the Settings icon –>Setup –> Collection and Groups –> Switch Port Management side tab:

  • Port Control Preference: You can specify SNMP or CLI as the polling protocol preferred by Switch Port Manager as the primary method of information gathering;
  • Periodic Polling: Define regular polling time periods;
    Choose a polling interval of 30 or more Minutes or in between1 and 24 Hours.
  • Scheduled Polling: Schedule recurrent polling based on hourly, daily, weekly or monthly time periods. Choosing this option, an Add New Schedule editor appears; click the Edit icon to make scheduling changes.
    Choose a Recurrence Pattern of Once, Hourly, Daily, Weekly or Monthly; in all cases you must choose an Execution Time.
  • Completely disable NetMRI from performing switch port polling by selecting Disable Switch Port Polling.
  • Click the Poll Now button to immediately begin polling all switch and switch-router devices in the managed network.

See Switch Port Management for more information on the use of switch device polling and related topics.


Note: See Creating Device Groups for information on the Groups tab and its associated functions.


Adding and Editing Device Credenti als


Note: SNMP and/or CLI Credentials can be specified within the Device Viewer for individual devices. Should such a credential not work for a given device, or if command-line access is lost for a given device, NetMRI will always re-guess credentials from the global credential list, including vendor defaults if available. See the sections Adding and Testing SNMP Credentials for a Device and Adding and Testing CLI Credentials for a Device for more information.


The Device Viewer offers dedicated CLI Credentials and SNMP Credentials pages (Settings icon –> Setup –> CLI Credentials and Settings icon –> Setup –> SNMP Credentials) to globally manage and test CLI and SNMP credentials. See About SNMP Credentials , About CLI Credentials and Credential Import Formats for further details about credential definition.

For all device credential tables, the Select check box is to the far left of the page. When you select multiple rows of a table, a whole page, or multiple pages of either data type, you can click Delete to remove multiple entries from the table. You cannot edit multiple rows of data; the Delete option is the only available option after selecting multiple rows.

Doing so enables you to delete all selected records from the table. Exercise caution when performing this action, as you may unintentionally delete rows of data that you did not wish to select.

Adding and Testing SNMP Credentials for a Device

The Device Viewer allows you to enter login credentials for a device in the network and test them. (The device must already be recognized in NetMRI through discovery.) Credentials can be specified for SNMP and for CLI.

To establish SNMP device credentials at the device level, do the following:

  1. Go to Network Explorer –> Inventory –> Devices and click a device IP, or to Network Explorer –> Discovery and click a device IP. The chosen device's Device Viewer appears.
  2. Click Settings and Status –> SNMP Credentials to open the page for creating SNMP login credentials.
  3. Click the Edit button to enable changes to the current settings for device-specific SNMP information.
  4. Click either Use SNMP v1/2c or Use SNMP v3. The options are mutually exclusive. If using SNMP v1/2c, enter the community string for the device.
    If using SNMP v3, enter the required authentication and privacy passwords and choose their encryption protocols from the Auth. Protocol and Privacy Protocol drop-downs.
  5. Click Test to try out the new credential. You can also click Show Password to verify that you've entered the correct values.

Note: When you click Show Password, the table of credentials for the selected device will display a new Password column.


For SNMP credentials, NetMRI tests against device-related OIDs such as sysUptime and sysDescr. The test is considered passed if these items are successfully polled. For SNMPv1/v2c tests, SNMP version 1 is used during the test.

A test example is shown below:

Test Starting

+++ Checking SNMPv1/v2c [public] ................. Credential passed

Discovered working credential for device after testing 1 credentials

Test Completed

6. Click Save to commit the changes.

Saved credentials can be deleted by clicking the Delete icon in the table row.

The lower pane is a history that lists all credentials attempted during the last credential guessing attempt for the given device. This data resets each time credentials are guessed for a device. The table indicates the time of each guess and the result of that attempt. If a device is manually configured with a credential, NetMRI updates the history once it attempts to use that credential for data collection.

Adding and Testing CLI Credentials for a Device

To establish CLI device credentials at the device level, do the following:

  1. Go to Network Explorer –> Inventory –> Devices and click a device IP, or to Network Explorer –> Discovery and click a device IP. The chosen device's Device Viewer appears.
  2. Click Settings and Status –> CLI Credentials to open the page for creating CLI login credentials.
  3. For CLI Credentials, you may supply up to three different login tuples: for SSH, for Telnet and for the HTTP protocol. You can also add Enable passwords. Enter the Username/Password (SSH Username and SSH Password, for example) for any or all three as required for the selected device.
  4. Click Test to try out the new credential. You can also click Show Password to verify that you've entered the correct values.

For CLI credentials, NetMRI attempts to log in to the device using both telnet and SSH with the credentials configured for each, including empty credentials. The test passes if the login is successful. The HTTP protocol is not used during the test.

A test example is shown below, indicating that no SSH credential is provided but a successful telnet login tuple was provided:

Test Starting

+++ SSH: Trying [] [] [] ........................... FAILED

+++ Telnet: Trying [qagroup] [qalogin] [] .......... OK

+++ Telnet: Credentials Successful [qagroup] [qalogin] []

+++ Discovered working credential for device after testing 1 credentials

Test Completed

5. Click Save to commit the changes.

Saved credentials can be deleted by clicking the Delete icon in the table row.

The lower pane is a history that lists all credentials attempted during the last credential guessing attempt for the given device. This data resets each time credentials are guessed for a device. The table indicates the time of each guess and the result of that attempt. If a device is manually configured with a credential, NetMRI updates the history once it attempts to use that credential for data collection.

Retrieving Configs

A Get Configs button appears in the CLI Credentials page of the Device Viewer, to fetch the current configuration files from the device. After clicking Get Configs, a message appears in the Device Viewer:

A request to retrieve the configs has been dispatched. If a change from the previous retrieval is detected, the new configs will appear shortly. Otherwise, the Last Collected timestamps of the previous retrieval are updated to reflect the current time, indicating that no change was detected.

This feature can be verified under Configuration Management –> Archive tab, and clicking the table row for the device. This brings up the Config Explorer for the selected device. A Get Config button is also provided in this location.

About SNMP Credentials

NetMRI uses SNMP read-only community strings to collect data for its analysis. NetMRI is pre-configured with several commonly used community strings taken from the list of default community strings configured by the device vendor. If the community strings provided during installation do not work for a given device, the system tries well-known vendor defaults. When NetMRI guesses SNMP credentials for a device, it starts with the most secure user-provided credentials (SNMP v3) and works down to the least secure (SNMP v1/v2) credentials when deciding how to access the device. In all cases, NetMRI follows the specified priority order.

If a default community string works for the device, NetMRI begins normal SNMP processing and the "Weak Community String" issue fires to alert you to this condition. You will see all vendor default community strings that were able to return SNMP data for a device in the Default Credentials Report.

Manually entered community strings are used first, in priority order, then the default community strings are tried in priority order if the Use Vendor Default Community Strings option is enabled in the Settings icon –> Setup section –> Collection and Groups –> Global tab –> Network Polling panel. That option allows you to disable use of the vendor default community strings for determination of which strings NetMRI can use. This is typically done in installations having tight security setups that have removed all vendor defaults from their installation. Note that this option does not prevent the vendor default from running.

NetMRI can periodically check for vendor default community strings. Checking for vendor default community strings can help insure that the network meets compliance standards. You can add vendor-specific default community strings that may not be listed. NetMRI will only check for default vendor community strings when the Vendor Default Credential Collection option is enabled in the Settings icon –> Setup –> Collection and Groups –> Global tab –> Config Management panel.

SNMP Collection Logi c

The following figure shows how SNMP collection settings control collection at the network, group and device levels.


Features for enabling and disabling SNMP collection are available in the following locations:

  • For the network: In the Network Polling panel (Settings icon –> Setup section –> Collection and Groups –> Global tab).
  • For groups: In the Device Groups side tab (Settings icon –> Setup section Collection and Groups page –> Groups tab–> Device Groups side tab).
  • For devices: In the Device Viewer's General Settings page (Device Viewer –> Settings & Status section –> General Settings page).

SNMP Data Collection and Licensing Effects

NetMRI guesses the SNMP credentials of all known network devices that are licensed or unlicensed in the included discovery ranges, and collects each SystemInfo table. The device host name and device type get resolved based on information from the SystemInfo table, enabling the identification of unlicensed network devices in NetMRI. If the device is unlicensed, SNMP collection stops at that point, excluding other data collection, such as Routing, ARP, and interfaces.

Choosing SNMP Protocol Preferences

NetMRI provides finer control for SNMP protocols used in device discovery and device management. NetMRI allows for discovery of devices using any of the three protocols SNMPv1, SNMPv2c or SNMPv3.

Community string collection can be performed using SNMPv1 and/or SNMPv2c only. In previous releases, SNMPv1 was the required default. You may choose to define the default SNMP data collection protocol as the following:

  • SNMPv1 only;
  • SNMPv2c only;
  • SNMPv2c as the default with SNMPv1 as a fallback for devices that support only SNMPv1.

NetMRI automatically discovers and manages devices that support only the SNMPv1 protocol, regardless of setting. To define how NetMRI applies its SNMPv1 and SNMPv2 support for data collection, two Advanced Settings can be changed.

  1. Go to Settings icon –> General Settings –> Advanced Settings –> Data Collection category. The SNMPv1 Data Collection Fallback setting prevents NetMRI from attempting to collect from a device that has a spurious or incorrect SNMPv2c credential, and will 'fall back' to SNMPv1 for collection.
  2. Click the Actions icon and choose Edit.
    1. If you want SNMPv1 to be allowed for data collection, choose enabled for data collection;
    2. If you want SNMPv2c to be the specific data collection protocol, choose disabled for data collection.
  3. Click OK to commit settings.
  4. Go to Settings icon –> General Settings –> Advanced Settings –> Discovery category. The SNMPv1/SNMPv2c Discovery Version setting allows a choice between three options:
    • Use SNMPv1 for credential discovery;
    • Use SNMPv2c for credential discovery;
    • Use both SNMPv1/SNMPv2c for credential discovery.

Should you choose the third option, Use both SNMPv1/SNMPv2c for credential discovery, NetMRI continues to use SNMPv1 for credential discovery on devices that support only SNMPv1, and uses SNMPv2c whenever it is supported by target devices. Using the Use both SNMPv1/SNMPv2c option imposes some time delay for credential collection, in cases where non-working/incorrect credentials are attempted during data collection.

5. Click the Actions icon and choose Edit.

    1. For exclusive use of SNMPv1, choose the Use SNMPv1 for credential discovery option;
    2. For exclusive use of SNMPv2c without fallback to SNMPv1, choose the Use SNMPv2c for credential discovery option;
    3. For default use of SNMPv2c with fallback to SNMPv1 for devices that support that protocol, choose the Use both SNMPv1 and SNMPv2c for credential discovery option.

6. Click OK to commit settings.

SNMPv3 Credentials for Discovery and Management

Unlike earlier versions of SNMP, accounts using SNMPv3 can use a standard suite of authentication and privacy protocols. If NetMRI will use SNMPv3 to collect data from devices supporting the protocol, you can define specific user credentials with combinations of authentication and protocol support, and the unique keys for each protocol. NetMRI also supports multiple entries for the same username string, enabling NetMRI to check similar SNMPv3 credentials that use different authentication and security protocols.

SNMPv3 allows for the use of two secret keys for every credential–one for authentication, and another for encryption. NetMRI allows flexible application of keys–authentication but no encryption, for example. You can define users in one of three ways:

  • SNMPv3 user, with no authentication or privacy credentials
  • SNMPv3 user, with authentication but no privacy credentials
  • SNMPv3 user, with both authentication and privacy credentials

You can test any SNMP credential against any currently discovered or catalogued device. You can also import sets of SNMPv3 credentials from a Microsoft Excel Comma Separated Values (.CSV) data file. The topic Credential Import Formats describes, with examples, the required data structure.

To add SNMPv3 credentials, do the following:

  1. Open Settings icon –> Credentials –> SNMPv3.
  2. Click New.
  3. To define the order of lookup, enter a new Priority value. The lower the value, the higher the priority of the user credential.
  4. Enter the Authentication Password and choose the Authentication Protocol.
  5. Enter the Privacy Password and choose the Privacy Protocol.
  6. Click Save.
  7. To test a credential, click Test. Choose the Hostname or IP and click Start.
  8. To import a set of credentials, click Import. The .CSV file should be a set of tab-separated values matching the categories for the SNMPv3 credentials table. You do not need the column headers as the first row in the file, which can be created in a text editor or exported from Microsoft Excel.

About CLI Credentials

The CLI tab (Settings icon –> Setup –> Credentials –> CLI tab) lists site-specific username and password combinations that NetMRI uses when attempting to access a device using telnet or SSH. After a device is discovered, NetMRI uses these for configuration collection, CCS scripts and other purposes.


Note: For CLI access to managed devices, NetMRI needs the ENABLE password to access configuration files on some devices, but does not need it for any other reason. Therefore, Infoblox recommends you create a username and password specifically for NetMRI, and restrict the commands that can be executed by that account to those required to display the configuration information.


The CLI Vendor Defaults tab (Settings icon –> Setup –> Credentials –> CLI Vendor Defaults tab) lists well-known (and therefore weak) username and password combinations. These credentials are a subset of the published vendor default username/passwords used when the device is shipped by the manufacturer.

Add other vendor default passwords listed in the Default Credentials Report. If the Vendor Default Credential Collector option (Settings icon –> Setup –> Collection and Groups –> Global tab –> Config Management panel) is enabled and a vendor default username/password combination successfully logs into a device, an issue is generated.

NetMRI will try site-specific username/passwords, in priority order, when first logging in to a device via a CLI connection (SSH or telnet). Once NetMRI determines a password, it will save it as information specific to the device. If there is no site-specific password, the system will try the vendor default credentials in priority order. NetMRI will always use site-specific username/password combinations when trying to determine the new login credentials for a device, and they will not be used for vendor default credential checks.

Credential Import Formats

The syntax for credential data files imported through corresponding tabs in the Settings icon –> Setup –> Credentials page, and in the Setup Wizard's Setup Wizard: CLI Credentials, Setup Wizard: SNMPv1/2 Credentials and Setup Wizard: SNMPv3 Credentials (Rare) steps, is described in this section.

For credential import, NetMRI accepts files exported from a credential settings table, ignoring any priority values in imported files. To specify a different collector in the import file, remove the UnitID column and update the Collector field. When importing credentials on an Operations Center, if no collector is specified in the import file, the credentials are applied to all collectors.

SNMP Credentials:

<community string>

SNMP Vendor Defaults:

<community string> <tab> <vendor name>

SNMPv3

SNMPv3 noAuthNoPriv credentials:

<snmpv3 user>

SNMPv3 authNoPriv credentials:

<snmpv3 user> <tab> <auth protocol> <tab> <auth password>

The authentication protocol is MD5 or SHA.

SNMPv3 authPriv credentials:

<snmpv3 user> <tab> <auth protocol> <tab> <auth password> <tab> <priv protocol> <tab>
<privacy password>

The privacy protocol is 3des, aes or des.
An example, with the second user being an authNoPriv credentials user:

dpadure   md5   test   3des   test

rgrace   sha   1authoEL2r#*$

johnson   md5   test   3des   test
All values are separated by hard tabs in the CSV file, which may be edited using a text editor.

CLI Credentials

<username> <tab> <password>

<username> can be empty for a line password credential.

or:

ENABLE <tab> <password>

Used for privileged mode passwords.

or:

<username>

For username only scenarios.

or:

<tab> <password>

For password-only scenarios.

CLI Vendor Default Credentials

<username> <tab> <password> <tab> <vendor>

username can be empty for a line password credential.

password can be empty.

ENABLE <tab> <password> <tab> <vendor>

Used for privileged mode passwords.

Expected Discovery Results

Outcomes of credential attempts are displayed in two columns:

  • The Successful column shows the number of devices where NetMRI attempted the credential and found that the credential worked.
  • The Invalid column shows the number of devices that have the given credential configured but is not currently working. (This is not the number of times the given credential was guessed but failed).

To display a list of devices for which a given credential was successful or valid: Click a link in the Successful or Invalid column. (The list is limited to 500 devices.)


Note: Operations Center only: Before changing settings in this page, use the Filter by Collector field in the right side of the header to select a Collector.


Debugging Issues in Discovery and Data Collection


Note: Juniper device discovery polling intervals occur hourly because such devices do not support the ccmHistory SNMP MIB object, which is limited to Cisco devices.


The CC column in the Network Explorer –> Discovery table reveals important debugging information for configuration collection issues. The most important discovery and Config Collection issues are listed in this topic, along with where in NetMRI to fix them.

Config Collection:

Warning icons in the CC column indicate possible configuration data  collection problems. Other locations that report related messages include Device Viewer –> Settings & Status –> Management Status and Settings
icon –> Setup –> Discovery Settings –> Seed Router. Specific messages are described below.

Config Not Changed

The configuration for the device has not changed since the previous polling of the device. No problem is indicated here unless you have pushed a changed configuration to the device. Even in those cases, allow some more time for the device to synchronize with NetMRI. If you expect changes to be reflected in device polling. go to Device Viewer–> Configuration Management–> Config Explorer and check the Running Config Saved? status line. If the answer is No, ensure the changes in the device's running-config are saved according to the device's configuration data saving requirements.

CLI Credentials Unknown

NetMRI cannot obtain the device configuration due to not having the correct CLI username/password tuple, and credential guessing did not work for the device. Go to the Device Viewer –> Settings & Status –> CLI Credentials page for that device. click Edit and enter the necessary values for the SSH and/or Telnet login tuple and the Enable Password if necessary. Each attempt at connection and collection is listed in the table. Note that the C column, for CLI Credentials Status, may show an Error, usually listed as Failed to authenticate: Invalid Username and/or password.

Configuration Collection Disabled Globally

This message appears for devices that support configuration collection, but the collection was skipped because Config Collection is globally disabled in NetMRI. The same message appears in the Device Viewer–> Settings & Status –> Management Status page. Go to Settings icon –> Setup –> Collection and Groups –> Groups –> Config Management side tab, and enable the Config Collection checkbox. Also ensure the proper protocols (SSH, Telnet, HTTP) are enabled for config collection.

Configuration Collection Enabled Globally, All Protocol Options Disabled

This message appears for devices that support configuration collection, but the collection was skipped because Config Collection is globally enabled in NetMRI but no data collection protocols were enabled. The same message appears in the Device Viewer–> Settings & Status –> Management Status page. Go to Settings icon –> Setup  –> Collection and Groups –> Groups –> Config Management side tab, and enable the Config Collection checkbox. Ensure the proper protocols (SSH, Telnet, and/or HTTP) are enabled for config collection.

Configuration Collection Disabled at Device Group level

The device showing this message currently has config collection disabled for the Device Group to which the device belongs. Go to Settings icon –> Setup –> Collection and Groups –> Groups, click the Action icon and choose Edit for the selected Device Group. In the Group Settings tab, enable the Config Collection checkbox.

Not Included by Discovery Settings

The message indicates that although the device has been detected by NetMRI, it is not included in any IP Ranges or as a Static IP with the Exclude from Discovery Settings option, is not reachable through Device Hints, or is not detectable as a Seed Router.
The device in question may also be explicitly excluded from management (by previously clicking the Unmanage button in Device Viewer –> Settings & Status –> Management Status page). Go to Settings icon –> Setup –> Discovery Settings and change the appropriate settings in any of the four categories. This message appears only during a manual Get Config operation.

Not LIcensed

The message indicates that the device has not been added automatically to the full NetMRI license for the appliance reporting the Issue. Go to the Device Viewer –> Settings & Status –> Management Status page and click the License button. In the License Status dialog, choose the settings necessary to change the licensing status for the device. This message appears only during a manual Get Config operation.

Running Discovery Diagnostics


Note: Output from this tool is typically used for Infoblox Technical Support. The tool should only be run after you have been instructed to do so by Infoblox Technical Support.


The Discovery Diagnostics tool (Tools –> Device –> Discovery Diagnostics) helps Infoblox Technical Support to diagnose discovery and data problems for a given device.
To run discovery diagnostics, do the following:

  1. If NetMRI doesn't know the community string for the device, enter it in the Community String field.

    Note: If NetMRI knows the community string for the device, it is used for the test. If you enter a community string, it is used in addition to the one known to NetMRI.

  2. Normally, leave the Force Tests option set to Off. (If NetMRI can't run the tests to provide the data needed, this option can be set to On to force the appliance to run all tests. Select the On option when directed by Infoblox Technical Support.)
  3. Click OK.
  4. When the test is finished, "Processing Completed" appears above the log.
  5. Click TEXT to save the log.
  6. Send the log to Infoblox Technical Support.

Discovery Settings Import Formats

The following sections detail the syntax for CIDR address block data files imported through corresponding tabs in the Discovery Settings page (see Configuring Network Discovery Settings) and in the Setup Wizard's Discovery Ranges, Static IPs and Seed Routers steps (see Running the Setup Wizard for more information). It also includes syntax guidelines for importing CISCO APIC information.

NetMRI will import a file previously exported from a discovery settings grid. Export files must have a header line, and each column is comma-separated.

Range Examples

Specifying a range includes up to five fields, separated by tabs or spaces:

<range_value> <range_type> <discovery_status> <ping_sweep_ind> <Virtual_Network_Name>

Values in each field:

<range_value>                     ipv4 or ipv6 prefix

<range_type>                      CIDR|RANGE|WILDCARD (constant)

<discovery_status>                INCLUDE|IGNORE|EXCLUDE (constant)

<ping_sweep_ind>                  TRUE|FALSE (constant)

<Virtual_Network_Name>             Virtual network name


In all examples, the CIDR, RANGE and WILDCARD keywords are optional.

INCLUDE, IGNORE and EXCLUDE are optional. If not specified, INCLUDE is assumed.

Examples:

10.1.1.1/24 CIDR EXCLUDE FALSE GREEN

10.1.1.1/24 INCLUDE TRUE GREEN

fe80:0:0:0:0:0:ac10:100/113 INCLUDE

fe80::ac10:1ff/128 EXCLUDE

10.1.1.1-10.1.1.255 RANGE EXCLUDE

172.16.1.1-172.16.1.255 EXCLUDE

fe80:0:0:0:0:0:ac10:100/113-fe80:0:0:0:0:0:ac10:1ff/128 RANGE EXCLUDE

fe80::ac10:100/113-fe80::ac10:1ff/128 RANGE EXCLUDE

Further examples:

10.1.1.* WILDCARD EXCLUDE
10.1.1.* EXCLUDE

Static IP Examples

Specifying a IP for discovery includes three fields, separated by tabs or spaces:

<range_value> <discovery_status> <Virtual_Network_Name>

Values in each field:

<range_value>                       ipv4 or ipv6 address

<discovery_status>                  INCLUDE|IGNORE|EXCLUDE (constant)

<Virtual_Network_Name>              Virtual network name

INCLUDE, IGNORE and EXCLUDE are optional. If not specified, INCLUDE is assumed.
Examples:

172.16.222.237 IGNORE Red
2001:db8:0:ef0:13::10 INCLUDE Green

Seed Router Examples

Specifying a seed router for discovery includes two fields, separated by tabs or spaces:

<range_value> <Virtual_Network_Name>

Values in each field:

<range_value>                                                    ipv4 or ipv6 address

<Virtual_Network_Name>                                   Virtual network name


Examples:

172.16.222.1 Red
2001:db8:0:ef0:13::1 Green

CISCO APIC Examples

Specifying an APIC for discovery includes five fields, separated by tabs or spaces:

<controller_address> <Virtual_Network_Name> <protocol> <apic_username> <apic_password>

Values in each field:

<controller_address>
APIC address (ipv4, ipv6, or hostname)
<Virtual_Network_Name>

Virtual network name

<protocol>
HTTP or HTTPS protocol for connection
<apic_username>
User name for APIC
<apic_password>
Password for APIC

Examples:

172.16.10.1 Network1 https apic_user apic_password

Executing NIOS IPAM Sync

Infoblox NIOS software, running on Infoblox appliances, delivers core network services—including DNS, DNSSEC, DHCP, IPAM, HTTP, FTP, TFTP, NTP and others—that are important to the operation of all IP-based networks. IP address management (IPAM) functionality is built in to Infoblox NIOS software and includes a comprehensive suite of functions that support address allocation, management, and reporting.

Use the Settings icon –> Setup –> NIOS IPAM Sync tab to configure NetMRI to populate the NIOS IPAM database with the IP network discovery data compiled by a NetMRI instance. During a run, device data (IP addresses and other data), subnets/DHCP networks or both are exported. A synchronization can be run immediately or scheduled for future times. For how to add, edit, and delete a sync configuration, see Configuring IPAM Sync. For how to synchronize IP address data between NetMRI and a new NIOS appliance, see Synchronizing Between NetMRI and NIOS Appliances.

NetMRI tracks the last time it has successfully communicated with a device via NMAP (used for fingerprinting), SNMP and telnet/SSH/HTTP. This timestamp information appears in the Network Explorer–> Discovery page. To provide the most accurate possible timestamp, the protocols used to generate the timestamps also includes ICMP Ping and NetBIOS communications protocols. This allows NetMRI to track the last time it communicated with a device across any related protocols. (Ping and NetBIOS data results are not directly displayed in the Network Explorer–> Discovery page.)

During IPAM Sync operations, NetMRI uses the maximum timestamp for a given device (i.e. across all protocols) to populate the timestamp value that is sent to the NIOS system. This is defined as the last_discovered_timestamp IPAM Sync data field.


Note: NetMRI supports synchronization of IPv6 subnet and address information between NetMRI and target NIOS systems, to automatically define networks in IPAM. Some subnetworks may not be reported to NIOS during IPAM Sync owing to their addressing being part of MPLS VPNs.


Keep in mind the following to get consistent results of synchronization between NetMRI and NIOS:

  • Network Views: Be aware of overlapping subnets and IP addresses. If you execute IPAM Sync several times, do not export different NetMRI network views to the same NIOS network view. Otherwise, some discovered data may be lost.
  • Device reachability: Once a device became unreachable, it remains visible in NetMRI for some time, but it will not be exported to NIOS. If you see the device in NetMRI, but not in NIOS, check the device interfaces and reachability. Some of the interfaces may become disconnected. Additionally, check if the corresponding device subnet is displayed in the list of subnets in NetMRI.

Also, see the following sections for additional information about NIOS IPAM Sync:

Configuring IPAM Sync

To add a sync configuration, do the following:

  1. Click Add Sync Configuration in the upper left corner. The Sync configuration wizard opens.
  2. In Step1 of the Wizard, enter the NIOS Grid Master IP address or host name, with user name and password. For standalone NIOS deployments, enter the IP address or host name of the NIOS device. The default login credentials are admin/infoblox.
  3. Click Next.

    Note: Make sure the NIOS system is reachable before attempting a connection, and ensure you have the correct admin account and password. The specified username and password also must provide access to the Infoblox DMAPI (Data and Management API). Any NIOS administrator account can be set to allow API access from within NIOS with an Allowed Interfaces setting of API. Consult the Infoblox API Documentation guide for the version of NIOS in the current operation for more details, and consult the NIOS Administration Guide for the procedure on defining API interface access for an admin account.


  4. In Step2, in NS1 Network View, select default as the view to which to export data. This information is obtained from the Infoblox Grid Master.
  5. In NetMRI Network View, select the required view.
  6. In Time restriction, select Include all data, regardless of polling time.

    In versions prior to 7.3.1, NetMRI sent data collected from devices that were successfully polled within the last two hours. This restriction was removed in version 7.3.1. You can request to export all data regardless of last successful device polling time or data from devices successfully polled in the last several hours.
  7. Activate Synchronize Device Information if devices (IP addresses) are to be included in the synchronization.
  8. If you enabled the synchronization of device information and you want to include end host IP addresses into NIOS IPAM Sync, select Include addresses from ARP tables.
    By default, only routers IP addresses are included into NIOS IPAM Sync. Selecting this option allows you to export IP addresses of end hosts from ARP tables of discovered devices to NIOS IP Map, along with routers IP addresses. These end hosts are listed in a separate tab in NetMRI: Network Explorer -> Switch Port Management -> End Hosts -> End Host Present. If the discovery engine does not recognize a device as infrastructure or network device, it is treated as end host. Data displayed for end hosts collected from ARP tables includes the IP address, MAC address, and Last Discovered and First Discovered stamps.

    Note: Retrieving end hosts IPs based on ARP entries does not guarantee accurate results as the lifetime of ARP tables entries on network devices is very limited (e.g., up to 5 minutes officially, 10 minutes in real life for Cisco IOS-based devices) and the amount of tables entries is relatively small.


  9. To add internal subnets as networks in NIOS: activate the Add IPAM networks for subnets within NetMRI discovery ranges option. This will export subnets discovered by NetMRI and classified as internal (i.e., within the defined discovery ranges). To export all internal subnets, select the All option. To limit the exported internal subnets, select the Restrict to subnet s within the following summary routes option, and enter a list of summary routes. Separate each route with a comma, or put each on a new line. Subnets within a listed summary route are exported. For example, to export only the subnets in a class A 10 network, enter 10.0.0.0/8.
  10. To add external subnets as networks in NIOS: Activate the Add IPAM networks for subnets outside of NetMRI discovery ranges option. This will export subnets discovered by NetMRI and classified as external (i.e., outside the defined CIDR blocks). To export all external subnets, select the All option. To limit the exported external subnets, select the Restrict to subnets within the following summary routes option, and enter a list of summary routes as described above for internal subnets.
  11. Click Next.
  12. In Step 3, if you want to schedule synchronization, select Schedule Enabled. This is optional. If you do not schedule a synchronization, you can execute a synchronization at any time. For information, see the next section.
  13. Select a Recurrence PatternExecution Time, and day (this is the starting day for repetitive synchonizations).
  14. Click Next.
  15. In Step 4, review the sync configuration. Click < Previous if you need to change any settings.
  16. Click Finish.

For how to run a configured synchronization between NetMRI and a NIOS appliance, see the next section, Synchronizing Between NetMRI and NIOS Appliances.

To edit a sync configuration, do the following:

  1. In Settings –> Setup –> NIOS IPAM Sync, select Edit in the Actions column for the required sync configuration. This displays a summary of the current configuration.
  2. Click Edit.
    The Sync configuration wizard is started. See the procedure for addig a sync configuration above for the wizard steps.

To delete a sync configuration:

  1. In Settings –> Setup –> NIOS IPAM Sync, select Delete in the Actions column for the required sync configuration.
  2. Confirm the deletion.

Synchronizing Between NetMRI and NIOS Appliances

To configure IPAM synchronization settings prior to running a synchronization, see the previous section.

To run a synchronization between NetMRI and a NIOS appliance:

  1. In Settings –> Setup –> NIOS IPAM Sync, select Sync in the Actions column for the required sync configuration. 
  2. Click Yes to confirm.
    The IPv4 and IPv6 Networks are added to the NIOS appliance database. Also, the CSV import of discovered data is performed.
  3. Open the NIOS GUI and verify all the data are imported in the NIOS appliance.

Synchronization data that is populated after NetMRI connects to the NIOS appliance includes the following:

IPAM Sync Data Field

NetMRI (Model->Attribute)

Description

ip_address

Device->DeviceIPDotted

A valid IPv4 Address. Required.

mac_address

Device->DeviceMAC

A valid mac address. Must be lowercase. Optional.

last_discovered_timestamp

Device->DeviceTimestamp

Timestamp of last time the discoverer has seen the device. A UTC timestamp. Required.

first_discovered_timestamp

Device->DeviceFirstOccurrence

Timestamp of first time the discoverer has seen the device. A UTC timestamp. Optional

netbios_name

<none>

The NETBIOS name. String Type. Maximum size 15 characters. Optional.

os

Device->DeviceVersion

The OS of the ip. String Type. Maximum size 256 characters. Optional.

network_component_type

Device->DeviceType

The type of component connected to the ip. Eg Switch, Router, Other. Optional. String type. Max size 32.

network_component_name

Device->DeviceName

Name of component connected to the ip. Optional. String type. Max size 64.

network_component_ description

Device->DeviceSysDesc

Description of component connected to the ip. Optional. String type. Max size 256.

network_component_ip

Device->DeviceIPDotted

IP address of component connected to the ip. Optional. String type. IPv4 address format.

network_component_port_ number

Interface->SwitchPortNumber

Port number on the component connected to the ip. Optional. Unsigned integer type. Range 0 - 9999.

network_component_port_ name

Interface->ifName

Port name on the component connected to the ip. Optional. String type. Max size 64.

network_component_port _description

Interface->ifDescr

Description of the Port on the component connected to the ip. Optional. String type. Max size 256.

port_vlan_name

Vlan->VlanName

Name of the Vlan on the Port. Optional. String type. Max size 64.

port_vlan_description

<none>

Description of the port vlan. Optional. String type. Max size 256.

port_vlan_number

Vlan->VlanIndex

Port Vlan Number. Optional. Unsigned integer type. Range 0 - 9999.

port_speed

Interface->ifSpeed

Speed settings on the switch port. Optional. String type. Valid values are: 10M, 100M, 1G, 10G, 100G, Unknown.

port_duplex

Interface->ifDuplex

Duplex settings on the switch port. Optional. String type. Valid values are: Full, Half.

port_status

Interface->ifAdminStatus

Administratively up or down. Optional. String type. Valid values are: Up, Down, Unknown.

port_link_status

Interface->ifOperStatus

Connected or not. Optional. String type. Valid values are: Connected, Not Connected, Unknown.

discovered_name

Device->DeviceDNSName

DNS name of the ip. Optional. String Type. Max size 256.

Overlay/Overwrite Logic

The following overlay/overwrite logic applies to IPAM Sync:

  • Network sync: Newly-imported subnets are imported as “managed”.
    • If the imported subnet conflicts with an existing subnet, it is not accepted. The imported subnet can go into a container as long as there is no conflict.
    • If the subnet already exists, no changes are made.
    • If the subnet is in IPAM but not in NetMRI, it is left in IPAM.
  • IP address sync: New IP addresses are added and marked as “unmanaged”. If an IP address already exists, the field values is overwritten during the import.
    • Before NetMRI 7.1.4 and NIOS 8.1: If the IP address exists in IPAM but it is not in the import file, it is left in IPAM.
    • As of NetMRI 7.1.4 and NIOS 8.1: If the IP address exists in IPAM but it is not in the import file, its discovered data is cleared out. You can control the time that the IP address stays in the NetMRI database after it is no longer discovered under NetMRI. To do so, go to Setup -> General Settings -> Advanced Settings.

Delivering NetMRI Discovered Data to IPAM

Fields related to Cisco ACI data (tenant, bridge_domain, endpoint_groups) are specific for SND elements and controllers. Fields Wireless Access Point Name, IP, and SSID are related to the wireless access points to which a device is connected. Attached device information usually means neighbor switch or router to which a given device is directly connected. Only IP Address, MAC Address, Last Discovered, and First Discovered fields are filled for end hosts collected from ARP tables. VRF information is specified for corresponding interfaces of infrastructure devices.

The following table helps to locate places in NetMRI where the discovered data appears.

Discovered Data FieldWhere Exported Data Appears in NetMRI
IP AddressNetwork Explorer -> Discovery
Last Discovered
First Discovered
MAC AddressInterface Viewer
OSDevice Viewer
Discovered Name
Device Model
Device Vendor
Device LocationDevice Viewer -> Device/Network Explorer -> Device Identification
Device Contact
NetBIOS Name
Device OUI
Attached Device Data
Attached Device VendorFor attached device: Device Viewer
Attached Device Address
Attached Device Name
Attached Device Type
Attached Device Model

Attached Device Description

For attached device: Device Viewer -> Device/Network Explorer -> Device Identification
Attached Device Location
Attached Device Contact
Attached Device Port DescriptionFor attached device: Device Viewer -> Interface -> Configuration
Attached Device Port Name
Attached Device Port
Port Data
Port DuplexInterface Viewer
Port Link
Port Speed
Port Status
VLAN NameDevice Viewer -> Interfaces -> Configuration
VLAN ID
Cisco ACI Data
ACI tenantDevice Viewer -> ACI
ACI bridge domain
ACI endpoint groups
VRF and BGP Data
VRF NameDevice Viewer -> Router -> VRF table
VRF Description
VRF RD
BGP ASDevice Viewer -> Router -> BGP
Wireless Access Point Data
Wireless Access Point NameDevice Viewer -> Wireless

Wireless Access Point IP

Wireless Access Point SSID


Supporting Cisco Discovery Service

NetMRI automatically supports an Infoblox utility, Cisco Discovery Service, that enables network administrators to provide Cisco-validated reporting and analysis. NetMRI operates as a Cisco Discovery Service-enabled system supporting discovery of network systems for analysis and management. You can use the CDS Integration Tool as part of a new NetMRI installation, or use the tool to extract further insight and value from an existing deployment. Cisco Gold Partner status is required for effective use of the software utility.
NetMRI supports CDS API version 2.0 and uses a NetMRI device or virtual machine to inspect all aspects of a network's Cisco infrastructure to collect the following information:

  • The customer's inventory of Cisco network infrastructure devices
  • Partner identification
  • Customer identification

NetMRI uses secure network connections, including HTTPS, to protect information for transit to the Cisco CDS. Acting as the intermediary, the NetMRI also registers the Infoblox Partner + Customer combination with the Cisco Discovery Service.

The Cisco Discovery Service provides complete information about a network facility's Cisco network infrastructure devices, including the following:

  • NetMRI Asset Inventory: a list of all devices discovered by NetMRI.
  • Chassis Inventory: a list of all Cisco devices located in the network.
  • ISO 27002 reports on compliance with best practices guidelines for Sarbanes-Oxley, HIPAA, and GLBA compliance.
  • End-of-life milestones and migration recommendations thereof.
  • Identification of customer equipment producing PSIRT (Product Security Incident Response Team) alerts.
  • Identification of customer equipment with either valid or expired contracts.
  • Identification of customer equipment with Cisco Field Notices.
  • Payment Card Industry (PCI) compliance reports against the PCI data security standard.
  • Select Issue details from NetMRI.
  • Overall network health assessment.
  • Port Saturation Summary: report on switch port consumption.

Cisco Discovery Service uses a Release 6.3.1 (or better) NetMRI system to inspect the desired network and compile the information base after discovery. Compatible NetMRI appliances include the following:

  • Virtual NetMRI Appliance (VMWareTM compatible)
  • NetMRI 1102-A Appliance
  • NetMRI NT-4000 Appliance

The CDS is not operated by standard NetMRI administrators and is not configured for use in NetMRI. For more information about usage of CDS, contact your Infoblox representative.

  • No labels

This page has no comments.