Adding or editing a policy
This topic provides instructions forand describes .
BMC Network Automation supports the following types of policies:
- Time-based policies: Execute once at a specified date/time, or on a recurring basis. Time-based policies can run conditionally or unconditionally. When using condition(s) in a time-based policy, the condition(s) must have occurred in the past for a designated network span at the time of execution.
- Event-based policies: Triggered by detected conditions (that is, events). These events can be from external systems (for example syslog), events reporting detection of configuration changes or discrepancies, system events, user events, policy events, and so on.
- The default action on some predefined policies is to log an event. Before enabling the policy, delete this action and add the appropriate email or SNMP notifications.
- BMC strongly recommends that you enable the Auto Archive policy so hat configuration changes made external to the system can be detected, archived, and audited in realtime. See Configuring existing syslog servers to forward events.
- Additional information about configuring policy notifications (for example, compliance violations detected) can be found in Managing policies and Performing a quick start configuration.
To add or edit a policy
In the BMC Network Automation console, click the Policies tab, and select Policies > Policies.
- On the Policies page, perform one of the following actions:
- To add a new policy, select Add.
- To edit an existing policy, select Edit in the relevant row.
- To create a new policy by copying and editing an existing policy, select Copy in the relevant row.
On the Details tab of the Add/Edit/Copy Policy page, enter information in the following fields:
Specify a unique name for the policy, up to 40 characters.
(Required for a new policy) Specify either time or event-based policy.
Select any of the following options:
- Enabled: Select to enable the policy.
- Auto Purge: Select to purge the policy when it becomes dormant. A policy becomes dormant when the end date/time has expired. If you plan to run the policy after it has become dormant (for example scheduled run once snapshot), clear this check box.
- On Error, Skip Remaining Actions: If an action fails, skip remaining actions.
(Applicable for version 8.9.01 and later) Send Notification
Whether to send an email and SNMP trap notification to one or more recipients and SNMP manager stations based on the state changes in the job that is created when the policy executes.
(Applicable for version 8.9.00) Send Email Whether to send an email based on job state transitions in the job that is created when the policy executes.
- For a time-based policy, specify how often to run the policy through the Repeat field. Then set the start time, end time, and run times. The exact method to set the run times differs, depending on your choice in the Repeatfield.
- Run Hourly: Run policy hourly at the specified runtimes (up to every 5 minutes)
- Run Daily: Run policy daily at the specified runtimes.
- Run Weekly: Run policy weekly at the specified runtimes.
- Run Monthly: Run the policy monthly at the specified runtimes.
- For an event-based policy, configure the following settings:
Execution Delay: (Optional) Specify the number of minutes (from 1 to 60) to delay execution of the policy after it is triggered. A value of blank or zero disables the delay, resulting in immediate execution of the policy when a trigger is received.
Policies shipped with BMC Network Automation have the delay disabled. During the delay, if an identical trigger occurs, the policy does not run again on that trigger, as the original run is still pending.
Use the delay when, under normal operating conditions, multiple identical triggers can be expected within a short period of time.
- If users make manual changes to a device by going in and out of config mode repeatedly and generate several syslog messages that trigger the Auto-Archive policy, a delay in the policy (for example, five minutes) can reduce the number of snapshots caused by several device changes performed close together.
- If a configuration has multiple compliance violations causing multiple events to trigger a policy, using the delay enables the policy to run only once for all detected violations.
- Activate & Deactivate: Specify when the policy is active (for example select Current and Never for a policy that should always be active).
- Interval: (Optional) Specify time of day when the policy is active (for example from 8:00 to 18:00--core business hours). Unselect the interval if the policy is active all hours of the day.
- Weekday: (Optional) Specify which days of the week the policy is active (for example Monday-Friday). If you want to run the policy every day of the week, do not select any of the days.
- On the Conditions tab, associate conditions with the policy.
Conditions are required for event-based policies, and optional for Time-based policies. You must define conditions first for use in a policy. The conditions below state execute the policy actions when no other compliance violations have been reported in the recent past.
Specify conditions through the following fields:
- Triggering Condition: Select a condition that triggers the testing of all other conditions (specified in the Other Conditions box). When the triggering condition and other conditions are true, the policy initiates the Action list.
- Other Condition(s): (Optional) Logical expression of conditions that have occurred in the past (for example, Change Detected Past).
To connect multiple conditions or modify a condition, select an operator — AND, OR, NOT, or an opening or closing parenthesis.
To add or remove a condition, use the + or - buttons.
On the Actions tab, specify the actions to be executed when the policy condition is evaluated as true by clicking Add Action in the menu and selecting the actions to be added to the list.
For a list of available actions and their associated parameters see Managing jobs.
You can perform the following actions on actions:
Icon Action Description View View policy action. Edit Edit policy action. Copy Create a copy of policy action. Delete Delete policy action. Move Down Change the order of actions downwards. Move Up Change the order of actions upwards.
- On the Job Details tab, assign dynamic field values for the job that is created when the policy executes.
- If you are editing an existing policy, on the Status tab you can view historical policy executions and you can select a Job ID to display the Job Details report.
The report shows details of any action completion status and any configuration changes made or detected, as applicable.
- Click Save.
How policies interact with conditions
In the BMC Network Automation system, any event logged to the Event Log can cause a policy to trigger. These events include external events (syslog), configuration change detection events, and configuration discrepancy events. All policies must have a triggering event. For time-based policies, time is the trigger that wakes up the policy. For event-based policies, the Triggering Condition is the triggering event that wakes up the policy.
In the example, the Triggering Condition is Compliance Violation Detected Now. The policy time is the past 1 minute (see below). So if within the policy time two or more compliance violation events (that is, Occurrence Count = 2) are logged, the policy is triggered once (that is, suppress multiple notifications if configuration file has more than one violation).
Multiple policies can be active at one time. For example, one policy can send notifications of security changes to the security team; another policy can send notifications of Running versus Startup discrepancies to the Engineering team; while another policy can be monitoring device configuration changes to perform real-time configuration snapshot operations.
For more about creating or editing conditions, see Viewing the conditions listing.
When a policy includes emailing attached reports, it is possible those reports are configured for the Entire Network span. Normally, selecting Entire Network results in a report filtered by the security restrictions of the requesting user. That is, the report does not include devices in realms the user cannot access. Because a policy is not associated with any particular user, this security filtering does not occur. A report on the Entire Network can include every device in the BMC Network Automation system (optionally filtered by a device filter). Caution is needed to ensure sensitive information about the network is not disclosed to unauthorized email recipients. In addition, a report on the Entire Network can consume a lot of CPU while being generated.