07-12-2013 06:12 AM
I am working on upgrading NNM 7.5 to NNMi 9.2, which so far has proved to be less than ideal. One of the issues I am working on now is trying to replicate some status mappings we had to do to monitor some ports on our network. We have a device that reports a port as "dormant" instead of down, we tested this by having someone pull the pairs on a live circuit and checking the ipOperStatus. In order to do this ni NNM 7.5 we could use the netmon.statusMapping configuration:
After this configuration change was made, and netmon was restarted, netmon would report status changes from up to dormant as down, which solved our problem with monitoring these ports. It appears this is one of the many things HP decided to rip out of the new NNMi, or at least as far as I can tell. Has anyone else used this configuration and migrated to 9.2?
07-12-2013 07:02 AM
Its a paradiagm shift between 7.5 and anything above 8.0 the only thing that remains the same somewhat is the name and overall place where it fits in managing networks.
What NNMi looks are are IfAdmin status and ifOper status and Management status to built the overall "status" of an interface.
If an interface is Managed and Administratively enabled you will get status changes. Out of the box only interfaces that connect to interfaces of devices in NNMI's inventory are eligible to be automatically managed and monitored if and only if there is some associative information available (ARP, OSPF, BGP, Subnet, CDP , JDP, LLDP etc) that provides logical connectivity between them.
Management by exception! If its not managed any event that is specific to it such as (link down) will be dropped and not registered.
Andy Kemp, CISSP
07-12-2013 07:15 AM
I have added a monitoring rule to poll these interfaces and they show up dorman, but I need an incident generated on the dormant status. The dormant status is not a down status according to any official documentation of the ifOperStatus values, which is why this status does not trigger an event on NNM or NNMi. This is a fault of the device, not the system. However, there was a way to trigger an event in previous versions of NNM, and I need this functionality from a business standpoint.
07-12-2013 07:34 AM - edited 07-12-2013 07:36 AM
"Dormant" would be identified by what code in the IfMib table ? Theres a enhancement request in the owrks right now because the curent implementation also doesnt react well with a code of 2 (aka testing).
There's no current "dormant" status for an interface, the closest would be "blue" or unknown
Andy Kemp, CISSP
07-12-2013 07:44 AM - edited 07-12-2013 07:47 AM
"Dormant" is ifOperStatus value 5
I'm not sure what you mean by it not being a current value, here it is in my NNMi interface inventory...
07-12-2013 07:56 AM - edited 07-12-2013 08:03 AM
Ahh my misunderstanding, I had to look it up since I havent seen one of those since I swapped over from 7.53 to 8.10 in 2008. What sort of equipment is displaying that out of curiousity ?
Its the SNMP agent on the device thats not reporting properly the state change, not an issue with NNMI.
Are you using SNMPv1 by chance ?
Andy Kemp, CISSP
07-16-2013 03:11 AM
It should be possible to create an interface group for that set of ports then run a custom poll against that group looking specifically for ifOperStatus=5 and raise an alert if it occurs.
PS : It will probably be possible to create the interface group based on type, however these days I only create groups based on custom attributes as this ultimately gives much better control (and stops groups randomly changing due to upgrades/additions!)