Adding or editing a rule

Rules can be used to provision new devices and audit and enforce configuration best practices based on a set of rules. This topic describes how to configure a rule.

To add or edit a rule

1. Open the Rules page by navigating to Network > Scripts > Rules.
2. Perform one of the following actions:
   • To define a new rule, click Add .
     The Add Rule page is displayed.
   • To create a new rule by duplicating and editing an existing rule, click Copy .

   • To edit an existing rule, click Edit .

     Tip

     To help you identify a rule that you want to copy or edit, you can view the summary of the attributes of a rule by clicking its name.

3. On the Details tab, enter or modify settings in the following fields:

   The [confluence_table-plus] macro is a standalone macro and it cannot be used inline. Click on this message for details.
   This macro generates standalone content. As a consequence you need to make sure to use a syntax that separates your macro from the content before and after it so that it's on a line by itself. For example in XWiki Syntax 2.0+ this means having 2 newline characters (a.k.a line breaks) separating your macro from the content before and after it.
   

4. On the Grammar tab, specify the patterns that must be matched by the device to comply with this rule. For more information, see Defining-rule-grammar.
5. (Optional) Test the rule grammar against the multiple configurations before the rule is saved:
   1. Enter the configuration against which you want to test the rule grammar by using one of the following methods:
      • Type the configuration.
      • Click Select Configuration and load the configuration from a file.
      • Click Select Configuration and load the configuration from the system of an existing device.
   2. Click Try It.
      The Results window shows the trace similar to the one shown in the Compliance Summary report. The trace indicates the behavior of the rules against different configurations and shows color codes to help create the proper grammar as follows:
      • Whether the rule grammar will pass or fail against the configuration
      • If failing, the reason for failure with the help of color codes
        For more information about how to understand the trace output, see Viewing-a-Compliance-Summary-report.

6. On the Spans tab, specify the network spans that you want to exclude from auditing and compliance enforcement by using the Add button. 
   
   You can apply a rule set to a large number of devices and then exclude a few devices or groups from the entire rule set or from specific rules. The excluded devices are thus ignored or skipped when auditing and enforcing the rule (that is, Deploy to Active with Configuration = Remediate With All Assigned).
   You can exclude the spans at the rule level, as follows:

   Span	Description
   Realm	Excludes the devices in a realm from applying the rule. You need to add realms one by one. You are limited to accessible realms.
   Group	Excludes the devices in a group from applying the rule. You need to add groups one by one. You are limited to groups in accessible realms.
   Device	Excludes one device from applying the rule. You need to add devices one by one. You are limited to devices in accessible realms.
   Group Filter	Excludes one or more groups matching a name from applying the rule. You can choose to look for groups in one particular realm, or you can choose to look for groups in any realm. You can use the wildcard character, asterisk (*) to search for groups. For example, you can enter Model_Cisco.176* in the filter criterion to exclude all the devices that belong to groups whose name starts with Model_Cisco.176, irrespective of the realm the groups belong to. The filtered groups include simple groups (both static and auto groups) only, not combo groups. If a new device is added to the system and if the device belongs to a group that satisfies the filter criterion, that device is excluded from the auditing and compliance enforcement automatically. Note: While choosing the excluded spans for a rule, the [Any] realm option is available for selection only if more than one realm exists in the system.

   In the following example, the group Vendor.Cisco group in the Default realm is being added to the excluded network spans. This span is ignored when TrueSight Network Automation audits and enforces the rule.
   
   

7. On the Corrective Actions tab, specify the span action that can be run to correct or remediate a violation of this rule. For each applicable trail, you might define a corrective action, where you enter parameters for either a Deploy to Active, Deploy to Stored, Deploy OS Image, or custom action. A rule with no corrective actions cannot be remediated. By default, a new rule has no corrective actions.
   
   In the Action column, click the Plus icon  to add a corrective action for the trail. Once added, you can edit or delete it. For example, to remediate a violation to the running trail, you might define a corrective action, Deploy to Active as follows:
   
   The options available here are very similar to the options when adding the same type of span action to a job. For more information, see the applicable topics under Creating-a-span-job. The Deploy to Active and Deploy to Stored span actions include a new configuration option, Complying With This Rule. When you select this option, the system computes the configuration that complies with this rule, and when applicable, passes it through SmartMerge to yield an incremental merge script. The initial configuration for computing a compliant configuration is the current running configuration (for a Deploy to Active action) or the current startup configuration (for a Deploy to Stored action). Therefore, this option is available only for those trails in those actions.
   
   The corrective action defines the span action options that are to be used when remediating. You can remediate by running a job with a Remediate, Deploy to Active, or Deploy to Stored span action. Note that the same options in a Deploy to Active or Deploy to Stored action are configurable in the corrective action and also in the job or policy's span action editor. In the job or policy's span action editor, you can choose which set of options are to take effect – either the ones in the job or policy, or the ones from the corrective action for the rule. That is, you can choose to override the options defined in the corrective action.
8. When you have finished performing the configuration on the various tabs, click Save to save the rule.

The following video (6:45) explains how to define corrective actions using product version 8.9.00.

https://www.youtube.com/watch?v=vU5TGKDvzM4

Remediation considerations

When the domain for a rule is OS Image Name, use caution when choosing the trails and creating associated corrective actions. The system associates the same image version with configurations of every trail. So, flagging violations in many trails is redundant and not recommended. You should apply the rule to a single trail (the running or other main configuration) and define a single corrective action for that trail.

Running automatic compliance checks in the activation window

The system checks for compliance violations only if a rule is active. A rule is active only within its activation window based on the current date of the Network Automation web server. The following table lists various combinations of activation and deactivation dates that determine whether a rule is within its activation window.

While a rule is active, the system performs compliance checking of that rule when configuration changes are detected. Under certain circumstances (for example, when you add a new rule, edit a rule's grammar, or change the devices assigned to a rule set), you must perform a manual Refresh Device Status action to update the existing violations. But, the system performs an automatic refresh when a rule becomes active – that is, when the current time reaches the rule's activation date. The system also automatically clears violations when the current system time reaches a rule's deactivation date. These automatic refreshes are performed daily at the time specified in the Perform Daily Rule Activation/Deactivation At system parameter.

The automatic activation check is also done when you add a new rule that is within its activation window, or edit an existing rule such that it is now within its activation window. Since the automatic check is at a specified time, you do not immediately see violations. If you do not want to wait for this automatic check to find the violations, you should run the manual Refresh Device Status action.

For example, if you add a new rule whose activation date is February 15 and deactivation date is May 31, and today is March 1, the rule is considered to be active and the system performs an automatic compliance check at the scheduled time. On May 31, the rule is no longer active and the system clears its violations at the scheduled time.

If you edit a rule such that an active rule is no longer active, the system clears the violations when you save the rule. For example, if the rule initially had no deactivation date, and you assigned a deactivation date of yesterday, the violations are cleared at save time.

For a sample rule grammar that utilizes the activation window to run automatic compliance checks, see Device End of Life. 

Network Automation is installed with a set of canned rules. These rules have no activation or deactivation dates, so they are within their activation windows. However, they belong to disabled rule sets, so no violation checking is performed by default.

When you upgrade to version 20.02, all existing rules are assigned null activation and deactivation dates, so that they are within their activation windows. But since these are pre-existing rules that were already "active", it is assumed that you have maintained their violation states properly. These rules do not undergo an automatic compliance check.

Related topic

Managing-system-parameters