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 2

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

JYatMicroFocus

In my last blog post, I discussed how to enhance network monitoring by changing the node status on the NNMi topology map when out of compliance with policy in Network Automation.

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 (NA) 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.  This week, I have a second use case – Reset GRE tunnel interface on Cisco Routers.”

 

Use Case 2 – Reset GRE tunnel interface on Cisco routers

Customers configured a GRE tunnel interface hosted on a physical interface (tunnel source) on a router. When the tunnel interface was down, NNMi received an InterfaceDown incident.  However, the user would have to search in the entire router’s configuration to identify the tunnel source. Then the user manually shuts down and brings up the physical interface, hence the tunnel interface.  Customers have said that they would like to have this manual remediation fully automated.

The customized solution to meet this requirement is to implement an action which is invoked by the tunnel InterfaceDown incident.  The action would call NA APIs to retrieve the configuration of the tunnel interface and identify its tunnel source interface.  The action would then call NA APIs to run Change Plan tasks which would shut down and bring up the physical (tunnel source) interface, hence bring up the tunnel interface as well. The following are the three steps to implement the solution:

Step 1 – Configuration an action script for Management Event “InterfaceDown”

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

 

b. )Double click on the “InterfaceDown” from the list, then choose the “Actions” tab:NNMi Management Event 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 the tunnelreset.sh script and put it in /var/opt/OV/shared/nnm/actions/ directory.

Note: I also passed three parameters to the script:

$managementAddress – the node’s management IP address

$sourceNodeLongName – the node’s long name

$ifName – the interface name (only the tunnel interface down will be considered)NNMi Lifecycle Transition Action.png

 

Step 2 – Create two Change Plans on NA server

a). ShutdownInterface – this change plan will shut down an interfaceNNMi Shutdown interface.png

 

b). StartInterface – this change plan will start an interface

 

NNMi Startinterface.png

Step 3 - Implement the action script 

 a). The script will check the parameter ifName, the interface name. If it starts with “Tu” (most customers name tunnel interfaces starting with “Tu”), the script will call NA API to get the complete device configuration, and from the configuration the script will fetch the source interface of the tunnel interface. Here is the code excerpt:Public string.png

b). The script will call NA API to run two Change Plan tasks, ShutdownInterface and StartInterface:Public void start interface.png

 

 

Example 2

In this example, the router ‘cairns’ has a tunnel interface ‘Tu201’ which is hosted on a physical interface ‘FastEthernet0/0’:

 

Interfaces.png

 Now, for some reason, the tunnel interface ‘Tu201’ was down. NNMi received an InterfaceDown incident:

 NNMi Interface down.png

 Interfaces 2.png

This incident invoked the action script “tunnelreset.sh”.  The script called NA API to retrieve the Tunnel201 Interface configuration as shown below:Tunnel1201.png

 

From the configuration, the script fetched the “Tunnel Source” of ‘Tu201’:

Tunnel source FastEthernet0/0, destination 172.16.30.201

The source interface of Tu201 is FastEthernet0/0.

The script then called NA API to run the change plan “ShutdownInterface” to shut down the Tunnel Source “FastEthernet0/0”:script to shutdown an interface.png

 

Interfaces 3.png

The script waited for 60 seconds, then called NA API again to run the change plan “StartInterface” to start Tunnel Source:Script to start an interface.png

 This step brought up Tunnel Source, as well as the Tunnel201, as shown below:NNMi Tunnel Source.png

 And the InterfaceDown incident was closed:All incidents.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.  You can get access to the complete source code attached to this blog below.

 

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