Configure an Event Policy to Change the Configuration

An event policy performs actions in response to specific events. You can configure custom event policies in the Junos OS configuration that listen for a specific event or correlated events and then execute an action, which might include creating a log file, invoking Junos OS commands, or executing an event script. At times, it might be necessary to modify the configuration in response to a particular event. For example, upon receipt of an SNMP_TRAP_LINK_DOWN or SNMP_TRAP_LINK_UP event for a given interface, the event policy action might modify the configuration of a static route to adjust its metric or modify its next hop.

Event policies can modify the configuration by invoking an event script that changes and commits the configuration or by using the change-configuration statement to execute configuration mode commands that change the configuration. Prior to Junos OS Release 12.1, an event policy invoked an event script to execute configuration changes. Starting in Junos OS Release 12.1, in addition to invoking an event script, you can configure an event policy with the change-configuration action, which uses Junos OS configuration mode commands to modify the configuration.

To modify the configuration through an event policy using configuration mode commands, configure the change-configuration statement at the [edit event-options policy policy-name then] hierarchy level. For example:

The commands statement specifies the configuration mode commands that are executed upon receipt of the configured event or events. Enclose each command in quotation marks (" "), and specify the complete statement path to the element, identifier, or value as you do in configuration mode when issuing commands at the [edit] hierarchy level. The commands statement accepts the following configuration mode commands:

• activate

• deactivate

• delete

• set

The event process (eventd) executes the configuration commands in the order in which they appear in the event policy configuration. The commands update the candidate configuration, which is then committed, provided that no commit errors occur.

You can configure the commit-options child statement to customize the event policy commit operation. You can commit the changes on a single Routing Engine or configure the synchronize option to synchronize the commit on both Routing Engines. When you configure the synchronize option, the Routing Engine on which you execute this command copies and loads its candidate configuration to the other Routing Engine. Both Routing Engines perform a syntax check on the candidate configuration file. If no errors are found, the configuration is activated and becomes the current operational configuration on both Routing Engines. By default, the synchronize option does not work if the responding Routing Engine has uncommitted configuration changes. However, you can enforce commit synchronization on the Routing Engines and ignore any warnings by configuring the force option.

Additionally, if you are testing or troubleshooting an event policy, you can configure the check commit option to verify the candidate configuration syntax without committing the changes. On dual control plane systems, when the check synchronize statement is configured, the candidate configuration on one control plane is copied to the other control plane, and the system verifies that both candidate configurations are syntactically correct. The check statement and the other commit-options statements are mutually exclusive.

The change configuration action might fail while acquiring a lock on the configuration. Configure the retry statement to have the system attempt the change configuration event policy action a specified number of times if the first attempt fails. Configure the user-name statement to execute the configuration changes and commit under the privileges of a specific user. If you do not specify a username, the action is executed as user root.