Manage automation scripts using Yang RPCs

Automation scripts using YANG RPCs

An automation script is a software tool that

  • interacts with network devices using standardized APIs such as NETCONF or gNMI,

  • executes remote procedure calls (RPCs) defined by YANG data models to retrieve or edit device configuration, and

  • enables automated, repeatable, and scalable management operations for network infrastructure.

To use automation scripts for remote management, you must establish an SSH session between the client (the script or application) and the network device (the server). For example, enabling the NETCONF SSH agent on a router requires these configuration commands:

  • ssh server v2

  • netconf agent tty

Once connected, the client sends one or more RPC requests such as get-config to retrieve device configuration or edit-config to modify it. The server processes each request and sends a response.

Table 1. Feature History Table

Feature Name

Release Information

Description

Manage Automation Scripts Using YANG RPCs

Release 7.3.2

This feature enables you to use remote procedure calls (RPCs) on YANG data models to perform the same automated operations as CLIs, such as edit configurations or retrieve router information.

A Python script uses the NETCONF protocol to automatically update interface settings on multiple routers by sending edit-config RPCs. An automation tool retrieves system status from a network device using gNMI and YANG-defined telemetry models.

Common script actions

A common script action is a network automation operation that

  • uses YANG remote procedure calls (RPCs) to manage automation scripts,

  • supports multiple script types such as config, exec, process, and Embedded Event Manager (EEM), and

  • produces output responses that describe the result of each action and indicate success or failure.

YANG RPCs (Remote Procedure Calls) enable centralized and programmatic management of automation scripts within a network device or system. The Cisco-IOS-XR-infra-script-mgmt-act.yang model allows users to add scripts to the repository, remove scripts, execute scripts, and stop running scripts. Each RPC provides a response that includes an operation status (True for success, False for failure) and a descriptive message.

Table 2. Feature History Table
Feature Name Release Information Description

Manage Common Script Actions Using YANG RPCs

Release 7.5.1

This feature enables you to use YANG remote procedure calls (RPCs) on Cisco-IOS-XR-infra-script-mgmt-act.yang data model to perform actions on the automation scripts such as add or remove script from the script repository, run, or stop script from running.

Add a script

Add scripts to the device script repository to automate configuration, execution, or monitoring processes. You can add up to 10 scripts at a time and specify optional checksum values for script integrity.

Use this procedure to add configuration, exec, process, or EEM scripts to your device repository. Adding scripts with checksums ensures the integrity and authenticity of scripts before execution.

Before you begin

Before you begin:

  • Ensure you have access to the device with the required administrative privileges.

  • Prepare your script files and confirm their locations.

  • Optionally, compute and have ready the checksum value(s) for your scripts if you want to verify integrity.

Procedure

Step 1

To add a single script to the repository, use the following RPC call with the script type, source, and script name:

Example:

<add xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-script-mgmt-act">
         <script-type>exec</script-type>
         <vrf></vrf>
         <source>/harddisk:/</source>
         <script-name>sample.py</script-name>
         </add>

The specified script is added to the repository.

Step 2

To add multiple scripts at the same time, list each script name within the same RPC request:

Example:

<add xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-script-mgmt-act">
          <script-type>exec</script-type>
          <source>/harddisk:/</source>
          <script-name>sample2.py</script-name>
          <script-name>sample3.py</script-name>
          </add>

All specified scripts are added to the repository in a single operation.

Step 3

To add a script with a checksum value for integrity validation, use the following RPC request:

Example:

<add-checksum xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-script-mgmt-act">
          <script-type>exec</script-type>
          <source>/harddisk:/</source>
          <script-checksums>
          <script-name>sample.py</script-name>
          <checksum>e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855</checksum>
          </script-checksums>
          </add-checksum>

The script is added to the repository with its checksum recorded for future validation.

Step 4

To add multiple scripts with their respective checksum values, include multiple script-checksums blocks:

Example:

<add-checksum xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-script-mgmt-act">
          <script-type>exec</script-type>
          <source>/harddisk:/</source>
          <script-checksums>
          <script-name>sample.py</script-name>
          <checksum>e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855</checksum>
          </script-checksums>
          <script-checksums>
          <script-name>sample2.py</script-name>
          <checksum>e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855</checksum>
          </script-checksums>
          </add-checksum>

All specified scripts are added with their checksums for verification.

Scripts are successfully added to the repository and are available for management or execution. Scripts with checksums are validated for integrity.

What to do next

After adding scripts, verify script availability and correct checksum status using the script management tools or commands available on your device.

Remove a script

Use this task to remove a script or multiple scripts from the repository by sending an RPC request with the script type and name.

Removing obsolete or unnecessary scripts helps maintain a clean and secure repository environment.

Perform this task when you need to delete scripts that are no longer required or must be replaced in the Cisco IOS XR script repository. This applies to both single and multiple script removals.

Before you begin

Before you begin, ensure you have the required access privileges to send RPC requests to the device and know the exact script type and script names you want to remove.

Procedure

Step 1

Provide the script type and script name(s) for each script to remove.

Example:

<remove xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-script-mgmt-act">
          <script-type>exec</script-type>
          <script-name>sample.py</script-name>
          </remove>

Step 2

If removing multiple scripts, include each script name within the request (up to 10).

Example:

<remove xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-script-mgmt-act">
         <script-type>exec</script-type>
         <script-name>sample2.py</script-name>
         <script-name>sample3.py</script-name>
         </remove>

Step 3

Send the RPC request to the device for processing.

Step 4

Verify the RPC response to ensure the scripts were removed successfully.

Example:

<responses>
            <script-name>sample.py</script-name>
            <response>sample.py has been removed from the script repository</response>
            <status>True</status>
            </responses>

The response indicates the status of each script removal.

The specified scripts are removed from the repository. Confirmation is provided in the RPC response.

What to do next

Review the list of scripts in the repository to confirm that only the required scripts remain.

Stop a script

Use this task to halt an active script on the device. This is useful if you need to interrupt a script that is currently running or if you need to recover from potential script-related issues.

Stopping a script requires the request ID assigned when the script was started. You must send an API request using the documented XML format to instruct the system to terminate the specific script instance.

Before you begin

Before you begin:

  • Identify the request ID for the script you want to stop.

  • Ensure you have access and permission to send API requests to the target device.

Procedure

SUMMARY STEPS

  1. Send a stop request using the required XML payload, replacing with the script's actual request ID.
  2. Verify that the API response includes <status>True</status>, confirming the script has stopped.

DETAILED STEPS

Step 1

Send a stop request using the required XML payload, replacing with the script's actual request ID.

Example:

<stop xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-script-mgmt-act">
          <request-id>1622058854</request-id>
          <description></description>
           </stop>

Step 2

Verify that the API response includes <status>True</status>, confirming the script has stopped.

Example:

<script-stop-response>
            <response></response>
            <status>True</status>
            </script-stop-response>

If the status is not True, confirm the request ID is correct and that the script is currently running.

The script has successfully stopped when status returns True.

The specified script instance is stopped and can no longer perform any operations.

What to do next

You may submit new scripts or manage script instances as needed now that the prior script has been terminated.

Run a script

Execute a specified script file on the device. Optionally, configure logging options for monitoring and troubleshooting.

Running a script automates management or operational tasks and may require different logging levels for troubleshooting. Perform this task when you need to automate a workflow, gather data, or perform custom operations via scripting.

Before you begin

Before you begin, ensure:

  • The script file is uploaded and accessible on the device.

  • You have the correct permissions to execute scripts.

Procedure

Step 1

Specify the script name to run.

Example:

<run xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-script-mgmt-act">
          <script-name>sample.py</script-name>
          </run>

Step 2

(Optional) Set the desired logging level. Available levels include critical, debug, error, info, or warning.

Example:

<log-level>Info</log-level>

Step 3

(Optional) Define other parameters such as log path, maximum runtime, or add script arguments as required.

Example:

<argument-list>--verbose</argument-list>
          <log-path>/var/logs</log-path>
          <max-runtime>300</max-runtime>

Step 4

Submit the run command to execute the script.

The device schedules and initiates script execution.

Example:

<run/>

The system displays an RPC response confirming the script has been scheduled. For example: 

<script-run-response>
          <response>Script run scheduled</response>
          <request-id>1622058854</request-id>
          <status>True</status>
          </script-run-response>

The script runs successfully. Monitor log files and system status as needed to verify completion and review outputs.

What to do next

After running the script, review its output, address any errors, and archive logs for future reference if necessary.

Exec scripts

An exec script is a network automation feature that

  • enables users to execute predefined actions or sequences on network devices,

  • makes use of remote procedure calls (RPCs) to interface with device data models, and

  • supports integration with configuration, action, and operational data models.

Supported use cases for exec scripts

Exec scripts allow automation for common operational tasks, such as configuration backup, data collection, or network health monitoring.

Example of an exec script

For instance, an exec script can be triggered to periodically back up the device running configuration by calling an RPC on the Cisco-IOS-XR-infra-script-mgmt-act data model.

Add an exec script

Use this task to upload an exec script from an external source to the router’s harddisk:/mirror/script-mgmt/exec script management repository for execution via script management features.

This task is used when you need to add a new executable script to automate operations or perform custom actions on a Cisco IOS XR device. You can use either the YANG data model interface or equivalent CLI commands based on your operational preference.

The script add exec script-location script.py is the equivalent command for Cisco-IOS-XR-infra-script-mgmt-act.yang.

Before you begin

Before you begin, ensure:

  • You have the required exec script (for example, sample1.py) available on your file system or accessible from your management device.

  • You have NETCONF/YANG or CLI access with sufficient privileges to execute script management operations.

Procedure

Step 1

Use the YANG data model to add the exec script via NETCONF RPC.

Example:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
          <script-add-type-source xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-script-mgmt-act">
           <type>exec</type>
           <source>/harddisk:/</source>
           <file-name-1>sample1.py</file-name-1>
           </script-add-type-source>
           </rpc>

Upon completion, the system logs a message indicating that the script has been successfully added.

Router: script_manager[66762]: %OS-SCRIPT_MGMT-6-INFO :
            Script-script_manager: sample1.py has been added to the script repository

Step 2

Alternatively, use the CLI to add the exec script directly.

Example:

 script add exec harddisk:/sample1.py

The system confirms successful upload in the CLI output.

The exec script is now present in the script repository (harddisk:/mirror/script-mgmt/exec). It can be managed and executed as required.

What to do next

Optional: Verify the script is available by listing scripts in the repository using appropriate CLI command or NETCONF get operation.

  • To list scripts via CLI: 

    script list exec

Configure checksum

Ensure the integrity of script files by associating a checksum value, such as SHA-256, with the script.

Associating a checksum with a script protects against file tampering or corruption. You can configure the checksum using YANG data models or through the CLI, depending on your management preference.

Before you begin

Before you begin, ensure that:

  • The script file you want to secure (.py, .sh, etc.) is present on the device.

  • The calculated checksum value (for example, SHA-256 digest) is available.

  • You have administrative access via CLI or NETCONF/YANG API.

Procedure

Step 1

Calculate the checksum value for your script file using a utility such as sha256sum.

Example:

sha256sum sample1.py

Step 2

Associate the checksum with the script using one of the following methods:

  • CLI Method: Enter the following command from configuration mode:: 
    script exec sample1.py checksum SHA256 5103a843032505decc37ff21089336e4bcc6a1061341056ca8add3ac5d6620ef
  • NETCONF/YANG Method: Send an edit-config RPC to configure the checksum for the script file: 
    <rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="uuid">
          <nc:edit-config>
          <nc:target>
          <nc:candidate/>
          </nc:target>
          <nc:config>
          <scripts xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-script-mgmt-cfg">
          <exec-script>
           <scripts>
           <script>
           <script-name>sample1.py</script-name>
           <checksum>
           <checksum-type>sha256</checksum-type>
           <checksum>5103a843032505decc37ff21089336e4bcc6a1061341056ca8add3ac5d6620ef</checksum>
           </checksum>
           </script>
           </scripts>
           </exec-script>
           </scripts>
           </nc:config>
           </nc:edit-config>
           </rpc>

Step 3

If using NETCONF, verify that the response contains <ok/> to confirm successful configuration.

Example:

<rpc-reply message-id="uuid" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
          <ok/>
          </rpc-reply>

Step 4

Verify that the checksum is applied by displaying the script properties using the appropriate CLI or YANG command.

Example:

Router# show script exec

The selected script now has an associated checksum value, protecting it against unauthorized modification or corruption.

What to do next

After configuring the checksum, test execution of the script to ensure proper operation and integrity verification.

Run an exec script

Use this task to execute a Python script (such as sample1.py) on the router for automation or system management functions.

You can run Python scripts from the router using either the CLI command or an RPC request through NETCONF/YANG interfaces. Successful execution provides operational insights or enables automation workflows.

Before you begin

  • Ensure the Python script (sample1.py) is uploaded to the router's script directory.

  • Verify you have sufficient privileges to execute scripts on the router.

Procedure

Step 1

Run the script using the CLI command.

Example:

script run sample1.py

A successful command schedules the script for execution and logs the activity in syslog.

The router executes the script and displays status output.

Step 2

Alternatively, run the script via NETCONF/YANG RPC request.

Example:


            <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
            <script-run xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-script-mgmt-act">
            <name>sample1.py</name>
            </script-run>
            </rpc>

A successful execution returns an <ok/> response in NETCONF.

The script runs and the completion status is returned via RPC reply.

Step 3

Verify execution using syslog messages.

Example:


            Router: UTC: script_control_cli[67858]: %OS-SCRIPT_MGMT-6-INFO : Script-control: Script run scheduled: sample1.py. Request ID: 1631795207
            Router: script_agent_main[248]: %OS-SCRIPT_MGMT-6-INFO : Script-script_agent: Script execution sample1.py (exec) Started : Request ID : 1631795207 :: PID: 18710

Confirm that syslog entries show script scheduling and execution status for traceability.

The selected Python script executes successfully on the router. You can view output and confirmation in CLI, NETCONF response, or syslog entries.

What to do next

  • Review script output and logs to ensure the script completed as intended.

  • Address any errors or exceptions recorded in syslog.

Stop an exec script

Terminate a currently running exec script.

Use this task when you need to manually halt a script that is currently executing on the device. This action helps prevent unintended consequences if a script behaves unexpectedly or must be stopped for operational reasons.

Before you begin

Ensure you have administrative access to the device via CLI or NETCONF.

Procedure

Step 1

In the CLI, enter the following command to stop the exec script:

Example:

script stop <script-name>

Replace <script-name> with the name or identifier of the running script you want to stop.

Step 2

Alternatively, if you are using NETCONF, send an RPC request as shown:

Example:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
          <script-stop-request xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-script-mgmt-act">
          <request>SCRIPT-ID</request>
          </script-stop-request>
          </rpc>

Replace SCRIPT-ID with the identifier for the script you want to stop.

The specified exec script is stopped.

What to do next

Verify the script has stopped by checking the script status. Restart or perform additional troubleshooting if required.

Remove an exec script

Remove an exec script from the script management repository to free up space or eliminate scripts that are no longer needed. This does not delete the script's management or execution history data.

Use this task when you want to remove a specific exec script from the repository. The removed script cannot be run unless you add it back again. The equivalent CLI for Cisco-IOS-XR-infra-script-mgmt-act.yang is script remove exec <script_name.py>

Before you begin

Ensure you have administrative access to the device or system where the script repository is managed.

Procedure

Step 1

Access the script management tool or command-line interface.

Step 2

List the available exec scripts to identify the script you want to remove.

Step 3

Remove the target exec script using the appropriate command or menu option.

For command-line removal, use:script remove exec <script_name.py>

Step 4

Verify that the script has been removed from the repository.

Example:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <script-remove-type xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-script-mgmt-act">
    <type>exec</type>
    <file-name-1>load_modules_ut.py</file-name-1>
  </script-remove-type>
</rpc>

The selected exec script is removed from the repository and cannot be executed unless re-added.

What to do next

If needed, add a different script to the repository or clean up additional scripts as required.

View the script execution status

Check the progress and results of script execution on the device to confirm operational status or diagnose issues.

Network administrators may need to verify the status, logs, and outcomes of scripts that run on the device for troubleshooting or operational monitoring.

You can use either the CLI command or NETCONF RPC calls to view script execution status.

Before you begin

Ensure you have the required access privileges to run operational commands on the device (CLI or NETCONF), and that at least one script has been executed.

Procedure

Step 1

Use the CLI command to display script execution status and details.

Example:

show script execution [request-id <value>] [name <filename>] [status {Exception | Executed | Killed | Started | Stopped | Timed-out}] [reverse] [last <number>]

Replace options in brackets as needed to filter specific execution results by request ID, script name, or status.

The command displays script execution entries, including request ID, script name, current status, execution duration, and log path.

Step 2

Alternatively, send a NETCONF RPC request to retrieve script execution details programmatically.

Example:

<rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="unique-id">
          <get>
          <filter>
          <script xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-script-mgmt-oper">
          <execution>
          <requests>
          <request>
          <request-id><your-request-id></request-id>
          <detail>
          <execution-detail/>
          </detail>
          </request>
          </requests>
          </execution>
          </script>
          </filter>
          </get>
          </rpc>

Replace <your-request-id> with the actual ID of the script execution you want to query.

A successful response returns execution summary, duration, log path, run options, and event history for the specified script execution.

Step 3

If more detail is needed, review the log path shown in the output.

Use the displayed log file path to access detailed execution logs for troubleshooting.

You have successfully retrieved the script execution status and details, which can now be used for monitoring or troubleshooting purposes.

What to do next

If issues are detected, use the log files or event details to further diagnose and resolve script execution problems.

EEM scripts using RPCs

EEM scripts using RPCs are automated network management tools that

  • leverage Remote Procedure Calls (RPCs) to interact with device configuration and status

  • support dynamic, event-based automation through the Cisco IOS XR event manager framework, and

  • integrate programmable operations with data models such as Cisco-IOS-XR-um-event-manager-policy-map-cfg.yang and Cisco-IOS-XR-um-event-manager-cfg.yang.

Relevant data models and protocols

The following YANG data models support EEM scripts with RPC functionality:

  • Cisco-IOS-XR-um-event-manager-policy-map-cfg.yang

  • Cisco-IOS-XR-um-event-manager-cfg.yang (augmented for advanced programmability)

Using NETCONF or gNMI protocols, EEM scripts can launch device configuration changes or collect telemetry in response to specific network events.

Example of EEM script using RPCs

A sample EEM script is configured to monitor interface status. When an interface goes down, the script automatically triggers an RPC call to reset the interface and log the event for future auditing.

Configure event actions using the data model

Configure actions that automatically respond to specific network events by defining triggers and corresponding scripts using the YANG data model and NETCONF RPC.

Use this process to automate proactive handling of events (like syslog patterns) on NETCONF-enabled Cisco IOS XR devices. Event triggers and actions ensure operational responses are consistent and timely.

Before you begin

  • Confirm NETCONF access and administrative credentials for your device.

  • Ensure the device supports Cisco-IOS-XR-um-event-manager features.

  • Prepare the event criteria (name, trigger pattern, severity) and action details (script, username, timeout, checksum).

Procedure

Step 1

Access the NETCONF configuration interface for your Cisco IOS XR device.

Step 2

Define an event trigger by setting these parameters.

  1. Specify event-name (e.g., "event_1").

  2. Set occurrence count and period in seconds.

  3. Choose type as syslog, and provide the pattern and severity level.

Step 3

Configure an event action.

  1. Enter action-name (e.g., "action_1").

  2. Set type to script, with script-name, maxrun (timeout), and checksum values.

  3. Provide username for script execution.

Step 4

Send the configuration using a NETCONF edit-config RPC request.

Example:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
      <edit-config>
        <target><candidate/></target>
        <config>
          <event xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-um-event-manager-cfg">
            <manager>
              <event-trigger xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-um-event-manager-policy-map-cfg">
                <event>
                  <event-name>event_1</event-name>
                  <occurrence>2</occurrence>
                  <period><seconds>60</seconds></period>
                  <type>
                    <syslog>
                      <pattern>"Syslog for EEM script"</pattern>
                      <severity><warning/></severity>
                    </syslog>
                  </type>
                </event>
              </event-trigger>
              <actions xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-um-event-manager-policy-map-cfg">
                <action>
                  <action-name>action_1</action-name>
                  <type>
                    <script>
                      <script-name>event_script_1.py</script-name>
                      <maxrun><seconds>30</seconds></maxrun>
                      <checksum><sha256>bb19a7a286db72aa7c7bd75ad5f224eea1062b7cdaaeee06f11f0f86f976831d</sha256></checksum>
                    </script>
                  </type>
                  <username>eem_user_1</username>
                </action>
              </actions>
            </manager>
          </event>
        </config>
      </edit-config>
    </rpc>
    ```

Step 5

Commit your configuration using the NETCONF commit RPC request.

Example:

 <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="102">
      <commit/>
    </rpc>

Step 6

Verify a successful NETCONF response includes <ok/>.

Example:

    <rpc-reply message-id="urn:uuid:16fa22ed-3f46-4369-806a-3bccd1aefcaf"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
      xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
      <ok/>
    </rpc-reply>
    ```

Your event-driven actions are now active and scripts are launched automatically when a matching event occurs.

What to do next

  • Test the configuration by producing a matching syslog event on the device.

  • Review system logs to confirm script execution and troubleshoot if needed.

Create a policy map for events and actions with a data model

You use a data model to create a policy map that defines actions for specific network events.

This enables automation and centralized management of event policies on supported devices.

Policy maps provide a reusable model for associating events with actions. By using the YANG data model, you can configure these policies programmatically and ensure consistent behavior across devices.

Before you begin

Before you begin, ensure the following:

  • You have administrator access to the device.

  • NETCONF is enabled on the device.

  • You have the syntax details for the required YANG module and CLI commands.

Procedure

Step 1

Use the YANG data model Cisco-IOS-XR-um-event-manager-policy-map-cfg or the CLI to define a new policy map for event management.

Example:


          <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
          <edit-config>
          <target>
          <candidate/>
          </target>
          <config>
          <event xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-um-event-manager-cfg">
          <manager>
          <policy-maps xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-um-event-manager-policy-map-cfg">
          <policy-map>
          <policy-map-name>policy_1</policy-map-name>
          <trigger>
          <event>event_1</event>
          </trigger>
          <actions>
          <action>
          <action-name>action_1</action-name>
          </action>
          </actions>
          </policy-map>
          </policy-maps>
          </manager>
          </event>
          </config>
          </edit-config>
          </rpc>

Alternatively, configure the equivalent policy map and event-action relationship using the CLI:

event manager policy-map policy-name

action action-name

trigger event event-name

Step 2

Commit the changes to apply the configuration.

Example:


          <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="102">
          <commit/>
          </rpc>

Step 3

Verify successful configuration.

If the RPC reply contains an <ok/> message, the configuration is successful.

The device is now configured with a policy map that assigns actions to specific events. Event policies are active and managed according to your definitions in the data model or CLI.

What to do next

Review policy operation and monitor event actions to ensure expected behavior. Adjust policy maps or event triggers as needed based on operational requirements.

Operational model for EEM script

An operational model is a framework that

  • describes how a system, process, or component behaves under various conditions,

  • defines the roles, actions, and interactions among different parts or actors during operation, and

  • enables prediction, analysis, or management of real-world operational scenarios.

Table 3. Feature History Table
Feature Name Release Information Description

Operational Data Model for EEM Script

Release 7.5.2

You can programmatically retrieve the operational status of events, actions, and policy maps using the YANG data model.

In earlier releases, you used the show event manager command to view the operational status of event scripts.

This release introduces Cisco-IOS-XR-ha-eem-policy-oper.yang and Cisco-IOS-XR-event-manager-policy-map-oper.yang data models.

Retrieve actions using the operational data model

The purpose of this task is to allow you to retrieve detailed information about specific IOS XR actions configured on the router by querying the operational data model with NETCONF. Action details are useful for validating scripts, troubleshooting, and monitoring operational status.

Actions in IOS XR are RPC statements that trigger operations or execute scripts. By querying the operational YANG model, you can programmatically view action attributes, recent status, run counts, and associations with policy maps.

This task is typically performed by network administrators or automation engineers managing IOS XR devices in programmable environments.

Before you begin

Before you begin, ensure these prerequisites are met:

  • NETCONF is enabled and accessible on the IOS XR router.

  • You have valid credentials to access the router via NETCONF.

  • The target action name (for example, action2 ) is known.

Procedure

Step 1

Prepare a NETCONF RPC <get> request targeting the YANG module Cisco-IOS-XR-ha-eem-policy-oper and specify the action name you want to retrieve.

Example:


            <rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:example-message-id">
            <get>
            <filter>
            <eem xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ha-eem-policy-oper">
            <action-names xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-event-manager-policy-map-oper">
            <action-name>
            <action-name>action2</action-name>
            </action-name>
            </action-names>
            </eem>
            </filter>
            </get>
            </rpc>

Replace action2 with the actual action name you want to query.

Step 2

Send the NETCONF RPC request to your IOS XR device using your preferred NETCONF client or automation tool (such as ncclient or YANG Suite).

If using command-line tools, ensure the session is authenticated and the device supports the required YANG modules.

Step 3

Review the RPC response details to verify the action attributes and operational status.

Example:


            <rpc-reply message-id="urn:uuid:example-message-id" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
            <data>
            <eem xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ha-eem-policy-oper">
            <action-names xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-event-manager-policy-map-oper">
            <action-name>
            <action-name>action2</action-name>
            <action-name-xr>action2</action-name-xr>
            <script-name>event_script_2.py</script-name>
            <action-type>script</action-type>
            <triggered-count>7</triggered-count>
            <policy-count>1</policy-count>
            <max-run>20</max-run>
            <checksum-enabled>SHA256</checksum-enabled>
            <last-run-status>Success</last-run-status>
            <user-name>eem_user</user-name>
            <checksum-string>270b9730e77c9bd6f5784084ed21e29d8d7b8edaf8f98a4513879a1631c493ad</checksum-string>
            <action-policy-map>
            <policy-name>policy3</policy-name>
            </action-policy-map>
            </action-name>
            </action-names>
            </eem>
            </data>
            </rpc-reply>

Verify fields such as script-name, last-run-status, triggered-count, and policy associations for troubleshooting or validation purposes.

You have successfully retrieved the action details from the operational data model.

The system returns the operational attributes of the specified action in the NETCONF RPC response. This data allows you to automate monitoring, troubleshooting, or auditing of IOS XR actions and associated scripts.

What to do next

Optionally, repeat the query for other action names or use the retrieved output to update your automation records or configuration monitoring dashboards.

Retrieve a policy map using the operational data model

Retrieve the configuration and operational status of a policy map by submitting a NETCONF RPC request based on the Cisco-IOS-XR-ha-eem-policy-oper YANG model.

Use this task when you need to audit, troubleshoot, or verify the state and details of policy maps on Cisco IOS XR devices programmatically. This method provides a structured XML response containing policy actions, status, and event triggers.

Before you begin

  • Ensure NETCONF is enabled on the target device.

  • Have appropriate user credentials with permission to access operational data.

  • Know the policy map name you want to retrieve.

Procedure

Step 1

Connect to the device via a NETCONF-capable client.

Connection to the device is established.

Step 2

Submit an RPC request using the Cisco-IOS-XR-ha-eem-policy-oper YANG model with the specific policy map name in your filter.

Example:


            <rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:3cec3f3a-395b-4763-b1a1-1053149da60c">
            <get>
            <filter>
            <eem xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ha-eem-policy-oper">
            <policy-map-names xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-event-manager-policy-map-oper">
            <policy-map-name>
            <policy-name>policy4</policy-name>
            </policy-map-name>
            </policy-map-names>
            </eem>
            </filter>
            </get>
            </rpc>
The device returns a detailed XML response containing the policy map's configuration and operational status.

Step 3

Review the RPC response and verify details for the specified policy map, such as status, event map, action map, and occurrence counters.

Example:


            <rpc-reply message-id="urn:uuid:3cec3f3a-395b-4763-b1a1-1053149da60c" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
            <data>
            <eem xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ha-eem-policy-oper">
            <policy-map-names xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-event-manager-policy-map-oper">
            <policy-map-name>
            <policy-name>policy4</policy-name>
            <policy-status>active</policy-status>
            <policy-occurrence>2</policy-occurrence>
            <event-count>2</event-count>
            <policy-event-map>
            <event-name>event5</event-name>
            <event-status>active</event-status>
            </policy-event-map>
            <policy-action-map>
            <action-name>action4</action-name>
            <checksum-enabled>SHA256</checksum-enabled>
            </policy-action-map>
            </policy-map-name>
            </policy-map-names>
            </eem>
            </data>
            </rpc-reply>
The requested policy map details are available and can be used for verification or troubleshooting purposes.

The specified policy map's operational details are successfully retrieved and displayed in XML format.

What to do next

  • Optionally, store or export the policy map details for audit or ongoing monitoring.

  • If further analysis is needed, reference the YANG model documentation for available attributes.

Retrieve events with trigger conditions using the operational data model

Retrieve and review event details by using the YANG operational data model to monitor event manager trigger conditions.

Use this procedure when you need to verify or troubleshoot event triggers registered via the event manager subsystem. This enables programmatic monitoring without relying solely on CLI output.

Before you begin

  • Ensure you have NETCONF or RESTCONF access enabled on the target Cisco IOS XR device.

  • Obtain device credentials with appropriate read privileges.

  • Have the desired event trigger name(s) ready.

Procedure

Step 1

Establish a NETCONF session with the device using your preferred YANG management tool.

Step 2

Send a get operation with a filter that targets the event trigger data for the specific event name.

Example filter (replace event4 with your event name):

Example:

<rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
          <nc:get>
          <filter>
          <eem xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ha-eem-policy-oper">
          <event-trigger-names xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-event-manager-policy-map-oper">
          <event-trigger-name>
          <event-name>event4</event-name>
          </event-trigger-name>
          </event-trigger-names>
          </eem>
          </filter>
          </nc:get>
          </rpc>

Step 3

Review the returned RPC response for event status, type, details, and policy mapping.

Key fields: event-status, event-type, event-policy-map, event-triggered-count.

Example:

<event-name>event4</event-name>
          <event-status>active</event-status>
          <event-type>syslog</event-type>
           <event-policy-map>
           <policy-name>policy4</policy-name>
           </event-policy-map>

Step 4

Optionally, use the CLI for equivalent information if needed.

CLI command:

Router# show event manager event-trigger event-trigger-name detailed

For more details, refer to the View Operational Status of Event Scripts topic.

You have retrieved and verified the operational status and configuration of event triggers using the YANG data model or CLI.

What to do next

  • Use the collected data for further troubleshooting, policy adjustment, or monitoring automation as needed.