Node Form

The dynamically generated name assigned to this device.

The NNMi administrator configures how NNMi populates this attribute through two configuration settings: (1) The Node Name Resolution attributes in Discovery Configuration (full or short DNS name, full or short sysName, IP address). (2) The Name might be converted to all uppercase or all lowercase (depending on how the NNMi administrator configured settings in the nms-topology.properties file).

This name is used in table views and maps.

The fully-qualified hostname currently stored in the NNMi database for this device (according to any hostname resolution strategy currently in use in your network environment; for example, DNS). 

NNMi follows a set of rules to dynamically generate the value stored in the NNMi database for each Node's Hostname. Click here for details.

• If the Node supports SNMP, NNMi requests the Hostname using the IP Address of the associated SNMP agent (the Management Address attribute value on the Node form).

  When the NNMi administrator chooses Enable SNMP Address Rediscovery  in the Communication Configuration:

  • If the SNMP Agent does not respond, NNMi checks for another Management Address to request the Hostname, and the Hostname could change.
  • If the SNMP Agent associated with the node changes, the Management Address and Hostname could change.

  When the NNMi administrator disables Enable SNMP Address Rediscovery  in the Communication Configuration, when the current management address (SNMP agent) becomes unreachable, NNMi does not check for other potential management addresses.

• If the Node does not support SNMP, no Management Address is available. NNMi requests a Hostname starting with the lowest IP Address associated with the node (a Discovery Seed value or an IP address value gathered from a neighboring device). NNMi uses the first Hostname provided. The Hostname might change during a future discovery cycle.

NNMi administrators can use NNMi property file settings to change the way NNMi determines Hostname values:

• nms-topology.properties file settings:
  If DNS is the source of the Node's Hostname, there are three choices. By default NNMi uses the exact Hostname from your network configuration. It is possible to change NNMi behavior to convert Hostnames to all uppercase or all lowercase.
• nms-disco.properties file settings:
  The Hostname is either requested from the Node's lowest loopback interface IP address that resolves to a Hostname or requested from the Node's designated Management Address (SNMP agent address). With either choice, when no IP address resolves to a Hostname, the IP address itself becomes the Hostname.

IP address NNMi uses to communicate with this node through SNMP. This is the IP address of the device's SNMP agent.

When NNMi first discovers a node, the seed address (provided by the NNMi administrator) or discovered address (for non-seeded nodes) becomes the initial Management Address of the node. After NNMi builds an inventory of all IP addresses associated with the node, NNMi follows a set of rules to determine which address is the best choice as the node's Management Address. Click here for details.

(NNMi Advanced) The NNMi administrator specifies whether NNMi prefers IPv4 addresses, IPv6 addresses, or dual-stack (both) when selecting the Management Address.

1. NNMi ignores the following addresses when determining which Management Address is most appropriate:

   • Any address of an administratively-down interface.
   • Any address that is virtual (for example, VRRP).
   • Any IPv4 Anycast Rendezvous Point IP Address or IPv6 Anycast address.
   • Any address in the reserved loopback network range. IPv4 uses 127/24 (127.*.*.*) and IPv6 uses ::1.
   • Any IPv6 link-local address.
2. If the NNMi Administrator chooses Enable SNMP Address Rediscovery  in Communication Configuration, NNMi prefers the last-known Management Address (if any).

3. If the Management Address does not respond and the NNMi Administrator specifies Enable SNMP Address Rediscovery in Communication Configuration, NNMi uses the Communication Configuration settings for Management Address Selection. The NNMi Administrator chooses the order in which NNMi checks the following:

   • Seed IP / Management IP - If the NNMi Administrator configures a Seed, NNMi uses the Seed address (either a specified IP address or the DNS address associated with a specified hostname) only during initial Discovery. NNMi then requests the current Management Address (the address from which the node's SNMP Agent responds) and uses that IP address for all communication after initial discovery.
   • Lowest Loopback - If a node supports multiple loopback address, NNMi queries each loopback addresses, starting with the lowest number. NNMi uses the loopback address with the lowest number from which the SNMP agent responds (for example, 10.16.42.197 is a lower number than 10.16.197.42).
   • Highest Loopback - If a node supports multiple loopback address, NNMi queries each loopback addresses, starting with the highest number. NNMi uses the loopback address with the highest number from which the SNMP agent responds.
   • Interface Matching - The NNMi Administrator chooses which interface MIB variable NNMi queries to detect changes. NNMi can use the following MIB-II attribute values: ifIndex, ifName, ifDescr, ifAlias, or a combination of these (ifName or ifDescr, ifName or ifDescr or ifAlias). NNMi searches current database entries for information about the interface in this order: index, alias, name, and description. If multiple IP addresses are associated with the interface, NNMi starts by querying the lowest IP address and selects the first responding address in ascending order.
4. If no response, NNMi queries any remaining IP addresses in the node's IP address inventory, starting with the lowest number. NNMi uses the address with the lowest number from which the SNMP agent responds.

5. If no response, NNMi checks for any Mapped Address configured for one of the currently known addresses (see the Mapped Address column in the Custom IP Addresses view).

   The address represents a static Network Address Translation (NAT) pair's external IP address from the internal/external IP address pair. NNMi Administrators configure these pairs using the Overlapping IP Address Mapping form. NNMi uses this list of addresses starting with IPv4 from low to high, then IPv6 from low to high.

6. If no response, NNMi might be configured to repeat the sequence using SNMPv1, SNMPv2c, or SNMPv3 in the order specified by the NNMi administrator (Communication Configurations SNMP Minimum Security Level settings).
7. When all else fails, NNMi retains the last known Management Address (if any) and automatically changes the State of that SNMP Agent object to Critical.

This process is repeated during each Spiral Discovery cycle, and the Management Address can change. For example, NNMi's inventory of addresses for the node expands, or the current Management Address does not respond to SNMP queries due to network problems or node reconfiguration. The NNMi administrator can prevent changes to the management address using the Communication Configurations Enable SNMP Address Rediscovery  (disabled) or Preferred Management Address setting.

If this field shows unexpected results:

• Use the Actions → Polling → Configuration Poll command to gather the most current information about this node.

  You can also right-click any object in a table or map view to access the items available within the Actions menu.
• Check with your NNMi administrator. The NNMi administrator can configure a specific management address for this node in the Communication Configuration settings.

Overall status for the current node. NNMi follows the ISO standard for status classification. See the Node Form: Status Tab for more information. Possible values are:

  No Status

  Normal

  Disabled

  Unknown

  Warning

  Minor

  Major

  Critical

The status of all IP addresses and the SNMP associated with this node contribute to node status. For information about how the current status was determined, see the Conclusions tab. Status reflects the most serious outstanding conclusion. See Watch Status Colors for more information about possible status values.

(NNMi Advanced) If a Web Agent is associated and the node is a Virtual Machine, note that the following categories indirectly indicate the current condition of the hypervisorThe virtual machine manager in charge of delegating various aspects from a pool of resources to become virtual devices. The delegations might be static or dynamic, depending on the manufacture's implementation. The type of virtual machines being generated depends on the manufacturer's implementation.:

  Indicates that the hypervisor is Up

  Indicates that the hypervisor is Down

  Indicates a Null value in hypervisor state

(NNMi Advanced) NNMi displays this attribute only in Node forms of VMware virtual machines:

 Powered On – Indicates the device is turned on.

 Powered Off – Indicates the device is turned off.

 Suspended – Indicates the device is suspended.

The following values indicate NNMi could not gather the required data:

  Agent Error – Indicates an error was returned in response to the query.

  No Polling Policy - No polling policy exists for this monitored attribute.

  Not Polled - Indicates that this attribute is intentionally not polled, based on current Monitoring Configuration settings, current Communication Configuration settings, or because the parent Node is set to Not Managed or Out of Service. This object attribute might or might not have an associated polling policy.

  Not Provided — The device does not support providing information for this monitored attribute.

 Unavailable - The agent responded with a value outside the range of possible values or returned a null value.

  Unset – Currently not used by NNMi.

Indicates whether or not NNMi is currently monitoring the node. Possible values are:

  Managed – Indicates the node is managed by NNMi.

  Not Managed – Indicates the node is intentionally not managed. For example, the node might not be accessible because it is in a private network. NNMi does not update discovery information or monitor these nodes.

  Out of Service – Indicates a node is unavailable because it is out of service or participating in a Scheduled Node Outage. NNMi does not update discovery information or monitor these nodes. See the Outage History tab for more details.

NNMi administrators and Level 2 Operators can use the drop-down selection list to change the current setting. NNMi uses this setting in a variety of ways. See How NNMi Assigns the Management Mode to an Object.

(NNMi Advanced - Global Network Management feature) Any change to the Node's Management Mode setting is immediately sent from a Regional Manager (NNMi management server) to the Global Manager. (Changes to Management Mode for other objects are sent during the next Spiral Discovery cycle on the Regional Manager.)

Name of the device profile that determines how devices of this type are managed and the icon and background shape displayed on maps.

Click the  Lookup icon and select  Open to display the Device Profile Form for more information.

Security Group Mappings specify which User Groups have access a node. NNMi users see only those nodes assigned to their Security Group Mapping. You see a node and its associated incidents only if one of the User Groups to which you belong is mapped to that node's Security Group.

NNMi administrators assign each node to a Security Group. Each node is associated with only one Security Group. An NNMi administrator can use this attribute to change the Security Group for a node.

(NNMi Advanced) This attribute appears when you are viewing a node form for either:

• a partitioned virtual instance of another node
• a virtual machineA device that utilizes components from multiple physical devices. Depending on the manufacture's implementation, the virtual machine may be static or dynamic. (hosted by a hypervisorThe virtual machine manager in charge of delegating various aspects from a pool of resources to become virtual devices. The delegations might be static or dynamic, depending on the manufacture's implementation. The type of virtual machines being generated depends on the manufacturer's implementation.)

This attribute is the Name of the node hosting (providing) this virtual node. The value could be a DNS name, a MIB-II sysName, or an address (depending on how your NNMi administrator configured the discovery process).

Click the  Lookup icon and select Show Analysis or  Open to display more information about the host node.

• NNMi might discover the virtual machine before discovering the hypervisor.
• The hypervisor owning this virtual machine has recently changed. NNMi has not yet gathered details from the new hypervisor.

Tenants enable NNMi administrators to partition a network across multiple customers.

A Tenant is the top-level organization to which a Node belongs.

NNMi administrators can use this drop-down to change the Tenant assignment for a Node, or use the  Lookup icon and select  New to create a new Tenant. Use caution when changing the Tenant assignment, see Change Tenant Assignment for a Node.

Devices that belong to the Default Tenant can have Layer 2 Connections to any device in any Tenant. Devices within any Tenant other than Default Tenant can have Layer 2 Connections only to devices within the same Tenant or the Default Tenant.

(NNMi Advanced) This attribute only appears if the Global Network Management feature is enabled and you are using a Global Manager. See NNMi's Global Network Management Feature (NNMi Advanced) for more information.

Local = The NNMi management server you are currently signed into.

<name> = The name your NNMi administrator assigned to a Regional Manager (NNMi management server). If you see a <name> value, it means that you are currently signed into a Global Manager, and other NNMi management servers report to this NNMi management server.

Current discovery status for the node. Possible values are:

Newly Created – Indicates the node's hostname and associated IP addresses are in the NNMi database, but NNMi needs to collect more information before determining state, status, and connectivity to other devices in your network environment.

Discovery Completed – Indicates that NNMi collected all of the required information about the node.

Rediscovery in Process – Indicates NNMi is updating information about the node.

(NNMi Advanced - Global Network Management feature) The text you enter here is not sent from a Regional Manager (NNMi management server) to the Global Manager. NNMi administrators for the Global Manager can add notes that are stored in the NNMi database on the Global Manager.

Provided for network operators to use for any additional notes required to further explain the node. Information might include why the node is important, if applicable, or to what customer, department, or service the node is related. Additional information might include where the nodes is located, who is responsible for it, and its serial number. You might also track maintenance history using this attribute.

Type a maximum of 1024 characters. Alpha-numeric, spaces, and special characters (~ ! @ # $ % ^ & * ( ) _+ -) are permitted.

The MIB II sysName value returned from the device's SNMP agent. This attribute is set by the device administrator.

If sysName is part of the strategy used to populate the node Name attribute value, NNMi avoids populating the NNMi database with multiple devices having the same manufacturer's default name by following a set of rules. Click here for details.

For each device type, NNMi has a Device Profile that includes a record of the manufacturer's default sysName. Other settings within the Device Profile can change the way NNMi determines sysName values.

To view the Device Profile associated with this node, locate the Device Profile attribute in the Basics section of the Node form, and click the   Lookup icon. Your NNMi administrator can make changes to a Device Profile, if necessary.

Type of the agent (SNMP or Web).

• Each physical device configured with an SNMP Agent will have an SNMP Agent.

• Each hypervisorThe virtual machine manager in charge of delegating various aspects from a pool of resources to become virtual devices. The delegations might be static or dynamic, depending on the manufacture's implementation. The type of virtual machines being generated depends on the manufacturer's implementation. could have two agents:

  • SNMP Agent gathering SNMPSimple Network Management Protocol data.
  • Web Agent gathering SOAPSimple Object Access Protocol data from the VMware VSphere® WebService.
• Each virtual machine provided by the hypervisor has only the Web Agent.

Indicates whether the agent is an SNMP Agent or Web Agent.

For Web Agents hosted on VMware hypervisors, the field shows VMware vSphere.

For SNMP Agents, the field shows the combination of the SNMP version used by the agent (for example, SNMPv2c) and the IP address of the agent.

To see more details about an SNMP AgentSimple Network Management Protocol (SNMP) is an Internet-standard protocol used to manage devices on IP networks. The SNMP Agent uses this protocol to report information to authorized management programs. or Web AgentThe Web Agent represents a management service running on a device and contains the settings NNMi uses to communicate with the device., click the agent name to open the SNMP Agent form or Web Agent form.

Indicates whether the agent assigned to this node is available and how NNMi is interacting with this agent. Possible values are:

For the SNMP Agent:

  Normal – Indicates that the agent responds to requests requiring authentication and login.

  Not Responding – Indicates that the SNMP agent does not respond to requests requiring authentication and login.

  Not Polled – Indicates that this SNMP Agent's address is intentionally not polled, based on current Monitoring Configuration settings, current Communication Configuration settings, or because the parent Node is set to Not Managed or Out of Service. The SNMP Agent’s address might or might not have an associated polling policy.

  No Polling Policy – Indicates that this SNMP Agent's address is being polled, but no polling policy exists in any Monitoring Configuration settings for this monitored attribute.

  Unset – Currently not used by NNMi.

For the Web Agent:

  Normal – Indicates that the agent responds to requests requiring authentication and login.

  Not Responding – Indicates that the Web Agent does not respond to requests requiring authentication and login.

  Not Polled – Indicates that this Web Agent is intentionally not polled, based on current Monitoring Configuration settings, current Communication Configuration settings, or because the parent Node is set to Not Managed or Out of Service. The Web Agent might or might not have an associated polling policy.

  No Polling Policy– Indicates that this Web Agent is being polled, but no polling policy exists.

  Unset – Currently not used by NNMi.

State is determined by the State Poller Service. The current state contributes towards the status calculation for the node. See the Node Form: Status tab for more information.

Table view of the IP addresses associated with the selected node. You can use this table to determine the status, state, address, interface, and subnet for each address associated with the selected node.

Double-click the row representing an IP address. The IP Address Form displays all details about the selected IP address.

Interfaces

Table view of all of the interfaces associated with the current node.

If the interface is physical, you can use this table to determine the status, administrative state, operational state, name, type, interface speed, and Layer 2 Connection for each interface associated with the selected node.

If NNMi is also managing a virtual environment, use this table to also view the details about any interface that represents a virtual switch. These interfaces will have either a blank or 0 bps IfSpeed value.

Double-click the row representing an interface. The Interface Form displays all details about the selected interface.

Interfaces

Table view of all of the interfaces representing a virtual switch that is configured on the selected hypervisor.

Double-click the row representing a virtual switch. The Virtual Switch's Interface Form (NNMi Advanced) displays all details about the selected interface that represents a virtual switch.

Chassis

Table view of all of the Chassis associated with the current Node.

Double-click the row representing a Chassis. The Chassis Form displays all details about the selected Chassis.

Cards

Table view of all of the cards associated with the current node.

Double-click the row representing a Card. The Card Form displays all details about the selected Card.

Ports

Table view of all of the ports associated with the selected node. Use this table to access information about each port associated with the selected node.

Double-click the row representing a port. The Port Form displays all details about the selected port.

Table view of all of the VLAN ports associated with the current node. Use this table to determine all port and VLAN combinations associated with this node.

Double-click the row representing a VLAN port. The VLAN Port Form displays all details about the selected VLAN port.

VLAN connections are determined by a common VLAN Id. The name assigned to that VLAN can be designated by each participating Node/Interface's configuration settings for that VLAN Id.

Local VLAN Name = the VLAN name assigned by the configuration settings on the currently selected Node/Interface.

The identification value for the current VLAN. This value is taken directly from the MIB file provided by the Vendor.

Click the  Lookup icon and select  Show Analysis or  Open to display more information about the VLAN.

Port Name

The port name consists of <Card-number / Port-number>.

Click the  Lookup icon and select  Show Analysis or  Open to display more information about the VLAN.

Table view of all of the Router Redundancy Groups associated with the current Node. Use this table to determine all Router Redundancy Groups to which the current Node belongs.

Double-click the row representing a Router Redundancy Group. The Router Redundancy Group Form (NNMi Advanced) displays all details about the selected Router Redundancy Group.

Table of all of the capabilities associated with the selected Node. Use this table to access information about each Capability.

Double-click the row representing a Node Capability to open the Node Capability Form and view more information.

For more information, see Node Capabilities Provided by NNMi.

(NNMi Advanced, plus Route Analytics Management System (RAMS) for MPLS WAN) The node supports Router Analytics Management System (RAMS) and MPLS WAN.

Label used to identify the Capability that was added to the node object.

Node Form: Capabilities Tab shows a list of all available Capabilities for that node.

For more information, see Node Capabilities Provided by NNMi.

Used as a unique identifier for the Capability. Any capability provided by NNMi begins with the prefix com.hp.nnm.capability.

For more information, see Node Capabilities Provided by NNMi.

Table view of all Node Groups to which this node belongs.

Double-click the row representing a Node Group. The Node Group Form displays all details about the selected Node Group.

Table view of the fault and performance metrics associated with the current node. You can use this table to determine the Status, Name, and Type for each Node Sensor metric associated with the selected node.

Double-click the row representing a Node Sensor. The Node Sensor Form displays all details about the selected Node Sensor.

Value assigned to the Custom Attribute for the selected node. Limit 2,000 of any combination of keyboard entries including spaces.

For more information, see Custom Node Attributes Form.

• For a virtual machine: UUID of the hypervisor that hosts the virtual machine
• For a hypervisor: UUID of the hypervisor

Value assigned to the Custom Attribute for the selected node. Limit 2,000 of any combination of keyboard entries including spaces.

For more information, see Node Form: Custom Attributes Tab.

Node

Name of the topology node from which the Custom Poller Policy information is being collected. This is the current value in the NNMi database for the Name attribute of the node. The value could be a DNS name, a MIB-II sysName, or an address (depending on how your NNMi administrator configured the discovery process).

The State of the Custom Polled Instance as determined by any Thresholds (High State / Low State value) or Comparison Maps (State Mapping = the NNMi administrator assigns a State value for each possible Polled Instance value) configured for the current Custom Poller Collection's MIB Expression.

Possible State values for a Polled Instance (Threshold = High State/Low State; or Comparison Map = State Mapping) are:

Normal 

Warning

Minor

Major

Critical

Represents the MIB Expression that NNMi polls according to configuration settings. Additional information associated with the MIB Variable includes the MIB Expression Name and any Threshold settings configured for the Custom Poller Collection.

Click the Lookup icon and select  Show Analysis or  Open to display more information about the MIB Variable.

See MIB Variable Form for more information about the MIB Variable attribute.

This attribute contains the multiple filtered instances for the MIB Expression. Each instance value identifies a row in the MIB table.

If a MIB expression includes multiple MIB Variables that have multiple instances, each instance value that is valid across all MIB Variables for a node is listed here. If NNMi is unable to find the same instance for all MIB Variables in the expression, a Polled Instance is not created. This is because NNMi cannot correctly evaluate a MIB Expression with missing values. If Polled Instances are not created as expected, check the Custom Node Collection view for Discovery State and Discovery State Information values.

The value from the MIB Expression that caused the State to change.

Table view of the Node Diagnostic Results associated with the selected node. You can use this table to determine the start time, definition, status, report name, and last update time for each Node Diagnostic Result associated with the selected node.

Double-click the row representing a Node Diagnostic Result . The Node Diagnostic Results Form (Flow Run Result) displays all details about the selected Node Diagnostic Result.

Start Time

Date and time NNM iSPI NET created this instance of the Diagnostics report. NNM iSPI NET uses the locale of the client and the date and time from the NNMi management server.

Definition

The name of the NNM iSPI NET Diagnostics report definition.

The current status of this NNM iSPI NET Diagnostics report. Possible values include:

• The Diagnostic is in the queue, but is not yet running
• The Diagnostic has been submitted and is not finished running
• The Diagnostic has finished running
• An error condition prevented the Diagnostic from being submitted
• NNMi was unable to submit or run the Diagnostic due to a timeout error. The timeout limit for submitting a Diagnostic is one hour. The timeout limit for running a Diagnostic is four hours.

• The number of Diagnostics in the queue might prevent NNMI from submitting the Diagnostic.
• A configuration error, such as an incorrect user name or password, might prevent NNMi from accessing the required Operations Orchestration server.

Contact your NNMi administrator for Diagnostic log file information.

Click this link to open the actual report. NNM iSPI NET uses this text string to display the selected instance of the diagnostics report in a browser window.

You might be prompted to provide a user name and password to access the Operations Orchestration software. See the NNM iSPI NET Planning and Installation Guide for more information.

Incident Lifecycle State of the target Incident.

If the incident's Lifecycle State matches the value specified here, the Diagnostic runs.

The Diagnostic automatically runs on each applicable Source Node in the specified Node Group if the incident has the Lifecycle State currently configured in this attribute of the Diagnostic (Flow Definition - set of automated commands).

Table view of the incidents associated with the selected node. These incidents are sorted by creation time so that you can view the incidents in chronological order. Use this view to determine which incidents are still open for the selected node.

Double-click the row representing an incident. The Incident Form displays all details about the selected incident.

Overall status for the current node. NNMi follows the ISO standard for status classification. Possible values are:

  No Status

  Normal

  Disabled

  Unknown

  Warning

  Minor

  Major

   Critical

The status of all IP addresses and the SNMP Agent associated with this node, and well as interface health contribute to node status. For information about how the current status was determined, see the Node Form: Conclusions Tab. Status reflects the most serious outstanding conclusion. See Watch Status Colors for more information about possible status values.

Your NNMi administrator might configure Custom Poller so that the Status of a Custom Node Collection effects the topology node's Status. Click here to view the effect of a Custom Node Collection's Status on the topology node's Status. See About Custom Poller  for more information.

The effect of a Custom Node Collection's Status on the topology node's Status is determined as follows:

• If at least one Custom Collection Node's Status is Critical, the topology node Conclusion Status is Critical.
• If at least one Custom Collection Node's Status is Major, but none are Critical, the topology node Conclusion Status is Major.
• If at least one Custom Collection Node's Status is Minor, but none are Critical or Major, the topology node Conclusion Status is Minor.
• At least one Custom Collection Node's Status is Warning, but none are Critical, Major, or Minor, the topology node Conclusion Status is Warning.
• If the Status of all Custom Collection Nodes are Normal, the topology node Conclusion Status is Normal.

List of up to the last 30 changes in status for the selected node. This view is useful for obtaining a summary of the node status so that you can better determine any patterns in node behavior and activity.

Double-click the row representing a Status History. The Status History form displays all details about the selected Status.

The dynamically generated list of summary statuses of the node that contributed to the current overall Status of the selected node. Status is set by the Causal Engine.

Each Conclusion listed is still outstanding and applies to the current overall Status.

This view is useful for obtaining a quick summary of the Status and problem description for the current node that led up to the node's most current Status.

The Status value is correlated based on the most critical Conclusions.

Double-click the row representing a Conclusion. The Conclusion form displays all details about the selected Conclusion.

The following table describes the possible Conclusions that might appear for a node object.

A Y in the Incident? column indicates that the Conclusion results in an incident.

Critical Status Conclusions

Major Status Conclusions

Minor Status Conclusions

Warning Status Conclusions

Disabled Status Conclusions (NNMi Advanced)

Unknown Status Conclusions

Normal Status Conclusions

Multiple Node conclusions can appear for the same node object. For example, if a node is functioning properly and it has monitored addresses, interfaces, at least one card, and a card redundancy group, you would see these conclusions together:

• SNMPAgentResponding
• AllResponsiveAddressesInNode
• InterfacesUpInNode
• CardsUpInNode
• CrgNormalInNode

One of the following:

• The name assigned to the Scheduled Outage whose start or stop history is being recorded here.
• For all other Management Mode changes, this value is empty (blank).

The NNMi User Name of the person who initiated the Node State change.

Created

Date and time the selected object instance was created. NNMi uses the locale of the client and the date and time from the NNMi management server.

This value does not change when a node is rediscovered. This is because the Node object is modified, but not created.

Last Modified

Date the selected object instance was last modified. NNMi uses the locale of the client and the date and time from the NNMi management server.

Note the following:

• When a node is rediscovered, the Last Modified time is the same as the Discovery Completed time. This is because the node’s Discovery State changes from Started to Completed.
• When a Node is initially discovered, the Last Modified time is slightly later than the Created time. This is because node discovery does not complete until after the Node is created.

ID

The Unique Object Identifier, which is unique within the NNMi database.

UUID

The Universally Unique Object Identifier, which is unique across all databases.

The description, based on information from the MIB-II sysDescr string provided by the vendor.

Maximum length is 255 characters: alpha-numeric, spaces, and special characters (~ ! @ # $ % ^ & * ( ) _+ -)

Device family name provided by the vendor; for example Cisco Catalyst 6500 Series Switches or HP AdvanceStack Routers.

Click the  Lookup icon to access the Device Family Form for more details.

Name of the vendor that manufactures the device.

Click the  Lookup icon to access the Device Vendor Form for more details.

The value of this attribute determines which background shape NNMi uses for the map icon representing devices of this type. See About Map Symbols for more information about the possible values.

Click the  Lookup icon to access the Device Category Form for more details.

Indicates who created or last modified the device profile.

If the Author attribute value is Network Node Manager, any changes are at risk of being overwritten in the future.

• Click  Lookup and select  Show Analysis to display details about the currently selected Author.
• Click  Quick Find to access the list of existing Author values.
• Click  New to create an Author value.

If  enabled, Spiral Discovery does not use a MIB-II sysName value for the Name attribute for discovered Nodes of this type. If sysName is part of the current node Name strategy, NNMi uses the next designated node Name choice in the strategy established by your NNMi administrator.

If  disabled, MIB-II sysName can potentially be used as the Name attribute value for nodes of this type.

The vendor's default sysName text string, from MIB-II sysName.

If the SNMP agent responds to a sysName request with a value that matches or starts with the entry in this field (case-sensitive), Spiral Discovery ignores the sysName and considers sysName to be unset. As a result, NNMi instead tries to find a DNS name or IP address for this node (according to the strategy established by your NNMi administrator).

For example, when an SNMP agent responds with a default sysName, NNMi's maps might display multiple icons with the same name (one for every device of that type in your environment that responded to an SNMP query with the default sysName). Usually, the device administrator changes the default sysName value to something more meaningful, so this problem is avoided.

This attribute enables the NNMi administrator to override the IP Forwarding (Layer 3) and LAN Switching (Layer 2) Capability settings provided by Spiral Discovery (displayed on the Node Form: Capabilities Tab).

Note the following:

• The Force Device attribute does not affect default membership for the Node Groups provided by NNMi. For example, the Force to router settings does not add the Node to the Routers Node Group. NNMi uses the Device Category to determine Node Group membership for the Node Groups it provides.
• The Force Device setting does not affect the background shapes displayed on an NNMi map. NNMi uses the Device Category specified in the Device Profile to determine the map background shapes displayed.

The following table describes the possible Force Device settings and subsequent behavior:

An NNMi administrator might want to use this attribute to override the IP Forwarding (Layer 3) and LAN Switching (Layer 2) capabilities setting for the device under the following circumstances:

• The sysServices setting in MIB-II that is used to determine the IP Forwarding (Layer 3) and LAN Switching (Layer 2) capability during discovery is not accurate due to a firmware defect on the device.

• The device serves as a router, switch, or switch and router and the NNMi administrator wants to force the device to be treated as only one of the following: 1) a router, 2) a switch, or 3) a switch and router.

• The device serves as a virtual router, but should not be managed as a router.

  Setting the Force Device attribute to Force to end node enables the NNMi administrator to configure Spiral Discovery to ignore this device (unless the device is within the Default Tenant and an Auto-Discovery Rule is configured to "Discover Any SNMP Device" or configured to include the matching System Object ID).

Your NNMi administrator chooses which interface MIB variable the NNMi State Poller queries to detect interface changes. NNMi can use the following MIB-II attribute values: ifIndex, ifName, ifDescr, ifAlias, or a combination of these (ifName or ifDescr, ifName or ifDescr or ifAlias). See the General Interface Attributes (SNMP Values) in Interface Form: General Tab for information about these four MIB-II attributes that are available to use for this setting.

If you are an Administrator, see Detect Interface Changes for more information.

A network device's interfaces can be configured with proprietary Layer 2 discovery protocols, instead of or in addition to the industry standard LLDP (see the list of Topology Source protocols in Layer 2 Connection Form).

By default, NNMi checks the interface for standard LLDP and vendor-specific IEEE 802 Layer 2 protocol. NNMi uses data from both protocols to calculate the Layer 2 Connection, but by default prefers the data provided through LLDP.

Forwarding Database (FDB) information can cause NNMi to establish wrong Layer 2 Connections in the following cases:

• When the FDB is configured as cache and contains obsolete data.
• In network environments with hardware from a variety of vendors, when each vendor generates different and sometimes conflicting FDB data.

Optional: NNMi administrators can configure Spiral Discovery to ignore the FDB data from one Node Group when calculating Layer 2 Connections (the FDB data is still included in other calculations).

(NNMi Advanced - Global Network Management feature) NNMi must read the Forwarding Database (FDB) tables from Ethernet switches within the network before accurate communication paths between these network devices can be calculated. Because the FDB data is involved, NNMi can produce different results on a Regional Manager as opposed to the Global Manager.

If NNMi discovers more than one IEEE 802 Layer 2 protocol being used by a particular device's interface, the Device Profile's setting controls NNMi's protocol preference:

 Prefer LLDP = Enabled: NNMi gives priority to the LLDP data.

 Prefer LLDP = Disabled: NNMi gives priority to the vendor-specific IEEE 802 Layer 2 protocol data.

If NNMi detects incorrect neighbors, make sure that the interfaces at both ends of the Layer 2 Connection are using the same configuration for Layer 2 discovery protocol. For more information, see Troubleshooting Layer 2 Connections.

Device family name. For example, Cisco Catalyst 6500 Series Switches or HP AdvanceStack Routers.

Maximum length is 255 characters. Alpha-numeric, spaces, and underline characters are permitted.

The required unique identifier that is important when exporting and importing device profile information within NNMi.

The value must be unique. One possible strategy is to use the Java name space convention. For example:

com.<your_company_name>.nnm.device_profile.family.<family_label>

Maximum length is 80 characters. Alpha-numeric characters and periods are permitted. Spaces are not permitted.

Optional. The URL to the device's management page (provided by the vendor). This page is used to provide configuration information for the device and is usually organized by device family.

Displays the icon that is associated with the Device Family.

If you are an NNMi administrator, you can customize the icon. See Customize Device Profile Icons for more information.

Vendor name.

Maximum length is 255 characters. Alpha-numeric, spaces, and underline characters are permitted.

The required unique identifier that is important when exporting and importing device profile information within NNMi.

The value must be unique. One possible strategy is to use the Java name space convention. For example:

com.<your_company_name>.nnm.device_profile.vendor.<vendor_label>

Maximum length is 80 characters. Alpha-numeric characters and periods are permitted. Spaces are not permitted.

Displays the icon that is associated with the Device Vendor.

If you are an NNMi administrator, you can customize the icon. See Customize Device Profile Icons for more information.

Category name.

Maximum length 255 is characters. Alpha-numeric, spaces, and underline characters are permitted.

The required unique identifier that is important when exporting and importing device profile information within NNMi.

The value must be unique. One possible strategy is to use the Java name space convention. For example:

com.<your_company_name>.nnm.device_profile.category.<category_label>

Maximum length is 80 characters. Alpha-numeric characters and periods are permitted. Spaces are not permitted.

Displays the icon that is associated with the Device Category.

If you are an NNMi administrator, you can customize the icon. See Customize Device Profile Icons for more information.