NOTICE: Branded Content
NOTICE: 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.
IT Operations Management (ITOM)
cancel

Improve Network Monitoring by Leveraging WebService APIs in NNMi and NA – Part 1

Improve Network Monitoring by Leveraging WebService APIs in NNMi and NA – Part 1

JYatMicroFocus Contributor.

Network Node Manager i and Network Automation, the two core products within Network Operations Management, come with a number of out-of–the-box integrations.  Additionally Network Node Manager I (NNMi) and Network Automation automation software both provide a rich set of WebService APIs which allow our customers to programmatically interact with NNMi and NA servers.  NNMi and NA also have a seamless built-in integration feature which allows the two products to interact with each other using event notification and actions.  The first use case is “Change node status on NNMi topology map when a node violates the policy compliance in Network Automation.”  Next week, we’ll discuss the second use, “Reset GRE tunnel interface on Cisco routers”

 

Use Case 1 – Change node status on NNMi topology map when a node violates the policy compliance in NA

NNMi receives a SNMP trap (NASnmpTrapv1) when NA detects a device is out of policy compliance.  By default, NNMi does not change the node status even if the trap’s severity is “Warning”.  (Some customers would like to change the node status to “Warning” and reflect it on a topology map.)

The customized solution to meet this requirement is to implement an action which will be invoked by the NASnmpTrapv1 trap. The action will call NNMi WebService APIs to change the conclusion and status of the device.  Below are the two steps to implement the solution:

Step 1 – Configuration an action script for SNMP Trap “NASnmpTrapv1”

a). From the NNMi UI Console, choose “Configuration > Incidents > SNMP Trap Configuration”:Configuration Incidents.png

 b). Double click on the “NASnmpTrapv1” from the list, then choose the “Actions” tab:SNMP Trap Configuration.png

 

c). Click the New button (*) to open the “Lifecycle Transition Action” window, and configure an action script as shown below. In this example, I created a natrapaction.sh script and put it in /var/opt/OV/shared/nnm/actions/natrapaction directory.

Note: I also passed two parameters to the script:

$sourceNodeLongName – the node’s long name

$msg – the trap messageLifecycle Transition Action.png

 

 

Step 2 – Implement the action script

The script will search for keywords “Policy Non-Compliance” in the trap message.  If found, the script will call NNMi API to change the node’s conclusion/status:action script.png

 The script will invoke a java client which calls for the “addConclusion” method of the NodeService to update the conclusion and status of the node.  Below is the code excerpt:public void.png

 

 

 

The second part of the script is for remediation of the device policy compliance violation.  I will explain it later.

Note: The complete source code is attached to the bottom of this blog.

Example 1

Let’s demo this solution with a concrete example.  In this example, I defined a policy “TestPolicy” in the NA server. The policy requires a device to deny all traffics from the network 174.16.0.0, as shown below:rule conditions.png

 

I also have a topology map for a node group named “AUSTRALIA”:Australia.png

 I will use the node “perth” to illustrate the solution.

Initially, I put this policy in the “Inactive” state so that all the devices do not violate the policy:

 

policy tag.png

The node “perth” is in Normal state:node summary.png

 

Now, I put the “TestPolicy” to “Active”, then I ran “Check Policy Compliance” task on this device in NA:new task.png

 The task failed, i.e., the device is not in policy-compliance (because there is no “deny 174.16.0.0” in its configuration):Task Information.png

 As a result, NNMi received an SNMP trap from NA indicating that the device perth does not comply with Configuration Policy TestPolicy, rule Deny-174-16-Network:SNMP traps.png

 

This trap consequently invoked the action script /var/opt/OV/shared/nnm/actions/natrapaction/ natrapaction.sh.  As explained above, the script invoked a java client which called NNMi WebService API “addConclusion” to change the node status of perth to “Critical” and set the “Conclusion” to “PolicyViolated” as shown below:Australia 2.png

 

Perth node.png

 

Next, I would like to demo how to restore node status from Major to Normal on Topology Map after remediation of device policy compliance violation on NA.

Now that the user realized from the topology map that a policy compliance violation was detected on the device “perth”, the user then fixed the configuration and the device is now in policy-compliance.  The remediation also triggered a NASnmpTrapv1 trap which invoked the action again.   The message in the trap just stated “Device Configuration Change” on the device “perth”, but it didn’t indicate what is the policy-compliance state.  Therefore, the action script invoked the 2nd part:Remediation of device policy.png

 It made a query to NA server to determine whether the device is in policy-compliance.  Once it received a position response, it changed the node status to “Normal” and set the conclusion to “PolicyComplied”:Conclusions.png

 Below are some additional code excerpts:

  • Call NA API to query for Policy Compliance status:

 

Public Short.png

  • Updated the node status and conclusion accordingly:Change status and conclusion.png

     

 

Summary

This blog demonstrated how to leverage NNMi and NA integration and WebService APIs to develop custom solutions to address some common use cases.  The blog only described the high level solution design and implementation.  As I mentioned earlier, it is not practical to include all the source code in this blog.  Anyone interested in obtaining the complete source code, can get it below. You can also reach out to me in the comments below if you have any questions.

 

Learn more about the Micro Focus Network Operations Manager suite and Network Node Manager I and Network Automation at their product pages.

 

 

 

 

 

 

 

 

 

About the Author

JYatMicroFocus

Attachments