Monitor with Table Views
NNMi provides the following out-of-the-box node and interface views to assist you in monitoring the network for problems. These views help you quickly identify the nodes and interfaces that need your more immediate attention:
Note the following:
- NNMi uses Conclusions to determine an object's Status. Therefore, an object with a non-Normal Status does not always have an open incident associated with it. See The NMMi Causal Engine and Object Status for more information about incidents, conclusions, and object Status.
-
If NNMi determines that it requires more time to complete its analysis for an object, one of the following occurs:
-
There is a delay between the change in object Status and any associated open incident.
-
NNMi determines that the incident does not apply and the incident is not generated.
For example, when an address is not responding to ICMP, the Status of the address is set to Critical, but the incident is delayed until the NNMi Causal Engine determines whether the address is in the shadow of a node that is down. If the address is in the shadow of node that is down, NNMi does not generate an Address Not Responding incident. If the address is not in the shadow of a node that is down, NNMi generates the Address Not Responding incident. See Node Down for more information about objects that are in the shadow of a node.
-
-
If Dampening is configured for the incident, one of the following occurs:
-
There is a delay between the change in object Status and any associated open incident.
To see an incident that has a Lifecycle State of Dampened, in the NNMi console, select either the Custom Incidents or Open Custom Incidents view and set the Lifecycle State Filter to Dampened.
-
NNMi determines that the incident does not apply and the incident is automatically deleted.
If you are an NNMi administrator, see Dampening Incident Configurations for more information.
-
-
If the Incident Configuration is suppressed, NNMi does not display the incident. If you are an NNMi administrator, see Suppress Incident Configurations for more information.
To view the nodes that have an open associated incident from a Node Group Topology Map view, click 
Indicate Key Incidents. This option enlarges each object on the map that has an associated open incident. This option is available only with Node Group maps.
- Non-Normal Node Sensors View
- Non-Normal Physical Sensors View
- Non-Normal Chassis View
- Non-Normal Cards View
- Non-Normal Interfaces View
- Monitor with Table Views
- Non-Normal SNMP Agents View
- Monitor with Table Views
- Monitor with Table Views
- Monitor with Table Views
- Monitor with Table Views
- Router Redundancy Group View
- Monitor with Table Views
- Custom Node Collections View
- Custom Polled Instances View
See Node Sensor Form for more details about the node sensor attributes that appear in this view's column headings. Node Sensors are displayed in three views: Node Sensors View, Non-Normal Node Sensors View, and Unmanaged Node Sensors View.
The Non-Normal Node Sensors view in the Monitoring workspace is useful for identifying all of the Node Sensors that might need operator attention. Examples of Node Sensors include buffers, CPU, disks, and memory.
Possible Statuses for these interfaces include:
Warning
Minor
Major
Critical
To display the Non-Normal Node Sensor view:
- In the Workspaces navigation pane, select the Monitoring workspace.
- Select the Non-Normal Node Sensor view.
For each Node Sensor displayed, you can see its Status, Name, Type, the Node in which it resides, and the date and time the Status was last modified.
Monitoring Workspace Views: 
See Also
See Physical Sensor Form for more details about the node sensor attributes that appear in this view's column headings. Node Sensors are displayed in three views: Physical Sensors View, Non-Normal Physical Sensors View, and Unmanaged Physical Sensors View.
The Non-Normal Physical Sensors view in the Monitoring workspace is useful for identifying all of the Physical Sensors that might need operator attention. Examples of Physical Sensors include backplane, fan, power, temperature, and voltage.
Possible Statuses for these interfaces include:
Warning
Minor
Major
Critical
To display the Non-Normal Physical Sensor view:
- In the Workspaces navigation pane, select the Monitoring workspace.
- Select the Non-Normal Physical Sensor view.
For each Physical Sensor displayed, you can see its Status, Name, Type, the Managed By (Node), Hosted On (chassis in which it resides), and the date and time the Status was last modified.
See Chassis Form for more details about the chassis attributes that appear in this view's column headings.
The Non-Normal Chassis view in the Monitoring workspace is useful for identifying all of the network chassis that might need operator attention. Possible statuses for these chassis include:
Warning
Minor
Major
Critical
Chassis displayed in this table all have the AdministrativeState equal to 
Up and a Status other than Normal.
To display the Non-Normal Chassis view:
- In the Workspaces navigation pane, select the Monitoring workspace.
- Select the Non-Normal Chassis view.
The columns in this table view show many attributes of each chassis.
By default, this view is sorted by the date the chassis status was last modified.
Chassis views are useful for quickly identifying items described in the following table.
| Use | Description |
|---|---|
|
View all network chassis per node |
Sort the view using the Managed By column. This can help you organize your chassis per node, so that you can identify the nodes that might need attention. |
|
Determine the health of each of the managed chassis |
Sort the view by the Status attribute. |
|
Determine the types of chassis that are being managed. |
Sort on the ifType (chassis type) attribute. |
|
Access a map view of the network chassis and its surrounding topology. |
Select the chassis of interest and use the Actions menu to select either the Layer 2 or Layer 3 Neighbor View. You can also right-click any object in a table or map view to access the items available within the Actions menu. |
See Card Form for more details about the attributes that appear in this view's column headings.
The Non-Normal Cards view in the Monitoring workspace is useful for identifying all of the Cards that have a status that is other than Normal. Possible statuses for these cards include:
Warning
Minor
Major
Critical
Cards displayed in this table all have the AdministrativeState equal to Up and a Status other than Normal.
To display the Critical Cards view:
- In the Workspaces navigation pane, select the Monitoring workspace.
- Select the Critical Cards view.
The columns in this table view show many attributes of each chassis.
To see the incidents related to a Card:
- Double-click the row representing the Card that has the incidents you want to see.
- Navigate to the Incidents tab to see the incidents associated with the selected Card.
See Interface Form for more details about the interface attributes that appear in this view's column headings.
The Non-Normal Interfaces view in the Monitoring workspace is useful for identifying all of the network interfaces that might need operator attention. Possible statuses for these interfaces include:
Warning
Minor
Major
Critical
Interfaces displayed in this table all have the AdministrativeState equal to Upand a Status other than Normal.
To display the Non-Normal Interfaces view:
- In the Workspaces navigation pane, select the Monitoring workspace.
- Select the Non-Normal Interfaces view.
For each interface displayed in the view, you can identify its status, Operational State, associated node Name value (Hosted On Node), the interface name, type, speed, a description of the interface, the ifAlias value, the date and time the status of the interface was last modified, the name of the Layer 2 Connection associated with the interface, and any notes included for the interface.
By default, this view is sorted by the date the interface status was last modified (Status Last Modified).
Interface views are useful for quickly identifying items described in the following table.
| Use | Description |
|---|---|
|
View all network interfaces per node |
Sort the view by Hosted On. This can help you organize your interfaces per node, so that you can identify the nodes that might need attention. |
|
Determine the health of each of the managed interfaces |
Sort the view by the Status attribute. |
|
Determine the types of interfaces that are being managed. |
Sort on the ifType (interface type) attribute. |
|
Access a map view of the network interface and its surrounding topology. |
Select the interface of interest and use the Actions menu to select either the Layer 2 or Layer 3 Neighbor View. See Use Table Views for more information. You can also right-click any object in a table or map view to access the items available within the Actions menu. |
See Node Form for more details about the node attributes that appear in this view's column headings.
The Non-Normal Nodes view in the Monitoring workspace is useful for identifying all of the nodes that might need operator attention. Possible statuses for these nodes include:
Warning
Minor
Major
Critical
For each node displayed, you can identify its status, device category (for example, Switch), hostname, management address, system location (the current value of the sysLocation MIB variable), device profile, whether the SNMP Agent is enabled on the node, the date and time its status was last changed, and any notes included for the node.
The device profile information determines how devices of this type are managed and the icon and background shape displayed on maps.
By default, this view is sorted by the date the node status was last modified (Status Last Modified).
Node views are useful for quickly identifying items described in the following table.
| Use | Description |
|---|---|
|
View all problem nodes |
Sort the view by Status so that you can be quickly alerted to existing and potential problems. |
|
Identify whether the problem can be isolated to a particular area of your network |
Sort the view by System Location. This is the current value of the sysLocation MIB variable. |
|
View all device types being managed |
Sort the view by the Device Profile attribute. |
|
View address and subnet information associated with a selected node to better determine the scope of the problem |
From the Nodes view, open the Node form. Then access the Address tab. See Node Form and IP Subnet Form for more information. |
|
Access a map view of a selected node and its surrounding topology |
Select the node of interest and use the Actions menu from the main toolbar. See Use Table Views for more information. You can also right-click any object in a table or map view to access the items available within the Actions menu. |
|
View the statuses of interfaces associated with a node |
If a node is not completely down, you might want to see which interfaces are down for the selected node. To do so, open the Node form and select the Interfaces tab. |
|
The number of devices that are served by this node. |
Select the node you want and access the Layer 2 or Layer 3 Neighbor View using the Actions menu. |
See SNMP Agent Form for more details about the SNMP Agent attributes that appear in this view's column headings.
The Non-Normal SNMP Agents view in the Monitoring workspace is useful for identifying all of the SNMP Agents that have a state that is other than Normal. Possible statuses for these nodes include:
Warning
Minor
Major
Critical
To display the Non-Normal Node SNMP Agents view:
- In the Workspaces navigation pane, select the Monitoring workspace.
- Select the Non-Normal SNMP Agents view.
For each SNMP Agent displayed in the view, you can identify the SNMP Agent Status, the Agent SNMP State, the Agent ICMP State, the associated node Name value (Hosted On Node), the IP address NNMi uses to communicate with this SNMP agent (Management Address), the date and time the Status was last modified, the version of the SNMP protocol in use, whether the SNMP agent is set up for SNMP communication in the network environment (SNMP Agent Enabled), the User Datagram Protocol port configuration for this SNMP agent (UDP Port), the time that NNMi waits for a response to an SNMP query before reissuing the request, and the maximum number of retries that NNMi issues for an SNMP query before determining the query result to be "unresponsive", the read community string, and the SNMP Proxy address.
If you have Administrator Role, the Non-Normal SNMP Agents view also displays the Read Community String.
See IP Address Form for more details about the node attributes that appear in this view's column headings.
The Not Responding Address view in the Monitoring workspace is useful for identifying all of the addresses that has a state that is 
Not Responding (the address is not responding to ICMP ping).
Because all addresses in this view have a state of Not Responding, the State column is not displayed in this view.
For each address displayed in the view, you can identify the status, address, associated node Name value (Hosted On Node), interface, the subnet prefix (In Subnet), the date and time the State was last modified, the prefix length (PL), and any notes included for the IP address.
Requires Network Node Manager iSPI Performance for Metrics Software (NNM iSPI Performance for Metrics). To populate performance data in the dashboard views or enhance NNM iSPI Performance for Metrics reports by sharing NNMi configuration settings, install the optional Network Performance Server (NPS).
(NNM iSPI Performance for Metrics) Data appears in the Interface Performance view in the Monitoring workspace only if the Network Node Manager iSPI Performance for Metrics Software is installed and your NNMi administrator enables performance monitoring.
The interface performance view helps you identify the over-used and under-used interfaces within nodes in your network. Sort this view by Hosted On Node to help identify which nodes receive the most traffic. You can proactively monitor your network and check for those interfaces that have an input or output utilization, error, or discard rate that indicates there might be a potential problem.
Your network administrator can set up Node Groups or Interface Groups that identify important network devices, and those groups can be filters for this view.
If you filter your view using multiple filters, NNMi uses the AND operator to combine the filters you have selected. See Filter a Table View for more information.
For each interface displayed, you can view polling states for its input and output utilization rates, input and output utilization baselines, input and output error rates, input and output discard rates, Frame Check Sequence (FCS) error rates, input and output queue drops, associated node Name value of the computer on which the interface resides (Hosted On Node), the interface name, speed, input speed, output speed, and any notes that exist about the interface.
See Interface Form for more details about the interface attributes that appear in this view's column headings.
See Chassis Redundancy Group Form for more details about the attributes that appear in this view's column headings.
The Chassis Redundancy Groups view in the Monitoring workspace is useful for identifying the names of the groups that provide redundancy protection against chassis failure.
To display the Chassis Redundancy Groups view:
- In the Workspaces navigation pane, select the Monitoring workspace.
-
Select the Chassis Redundancy Groups View view.
For each Chassis Redundancy Group displayed in this view, you can identify the Chassis Redundancy Group Status, Name, and the date and time the Status was last modified.
See Use Table Views for more information about sorting, filtering, and hiding attribute columns within a view.
To see the incidents related to a Chassis Redundancy Group:
- Double-click the row representing a Chassis Redundancy Group. The Chassis Redundancy Group Form displays all details about the selected Chassis Redundancy Group.
-
Navigate to the Incidents tab.
A table displays the list of Incidents associated with the selected Chassis Redundancy Group.
To view the members that belong to this group:
- Double-click the row representing a Chassis Redundancy Group. The Chassis Redundancy Group Form displays all details about the selected Chassis Redundancy Group.
-
Navigate to the Redundant Chassiss tab.
A table displays the list of Chassiss that belong to the selected Chassis Redundancy Group.
See Card Redundancy Group Form for more details about the Card Redundancy Group attributes that appear in this view's column headings.
The Card Redundancy Groups view in the Monitoring workspace shows the groups of redundant cards that your network administrator configured to provide one-to-one redundancy protection against processor card failure.
To display the Card Redundancy Groups view:
- In the Workspaces navigation pane, select the Monitoring workspace.
-
Select the Card Redundancy Groups View view.
For each Card Redundancy Group displayed in the view, you can identify the Card Redundancy Group Status, Name, and the time and date the Card Redundancy Group Status was last modified.
To see the incidents related to a Card Redundancy Group:
- Double-click the row representing the Card Redundancy Group that has incidents you want to see.
-
Navigate to the Incidents tab to see the incidents associated with the selected Card Redundancy Group.
A table displays the list of Incidents associated with the selected Card Redundancy Group.
To view the members that belong to this group:
- Double-click the row representing the Card Redundancy Group that has members you want to see.
-
Select the Redundant Cards tab.
A table displays the list of Cards that belong to the selected Card Redundancy Group.
(NNMi Advanced) Your network administrator might have set up groups of redundant routers to help ensure that information packets reach their intended destination. Use the Router Redundancy Group view to see all of the available groups of redundant routers in your network.
See Router Redundancy Group Form (NNMi Advanced) for more details about the Router Redundancy Group attributes that appear in this view's column headings.
To display the Router Redundancy Group view:
- In the Workspaces navigation pane, select the Inventory workspace or the Monitoring workspace.
- Select the Router Redundancy Group view.
For each Router Redundancy Group displayed in the view, you can identify the Router Redundancy Group status, Router Redundancy Group Name, the Router Redundancy Group protocol (for example, HSRP), and the date the Router Redundancy Group Status was last modified.
To see the incidents related to a Router Redundancy Group:
- 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.
- Navigate to the Incidents tab to see the incidents associated with the selected Router Redundancy Group.
To view the members that belong to this group:
- Double-click the row representing the Router Redundancy Group members you want to see.
-
Navigate to the Router Redundancy Members tab.
Each node that belongs to the selected Router Redundancy Group is listed. You also see which interface is assigned to the Router Redundancy Group within each node.
Inventory Workspace Views: See Also
See Node Group Form for more details about the Node Group attributes that appear in this view's column headings.
The Node Groups view in the Monitoring workspace is useful for identifying the names of the groups configured by your network administrator.
When monitoring your network, you might be interested in only viewing information for a particular set of nodes. Your network administrator can group sets of nodes into node groups. An example node group could be all important Cisco routers, or all routers in a particular building. See About Node and Interface Groups for more information about how your administrator sets up node groups. See Filter Views by Node or Interface Group for more information about filtering views using node and interface groups.
To display the Node Groups view:
- In the Workspaces navigation pane, select the Monitoring workspace.
- Select the Node Groups view.
- To display the definition for a particular Node Group filter, double-click the row representing a Node Group. The Node Group Form displays all details about the selected Node Group.
For each node group displayed in the view, you can identify the node group status, name, whether the node group appears in the filter list for node and interface views, whether the node group is available as a filter in the NNM iSPI Performance software, whether its status is calculated, the date and time its status was last modified, and any notes about the node group.
Mouse over a column heading for the complete name of a column heading attribute. See Custom Node Collections Form for more details about the attributes that appear in the view's column headings.
The Custom Node Collections view in the Monitoring workspace is useful for identifying the node objects for which Custom Poller Polices have been created.
For each Custom Node Collection displayed, you can identify a Custom Node Collection's overall Status, the Name of the associated topology node, the Active State of the Custom Node Collection's Policy, the name of the Policy that is applied to the current Custom Node Collection, as well as discovery information regarding the MIB Expression on each node for which you are collecting data, such as Discovery State, the Discovery State Last Modified, and Discovery State Information.
Note the following:
-
The Custom Node Collection's Status is the most severe State value returned from the Polled Instances for the Custom Node Collection.
The Custom Node Collection Status is not provided for any Custom Poller Collection that has a Collection Type of Bulk.
- The Active State for any Custom Node Collection associated with a Not Managed or Out of Service node that was previously managed, becomes Inactive. NNMi deletes all of the Polled Instances associated with the Not Managed or Out of Service node.
- You can display a Line Graph for those incidents that have a source node associated with Custom Node Collections. See Display a from an Incident (Custom Poller Only) for more information.
Mouse over a column heading for the complete name of a column heading attribute. See Custom Polled Instance Form for more details about the attributes that appear in the view's column headings.
The Custom Polled InstanceA Custom Polled Instance represents the results of a MIB variable when it is evaluated against a node. The first time a MIB variable is validated with discovery information, the results appear in the Monitoring workspace's Custom Polled Instances view. The Custom Polled Instance is updated whenever a change in State occurs and includes the most recent polled value that caused the State to change. These results are then used to determine the Status of the associated Custom Node Collection.s View is not populated for any Custom Poller Collection that has a Collection Type of Bulk.
The Custom Polled Instances view in the Monitoring workspace is useful for viewing the polling results for Custom Node CollectionA Custom Node Collection identifies a topology node that has at least one associated Custom Poller Policy. Because a topology node can be associated with more than one Policy, the same topology node might appear in multiple Custom Node Collections.. A Custom Polled Instance represents the results of a MIB expression when it is evaluated against a node in the Custom Node Collection. The first time a MIB Expression is validated with discovery information, the results appear in a Custom Polled Instance object. The Custom Polled Instance is updated whenever a change in State occurs and includes the most recent polled value that caused the State to change. For more information, click here.
A node can be associated with multiple Custom Polled Instances when its associated MIB expression includes MIBs that have multiple instances per node. For example, the associated MIB expression might perform a calculation using the ifInOctets and ifOutOctets MIB values. Using the MIB Filter and MIB Filter Variable specified, NNMi calculates these values for each interface that meets the filter criteria and that is associated with a node in the Custom Poller Collection.
The Active State for any Custom Node Collection associated with a Not Managed or Out of Service node that was previously managed, becomes Inactive. NNMi deletes all of the Polled Instances associated with the Not Managed or Out of Service node.
For each Custom Polled Instance displayed, you can identify the following:
- Status of the Custom Polled Instance
- State of the Custom Polled Instance
- Returned value from the MIB Expression that caused the State to change
- MIB Expression name
-
MIB Variable - Selected MIB variable provided by a MIB file loaded on the NNMi management server. The Custom Polled Instance represents an instance of the MIB Variable that is displayed.
Each Custom Polled Instance is associated with one instance of a MIB Variable. A MIB Variable can be associated with multiple Custom Polled Instances.
- MIB Instance value
- Filter Value (The instance of a MIB variable value after the MIB Filter is applied)
-
The Display Attribute (The value that results from the Instance Display Configuration. This value is used to identify the data instances that are displayed in the Line Graph. The NNMi administrator can specify the Instance Display Configuration information when configuring a MIB expression for Custom Poller.)
If the Instance Display Configuration is not set, NNMi identifies each instance that appears in a Line Graph using the Node's short DNS Name followed by the MIB Instance value in the format: <node_name> -<MIB_instance_value>. The <node_name> -<MIB_instance_value> is also used as the Display Attribute in the Custom Polled Instances view. If you are an NNMi administrator, see MIB Expressions Form (Custom Poller) for more information.
- Name of the topology Node on which the Custom Poller Policy information is being collected
- Name of the associated Custom Node CollectionA Custom Node Collection identifies a topology node that has at least one associated Custom Poller Policy. Because a topology node can be associated with more than one Policy, the same topology node might appear in multiple Custom Node Collections..
- Active State
- Date and time the Custom Polled Instance State was last modified
(NNMi Advanced - Global Network Management feature) Any Custom Polled Instances are not sent from a Regional Manager (NNMi management server) to the Global Manager. From the Global Manager, use Actions → Open from Regional Manager to see the list of Custom Polled Instances on the Regional Manager.
Related Topics