Adding or editing a policy

This topic provides instructions for adding or editing a policy and describes how policies interact with conditions.

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.

To add or edit a policy

1. In the BMC Network Automation console, click the Policies tab, and select Policies > Policies.

2. 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.

3. On the Details tab of the Add/Edit/Copy Policy page, enter information in the following fields:

   Field	Description
   Name	Specify a unique name for the policy, up to 40 characters.
   Type	(Required for a new policy) Specify either time or event-based policy.
   Options	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.

4. 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.
5. 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.

     Examples

     • 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.
6. 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.

7. 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.

8. On the Job Details tab, assign dynamic field values for the job that is created when the policy executes.
   
9. 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. 
   
10. Click Save.

Back to top

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.

Back to top

Related topics

Viewing the policies listing
Creating a notification job
Creating a configuration snapshot