Interface information for AddressNotResponding incident required

[test123x hugo]

Getting an AddressNotResponding incident for a 'Source Node' which has ~1k IP Addresses on one of its 2.5k interfaces is rather daunting...
...and more so, where, as happens in many 'Large' or 'Very Large' installations, operators solely depend on incidents. Without acess to the NNMi Console.

 Reason: As of now the only information available in an AddressNotResponding incident is
   -   The name of the Source Node (the node where this affected IP is on one of its 2.5k interfaces...)
   -   The unreachable IP Address
   -   A timestamp (Last Occurrence Time). - Plus two Custom Attributes (CAs), namely,
   -   A verbose information about the fact (com.hp.ov.nms.apa.symptom (String):  ICMPNoResponse)
   -   This incident's own SNMP Object ID  (.1.3.6.1.4.1.11.2.17.19.2.0.1)
That's it.

We cannot afford to have IP Addresses for their inherent beauty; we have them for doing our business.
Hence any not responding IP Address is an affected service which is meant to be delived through that IP.
And we would very much like to know: Which service? - We would very much like to alert those responsible for fixing it.

For doing that efficiently, we would need additional information in an AddressNotresponding incident,
like the hosting interface's Custom Interface Attribute (CIA),
or (as a bare minimum) the Name of the hosting interface, i.e. the needle in the haystack of the 2.5k of the interfaces in the given Source Node.

Obviously we are not struggling alone, as a quick Knowlegde Search clearly shows:

Ever since version 8.11 (way back in 2010) there were many requests of many users of this product
asking for more information in an AddressNotResponding incident.
These requests include
   o  $ifName
   o  interface's CIAs ($customAttrName , $customAttrValue)
   o  $ifAlias
and
   o  being able to do this for only those IP Addresses which are hosted on interfaces in certain Interface Groups 

The current limitation is even more surprising for us when viewing an AddressNotResponding incident in NNMiConsole:
Analysis pane shows 'Source Node' and 'Source Interface', and
in tab: Source IPAdress you can hop to the interface and see all the wealth -- given you have access to the UI. Hence such information seems to be just around the bend, isn't it?

Adding this widely requested fundamental information would make life much, much easier for a significant number of users of this product.

Maybe you can find a way to start bridging this huge gap between 'interface' and 'IP Address' which is currently seen in NNMi?

Related ideas:
https://community.microfocus.com/t5/NOM-Idea-Exchange/NNMi-uCMDB-OBM-Toplogy-integration-should-draw-a-relationship/idi-p/1766117

https://community.microfocus.com/t5/NOM-Idea-Exchange/Addres-Not-Responding-Enrichment/idi-p/2687779

[AkashDeep]

The idea has received an initial review to ensure adherence to our idea submission and community guidelines. More information may be needed at this stage, and we expect the community to help prioritize the idea with comments and community support (votes/kudos).

[tka]

Although distinct in description (from my limited understanding, as a non native English speaker), I would like to copy my comment from 2687779 also here, because I've tried to provide an idea how operator look at interfaces and IP-Addresses:

For our network operator the proper functionality of interface and IP-addresses configured on the interface are the same. From their perspective an interface down and/or a address not responding are used interchangeably for an interface outage.

So at first it is hard to explain them, that interface and IP-addresses are treated by the NNMi as different objects.

Furthermore, we use custom attributes for interface to provide an custom incident attribute in order to route the incident to the team in charge for the affected device, interface, ... . We would appreciate if we could provide the same service for IP-Addresses related to the enriched interface. As mentioned above, this would be natural from the network operating point of view.

From the technical description above I would like to highlight the following data, which would support the fault management process:

o $ifName
o interface's CIAs ($customAttrName , $customAttrValue)
o $ifAlias

These addtional information would gice the operator indications:

- Which interface is affected ($ifName)

- Severity and Side affects of this outage (ifAlias)

- Who is responsible ($customAttrName , $customAttrValue)

[tka]

For our network operator the proper functionality of interface and IP-addresses configured on the interface are the same. From their perspective an interface down and/or a address not responding are used interchangeably for an interface outage.

So at first it is hard to explain them, that interface and IP-addresses are treated by the NNMi as different objects.

Furthermore, we use custom attributes for interface to provide an custom incident attribute in order to route the incident to the team in charge for the affected device, interface, ... . We would appreciate if we could provide the same service for IP-Addresses related to the enriched interface. As mentioned above, this would be natural from the network operating point of view.

From the technical description above I would like to highlight the following data, which would support the fault management process:

o $ifName
o interface's CIAs ($customAttrName , $customAttrValue)
o $ifAlias

These addtional information would gice the operator indications:

- Which interface is affected ($ifName)

- Severity and Side affects of this outage (ifAlias)

- Who is responsible ($customAttrName , $customAttrValue)