H. Glossary

account

See user account.

active cluster node

The server currently running the NNMi processes in an application failover or high availability configuration.

address hint

See discovery hint.

application failover

An optional NNMi capability that transfers control of NNMi processes to a standby server when the currently active server fails. This feature, which must be configured by the user, utilizes JBoss clustering support.

ARP cache

The ARP (Address Resolution Protocol) cache is an operating system table that maps data link layer (OSI Layer 2) addresses to network layer (OSI Layer 3) addresses. Data link layer addresses are typically MAC addresses, while network layer addresses are typically IP addresses. In rule-based discovery, NNMi uses ARP cache entries on discovered nodes (as well as other techniques) to find additional nodes that can be checked against the current discovery rules.

auto-discovery

See rule-based discovery.

Causal Engine

NNMi technology that applies root cause analysis (RCA) to network symptoms, using a causality-based approach. Causal Engine RCA is triggered by certain occurrences, such as status polling, SNMP traps, and changes discovered as a result of certain incidents. Causal Engine uses RCA to examine the status of managed objects, clarifies conclusions related to these objects, and generates root cause incidents.

causality

Denotes the relationship between one event (the cause) and another event (the effect), which is the direct consequence (the result) of the first. NNMi uses causality analysis algorithms to analyze event cycles and identify solutions for resolving network issues.

cluster

In an NNMi context, a grouping of hardware and software, linked by high availability technology or by using JBoss clustering capabilities, that works together to ensure functional and data continuity if components overload or fail. The computers in a cluster are commonly connected to each other through high-speed LANs. Clusters are usually deployed to improve availability, performance, or both.

cluster member or node

In an NNMi context, a system within a high availability or JBoss cluster that has been or will be configured to support NNMi high availability or application failover.

community string

A password-like mechanism used in SNMPv1 and SNMPv2c implementations to authenticate SNMP queries to SNMP agents. The community string is passed in cleartext in SNMP packets, making it vulnerable to packet sniffing. SNMPv3 provides stronger security mechanisms for authentication.

conclusion

In NNMi, supporting detail generated and used by the Causal Engine that sheds further light on how the Causal Engine determined status and root cause incidents for a managed object.

console

See NNMi console.

controller

In NNMi application failover, a JGroups term for the cluster member that has the master cluster state. The controller is always the oldest member of the cluster.

discovery hint

An IP address found by NNMi using an SNMP ARP cache query; a CDP, EDP, or other discovery protocol query; or a ping sweep. NNMi further queries IP addresses found as discovery hints, then checks the results against the current discovery rules in rule-based discovery.

discovery process

The process by which NNMi gathers information about network nodes so they can be placed under management. Initial discovery runs as a two-phase process, returning device inventory information and then network connectivity information.

After initial discovery, the discovery process is ongoing. In list-based discovery, this means devices in the list of seeds will be updated if their configuration changes. In rule-based discovery, new devices will also be added if they match current discovery rules. Discovery can also be initiated on demand for a device or set of devices from the NNMi console or from the command line.

See also spiral discovery, rule-based discovery, and list-based discovery.

discovery rule

A range of user-defined IP addresses or system object IDs (object identifiers), or both, used to limit the rule-based discovery process. Discovery rules are configured in the Discovery Configuration portion of the NNMi console under Auto-Discovery Rules. See also rule-based discovery.

discovery seed

See seed.

episode

A term used in NNMi root cause analysis to refer to a specific connection duration, triggered by a primary failure, during which secondary failures are suppressed or are correlated under the primary failure.

fault polling

A key NNMi monitoring activity, in which NNMi issues ICMP pings, SNMP read-only queries of status MIBs, or both, for its managed interfaces, IP addresses, and SNMP agents to determine the state of each managed object. Users can customize the types of fault polling performed for different interface groups, node groups, and nodes under Monitoring Settings in the Configuration workspace of the NNMi console. Fault polling is a subset of state polling.

global manager

The NNMi management server in a global network management deployment that consolidates data from distributed NNMi regional manager servers. The global manager provides a unified view of topology and incidents across the entire environment. A global manager must have an NNMi Advanced license.

global network management

A distributed deployment of NNMi with one or more global managers consolidating data from one or more geographically distributed regional managers.

HA

See high availability (HA).

HA resource group

In modern high availability environments, such as Veritas Cluster Server, Symantec Cluster Server, and Microsoft Cluster Service, applications are represented as compounds of resources, such as the application itself, its shared file systems, and a virtual IP address. The resources consist of an HA resource group, which represents an application running in a cluster environment.

high availability (HA)

Used in this manual to refer to a hardware and software configuration that provides for uninterrupted service if part of the configuration fails. High availability (HA) means that the configuration has redundant components to keep applications running at all times even when a component fails. NNMi can be configured to support one of several commercially available HA solutions. See also application failover.

ICMP

See Internet Control Message Protocol (ICMP).

incident

In NNMi, a notification of an occurrence related to your network, displayed in NNMi console incident views and forms. NNMi includes a number of Incident Management and Incident Browsing views that enable users to filter incidents based on incident attributes. Most incident views display incidents generated directly by NNMi (sometimes called management events). NNMi also includes views for browsing incidents generated from SNMP traps and from NNM events.

interface

A logical connection terminal for utilizing various specifications and protocols used in networks.

interface group

One of NNMi's primary filtering techniques, where interfaces are grouped together to apply settings to a group or to filter visualizations by group. Interface groups can be used for any or all of the following: configuring monitoring, filtering table views, and customizing map views. See also node group.

Internet Control Message Protocol (ICMP)

One of the core protocols of the Internet protocol suite (TCP/IP). ICMP ping is used by NNMi together with SNMP queries for status polling.

L2

See Layer 2 (L2).

L3

See Layer 3 (L3).

Layer 2 (L2)

Refers to the data link layer of the Open Systems Interconnection (OSI) multilayered communication model. The data link layer moves data across physical links in the network. NNMi Layer 2 views provide information about the physical connectivity of devices.

Layer 3 (L3)

Refers to the network layer of the Open Systems Interconnection (OSI) multilayered communication model. The network layer is concerned with knowing the addresses of the neighboring nodes in the network, selecting routes, and quality of service. NNMi Layer 3 views provide information about connectivity from a routing perspective.

list-based discovery

A process, based on a list of seeds, that discovers and returns detailed network information only about the nodes that you specify as seeds. List-based discovery maintains a limited network inventory for specific queries and tasks. Contrast with rule-based discovery. See also discovery process and spiral discovery.

logical volume

A computer storage virtualization term referring to an arbitrarily sized space in a volume group that can be used as a separate file system or as a device swap space. Several of the high availability products supported by NNMi use logical volumes in their shared file systems.

Management Information Base (MIB)

In SNMP, the collection of data about the managed network, organized hierarchically. The data objects within the management information base refer to characteristics of managed devices. NNMi collects network management information by making SNMP queries to and receiving SNMP traps from managed nodes using MIB data objects (sometimes referred to as MIB objects, objects, or MIBs).

management server

The NNMi management server is the computer system on which the NNMi software is installed. The NNMi processes and services run on the NNMi management server. (Prior NNM revisions used the term NNM management station for this system.)

MIB

See Management Information Base (MIB).

NNM events

An NNMi term for events forwarded from previous generation NNM management stations to NNMi. NNMi provides incident views for browsing the incidents that NNMi generates from these forwarded events.

NNMi

Acronym referring to either Job Management Partner 1/Consolidated Management 2/Network Node Manager i or Job Management Partner 1/Consolidated Management 2/Network Node Manager i Advanced.

NNMi is a software product designed to aid network administration and to consolidate network management activities, including ongoing discovery of network nodes, monitoring for events, and network fault management. NNMi is accessed primarily from the NNMi console.

NNMi console

The NNMi user interface. Operators and administrators use the NNMi console for network management tasks.

NNMi management server

A computer system on which the NNMi software is installed and the NNMi processes and services are run.

NNMi Northbound interface

The NNMi functionality that forwards NNMi incidents as SNMPv2c traps to a Northbound application.

node

In the network context, a computer system or device (for example, printer, router, bridge) in a network. While nodes that are able to respond to SNMP queries provide NNMi with the most comprehensive management information, NNMi can also perform restricted management of non-SNMP nodes.

node group

One of NNMi's primary filtering techniques, where nodes are grouped together to apply settings to the group or to filter visualizations by group. Node groups can be used for any or all of the following: configuring monitoring, filtering table views, and customizing map views. See also interface group.

Northbound application

Any application that can receive and process SNMPv2c traps.

Northbound destination

An NNMi Northbound interface configuration that defines a connection to the trap-receiving component of a Northbound application and specifies the types of traps that NNMi sends to that Northbound application.

object identifier (OID)

In SNMP, a numerical sequence that identifies a management information base data object. An OID consists of numbers separated by dots in which each number represents a particular data object at that level of the MIB hierarchy. An OID is the numerical equivalent of an MIB object name; for example, the MIB object name iso.org.dod.internet.mgmt.mib-2.bgp.bgpTraps.bgpEstablished is equivalent to the OID 1.3.6.1.2.1.15.0.1.

OID

See object identifier (OID).

ovstart command

A command that starts the NNMi managed processes. Invoked at a command prompt. See the ovstart Reference Page.

ovstatus command

A command that reports the current status of the NNMi managed processes. Can be invoked from the NNMi console (by clicking Tools, and then NNMi Status) or at a command prompt. See the ovstatus Reference Page.

ovstop command

A command that stops the NNMi managed processes. Invoked at a command prompt. See the ovstop Reference Page.

Ping sweep

A network probe technique that sends ICMP ECHO requests to multiple IP addresses to determine which addresses are assigned to responsive nodes. When enabled in rule-based discovery, NNMi can use Ping sweep on configured IP address ranges to find additional nodes. Some network administrators block ICMP ECHO requests because Ping sweeps can be used in denial-of-service attacks.

port

In the context of network hardware, a connector for passing information into and out of a network device.

PostgreSQL

An open source relational database that NNMi uses by default to store information such as topology, incidents, and configuration information.

public key certificate

Used in network security and encryption, a file that incorporates a digital signature to bind together a public key with identity information. A certificate is used to verify that a public key belongs to an individual or organization. NNMi uses SSL certificates, which contain a public key and a private key, for authentication and encryption of client-server communication.

Quick Start Configuration Wizard

A wizard that runs automatically immediately after installation of NNMi has been completed. This wizard enables you to configure community strings for reading an SNMPv1 or SNMPv2c environment, to set up discovery for a limited range of nodes, and to create an administrator account.

RCA

See root cause analysis.

region

In NNMi, a grouping of devices for the purpose of configuring communication settings such as timeout values and access credentials.

regional manager

The NNMi management server in a global network management deployment that provides discovery, polling, and trap reception for devices, and that forwards information to the global manager.

role

See user role.

root cause analysis (RCA)

In NNMi, root cause analysis (RCA) refers to a class of problem-solving methods used by NNMi to determine root causes for network issues. In NNMi, the root cause is the actionable issue that will resolve associated problem symptoms if it is addressed. NNMi uses the identification of the root cause in two key ways: to notify the user of the actionable problem, and to suppress reporting of secondary problem symptoms until the root cause issue has been resolved. Determination of root cause might result in status changes for managed objects, generation of root cause incidents, or both.

An example of how NNMi uses RCA is the scenario in which a managed router fails, and managed nodes on the other side of the router from the NNMi management server can no longer respond to state polling queries. NNMi uses RCA to determine that the state polling failures are secondary problem symptoms. It reports the router failure as the root cause incident and refrains from reporting the problem symptoms for the downstream nodes until the router failure that is the root cause has been resolved.

root cause incident

An NNMi incident in which the Correlation Nature attribute is set to Root Cause. NNMi uses root cause analysis (RCA) to establish the root cause incident as the actionable issue that will resolve associated problem symptoms if it is addressed. See root cause analysis.

rule

See discovery rule.

rule-based discovery

Often called auto-discovery, NNMi can use rule-based discovery based on user-specified discovery rules to seek out nodes that NNMi needs to add to its database. NNMi looks for discovery hints in data from discovered nodes, and then checks those candidates against the specified discovery rules. You configure discovery rules in the Discovery Configuration area of the NNMi console under Auto-Discovery Rule. Contrast with list-based discovery.

seed

A network node that helps NNMi discover your network by acting as a starting point for the network discovery process. For example, a seed might be a core router in your management environment. Each seed is identified by an IP address or host name. Unless rule-based discovery has been configured, NNMi's discovery process is limited to list-based discovery of specified seeds.

seeded discovery

A process, based on seeds or seed files, that discovers and returns detailed layer-2 connection information only about the nodes that you specify as seeds. Seeded discovery maintains a limited network inventory for specific queries and tasks. Contrast with auto-discovery. See also spiral discovery.

Simple Network Management Protocol (SNMP)

A simple protocol operating at the application layer (Layer 7) of the OSI model, by which management information for a network element can be inspected or modified by remote users. SNMP is the predominant protocol used by NNMi to exchange network management information with agent processes on managed nodes. NNMi supports SNMPv1, SNMPv2, and SNMPv3, which are the three most common versions of SNMP.

SNMP

See Simple Network Management Protocol.

SNMP trap

Network management using polling (requests from an SNMP manager and responses from SNMP agents) is an SNMP design principle that promotes simplicity. However, the protocol does provide for communication of unsolicited messages from SNMP agents to the SNMP manager process (in this case, NNMi). Unsolicited agent messages are known as traps, and are generated by SNMP agents in response to internal state changes or fault conditions. NNMi generates incidents from received SNMP traps, displayed in the SNMP Traps incident browsing view.

SNMP trap storm

A large number of unsolicited SNMP agent messages, which can overwhelm an SNMP manager process (in this case, NNMi). You can configure an SNMP trap storm threshold in NNMi, using the nnmtrapconfig.ovpl command. NNMi blocks traps when incoming trap rates exceed the specified threshold rate, until the trap rates fall below the re-arm rate.

spiral discovery

NNMi's ongoing refinement of network topology information, which includes information about inventory, containment, relationships, and connectivity in networks managed by NNMi. See also discovery process, rule-based discovery, and list-based discovery.

state

NNMi generally uses the term state for self-reported managed object responses related to MIB II ifAdminStatus, MIB II ifOperStatus, performance, or availability. Contrast with status.

state polling

The directed monitoring performed by NNMi's State Poller, which uses ICMP ping and SNMP queries to retrieve fault, performance, component health, and availability data from managed objects. See also fault polling.

status

In NNMi, an attribute of a managed object that indicates its overall health. The status is calculated by the Causal Engine from the managed object's outstanding conclusions. Contrast with state.

sysObjectID

See system object ID.

system account

In NNMi, a special account provided for use during NNMi installation. After installation, the NNMi system account is used only for command-line security and recovery purposes. Contrast with user account.

system object ID

In NNMi, a specialized term for an SNMP object identifier that identifies a model or type of network element. The system object ID is part of a network element's MIB object, which is queried by NNMi from individual nodes during discovery. Examples of network element types that can be classified by their system object IDs include any member of the HP ProCurve switch family, an HP J8715A ProCurve Switch, and an HP SNMP agent for HP IPF systems. Other vendors' network elements can be likewise classified according to their system object IDs. A key use for the system object ID is in defining NNMi Device Profiles, which specify characteristics of network elements that can be deduced once a network element's type is known.

topology (network)

In communication networks, a schematic description of the arrangement of a network, including its nodes and connections.

trap

See SNMP trap.

trap-receiving component

The portion of a Northbound application that receives SNMP traps.

Some applications include a separately installable component that receives SNMP traps and forwards them to another component for processing. For any Northbound application that does not include such a component, trap-receiving component is synonymous with Northbound application.

unconnected interface

From NNMi's perspective, an unconnected interface is an interface that is not connected to any other device discovered by NNMi. By default, the only unconnected interfaces that NNMi monitors are those that have IP addresses are contained in nodes from the Routers node group.

user account

A means in NNMi of providing a user or group of users with access to NNMi. NNMi user accounts are set up in the NNMi console and implement predetermined user roles. See system account and user role.

user role

As part of setting up user access, the NNMi administrator assigns a pre-configured user role to each NNMi user account. User roles determine which user accounts can access the NNMi console, as well as which workspaces and actions are available to each user account. NNMi provides hierarchical user roles, which are predefined by the program and cannot be modified. Such roles include the following:

Administrator
Web service client
Operator level 2
Operator level 1
Guest