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.
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.
If Port Scanning is disabled, NetMRI attempts no port probes other than SNMP on any device.
Release 7.1.3Infoblox NetMRI Administrator Guide67
Fingerprinting is disabled by default for network polling. 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 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.
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.
Note: See the section Global Switch Port Management Polling Settings for more information on global settings for switch port polling.
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
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.
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:
Choose a polling interval of 30 or more Minutes or in between1 and 24 Hours.
Choose a Recurrence Pattern of Once, Hourly, Daily, Weekly or Monthly; in all cases you must choose an Execution Time.
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.
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.
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:
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.
\\
\\
*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 |
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.
To establish CLI device credentials at the device level, do the following:
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 |
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.
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:
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.
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.
The following figure shows how SNMP collection settings control collection at the network, group and device levels.
SNMP Collection for the entire network
Set in Settings icon –> Setup section –> Collectors and Groups –> Global tab -> Network Polling paneSNMP Collection for a device group
Set in Settings icon –> Setup section –> Collectors and Groups –> Groups tab -> Device Groups side tabSNMP Collection for a single device
Set in Settings & Status section –> General Settings pageIf collection is disabled
for the netwoorrkk...If collection is enabled for the netwoorrkk,
group collection is coonntrolled by...If collection is enabled
for the netwoorrkk but disabled for a group...If collection is enabled for the netwoorrkk and the
pareennt device group, device collection is coonntrolled by...If collection is enabled
for the netwoorrkk and the device group but disabled for a device...Data collection to this level is available for viewing. No new data is added; Group SNMP collection and individual device SNMP status settings are ignored.
No data collection takes place for any device in the group. Device SNMP status settings are ignored.
No SNMP data collection takes place for the device.
Features for enabling and disabling SNMP collection are available in the following locations:
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.
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.
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.
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:
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.
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.
<community string>
<community string> <tab> <vendor name>
SNMPv3
<snmpv3 user>
<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#*$ pjohnson md5 test 3des test
All values are separated by hard tabs in the CSV file, which may be edited using a text editor.
or:
or:
or:
<username> <tab> <password>
<username> can be empty for a line password credential.
ENABLE <tab> <password>
Used for privileged mode passwords.
<username>
For username only scenarios.
<tab> <password>
For password-only scenarios.
<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.
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.
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 |
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 |
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 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. |
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:
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.
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.
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
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
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
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:
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.
To edit a sync configuration, do the following:
To delete a sync configuration: Click Delete, then confirm the deletion.
To synchronize IP address data between NetMRI and a new NIOS appliance, do the following:
Add the IP address of the fresh NIOS appliance \[the default login is admin/infoblox\]. |
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 |
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. |
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.