Conditions for rule enforcement

TrueSight Network Automation can enforce a rule against a device and its current configurations under the following conditions:

• Compliance enforcement for a given rule is only relevant when the current configuration is in violation of that rule. That is, running a remediating span action corrects only rules known to be in violation. Violations are updated at each configuration change found during a snapshot and when you run a Refresh Device Status action. Violations are not updated when you add new rule sets or rules, or when you edit existing rule sets or rules.
• Compliance enforcement utilizes the corrective span actions defined in each rule for each configuration trail applicable to the rule. If there are no corrective actions, then no enforcement occurs. If a device does not support the type of corrective action defined in the rule (for example, device does not support Deploy to Stored), then no enforcement occurs.
• Depending on the corrective action, enforcement might include the computation of a configuration that complies with the rule. Such a configuration can be computed only from the current Running or current Startup configuration. Therefore, other trails cannot be corrected via a Deploy to Active or Deploy to Stored action of a configuration, Complying With This Rule.
• Enforcing compliance by computing a compliant configuration involves some combination of adding lines that are missing, or removing excess lines that should not be there. In order to add subject elements that are missing, the subject must have been specified as a line or lines. If the subject was specified as a pattern or patterns then TrueSight Network Automation cannot add the missing elements unless a correction is supplied.
• If you specified a Subject Frequency of "0..1" and the subject does not appear in the domain, this is not a violation because your Subject Frequency permits it.
• To enforce the rule when the Subject is not found in the audited configuration, you must set the Subject Frequency to (1..*). TrueSight Network Automation adds the lines or correction for patterns once to the configuration.
• If you specified a domain frequency of "0..*" and the domain does not appear in the configuration, this is not a violation because your domain frequency specification permits it.
• When enforcing compliance for a violation involving a missing domain block, this is only possible when the begin element for the block is specified as a line and not a pattern. The end element for a domain block can be specified as either a line or a pattern however. If it is specified as a line, then it is interpreted as an inclusive boundary and is added when the block is missing. If it is specified as a pattern, then it is interpreted as an exclusive boundary and is not added.
• When enforcing multiple rules (such as choosing to remediate with a rule set or with all assigned rule sets), TrueSight Network Automation will report certain conflicting corrections and skip the enforcement action. It will detect when one correction reverses a preceding correction to the same domain. That is, if one rule makes a correction by adding a line, and a subsequent rule makes its correction by removing that line, this is considered to be a conflict. Similarly, if a rule deletes a line from an interface block and a subsequent rule adds that same line to the same interface block, then that too is a conflict. You can override these conflict checks in both the Deploy to Active and Deploy to Stored actions.
• When enforcement of a rule results in the removal of configuration lines, the system does not automatically remove any other lines that refer to a parameter being deleted. For example, a rule that removes a policy-map does not automatically remove the service-policy line that refers to that policy-map. Often such references are innocuous when left behind, but if not, you must develop other rules that clear them away.