R12.1-2025Jul03

Programmable Remediation

Add Remediation Diagnosis Action

  1. In an NI diagnosis, navigate to Add Action > Advanced > Remediation to complete the remediation definition.

  2. In the Remediation dialog, define the following information:

  • Change Template: Select a change management template.
  • Device: Select a device variable, and the $this_device is selected by default.

    Information
    Note: You can choose either a device object variable or a list of device object, allowing remediation to be applied to multiple devices simultaneously. Therefore, the supported NI variable types include device object, string (for hostname or IP), list of device, and list of strings.
After selecting a CM template, its nodes will appear on the left side. Click each node on the left and you can complete its definition on the right side through the UI. For example, yuo can use NI variables to assign values to the parameters in each node.
Node TypeUIDescription
Define Change

You can directly define the command to change network and define the rollback command in case of the network change needs to be cancelled. NI variables can be inserted in these commands, and during NI execution, they will be replaced with actual values.

The rules for inserting variables here are the same as those used in defining variables within diagnosis messages.

Retrieve Live Data

Define how to benchmark before/after the change, especially by specifying CLI commands or built-in data. NI variables can be used in the CLI commands, for example, show interface $intf.

  • You can manually enter CLI commands to add, and during this process, variables can be inserted using the icon.
  • You can also click Select Data to choose built-in data for retrieval.
  • If you enter a command that does not meet the requirements, a prompt will notify you.
Execute CLI Command
  • You can manually enter CLI commands to add, and during this process, variables can be inserted using the icon.
  • If you enter a command that does not meet the requirements, a prompt will notify you.
Intent Node

See NI Remediation with Intent Node for more details.
Ansible Node

See NI Remediation with Ansible Node for more details.


After executing this intent, you can view the remediation results in the NI result in the intent view mode.


Logics for Merging Multiple Remediations

A remediation logic is often called multiple times within an NI (whether in the home intent or follow-up intents), with each call for one device. All instances will be merged into a single CM task according to the following rules:

  • If different CM templates are specified, only the first one will be used, and any subsequent CM templates in the remediation logic will be ignored.
  • For the same device, if different Change/Rollback commands are specified, they will all be appended; benchmark commands will also be merged.
There are also additional merging logic for the Ansible node:
  • For different devices, if you assign values for the input variables of the host variable in the Ansible node, they will be merged, with the distinct assignments for each device retained to generate the final inventory instance.
  • For the same Ansible node in NI remediation, if multiple target devices are specified, the configurations for these target devices and their host variables will be automatically merged.
  • For the Ansible node, if the same device is assigned different input variable values in different host variables, only the last assignment will be retained.
The merging rules for common scenarios are as follows:
Remediation 1Remediation 2Merging ResultDescription

CM Template 1

Device 1

    Change Command1

CM Template 1

Device 1

    Change Command2

CM Template 1

Device 1

Change Command1

Change Command2

 

When different Change/Rollback/Benchmark commands are specified for the same device, they will be merged for execution.

CM Template 1

Device 1

    Change Command1

CM Template 2

Device 2

    Change Command2

CM Template 1

Device 1

Change Command1

Device 2

Change Command2

 

If different CM templates are specified, only the first one will be used.

 

Note: The merging rule is that both the type and name of the CM nodes must be the same.

 

For example: If a node specified in template 2 cannot be found in template 1 with the same type and name, that node will be discarded.

CM Template 1

Device 1 - Benchmark Before

    ShowCommand1

CM Template 2

Device 2 - Retrieve Live Data 1

ShowCommand2

 

CM Template 1

Device 1 - Benchmark Before

    ShowCommand1

CM Template 1

Intent Template 1

    Include Device 1

CM Template 1

Intent Template 1

    Include Device 2

CM Template 1

Intent Template 1

    Include Device 1

Include Device 2

 

Merge the replication devices.

CM Template 1

Intent Template 1

    Include Device 1

 

CM Template 1

Intent Template 1

    Not Include Device 2

CM Template 1

Intent Template 1

    Include Device 1

CM Template 1

Intent Template 1

    Not Include Device 1

CM Template 1

Intent Template 1

    Include Device 1

 

CM Template 1

Intent Template 1

    Include Device 1

 

CM Template 1

Intent Template 1

    Include Device 1

    Macro Var Setting 1

CM Template 1

Intent Template 1

    Include Device 1

    Macro Var Setting 2

CM Template 1

Intent Template 1

    Include Device 1

Macro Var Setting 1

 

For the same NIT and device, if there are conflicts in the macro variable settings, only the first one will be taken.

Create CM Task and Open for Users

Prerequisites: Only when you interactively run a single intent, the following logics occur; the following logics will not occur if the NI is run in the backend, for example, the NI is triggered to run, or ADT intent is run via timer.

After the execution is complete, the framework checks for any CM task information in the NI result. If such information is found, a confirmation window will prompt you to decide whether to proceed with follow-up remediation. If you selects Yes, the CM task will be created and opened on a map with devices to be configured. You can then efficiently execute the network change by clicking each node in the CM task.

Execute Change viaUIDescription
Config Change Node

The CLI change commands for each device are displayed in the right pane:

To distinguish different types of changes for a single device, there is a CLI icon next to the device hostname on the left UI.

Ansible Node

The following change information for each device is displayed:

  • Playbook text
  • The definition line of host variables that defines input variables in the inventory template
  • The segment of the ‘external input vars’ in YAML in the inventory template that belongs to the current device

Additionally, there is also an Ansible node icon next to the device hostname on the left UI.

Information Note: If multiple config changes are defined in the CM template, they will be combined in order and displayed in this prompt box.

After you select Yes:

  • A new map is created from the client and all the devices in the CM device list will be drawn to this new map.
  • A CM task is created on this new map using the specified CM template and change list.
  • The newly created CM task is automatically opened on the new map, and the NI execution is completed.

After the CM task is opened, you can manually click to perform the subsequent remediation operations in the open CM task, including sending approval requests, benchmark before, executing change, etc.

Built-in Functions for Follow-up Remediation

Two built-in functions are provided to support the auto remediation for violations from golden config check:

Function SpecDescriptionReturn Description
int VerifyGoldenConfig(
string FullPath_Of_Golden_Rule,
string DeviceName,
bool RefreshConfigFile=true)
This function calls the Golden Config service to validate the config file of a specified device against the specified golden config rule. If 'RefreshConfigFile' is set to true, the function uses the config file retrieved in the current intent command section. Otherwise, it uses the config file from the current baseline.

The return value is an integer, which can be one of the following three values:

0: Failed to verify the golden config rule due to reasons such as:

  • No such golden rule
  • Invalid device
  • Device and rule do not match
  • Not used in a configuration command diagnosis and 'RefreshConfigFile' is set to true
  • Failed to retrieve the config file and 'RefreshConfigFile' is set to true

1: Violation / Alert – if any configuration instance violates the golden rule

2: Compliance / Success – all configuration instances comply with the golden rule

Table GetGoldenConfigCheckResult(string FullPath_Of_Golden_Rule, string DeviceName, bool OnlyInstanceWithAlert=True)  

This function is used to get the result of the latest golden config check result (against golden config rule) of the specified golden config rule for the specified device.

  • string FullPath_Of_Golden_Rule: The full path of a golden config rule defined in GES, including the rule name.
  • string DeviceName: The hostname of the device for which the configlet is expected to be retrieved.
  • bool OnlyInstanceWithAlert: If set to True, only the check results of config instances that violate the golden rule will be returned. If set to False, the check results of all config instances will be returned. Note: This parameter is set to True by default.

The result is a table, and each row of the table represents a check result of a config instance.

The return value can be assigned to a global variable in the type of table or local variable within the intent.

If the specified golden rule or device does not exist, or if they do not match, an empty table with no data rows is returned.

If the specified golden config rule is in the type of the single instance, the returned table will contain only one row of data or no data.

You can specify the entire config change command in NI, ignoring the change command template defined in the Define Change node of the CM template.

In NI, there are two sources of the change commands used for defining devices: one is to directly define change commands within NI, and some of the texts are constructed using variable values from NI; The other (in use case #1) is to get the configlet with golden config violation from the golden config, and then modify the configlet to generate change commands. Therefore, you can use the Function GetDeviceConfig here.