This post is a tech dive into HP NNMi 9.10, intended to illustrate a way to create custom incidents. People that make a living from tuning and playing with NNM should find it rather interesting, others are encouraged to seek amusement elsewhere….
NNMi 9.10 is a substantial progress from NNM editions before 8.xx. It is an entirely new implementation, based on JBoss and designed as NNM should have been all along: Multithread, multiuser, with a decent database and an open (web services) API. Being new, certain things are done in a different way, and one of them is generating custom incidents.
Recently I was asked to implement in NNMi 9.10 a way to create an event and change the status of a network node whenever a certain condition occured. The nodes in question were branch office routers with ISDN interfaces as backup lines and the condition was the activation of the ISDN interface. The customer wants their NOC to be alerted whenever a branch office router activates the ISDN interface when the primary line goes down. The catch here is that a switch to the ISDN backup line is not regarded as an event from the NNMi perspective, since whenever the router detects that the primary route goes down, it turns it administratively down and brings up the ISDN interface, so there is no fault: The router is polled normally from the ISDN side from NNMi and no incident is created, the node remains green.
In previous versions of NNM, it was possible to change the internal OvIfUp event of NNM so that it triggered an external action, a perl script that manually changed the node status and created an NNM event. With NNMi 9.10, this is no longer the case. So, what do we do now?
The first step is to go to the configuration menu -> Custom poller configuration and create a custom poller collection, as above. Enable the custom poller and create a new one, with the name “ISDN Poller”.
Above is the poller creation form. The important stuff is the MIB expression and the MIB Filter variable. What we want is to check the operational status of the ISDN interface: The algorithm that the poller should do is to poll the interfaces of the router, filter out the ISDN interface via the “ifDescr” MIB variable and then check the value of the operational status of that interface. If this is “Up” the router should be set in the “Major” state. This is shown in the form above: The MIB filter is set to ifDescr and we select to poll the ifOperStatus object from the “MIB Expression” field: We create a new expression, select “ifOperStatus” from the MIB mgmt-2 interfaces tree and set the node status to “Major”.
The next step is to make this poller work for us, so we need to bind it to a policy, as shown below. Go to the “Policies” tab and create a new policy. Select the node group that you want the new custom poller to be applied to and type the MIB filter. The MIB filter will be matched to the “MIB Filter Variable” of the previous form, in our case, this is “Dialer1”, which is set to the router as the ISDN interface.
That’s it. After this configuration, the custom poller will be activated according to the defined policy: It will run only for the node group (Collection) you have specified, will poll only the interfaces that their description is “Dialer1”, which in our case are ISDN interfaces, and whenever the Operational Status (ifOperStatus) of these interfaces is set to “1”, which is “Up”, a new incident will be created and the node will turn orange on the map (Major status). Straightforward? No. Does it work? Yes.