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:

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.

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

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.

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

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 Management 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:

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

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:

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 Credentials

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 Logic

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:

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:

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:

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:

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:

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

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

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

3. In Step 2: select the NIOS NS1 Network View to which to export data. This information is obtained from the Infoblox Grid Master.

4. Select the NetMRI Network View.

5. Activate Synchronize Device Information if devices (IP addresses) are to be included in the synchronization.

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

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

8. Click Next. (Steps 9–11 are optional.)

9. To schedule synchronization, activate the Enabled option. This option applies only to the schedule. You can execute any synchronization, even ones without this option activated, at any time, by clicking Sync in the configuration list.

10. Select a Recurrence Pattern, Execution Time and Date (this is the start date for repetitive synchonizations).

11. Click Next.

12.  In Step 4, review the sync configuration. Click < Previous if you need to change any settings.

13. Click Finish.

To edit a sync configuration, do the following:

  1. Click Edit for the sync configuration. This displays a summary of the current configuration.
  2. Click Edit in the lower right corner. This starts the Sync configuration wizard (see above). To synchronize a grid master: Click Sync, then confirm the synchronization.

To delete a sync configuration: Click Delete, then confirm the deletion.

Synchronizing Between NetMRI and NIOS Appliances

To synchronize IP address data between NetMRI and a new NIOS appliance, do the following:

  1. Choose Settings icon –> Setup –> NIOS IPAM Sync.
  2. Click Add Sync Configuration.

  3. Add the IP address of the fresh NIOS appliance [the default login is admin/infoblox].

  4. Click Next and select the Network View as "default." Select all checkboxes and leave the 'all' options as the default.

  5. Click Next and disable the Schedule option.
  6. Click Next and save the configuration.
  7. Click the Sync Icon The IPv4 and IPv6 Networks will automatically be added to the NIOS appliance database and will also perform the CSV import of discovered data.
  8. 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.

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:

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:

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:

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.