Contributor.. AlexTara Contributor..
Contributor..
148 views

HP NNMi version 10.10 NmsApa Issue

I have a special requirement to monitor each individual interface of a router and the way the NNMi's casual engine is managing the incident makes it dificult for me.

My setup is:

I have a router with 3 interfaces . The router is part of the "Important Nodes" node group. I'm using  an intermediate router to simulate conectivity problems by add blocking firewall rules for IP addresses between NNMi server and the router.

The NNMi configuration is the default one. I enabled AddressNotResponding event from management events.

 3 interfaces, management address is on one of them:

IP1: 1.1.1.1

IP2:1.1.2.1

IP3:1.1.3.1 - this is set as management

 Steps to reproduce:

Block IP1. Incident -> AddressNotResponding1

Block IP2. Incident -> AddressNotResponding2

Block IP3 (management). Incident  -> NodeDown

 

Unblock IP1.  NodeDown (Closed); AddressNotResponding1 (Closed)

Ublock IP2.   AddressNotResponding2 (Closed)

 

So at this stage, I still have the IP3 blocked, but from the node's incident tab, all incidents are closed. I can see the critical status of the IP3. The Interface statuses are unknonw (because of unresponsive SNMP). The snmp agent is Critical.

When the first interface (non management) come up, the NodeDown was closed, but in my opinion an AddressNotResponding for IP3 should have being created, but it was not.

After step Unblock Ip2, the router has no active incidents, still an IP address was not responding.

 Is it a normal behavior or an issue? How can I get any incident, related to this node or interface or ipaddress?

0 Likes
5 Replies
Vincent_M_NNM Acclaimed Contributor.
Acclaimed Contributor.

Re: HP NNMi version 10.10 NmsApa Issue

Hello Alex

Thanks for posting,

I think that would be a great idea if you can check this document:

https://softwaresupport.hp.com/group/softwaresupport/search-result/-/facetsearch/document/KM02118448

That link if for the causal analysis NNM performs to conclude any status and incident generation.

Regards,

Vincent Montenegro Mena
Customer Support Engineer

If you find that this or any other post resolves your issue, please be sure to mark it as an accepted solution.
If you are satisfied with anyone’s response please remember to give them a KUDOS by clicking on the STAR at the bottom left of the post and show your appreciation.
0 Likes
Contributor.. AlexTara Contributor..
Contributor..

Re: HP NNMi version 10.10 NmsApa Issue

Hello Vincent,

Thanks for your swift answer.

I’ve studied the document.

I conclude that I have a combination fi Important Node Unreachable, SNMP Agent Not Responding to SNMP Queries and IP Address Not Responding to ICMP scenarios.

The first two steps (block IP1 &IP2) generate AddressNotResponding Scenarios, creating associated incidents.

The third step (block IP3, also management address) applies Critical Node Down scenario, but this being considered the root cause, APA generates only NodeDown Incident. There are no AddressNotResponding and SNMPAgentNotResponding Incidents generated.

When unblocking IP1, the AddressNotResponding and NodeDown incidents are closed and node is set to status Minor, because “One or more IP addresses on the node do not respond to ICMP” and “The SNMP Agent associated with the node does not respond to SNMP queries.”

When unblocking IP2, the second AddressNotResponding is closed.

So at the end, the Node is in status Minor, One IP address is Critical and the SNMPAgent is in status Critical, but there are no incidents, associated with any of them.

It seems to me an error with the NmsApa logic.

 

Important Node Is Unreachable

Scenario: A node that is part of the Important Nodes Node Group cannot be reached.

You must add a node to the Important Nodes Node Group before the NmsApa service analyzes the node. If a node becomes unreachable before being added to the Important Nodes Node Group, the NmsApa service does not generate a NodeDown incident.

Root Cause: The node is down. The NmsApa service does not do neighbor analysis, but concludes that the node is down because it was marked as important.

Incident: A NodeDown incident is generated. There are no correlated incidents.

Status: The node is in Critical Status.

Conclusion: NodeDown

Important Node Is Reachable

Scenario: This scenario continues the previous “Important Node is Unreachablescenario. The important node comes back up and can be reached.

Root Cause: The node is up.

Incident: None generated. The NodeDown incident is closed.

Status: The node is in Normal Status.

Conclusion: NodeUp

0 Likes
Acclaimed Contributor.. AndyKemp Acclaimed Contributor..
Acclaimed Contributor..

Re: HP NNMi version 10.10 NmsApa Issue

What you're not grasping is page 39 and the role of "important nodes" in the logic.  It bypasses all rules.

Important Node Is Unreachable
Scenario
: A node that is part of the Important Nodes Node Group cannot be reached. You must add a node to the Important Nodes Node Group before the NmsApa service analyzes the node. If a node becomes unreachable before being added to the Important Nodes Node Group, theNmsApaservice does not generate a NodeDown incident.
Root Cause
: The node is down. The NmsApaservice does not do neighbor analysis, but concludesthat the node is down because it was marked as important.
Incident:
A NodeDown incident is generated. There are no correlated incidents.
Status : The node is in Critical Status.
Conclusion: NodeDown Important Node Is Reachable
Scenario
: This scenario continues the previous “Important Node is Unreachable”
scenario. The important node comes back up and can be reached.
Root Cause
: The node is up.
Incident
: None generated. The NodeDown incident is closed.
Status:
The node is in Normal Status.
Conclusion:
NodeUp
 
 
Have a nice day 🙂

Andy Kemp
I've lasted longer in the technology industry than most certifications.
0 Likes
Contributor.. AlexTara Contributor..
Contributor..

Re: HP NNMi version 10.10 NmsApa Issue

Hello Andy,

Thanks for clarifications.

I’m not arguing the Important Node Unreachable logic. It seems correct and functional.

I’m questioning the final status of Important Node Reachable event being Normal. This is why:

Before the Important Node Is Unreachable event arrived, the node was in status minor because:

- One or more interfaces in the node are down.

- One or more IP addresses on the node do not respond to ICMP.

 After the Important Node Is Reachable, the node status became “Normal”, even if the condition for being Minor still persist (one IP address is still unreachable).

So my opinion is that after Important Node Is Reachable, the status of the node should not be Normal, as described in the scenario, but the real status of the node, identified in page 7 of the same document:

 Minor – Node Status can be Minor if a managed object contained in the node has a problem, including any of the following

o One or more interfaces in the node are down.

o One or more IP addresses on the node do not respond to ICMP.

Alex.

 

 

 

0 Likes
Acclaimed Contributor.. AndyKemp Acclaimed Contributor..
Acclaimed Contributor..

Re: HP NNMi version 10.10 NmsApa Issue

Important nodes logic overrrides all other.

Have a nice day 🙂

Andy Kemp
I've lasted longer in the technology industry than most certifications.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.