Hp network Node Manager I Software (nnmi) Device Support Matrix Software Version: 25 Last Updated: May 25, 2015
Known Limitations General Discovery
Download 4.18 Mb.
|
- Navigate this page:
- State Poller Policy
- Layer 2 Connectivity
- Device-specific Issues
Known LimitationsGeneral DiscoveryInitial Seed -- You should seed discovery with core Router(s) that support SNMP to increase the speed at which Spiral Discovery finds Nodes in your network. Node is not automatically discovered -- If a node is not discovered automatically, it may be that it does not frequently communicate with Nodes which have been discovered (for instance, not in any ARP cache of discovered Nodes). For these Nodes, add them specifically as a Discovery Seed. Incorrect SNMP community string -- If a Node is discovered and listed as No IP Address reported by device -- Devices that do not report any IP Address information via SNMP (e.g., via MIB-2 ipAddrTable), are not automatically discovered by NNMi. These devices can be partially discovered by adding them specifically as Discovery Seeds; however, on-going spiral discovery is not possible. Contact your device vendor to request that the standard IP-MIB be supported by that device, or contact your HP support representative to request custom device support if the IP address information is available in another (i.e., vendor-specific) MIB. Missing Device Profile -- When a discovered Node is reported as a "Generic" model (i.e., ACME Generic Switch), an NNMi Device Profile that maps the device SNMP sysObjectID to associated Vendor, Family, Model and Category attributes in NNMi is missing. In cases where the device runs the same Device OS and reports same SNMP MIBs as other supported models from the device vendor, the actual NNMi content support for new device model is generally not affected. Usually, the only impairment is that the device does not get included in monitoring Node Groups that are defined by device category, vendor or model. It is also possible that the Node shape or Device Family icon displayed on the UI is not correct. As NNMi Administrator, missing Device Profiles can be defined using the Configuration: Device Profiles workspace in the NNMi console. Please also notify your HP support representative of the omission so that it can be included in a future release. Cisco Nexus 2000 series Fabric Extenders(FEX) Discovery -- As FEX is not a switch and not SNMP capable.A FEX functions only when connected to a Cisco Nexus 5K or 7K series and hence the FEX is discovered as a card module on the Cisco Nexus 5K or 7K series switches State Poller PolicyDuring Patch install or Uninstall the following Exception or similar StatePollerExceptions might occur: WARNING [StatePollerPolicyDataPopulator] An error occurred while creating the state poller policy: Venus CPU usage Performance Monitoring (44831). This policy will not be polled.: com.hp.ov.nms.statepoller.common.StatePollerException: Unable to find class for given class name: "com.hp.ov.nms.disco.deviceExtensibility.util.StringToNumericExpressionProcessor Resolution: The above problem is a timing issue with the policy loader. Problem can be resolved by restarting NNMi and the policies will be loaded correctly. Layer 2 ConnectivityDiscovery of Layer 2 Connections -- is only possible for devices that implement and report Layer 2 Discovery Protocols such as standard LLDP, Cisco CDP, Nortel SONMP, etc; or for Layer 2 Switches that report FDB (MAC neighbor forwarding database) information. Layer 2 connectivity for all other devices is generally dependent upon the NNMi support of the neighboring Layer 2 Switch. Other sources of Layer 2 connections in NNMi can be defined, where applicable, using IP Small Subnet Connection Rules or Cisco Un-numbered IP Interface Connection configuration for logically connected routers (and other devices) over point-to-point or WAN circuit-based links. Lastly, if no other source of Layer 2 connectivity information is available, the NNMi Connection Editor can be used to manually define the missing connections. Layer 2 Discovery Protocol Connections -- may be missing or inaccurate between neighboring devices that implement incompatible Layer 2 Discovery Protocols (e.g., Cisco CDP vs Nortel SONMP). In such cases, NNMi attempts to reconcile the connectivity based on available Layer 2 FDB information. Layer 2 Discovery Protocol Connections -- for devices that have both proprietary L2 Discovery Protocols(e.g., Cisco CDP) and standard LLDP enabled on different ports within the device may only report connections for the proprietary xDP protocol. In this case, discovery of the LLDP connections is dependent upon the NNMI Layer 2 support of the neighboring device. Layer 2 FDB-based Connections -- are discovered only for Layer 2 Switches that report MAC address Forwarding Data Base (FDB) information in standard BRIDGE-MIB, Q-BRIDGE MIB, or similar proprietary MIB. Furthermore, FDB-based discovery is dependent upon both (a) recent communication by the attached device on the relevant switch port (Switch FDB tables are transient), and (b) each interface on the attached device must have a unique MAC address (because MAC is the only remote interface identification reported by the Switch FDB). Link Aggregation -- discovery, monitoring and connectivity of Aggregate Links between devices is an NNMi Advanced only feature. You must have an i-Advanced license installed to enable this NNMi feature. Device-specific IssuesUpgrade Device OS/Software revision -- If you are running an old OS/software version on your device(s), upgrading to a newer version may improve the completeness of NNMi discovery and monitoring. Consult your device vendor for recommendations on the latest OS/software revision available and their SNMP MIB support. Cisco General Cisco IOS 12.4-8d (e.g., upgrade from 12.2-19) increases the number of VLANs reported to NNMi. Cisco devices with both LLDP and CDP enabled may only show CDP-based Layer 2 connections. See "Layer 2 Connectivity" limitations for details. In certain Cisco IOS Versions it has been reportedly found that the Entity MIB was partially implemented. Such cases will have unexpected behavior in NNMi such as partial discovery of the cards, ports and thereby the VLAN ports associated with these devices.(For instance this was seen in certain cases of Cisco 3700 series switches running Cisco IOS version 12.2) Cisco Nexus 5000 and 7000 The SNMP credentials (v1/v2c community or v3 user) configured in NNMi for the device must be mapped to the "network-admin" security group in the Nexus device configuration so that NNMi has SNMP read-access to the entire Nexus MIB. Nexus 7000 Virtual Device Context (VDC) are discovered and managed as independent Nodes in NNMi. However, the association of VDCs to the hosting (physical) Nexus switch is not depicted. VDC L2 connectivity based soley on FDB requires unique MAC address reporting in NX-OS 5.2 or later. Enable CDP or LLDP on the Nexus VDC running NX-OS 5.1.x or prior as workaround. Older NX-OS versions have limited SNMP MIB support that impairs associated NNMi support. NX-OS 5.0(2) or later required for proper discovery of Layer 2 connectivity. Nexus 5000 NX-OS 5.0(3)N2(1) required for proper Link Aggregation support involving Nexus FEX modules. NX-OS 5.2(6.16) and lower versions have limitations with MAC addresses of the interfaces changing upon every snmp polling of the ifPhyAddress. This might cause unexpected behavior in NNMi such as adding or removing the interfaces and discovering wrong L2 connections. Crossbeam C10 Crossbeam C10 running older firmware/software version(s) reports an incorrect SNMP SysObjectID (.1.3.6.1.4.6848.1.3.1.2), causing NNMi to not recognize the device. Basic NNMi Node/IP discovery & monitoring is performed; however, full NNMi support requires the C10 device software be updated to report the correct SysObjectID (.1.3.6.1.4.1.6848.1.3.1.2). Extreme XOS Extreme switches with both LLDP and EDP enabled may only show EDP-based Layer 2 connections. See "Layer 2 Connectivity" limitations for details. Foundry Routers Does not report Router Redundancy Group membership correctly when SNMP GetBULK is used to query the device. Workaround: Configure NNMi Communications Configuration to Disable GetBulk for these devices (globally or per node), then initiate Configuration Poll (or wait for next re-discovery cycle) on the affected devices. HP ProCurve ProCurve 9300 Series -- Firwmware 7.8.00a/8.0.01r does not report Router Redundancy Group membership correctly when SNMP GetBULK is used to query the device. Resolved in firmware rev 08.0.01w or later. See also workaround described for Foundry routers. Linux ucd-snmp snmpd agent To add connectivity, an SNMP Agent must support the interfaces group from MIB-II (.1.3.6.1.2.1.2.2.1). By default, the ucd-snmp Linux SNMP Agent (such as Nodes with Device Profile net-SNMPAgent5.1) does not return this tree. To enable, add: view systemview included .iso.org.dod.internet.mgmt.mib-2 fc to the /etc/snmp/snmpd.conf file. Restart the SNMP agent with: kill -HUP Juniper Juniper MX960 support require JUNOS 9.6 or later for LLDP-based discovery of Layer 2 connections. Juniper QFabric support requires JUNOS 12.2X50-D40 or later to resolve Juniper SNMP issue PR#840144. NNMi also requires Juniper NETCONF/XML (over SSH) to be configured on the Juniper QFabric Director and in NNMi Communications Configuration to supplement information obtained via SNMP. Both SNMP and NETCONF management information is necessary to provide complete discovery of the Juniper QFabric. Refer to Juniper's "NETCONF XML Management Protocol Guide" to enable & configure NETCONF on the QFabric system. Then configure the NETCONF (SSH) user/password credentials in NNMi using Communication Configuration Device Credentials tab for Specific-Node, Region or Default Settings. The entire Juniper QFabric system, which acts as a single distributed switch, is discovered and shown in NNMi as a single NNMi Node with each QFabric Node and Interconnect chassis reported under the Cards and Node Components tabs of the NNMi Node Details view. Internal QFabric connectivity is also discovered and listed in the Interfaces tab of the NNMi Node Details view and in NNMi L2 Connections Inventory views, but is not shown in L2 Neighbor Views (maps). Only "external" connectivity between the QFabric and other non-QFabric devices is shown in L2 Neighbor Views (maps). In Juniper JUNOS devices interfaces of ifType 53(propVirtual) are configured to achieve Layer 2 Switching (FDB, LLDP, LACP, etc()) instead of traditional physical interface. NNMi FDB L2 Discovery has a constraint that only physical interfaces will be included in FDB Layer 2 Connections. PropVirtual interfaces, in particular, are ignored for FDB Connection discovery. From NNM9.1 Patch5 onwards, to properly discover FDB Connections on Juniper JUNOS devices, ifType of logical interface is altered from propVirtual to the ifType of the underlying physical interface and the ifType of the underlying physical interface is altered to other(1) IfType. Juniper Netscreen devices that support NSRP protocol reports multiple interfaces (VSI) for the same member (VSD). NNMi has a constraint that only one interface can be discovered per member. Hence each VSI was discovered as member of the same group causing Multiple Primary incident to be generated. From NNM9.1 Patch5 onwards, each VSI is reported as a member of different group to avoid the "Multiple Primary" incidents. NetApp NetApp Filer Layer 2 connections to attached Switch may not be discovered or accurate because NetApp does not report unique MAC address on each network interface; especially in cases where NIC Teaming (aggregation) is enabled. See general Layer 2 Connectivity constraints for details. Nokia IPSO Firewalls Nokia IPSO 4.1 Build 022 or later required to correct memory utilization statistics (e.g., over 100%) reported by device. VMWare ESX/ESXi SNMP support, specific MIB support, or both should be enabled on the ESX/ESXi system. The SNMP support is disabled by default. Without SNMP enabled, NNMi cannot query the necessary MIBs to determine if the node is an ESX or ESXi system. Beginning with ESX Server 4.1, use the ESXi SNMP agent installed on the ESXi server. For ESXi 4.0 and older, use the Net-SNMP Agent for better results. For information about obtaining and installing the ESXi SNMP agent see http://www.vmware.com. For ESXi 5.1, IP Addresses are now reported by the ESXi server and discovered by NNMi For ESXi 5.0x (and ESXi 4.1 running ESXi agent), the ESXi SNMP agent does not report any IP Addresses; so only the discovery hint or seed IP Address is associated with the discovered ESXi Node. This can cause the management address and hostname to change over time. Therefore, while some amount of discovery and monitoring of such an ESXi server can be accomplished with NNMi, HP does not support full IP address management of the ESXi 5.0x and 4.x servers running the ESXi SNMP agent. HP recommends that ESXi server be updated to 5.1x or later to yield full IP Address discovery. Download 4.18 Mb. Share with your friends:
|