Achieve Network Operational Simplicity Using Automation Scripts

Network automation is imperative to deploy and manage the networks with large-scale cloud-computing architectures. The automation can be achieved through standard model-driven data models. To cater to the automation requirements, you leverage the Cisco IOS XR infrastructure to make API calls and run scripts from an external controller. These off-box scripts take advantage of the exposed interfaces such as NETCONF, SNMP, SSH to work on the network element. However, there is need to maintain an external controller to interact with the router.

To simplify the operational infrastructure, the automation scripts can be run on the router, eliminating the need for an external controller. The execution of the different types of scripts are faster and reliable as it is not dependent on the speed or network reachability of the external controller. Most script types interact with IOS XR Software using standard protocols such as NETCONF. You can download script to the router, configure scripts, view operational data, and set responses to events in the router.

In summary, on-box scripting is similar to off-box scripting, with the exception that the management software that runs in an external controller is now part of the router software. The scripts programmatically automate configuration and operational tasks on the network devices. You can create customized scripts that are based on your network requirement and execute scripts on routers running Cisco IOS XR operating system. The packages that support scripting are provided in the software image.


Note

You can create scripts using Python 3.5.

Explore the Types of Automation Scripts

There are four types of on-box automation scripts that you can leverage to automate your network operations:

  • Configuration (Config) scripts

  • Execution (Exec) scripts

  • Process scripts

  • EEM scripts

The following table provides the scope and benefit of on-box scripts:

Table 1. On-Box Automation Scripts

Config Scripts

Exec Scripts

Process Scripts

EEM Scripts

What is the scope of the script?

Enforce contextual and conditional changes to configurations, validate configurations before committing the changes to detect and notify potential errors. If configuration does not comply with the rules that are defined in the script, an action can be invoked. For example, generate a warning, syslog message, or halt a commit operation.

Run operational commands or RPCs, process the output, generate syslogs, configure system, perform system action commands such as system reload, process restarts, and collect logs for further evaluation.

Daemonize to continuously run as an agent on the router to execute additional checks outside traditional ZTP. Daemonized scripts are similar to exec scripts but run continuously. The script executes operational commands on the router and analyzes the output.

Run operational commands or RPCs, generate, and determine the next steps like logging the root cause or changing device configuration. Event policies can upload the output of event scripts to an on-box or off-box location for further analysis.

How to invoke the script?

All config scripts are processed automatically when commit command is executed on the router.

Exec script is invoked manually via CLI command or RPC.

Process script is activated via configuration CLI command.

Event scripts are invoked by defined event policies in response to a system event and allow for immediate action to take effect.

What are the main benefits of using the script?

Simplifies complex configurations and averts potential errors before a configuration is committed.

Ensures that the network configuration complies with rules and policies that are defined in the script.

Collects operational information, and decreases the time that is involved in troubleshooting issues.

Provides flexibility in changing the input parameters for every script run. This fosters dynamic automation of operational information.

Runs scripts as a daemon to continuously perform tasks that are not transient.

Automates log collection upon detecting error conditions that are defined by event policies.

Uploads the output of event scripts to an on-box or off-box location for further analysis.