About defining and organizing rules

Each rule is assigned to a rule set. Rule sets are assigned to network spans for auditing. One approach to organizing rules is by device type, for example:

Each rule can be bound to a single device type (for example, Cisco IOS Switch/Router) and OS image version (min/max). For example, if you have routers running IOS 11.x and 12.x, you can define different rules based on the command set, and place these rules in the same rule set called Router. BMC Network Automation applies the rule appropriately based on the device type and discovered OS image version.

Each rule can be bound to one or more specific models (for example, WS-C6503-E). For example, there may be parts of the Cisco IOS command set that apply only to particular switches; you might not want all IOS devices to be checked for compliance against these rules, since most will not pass. If you choose a limited set of models, then BMC Network Automation can maintain compliance status more efficiently and accurately.

When auditing and enforcing device compliance to assigned rule sets, you can exclude one or more network spans at the rule or rule set level. You can apply a rule set to a large number of devices, and then exclude a few devices/groups from the entire rule set or specific rules. The excluded devices are ignored when auditing and enforcing the rule set (that is, Deploy to Active with Configuration set to Remediate with All Assigned).

Rule set enforcement

When implementing a configuration change using the Remediate action or using the Deploy to Active or Deploy to Stored actions with Remediate With or Remediate With All Assigned options, BMC Network Automation applies the rule sets and rules in order, sorted by name.

This enables you to control the order in which rule sets and rules are applied, to eliminate conflicting or syntactically illegal changes. For example, a device can require attribute ABC to be configured before attribute XYZ. In this case, name the rule (for example, rule name = 1-ABC) for configuring ABC so that it executes before the rule (for example, rule name = 2-XYZ) configuring XYZ.

Rule set naming works the same way. If multiple rule sets are applied to a device and order matters, name the rule sets to execute by name order.

If you have created an ordered sequence of rule sets and rules that makes conflicting changes (where one rule adds a line while a subsequent rule removes that same line, or vice versa), the deploy action fails and reports a conflict error. You can check for this condition prior to running a Deploy to Active action by viewing the incremental merge script. The error message identifies the two rules in conflict. You should edit one or both rules to resolve the conflict.

The ordering of sub-actions also follows the rule name order. The system begins by constructing a list of candidate sub-actions, which are in the rulesetName.ruleName.trailSortOrder order, with one sub-action per corrective action. This list is then collapsed to combine like sub-actions into a single sub-action. The collapsed sub-actions preserve the name and trail order, and the duplicates collapse into the first sub-action. The order is thus deterministic. However, it might not always be clear how a collapsed sub-action is formed. Like sub-actions have identical options and only the devices or the list of enforced rules differ.