Programmable Remediation
Add Remediation Diagnosis Action
- In an NI diagnosis, navigate to Add Action > Advanced > Remediation to complete the remediation definition.
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.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.
Node Type | UI | Description |
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.
|
Execute CLI Command | ![]() |
|
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.
- 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.
Remediation 1 | Remediation 2 | Merging Result | Description |
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 via | UI | Description |
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:
Additionally, there is also an Ansible node icon next to the device hostname on the left UI. |
![]() |
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 Spec | Description | Return 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:
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.
| 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.