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 the three following critical tasks.

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

  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. You can define global default values for admin account logins, enable passwords, and also define admin account logins and enable passwords on individual devices. For more information, see  Adding and Editing Device Credentials.
• 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 Data Collection Techniques#bookmark177 and Running Discovery Diagnostics for more information.

Defining Group Data Collection Settings

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 polling . You must enable fingerprinting to use the Automation Change Manager's Rogue DHCP Detection feature.

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

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

• 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 Management  section of the Global page (Settings icon > Setup > Collection and Groups > Global > Config Management).

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.

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

Global Switch Port Management Polling Settings

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

Adding and Editing Device Credentials

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

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 panel 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, complete 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. Click Edit.
4. For CLI Credentials, you may supply up to three different login tuples: for SSH, Telnet, and for the HTTP protocol. Enter the username and password for any or all three as required for the selected device. For SSH and Telnet, you also provide a port number. You can use the default or custom ports.
5. Provide the Enable Password.
6. Click Test to try out the new credential. You can also click Show Password to verify that you have 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

7. Click Save to commit the changes.

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

The lower panel 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 the 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 ensure 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:

• 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.
   
   • If you want SNMPv1 to be allowed for data collection, choose enabled for data collection;
   • 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.
   • For exclusive use of SNMPv2c without fallback to SNMPv1, choose the Use SNMPv2c for credential discovery option.
   • 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 save your settings.

SNMPv3 Credentials for Discovery and Management

Accounts using SNMPv3 can use a 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 encyption protocol, and the unique keys for each protocol.

Currently, the SNMPv3 engine supports the following encryption (privacy) protocols:

• aes-128
• aes-192
• aes-192C (for Cisco devices only)
• aes-256
• aes-256C (for Cisco devices only)
• des
• 3des

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 cataloged 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, complete 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.

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, are 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 encyption (privacy) protocol is 3des, aes-128, aes-192, aes-192C, aes-256, aes-256C, 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 the following two columns:

• Successful: This column shows the number of devices where NetMRI attempted the credential and found that the credential worked.
• Invalid: This 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.

Debugging Issues in Discovery and Data Collection

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.

Running Discovery Diagnostics

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

   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.

2. Click OK.
3. When the test is finished, "Processing Completed" appears above the log.
4. Click TEXT to save the log.
5. 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 an 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>

<Virtual_Network_Name>

<protocol>

<apic_username>

<apic_password>

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.

You can configure a NetMRI instance to synchronize with the NIOS IPAM database and populate it with the NetMRI IP network discovery data. During a synchronization, device data (IP addresses and other data), subnets/DHCP networks, or both are exported from NetMRI to NIOS through a CSV file. You can run a synchronization immediately or schedule 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 in NetMRI. To provide the most accurate possible timestamp, the protocols used to generate the timestamps also includes ICMP Ping and NetBIOS communications protocols. Ping and NetBIOS data results are not directly displayed in the Network Explorer > Discovery page. NetMRI uses the maximum timestamp for a given device (i.e. across all protocols) to populate the timestamp value that is sent to NIOS.

For how to configure synchronization, see Configuring IPAM Sync. This section also lists IPAM Sync data fields that are exported from NetMRI to NIOS.

For how to execute a configured NIOS IPAM Sync, see Synchronizing Between NetMRI and NIOS Appliances.

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.

For additional information about NIOS IPAM Sync, see Overlay/Overwrite Logic

Configuring IPAM Sync

This section describes the following:

• How to add an IPAM Sync configuration.
• How to edit an IPAM Sync configuration.
• How to delete an IPAM Sync configuration.

To add a sync configuration, complete the following:

1. In Settings > Setup > NIOS IPAM Sync > Add Sync Configuration.
   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. 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 Step 2, 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 Pattern, Execution Time, and day (this is the starting day for repetitive synchronizations).
14. Click Next.
15. In Step 4, review the sync configuration. Click < Previous if you need to change any settings.
16. Click Finish.

Now you can run the configured synchronization between NetMRI and NIOS. For more information, see the next section, Synchronizing Between NetMRI and NIOS Appliances.

To edit a sync configuration, perform 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 adding a sync configuration above for the wizard steps.

To delete a sync configuration, complete the following:

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

Prerequisite: make sure that you added and configured an IPAM synchronization as described in the previous section.

To run a synchronization between NetMRI and a NIOS appliance, complete the following:

1. In Settings > Setup > NIOS IPAM Sync, select Sync in the Actions column for the required sync configuration. 
2. Click Yes to confirm.
   The CSV import of discovered data to NIOS is performed. The IPv4 and IPv6 networks are added to the NIOS appliance database.

Open the NIOS GUI and verify that all the data are imported in to NIOS.

The following table lists the data fields in the CSV file used for IPAM Sync:

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

Viewing IPAM Sync Discovered Data in NetMRI and NIOS

In NIOS, you can view the data discovered by NetMRI and synchronized using IPAM Sync as follows:

• IP addresses data: IPAM > select a network > IP List.
• Networks data: IPAM > Networks.

The following table helps to locate IPAM Sync discovered data in the NetMRI UI.

Fields related to Cisco ACI data (tenant, bridge_domain, endpoint_groups) are specific for SDN 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.

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 (VMWare^TM 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 the usage of CDS, contact your Infoblox representative.