Use > Monitor with the NNM iSPI Performance for QA > Monitor Incidents

Monitor Incidents

This topic includes the following sections:

QA Probes

NNM iSPI Performance for QA does not poll the QA probes for the nodes that have any of the following management modes: 

  • Not Managed: Indicates that the node is not managed on purpose.
  • Out of Service: Indicates that a node is unavailable because it is out of service.

NNM iSPI Performance for QA monitors the network performance with the following metrics:

  • Round Trip Time (RTT)
  • Jitter
  • Packet Loss (Can be from source to destination, destination to source, or two way.)
  • Mean Opinion Score (MOS)

For information on metrics, see the topic NNM iSPI Performance for QA Metrics in the NNM iSPI Performance for QAReports Online Help.

NNMi discovers the following types of QA probes:

  • DNS
  • HTTP and HTTPS
  • ICMP Echo
  • ICMP Jitter
  • Oracle
  • TCP Connect
  • UDP Echo
  • UDP
  • VoIP
  • DHCP

NNMi supports the multi-tenant architecture of NNMi. The security group and tenants configured in NNMi is also applicable for the QA probes in NNMi.

To perform a basic monitoring of the quality of your network performance, follow the steps as discussed below:

Log on to the NNMi console with the operator (level 1 or 2) or guest credentials. After you log on to the NNMi console, you can view the NNMi workspace.

You can access the inventory view to monitor the status and necessary details for the preconfigured QA probes in every device in your network.

NNM iSPI Performance for QA - For Juniper Devices

The probe types on Juniper devices, when discovered by NNM iSPI Performance for QA, are interpreted differently. The following table lists the probe types on the device and their interpretation by NNM iSPI Performance for QA:

The table below is for SRX and MX series of Juniper devices only.

Probe Type on Device Hardware Timestamp is Enabled Probe Type in NNM iSPI Performance for QA
icmp-ping/ icmp-ping-timestamp No ICMP Echo
icmp-ping/ icmp-ping-timestamp Yes ICMP Jitter
udp-ping/ udp-ping-timestamp No UDP Echo
udp-ping/ udp-ping-timestamp Yes UDP

If hardware timestamp is changed for a probe between two discovery cycles, the probe type also changes accordingly. For example, an udp-ping-timestamp probe with hardware timestamp enabled will be discovered by NNM iSPI Performance for QA as UDP probe. However, if hardware timestamp is disabled later, it will be rediscovered as an UDP Echo probe in the next discovery cycle.

Analyze the Root Cause of QA Probe Failure

Using root cause analysis, NNM iSPI Performance for QA performs the following tasks on the failed QA probes:

  • Identifies the underlying cause when a QA probe fails to run.
  • Correlates the probe failures that can be associated with the same cause.

  • Generates a common incident for the QA probes failed for a common cause.

    You can identify the cause of probe failure using this incident.

Causes for QA Probe Failure Between Nodes

  • When a specific source IP address fails to reach a specific destination IP address

    Incident Generated: TestDestNodeNotReachable

    Severity: Critical

    Root Cause Analysis:

    • All ICMP probes from a source IP address to a destination IP address fail.
    • Destination IP address cannot be reached from the source IP address.

    As a result, all other QA probes configured for the destination IP address fail. The incident denotes reachability failure and correlates all the other probe failures with it.

  • When a source IP address fails to reach a specific destination IP address

    Incident Generated: TestDestDown

    Severity: Critical

    Root Cause Analysis:

    • All ICMP probes from any source IP address to a specific destination IP address fail.
    • Destination node is down.

    As a result, all other QA probes configured for the destination IP address fail. The incident denotes that the destination node is down and correlates all the other probe failures from all source IP addresses with it.

  • When a service type fails between a source IP address and destination IP address

    Applicable only if more than one QA probe of the same service type runs between the selected source and destination IP addresses.

    Incident Generated: TestServiceNotReachable

    Severity: Critical

    Root Cause Analysis:

    • All probes for a service type fail between a specific source IP address and destination IP address.
    • The service type is unavailable between the source and destination IP addresses.

    As a result, all other QA probes of the same service type configured for the destination IP address fail. The incident denotes that the service type is unavailable and correlates all the other probe failures with it.

  • When a service type fails between any source IP address and a specific destination IP address

    Incident Generated: TestServiceDown

    Severity: Critical

    Root Cause Analysis:

    • All probes for a service type fail from all source IP addresses to a specific destination IP address.
    • The service type is unavailable on the destination IP address.

    As a result, all other QA probes of the same service type configured for the destination IP address fail. The incident denotes that the service type on the destination node is unavailable and correlates all the other probe failures from all source IP addresses with it.

Causes for QA Probe Failure Between Sites

  • When a specific source site fails to reach a specific destination site

    Incidents Generated:

    • SiteNotReachable

      Severity: Critical

    • SiteReachable

      Severity: Normal

    Root Cause Analysis:

    • All ICMP probes from a source site to a destination site fail.
    • Destination site cannot be reached from the source site.

    As a result, all other QA probes configured for the destination site fail. The incident denotes reachability failure and correlates all the other probe failures with it.

  • When a source site fails to reach a specific destination site

    Incidents Generated:

    • SiteDown

      Severity: Critical

    • SiteUp

      Severity: Normal

    Root Cause Analysis:

    • All ICMP probes from any source site to a specific destination site fail.
    • Destination site is down.

    As a result, all other QA probes configured for the destination site fail. The incident denotes that the destination site is down and correlates all the other probe failures from all source sites with it.

  • When a service type fails between a source site and destination site

    Incidents Generated:

    • ServiceToSiteNotReachable

      Severity: Critical

    • ServiceToSiteReachable

      Severity: Normal

    Root Cause Analysis:

    • All probes for a service type fail between a specific source site and destination site.
    • The service type is unavailable between the source and destination sites.

    As a result, all other QA probes of the same service type configured for the destination site fail. The incident denotes that the service type is unavailable and correlates all the other probe failures with it.

  • When a service type fails between any source site and a specific destination site

    Incident Generated:

    • ServiceToSiteDown

      Severity: Critical

    • ServiceToSiteUp

      Severity: Normal

    Root Cause Analysis:

    • All probes for a service type fail from all source sites to a specific destination site.
    • The service type is unavailable on the destination site.

    As a result, all other QA probes of the same service type that are configured for the destination site fail. The incident denotes that the service type on the destination site is unavailable and correlates all the other probe failures from all source sites with it.

For information about the correlated incidents raised and affected by NNM iSPI Performance for QA Root Cause Analysis, see Correlated Incidents.

Interpret Incidents

The NNM iSPI Performance for QA generates incidents to enable you to take appropriate action to maintain the health of your network.

For information about incidents generated by NNM iSPI Performance for QA, see the following:

QoS Incident Types Supported by the NNM iSPI Performance for QA

NNM iSPI Performance for QA supports the following incident types:

Metric Name Measurement Management Incident Name Severity
Pre Policy Bit Rate Kbps PrePolicyBitRateHigh Warning
Post Policy bit Rate Kbps PostPolicyBitRateHigh Warning
Packet Drop Percentage PacketDropForClassHigh

Major
Exceeded Packets Percentage PacketsExceedingPolicedRate Warning
Violated Packets Percentage PacketsViolatingPolicedRate Major
Discarded Packets Percentage QueueDiscardPacketsHigh Major
Queue Utilization (Queue Depth/Maximum Queue Depth) * 100 QueueUtilizationHigh Major
Queue Bandwidth Utilization (PostPolicyBytesPerSecond (per class)/bandwidth) * 100 QueueBandwidthUtilizationHigh Major
Dropped Shape Packets Percentage ShapeDroppedPacketsHigh Warning
Delayed Shape Packets Percentage ShapedDelayedPacketsHigh Warning
RED Packets Tail Drop Percentage REDTailDropPacketsHigh Major
RED Packets Drop Percentage REDDropPacketsHigh Major
Marked DSCP Packets Percentage PacketsMarkedDSCPHigh Warning
Marked IP Precedence Packets Percentage PacketsMarkedIPPrecedenceHigh Warning
Marked FRDE Packets Percentage PacketsMarkedFRDEHigh Warning

Baseline Incidents

The following table lists the NNM iSPI Performance for QA baseline incidents:

Incident Name Severity Description

DestinationToSourceNegativeJitterAbnormal

 Critical Measured value of the negative jitter is abnormal during the baseline monitoring time.
SourceToDestinationNegativeJitterAbnormal

DestinationToSourcePositiveJitterAbnormal

 Critical Measured value of the positive jitter is abnormal during the baseline monitoring time.
SourceToDestinationPositiveJitterAbnormal
TwoWayJitterAbnormal Critical Measured value of the two-way jitter is abnormal during the baseline monitoring time.

DestinationToSourcePacketLossAbnormal

 Critical Measured value of the packet loss percentage is abnormal during the baseline monitoring time.
SourceToDestinationPacketLossAbnormal
TwoWayPacketLossAbnormal Critical Measured value of the packet loss percentage is abnormal during the baseline monitoring time.
MeanOpinionScoreAbnormal Critical Measured value of Mean Opinion Score (MOS) is abnormal during the baseline monitoring time.
RoundTripTimeAbnormal Critical Measured value of the round trip time is abnormal during the baseline monitoring time.

Threshold Incidents

The following table lists the incidents raised for NNM iSPI Performance for QA threshold violations:

Incident Name Severity Description

DestinationToSourceNegativeJitterHigh

 Critical Measured value of the negative jitter is higher than the upper boundary of the configured threshold value.
SourceToDestinationNegativeJitterHigh

DestinationToSourcePositiveJitterHigh

 Critical Measured value of the positive jitter is higher than the upper boundary of the configured threshold value.
SourceToDestinationPositiveJitterHigh
TwoWayJitterHigh Critical Measured value of the two-way jitter is higher than the upper boundary of the configured threshold value.

DestinationToSourcePacketLossHigh

 Critical Measured value of the packet loss percentage is higher than the upper boundary of the configured threshold value.
SourceToDestinationPacketLossHigh
TwoWayPacketLossHigh Critical Measured value of the packet loss percentage is higher than the upper boundary of configured threshold value.
MeanOpinionScoreLow Critical Measured value of Mean Opinion Score (MOS) is less than the lower boundary of the configured threshold value.
RoundTripTimeHigh Critical Measured value of the round trip time is higher than the upper bound of the configured threshold value.
TestDisabled Critical Selected QA probe is in Disabled state.
TestError Warning Selected QA probe returned an error.
TestFailed Critical Selected QA probe failed to run.
TestTransient Critical Selected QA probe is in transient state.

Correlated Incidents

The NNM iSPI Performance for QA performs root cause analysis on the failed probes and generates correlated incidents for the probes failed because of common cause. These incidents enable you to identify the cause of probe failure.

The following table lists the incidents raised and affected by NNM iSPI Performance for QA Root Cause Analysis:

Incident Severity Correlated Incidents
TestDestNotReachable Critical TestFailed
TestDestDown Critical

TestDestNotReachable
TestServiceDown
TestServiceNotReachable Critical TestFailed
TestServiceDown Critical TestServiceNotReachable
SiteNotReachable Critical TestDestDown
SiteDown Critical SiteNotReachable

Monitor Using Dashboard View

The QA Performance dashboard is available in the Dashboard workspace only after you install the NNM iSPI Performance for QA. You can access the QA Performance Dashboard by clicking QA Performance in the Dashboard workspace. This dashboard displays the following tables and charts:

QA Performance Dashboard View
Dashboard Item Display Type Description
Probe Reachability % (avg) Graph The graph shows the average Probe reachability % metric value.
Probe Response Time (msecs) (avg and max) Graph The graph shows the average and maximum Probe Response Time metric values, in milliseconds.
Top 10 Probes by RTT (msecs) (avg) Table Ranks top 10 probes with the highest average Round Trip Time, in milliseconds.
Probe RTT, Jitter (msecs) (avg) Graph The graph shows the average Round Trip Time (RTT) and Two-Way Jitter metric values of all the probes, in milliseconds.
Interface Bandwidth Utilization % (avg) Graph The graph shows the average of interface bandwidth utilized by QoS classes in percentage (%).
Pre and Post Policy Rate (kbps) (avg) Graph The graph shows the average Pre Policy Rate and Post Policy Rate metric values, in kbps.
Top QoS Interfaces by Bandwidth Utilization % (avg) Table Ranks top 10 QoS interfaces with the highest Bandwidth Utilization % metric values.
Top 10 Class Packet Drop % (avg and max) Table Ranks top 10 Traffic Classes with the highest and its average Class Packet Drop % metric values.
Top 10 Ping Latency Pairs by RTT (avg) Table Ranks top 10 Ping Latency Pairs with the highest (average) Round Trip Time in milliseconds.
Ping Latency RTT (ms) (avg) Graph The graph shows the average Ping Latency RTT metric values.
Ping Latency Interface Utilization % (avg) Graph The graph shows the average Ping Latency Interface Utilization % metric values.

By default, the graph displays the line graph of the metrics. You can select the area, bar, or scatter graph for a detailed analysis.

Monitor Using Reports

The NNM iSPI Performance for QA provides you with reports that enable you monitor interface health, traffic flow through a specified interface and check the health of the NNM iSPI Performance for QA.

Launch Source Interface Reports

The NNM iSPI Performance for QA enables you to view source interfaces for the QA probes and analyze the traffic flows passing through the interface.

The NNM iSPI Performance for QA maps the interface only if the Network Node Manager i Software has discovered the interface and the interface information is available in the NNMi database. If the source IP is management IP, the NNM iSPI Performance for QA does not display the interface.

Using this feature, you can:

  • Monitor the interface health for a specific time range.
  • Monitor the traffic flow through the specified source interface for a specific time range.
  • Launch the NNMi Interface form and view the interface details.

Follow any of these techniques to configure the source interface to a QA probe:

  • For QA probes, specify the source IP address to the QA probe.
  • For RFC 4560 QA probes or Juniper RPM QA probes, specify the source interface index when configuring the QA probes.
  • You can also use the Probe Configuration form. For more information, see Manage QA Probes

The NNM iSPI Performance for QA maps the source IP address or the interface index configured for the QA probe to the interface in NNMi.

To launch the interface and traffic flow related reports for the source interface:

  1. Click next to the Source Interface in the QA Probes form.

  2. Select Open.

    The Interface form opens.

  3. Select Actions and Reporting - Report Menu to display the reports related to the interface.

For example, the Jitter or VoIP QA probe is configured on the edge router and the edge router is multi homed with different ISPs. So the selected metrics makes more sense when the correct interface for sending the traffic is picked. So the customer configures the QA probe with an interface. In this case, the interface is stored in the DB and also dumped to NNM iSPI Performance for Metrics Software for reporting.

Assume that there is a threshold violation and the customer wants to see all the Top N talkers, scoped by the interface. This is achievable because the interface is stored in NPS and all reports are scoped by interface.

Customer can pick all the ‘conversations’ between this source and destination to find the root cause.

Launch Application Health Reports

You can check the health of the NNM iSPI Performance for QA by viewing the QA Health Report.

To launch the Application Health Report:

Select Help → Help for NNM iSPIs → QA Application Health from the NNMi console to check the health status of NNM iSPI Performance for QA.

The user interface displays the following tabs:

  • Memory Details
  • CPU Usage Details
  • System Load Avg, Swap and other details
  • Database Connection Details
  • State Poller Health
  • GNM Health

The Memory Details tab contains the following information:

  • Name
  • Status
  • Used (%)
  • Max (MB)
  • Committed (MB)

The CPU Usage Details tab displays the QA CPU Utilization information only for Linux platforms:

  • CPU Usage Details
  • Load Average

The System Load Avg, Swap and other details tab contains the following information:

  • Available Processors
  • Free Physical Memory
  • Physical Memory
  • Committed Virtual Memory
  • Free Swap Space
  • Total Swap Space

The Database Connection Details tab contains the following information:

  • Connections Available
  • Total Connections
  • Maximum Connections in Use
  • Maximum Created
  • Connections Destroyed
  • Connections in Use

The StatePoller tab contains the following information:

  • Collections Requested in Last 5 minutes
  • Collections Completed in Last 5 minutes
  • Collections in Process
  • Time to Execute Skips in Last 5 minutes
  • Collection Collector State Count in Last 5 minutes
  • Poller result queue length 5 min(avg)

The GNM Health tab contains the details of the Regional Managers configured.

Monitor Using Graphs

The Real Time Line graph enables you to do the following tasks :

  • View the graph based on the real-time data of the metrics
  • View the graph for QA probes configured on a node
  • View the graph for selected QA probes

  • View the trend of the selected metric value, and analyze the performance based on the metric values at polling intervals

The NNM iSPI Performance for QA supports Multi-Tenancy architecture configured in NNMi. A user can view the Real Time Line graph only if the source node or QA probe can be accessed by the user.

You can view a toolbar in the Real Time Line graph. See Using Line Graphs topic in the Network Node Manager i Software Online Help for information about the toolbar.

Launch Real Time Line Graphs

Perform the following steps to launch a Real Time Line graph:

  1. Log on to NNMi console using your user name and password.

  2. You can either launch the graph for the QA probes configured on the node, or you can launch the graph for selected QA probes from one of the following Inventory views:

    • QA Probes View
    • Critical Probes View
    • Threshold Exceptions Probes View
    • Baseline Exceptions Probes View

  3. To launch the graph for QA probes configured on a node, follow these steps:

    1. Click Inventory in the Workspaces panel.
      The Inventory tab expands.
    2. Click Nodes, and the Node view appears.
      Select the node for which you need to view the Real Time Line graph.
    3. Select Actions →Quality Assurance → Graph → <Service> → <metric name> → <metric sub menu>
  4. Alternatively, to launch the graph for selected QA probes, follow these steps:
    1. Click Quality Assurance in the Workspaces panel. The Quality Assurance tab expands, displaying the QA Probes view.
    2. Select the QA probes for which you require to view the Real Time Line graph.
    3. Select Actions → Quality Assurance → Graphs → <metric name> → <metric sub menu>

    If a node has numerous probes configured, it is recommended you launch the Real Time Line graph for selected probes rather than launching the Real Time Line graph for a node. This facilitates you to make use of the Real Time Line graph effectively.

  5. The following table lists the valid service, metric name and the metric sub menu:

    Service Metric Name Metric Sub Menu
    UDP or TCP or VoIP Jitter
    • Mean Opinion Score
    • Negative Jitter DS
    • Negative Jitter SD
    • Positive Jitter DS
    • Positive Jitter SD
    • Two Way Jitter
    Packet Loss
    • Percentage Packet Loss DS
    • Percentage Packet Loss SD
    • Two Way Packet Loss %
    Round Trip Time
    • RTT in Milliseconds
    • RTT in Microseconds
    ICMP Echo Round Trip Time
    • RTT in Milliseconds
    • RTT in Microseconds
    UDP Echo Round Trip Time
    • RTT in Milliseconds
    • RTT in Microseconds
    HTTP or HTTP(S) Round Trip Time
    • RTT in Milliseconds
    • RTT in Microseconds
    DHCP Round Trip Time
    • RTT in Milliseconds
    • RTT in Microseconds
    DNS Round Trip Time
    • RTT in Milliseconds
    • RTT in Microseconds

    The Real Time Line Graph appears. In a Global Network Management environment, you cannot view the Real Time Line graph for the remote QA probes.

    Also, you can view the Real Time Line graph only for the metrics supported by the vendor-specific devices.

    All the metrics of NNM iSPI Performance for QA are supported by Cisco devices.

    The Juniper RPM devices supports the following metrics:

    • Negative Jitter DS

    • Negative Jitter SD

    • Positive Jitter DS

    • Positive Jitter SD

    • Two Way Packet Loss

    • RTT in Milliseconds

    The other devices supporting the DISMAN-PING using RFC 4560 supports only the RTT Milliseconds metric.

    An error message appears if you select a metric not supported by the vendor device.

  6. You can view a tool bar in the Real Time Line Graph, which facilitates you to traverse and extensively use the graph. The tool bar has the following menus and sub-menus:

    7. Menu Sub-Menu Description
    File

    Select Lines...

    		 Select lines in the real time line graph.
      Export to CSV Export the real time line graph to a csv file.
      Print... Print the real time line graph.
    View

    Legend

    		 View the legend for the real time line graph.
      Time Line Viewer Highlight a section of the data in the graph and continue to display all the data available.
     

    Lock Y-Axis

    		 Lock or unlock the Y-axis while viewing time segments of the graph.
      Notification History View the notification history in a pop up window.
    Help

    Graph Data Description

    		 Get help on the graph data description.
      Using Line Graphs Get help on using line graphs.
  1. You can select the polling interval:
    2. Field Name Description
    Polling Interval(s)

    Select the polling interval in seconds to view the real time line graph for the selected interval.

You can specify a polling interval that is greater than the QA probe polling frequency to make optimal usage of the graph.

If you launch the graph for QA probes configured on multiple nodes, you can view the following:

The X-Axis displays the unit of time, and the Y-Axis displays the selected metric for which you can view the graph.

You can view the graph of all the QA probes configured on the nodes and infer the trend of the metric for the time period. Each QA probe is identified by a unique color to distinguish the trend of all the QA probes in the graph. The color representing each QA probe appears in the legend of the graph.

If you launch the graph for selected QA probes, you can view the following:

The X-Axis displays the unit of time, and the Y-Axis displays the selected metric for which you can view the graph.

You can view the graph of the selected QA probes and infer the trend of the metric for the time period. Each QA probe is identified by a unique color to distinguish the trend of all the selected probes in the graph. The color representing each QA probe appears in the legend of the graph.

Measure Ping Latency

The NNMi enables you to measure the connectivity between a router and node in your network with the help of ping requests. Using a configuration file provided by the NNMi, you can define a router-node pair to trigger ping requests from the router to the node. The NNMi initiates ping requests originating from a source router to a destination node (defined by a router-node pair or a ping latency pair), collects the statistics of the ping from the router, and displays the statistics, such as round-trip time (RTT) and packet loss details, in the Ping Latency Pairs inventory view.

The Ping Latency Pair feature works only with Cisco routers.

The NNMi collects the ping statistics from the router immediately after a response for the ping request arrives. If the ping request for a router-node pair fails, the NNMi generates an incident. The incident is closed automatically when the ping request for the router-node pair is successful.

To use this feature, you must configure ping pairs by defining source routers and destinations nodes in the PingPair.conf file. For more information, see Configure Ping Latency Pairs. You can also modify the default size and frequency of ping requests if you have administrator or root access to the NNMi management server. For more information, see .

Access the Ping Latency Pairs Inventory View

The Ping Latency Pairs inventory view enables you to view the list of configured ping latency pairs in the network.

To launch the Ping Latency Pair Inventory view:

  1. Log on to the NNMi console using your user name and password.
  2. Click Quality Assurance in the Workspaces panel.
  3. Click Ping Latency Pairs. The ping pair nodes that are discovered in your network appear in the content pane along with some key attributes.

Key Attributes of the Ping Latency Pair Inventory View

The Ping Latency Pairs Inventory view displays the following key attributes:

Attribute Name Description
Status

The status of the configured ping pair. NNM iSPI Performance for QA calculates the status based on the polling status of the ping pair nodes and the threshold states. The status can be any one of the following:

  • Normal
  • Critical
  • No Status
Name

This is a combination of the FQDN of the source router and IP address of the destination node. This attribute appears in the following format:

<Source_FQDN>_<Destination_IP>
Source The name of the source node.
Source IP The IP address of the source node.
Destination The name of the destination node.
Destination IP The IP address of the destination node.
Manager Specifies whether the NNMi management server is Local or not. The name of the Regional Manager is displayed if the NNMi management server is not local.

In case of large number of Ping Latency Pairs, you can filter them based on the various QA groups. As you type, the auto-complete feature lists the matching QA Groups. You can select a QA Group name from the list.

Analysis Pane

The Analysis pane for the selected Ping Latency Pair shows the following details:

Attributes Description
Ping Pair Details Summary Denotes the status of the selected Ping Pair.

The status can be one of the following:

  • Normal
  • Critical
  • No Status
Name The name of the ping pair that you provide during the configuration.
Threshold State Displays if any configured thresholds are violated for the selected ping latency pair.
Latest Polled Values

Displays the following details of the source element for latest polling cycle:

  • RTT (in milliseconds)
  • Interface utilization

Performance Tab

The Performance tab enables you to analyze the performance faults for the selected ping pair with the help of graphs. The graph shows the following information:

  • RTT value of the selected ping pair
  • Reachability of the selected ping pair
  • Packet loss of the selected ping pair

You can easily monitor and analyze the performance of the ping pair from the color of the status. Whenever any problem arises, you can view the status in the Performance tab. The status of the ping pair enables you to easily determine the root cause of the fault.

The following table indicates the status information:

Ping Pair Status Status color indicating in the graph
Nominal Normal
High, Low Major
Critical Critical
No status No Status
Unavailable, Unknown Unknown
Not Polled, Threshold not set, Not defined Disabled

View Ping Latency Pair Details

The Ping Latency Pair Form view displays the details of a selected ping pair.

Ping Pair Details

Details Description
Name

This is a combination of the FQDN of the source router and IP address of the destination node. This attribute appears in the following format:

<Source_FQDN>_<Destination_IP>
Status

The status of the configured ping pair. The status can be one of the following:

  • Normal
  • Critical
  • No Status

Source Details

Details Description
Source The name of the source node.
Source IP The IP address of the source node.
Source Interface The interface name on which the source node resides.

Destination Details

Details Description
Destination The name of the destination node.
Destination IP The IP address of the destination node.
Destination Interface The interface name on which the destination node resides.

Source Proxy Details

Details Description
Node Name The name of the proxy source node.
IP Address The IP address of the proxy source node.

The right pane of the Ping Latency Pair form displays the QA Groups tab. The QA Groups tab lists the groups to which the selected ping pair belongs.

Valid Ping Latency Pair Statuses

The system displays any one of the following valid Ping Latency Pairs statuses while polling:

Status Description for Operators Description for Administrators
Normal The source node is Ok or Enabled The source node or site is Active or Enabled
Warning

The source node has returned one of the following statuses:

  • Other
  • Disconnected
  • Over the threshold value
  • Busy
  • Not Connected
  • Dropped
 The source node or site is Active or Enabled
Major Indicates the metric in QA probe breaches the threshold level. Indicates the metric in QA probe breaches the threshold level.
Critical

The source node has returned one of the following errors:

  • Timed out error
  • Sequence error
  • Verify error
  • Application specific error
  • DNS server timeout error
  • TCP connect timeout error
  • HTTP transaction timeout error
  • DNS query error
  • HTTP error
  • State error
  • Source node or site disabled

The source node or site has returned one of the following statuses:

  • Not ready
  • Create and go
  • Create and wait
  • Destroy
Unknown

The source node has returned one of the following errors:

  • SNMP error
  • If there is no polling policy

The source node or site is Active or Enabled.
Disabled The source node is disabled.

The source node or site has returned one of the following statuses:

  • Not in service
  • Disabled
Not Polled Indicates that the user has selected not to poll the source node. Indicates that the user has selected not to poll the source node.
No Status
  • When the node is not managed – Indicates the node is intentionally not managed. For example, certain nodes may not be managed during scheduled network maintenance cycles. Network Node Manager i Software does not update discovery information or monitor these nodes.
  • When the node is out of service – Indicates a node is unavailable because it is out of service. NNMi does not update discovery information or monitor these nodes. This attribute is useful for notifying NNMi when a device has been temporarily out of service, or should never be managed.
  • When the node is not managed – Indicates the node is intentionally not managed. For example, certain nodes may not be managed during scheduled network maintenance cycles. NNMi does not update discovery information or monitor these nodes.
  • When the node is out of service – Indicates a node is unavailable because it is out of service. NNMi does not update discovery information or monitor these nodes. This attribute is useful for notifying NNMi when a device has been temporarily out of service, or should never be managed.

Related Topics

Overview of Real Time Line Graph

Send Help Center feedback