IT Operations Management (ITOM)

A closer look at the 9 stages of the Device Lifecycle in Network Automation

A closer look at the 9 stages of the Device Lifecycle in Network Automation


Guest post by Asadullah Mohammad, Software Testing Engineer


HP Network Automation Software (NA) automates the complete operational lifecycle of network devices from provisioning to policy-based change management, compliance, and security administration. These capabilities are illustrated in the following figure:



A device in NA is a representation of the physical device, which the user performs various operations on, to manage the device.


Start a free trial of HP Network Automation here


What happens to a Device?

In this blog, we are going to look at what tasks or events occur on a device from the time it enters NA.  We are briefly going to discuss tasks which impact the device; as tasks are the primary mechanism by which NA interacts with devices in the network. However, will not get into too much detail of each task, as it is not in the context of this topic (and probably needs its own dedicated space).


From a device perspective, tasks typically undergo a series of stages from the moment it is introduced into NA.


Though, the stages mentioned below are not an actual representation of NA process from HP, they are an interpretation to give a better understanding of the events to NA users from my perspective.


The figure below illustrates the different stages of a Device Lifecycle in NA:


In summary:


  • Stage 1: Import/Add a Device
  • Stage 2: Automatically Triggered Tasks on a New Device
  • Stage 3: Scheduled Tasks
  • Stage 4: Rule Based Triggered Tasks
  • Stage 5: Managing Device Configuration
  • Stage 6: Device Software Updates
  • Stage 7: Compliance Check and Auto-Remediation
  • Stage 8: Other Device Specific Tasks
  • Stage 9: Deactivate/Delete the Device

 Let's look at these in more detail.


Stage 1: Import/Add a Device

The New Device Wizard and the New Device task can bring a single new device in NA.


The Import task and the Detect Network Devices task helps importing multiple devices into NA at one time. NA provides Device CSV Template which can be duly populated and used in Import task, while Detect Network Devices task uses IP range. The same can be achieved via the CLI as well.


During the process of importing/adding of a device, NA authenticates the device using Use network-wide password rules or Use device-specific password, each of which has multiple parameters such as the following:


  • Username
  • Password
  • Enable Password (if applicable)
  • SNMP Read Community String
  • SNMP Write Community String
  • SNMPv3


Additionally, the Device Access Settings provides further support for your unique network configuration.


Upon the completion of any of these tasks, the device shows up in NA Inventory.


These tasks also have Discover Driver task and Configure Syslog task selected by default in their task settings.


However, if you do not want NA to auto discover driver or configure syslog, you may do so by clearing the default selections while importing/adding the device.


Stage 2: Automatically Triggered Tasks on a new Device

HP Network Automation tries to discover the vendor/model of the device. If successful, it will retrieve and store the device configuration. Upon completion, NA configures the device for change detection.

This is done via series of device-specific tasks which are automatically triggered as a subsequent step of Import task, to identify the device configuration.


Discover Driver: This is non-recurring task triggered as soon as the device is introduced into the NA.


Using the authentication rules specified, the NA establishes a connection via one of the connection methods specified during device import. It then performs ‘SNMP Get’ to identify the device details which consist of the driver information along with other relevant information. The Device Password Rules used are tried in the order in which they are listed. Once the connection is established with the device, the same password is set for Password Selection—for future use. This saves time when the connection is established for subsequent connection requests. Similarly it works for Connection Method, by trying Telnet first followed by SSH and so on. However, Connection Methods may vary depending upon the type of information being retrieved from the device.


Once Driver Discovery is successfully done, a snapshot task is initiated automatically as a child task.


Take Snapshot: Automatic snapshot is triggered, after driver discovery. In this the task, NA establishes the connection with the Device and executes certain commands via CLI to retrieve information such as:


  • Version Information
  • Ancillary settings
  • Configuration
  • Startup configuration
  • VLAN configuration from vlan.dat file
  • Interface information
  • Ethernet power information


Once all the relevant information is retrieved, device ACLs are parsed from configuration.

The snapshot is stored in the database.


Configure Syslog: Configure Syslog task is scheduled automatically following driver discovery for newly added device. This task enables syslogging on the device via CLI, for change detection. The user can view the new configuration of the device to check the entry of the NA server IP.


If there is any further change in the configuration of the device, a syslog message is received by the NA server and a new snapshot task is triggered and stored in the database.


Run Diagnostic:  Whenever a configuration change is detected,  a diagnostic task is triggered to capture standard diagnostics. The Diagnostic task helps to fetch the Device File System, Module Status, Routing Table, Interfaces, and OSPF Neighbors. Also, VLAN Data Gathering Diagnostic task gets scheduled, if a configuration change is detected.


Deduplication: This task gets scheduled automatically only following Detect Network Devices task, for newly added device. This is to resolve instances of device duplication within the NA database.


Stage 3. Scheduled Tasks

There are certain scheduled tasks that are repetitive, which come available out of the box in NA. The frequency of the repetition can be edited according to your needs.


Run Diagnostics: Regularly detects device boots and repeated periodically every 21,600 seconds on the entire inventory. This task operates in parallel with other devices.


Another similar task gathers Module Inventory Data and is repeated weekly; weekdays= Saturday on the entire inventory. This task operates in parallel with other devices.


Take Snapshot: Regularly polls for device configuration changes and this process is repeated periodically every 21600 seconds on the entire inventory. This tasks operates in parallel with multiple devices. The task stores snapshot only incase, if there is a configuration change. However, you can edit it to save configuration regardless of whether there is change, by selecting ‘Make snapshot a checkpoint’ check box.


Data Pruning: Prunes the database to optimize it and is repeated weekly; weekdays= Sunday

Though there are only five scheduled tasks created by default. However, you can create and schedule other tasks in NA to trigger at a regular interval.


Stage 4: Rule Based Triggered Tasks

There are some rule-based events configured in NA. Some of the tasks get automatically triggered based on certain conditions being met as defined in the rules.


Run Command Script: A task which gets triggered if available space is detected to be low in the device, and a ‘compact’ script is executed to compress flash storage.


Run Diagnostic:  A built-in rule in NA to Capture Diagnostics is triggered on every Configuration Change.


Once NA captures diagnostics of various types, it can be viewed from the diagnostics page of the device.


Take Snapshot task is also triggered based on a built-in rule in NA, when the deployment of device configuration fails.


OS Analysis: A non-recurring task is triggered to analyze the OS and provide relevant Software Image Recommendation—once the inventory collection succeeds and the device shows up as managed in NA. This helps the user to identify the appropriate image for the device which can be used to update the device software using Update Device Software task.


Check Policy Compliance: Whenever the devices are reloaded or they experience a configuration change, NA validates the device against the policy assigned to its group. Each and every rule is checked to verify whether it applies or not. Then based on compliance status, the Auto-Remediation Script is executed to bring the device into compliance.


Stage 5. Managing Device Configuration

The series of tasks prior to this stage has already ensured that the entire device details, including the latest configuration changes, have been stored in the database. The tasks discussed earlier in this topic enables the user to identify what changes were made and by whom.


Network Automation maintains a history of device configuration and comparisons complete with last changes. You can easily identify the changes between current and previous configurations because NA highlights them in different colors and deploys the configuration per your requirement.


Deploy Configuration task allows you to deploy configurations based on multiple choices available under the device configurations page for older—as well newer configurations:


  • Deploy to running configuration
  • Deploy to startup configuration
  • Deploy to startup configuration and reboot

NA also indicates in its device view that the Startup and Running Configurations differ and suggests synchronizing the configuration by providing a hyperlink to Synchronize Startup and Running task.


Synchronize Startup and Running task enables synchronizing the startup and running configurations by overwriting the startup configuration with the current configuration, using a built-in script executed via CLI. This ensures that current configuration continues to run on the device reboot. However, NA overwrites startup configuration with the current configuration only when the checkbox ‘Force Save: If applicable, save the running configuration to the startup configuration upon task completion’ is selected. If NA should not change the startup configuration, make sure you clear this checkbox if you don’t want to force save.


NA also extracts the ACL statements and applications from the configurations and stores it independently of the configuration.


Run Commands Script allows you to manipulate ACLs using various scripts available out of the box, ACL Advanced Script types:


  • Cisco IOS Initial Setup
  • Cisco IOS Insert Line into ACL by Handle
  • Cisco IOS Insert Line into ACL by ACL id
  • Cisco IOS Remove Line into ACL by Handle
  • Cisco IOS Remove Line into ACL by ACL id

You can create multiple Run Command Script task to do various manipulations on the device depending on your need, using the 36 inbuilt scripts. A few can be seen in the figure below:



Also, you can limit the script types as per options seen in the figure below:



You may also use Delete ACLs task to remove older ACLs from device configuration.


Stage 6: Device Software Updates

The OS Analysis task collects information about the Cisco devices and the recommended software updates for those devices. Based on this recommendation, you can download images and add to the image set. Although, this is an automatically scheduled task, you may run it again to get the latest recommendations.


Download Image from task allows you to download images from to NA software repository i.e. Image set which is a groups of images.


Update Device Software task uploads image set which uploads each image in turn. If there is a problem during upload (e.g. size limit exceeds on the device), the rest of the upload is aborted.


Using this task, you may remove an image or files from the device to free up memory and replace them with your own image set.


You may also select which image should be set as the boot image for the device. This may take effect only after you reboot, depending upon the device. For this Reboot device after deploying software must be selected in this task.


There are several best practices recommended by HP that you should follow while updating device software. Please refer to the HP Network Automation Software User Guide [Login required] for details on it.


The figure below illustrates the overall process.



Backup Device Software allows you to create a backup of software images of a device or group of devices in the NA software image repository, based on Image Synchronization Report. This allows all the software images to be available in case of an emergency.


Stage 7: Compliance Check and Auto-Remediation

NA comes with four built-in compliance policies which are in an inactive state.


As discussed in an earlier section, once you set the policies as active or create new policies per your requirement, NA validates the device against the policy assigned to its group. This is triggered whenever the devices are reloaded or experiences a configuration change.


Check Policy Compliance tasks enables you to validate the device against the policies.  The result details on the task summary will show that the device is non-complaint and will inform you of which policy and which rules it is in violation of.


Alternatively, on the device home page, you can find the alert saying the device not in compliance with one or more policies. The Policy Events link will land you on Policy Activity page, where you can see the summary of events when the device is non-compliant with policies.


A policy has a set of rules which are automated tests validating at least one of the following:

  • Specific Configuration Settings
  • Specific Data model elements
  • The runtime state of a device (also known as diagnostic)
  • The software version running on the device

A diagnostic command is run on the device which collects info about the device which is not captured in a configuration file.


Besides this, each rule may have an Exception List and Auto-Remediation script configured. Each and every rule is checked to whether it applies or not, and then based on compliance status, the auto-remediation script is executed to bring the device in compliance. If the rule does not apply to a device, it is skipped for that device.


Stage 8: Other Device Specific Tasks

Although, we have discussed almost all of the device-specific tasks which are either triggered because of some event, are scheduled out of the box or have specific functions with respect to managing, configuring and keeping device in compliance, let’s have a look at few remaining ones which can be used otherwise.


Run ICMP Test: - Issues a ping or trace route command.


Deploy Passwords: - Change the password settings and SNMP community strings on a device using script executed through CLI via Telnet or SSH session.


Reboot Device: - Reboot a device to force save the configuration and take effect.


Provision Device from Template: Provision a device from NA device template.


Add Device Context: - Add a context to a device in Device Configuration and NA database. NA automatically discovers context on the parent device using NA Module diagnostics and Interface diagnostics.


Add VLAN: - Provision new VLAN entities and trunk ports. Upon adding VLAN ID and NAME to the device, this task gets created which established Telnet or SSH connection with the device and updates the device with VLAN information, which in turn triggers VLAN Data Gathering Diagnostic task and other tasks triggered due to configuration change.


Port Scan: - Scan the ports of a device to identify open ports, closed ports, and certain vulnerabilities.


Stage 9: Deactivate/Delete the Device

Deactivate the Device:

Once you Deactivate the device from device view, management of the device gets disabled.


You will not see any device-specific tasks available from device view (the tasks would be skipped even if you try do from main menu). You will receive the appropriate message, until the device is activated again.

NA continues to retain the device’s information in its database.


Delete the Device

Upon deleting the device from NA, the device will be removed from the system permanently, along with all of its configurations, tasks, relationships and any child context devices, including their data as well. You can perform this task from device view as well as from inventory. However, you will receive an alert prompt before you finally delete the device.


This is final stage of the device as long as it is in NA.


For more information on details of each task discussed in this blog and how to configure them, please refer to the following documents on your installed HP Network Automation Software:


HP Network Automation Software User Guide [Login required]


HP Network Automation Software Administration Guide. [Login required]


To check for recent updates, or to verify that you are using the most recent edition of a document, go to: [Login required]


Other articles about network automation:


About the author: Asad has over 9.5 years of experience in Software Testing across multiple domains. He has been with NMC team for over 1.5 years and is currently working with Network Automation Patch QA team since last 1 year. He is responsible for QA deliverables for Network Automation patch releases.


Asad has Bachelor of Engineering Degree in Computer Science from Magadh University, India.





HP Network Automation  software automates the complete operational lifecycle of network devices from provisioning to policy-based change management, compliance, and security administration. Start your free trial today.


Tweet to us at @HPITOps  and let us know what you think! | Friend HP Software on Facebook   | Join our Network Management Solutions group on LinkedIn    







Michael Procopio Procopio
  • infrastructure management
About the Author


HPE Software Product Marketing. Over 20 years in network and systems management.


Very useful article for Network Automation. Well documented !!

New Member.

This is an interesting blog , very informative.

New Member.

Hi Asad,

Great Blog !!

Interesting and Nicely explained the device life cycle in NA !