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”:
b). Double click on the “NASnmpTrapv1” from the list, then choose the “Actions” tab:
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 message
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:
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:
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.
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 188.8.131.52, as shown below:
I also have a topology map for a node group named “AUSTRALIA”:
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:
The node “perth” is in Normal state:
Now, I put the “TestPolicy” to “Active”, then I ran “Check Policy Compliance” task on this device in NA:
The task failed, i.e., the device is not in policy-compliance (because there is no “deny 184.108.40.206” in its configuration):
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:
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:
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:
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”:
Below are some additional code excerpts:
- Call NA API to query for Policy Compliance status:
- Updated the node status and conclusion accordingly:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.