Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

Configuring an Event Policy to Change the Configuration

Configuring an Event Policy to Change the Configuration Overview

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. Prior to Junos OS Release 12.1, an event policy invoked an event script to execute configuration changes. Starting with Junos OS Release 12.1, you can configure an event policy to modify the configuration using Junos OS configuration mode commands and then commit the updated configuration. For example, for 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.

You configure event policy actions at the [edit event-options policy policy-name then] hierarchy level. To modify the configuration through an event policy, configure the change-configuration statement and specify 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 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. 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.

Example: Changing the Configuration Using an Event Policy

It might be necessary to modify the configuration in response to a particular event. Starting with Junos OS Release 12.1, you can configure an event policy to make and commit configuration changes when the event policy is triggered by one or more specific events.

This example simulates an SNMP_TRAP_LINK_DOWN event for a specific interface. Upon receipt of the event, the event policy modifies the configuration of a static route to use a new next-hop IP address through a different exit interface.

• Requirements
• Overview
• Configuration
• Verification
• Troubleshooting

Requirements

• Routing, switching, or security device running Junos OS Release 12.1 or later.

Overview

You can configure an event policy action to modify the configuration when the policy is triggered by a single event or correlated events. Suppose you have a static route to the 10.1.10.0/24 network with a next-hop IP address of 10.1.2.1 through the exit interface ge-0/3/1. At some point, this interface goes down, triggering an SNMP_TRAP_LINK_DOWN event.

This example creates an event policy named update-on-snmp-trap-link-down. The event policy is configured so that the eventd process listens for an SNMP_TRAP_LINK_DOWN event associated with the interface ge-0/3/1.0. If the interface goes down, the event policy executes a change configuration action. Commands are executed in the order in which they appear in the event policy. The event policy configuration commands remove the static route through the ge-0/3/1 exit interface and create a new static route to the same target network with a next-hop IP address of 10.1.3.1 through the exit interface ge-0/2/1.

The event policy change configuration commit operation is executed under the username bsmith with a commit comment specifying that the change was made through the associated event policy. The retry count is set to 5 and the retry interval is set to 4 seconds. If the initial attempt to issue the configuration change fails, the system attempts the configuration change 5 additional times and waits 4 seconds between each attempt.

Although not presented here, you might have a second, similar event policy that executes a change configuration action to update the static route when the interface comes back up. In that case the policy would trigger on the SNMP_TRAP_LINK_UP event for the same interface.

Configuration

CLI Quick Configuration

Configuring the Event Policy

Step-by-Step Procedure

1. Create and name the event policy.

   [edit]bsmith@R1# edit event-options policy update-on-snmp-trap-link-down

2. Configure the events statement so that the event policy triggers on the SNMP_TRAP_LINK_DOWN event.

   Set the attributes-match statement so that the policy triggers only if the SNMP_TRAP_LINK_DOWN event occurs for the ge-0/3/1.0 interface.

   [edit event-options policy update-on-snmp-trap-link-down]bsmith@R1# set events snmp_trap_link_downbsmith@R1# set attributes-match snmp_trap_link_down.interface-name matches ge-0/3/1.0

3. Specify the configuration mode commands that are executed if the ge-0/3/1 interface goes down.

   Configure each command on a single line, enclose the command string in quotes, and specify the complete statement path.

   [edit event-options policy update-on-snmp-trap-link-down then change-configuration]bsmith@R1# set commands "delete routing-options static route 10.1.10.0/24 next-hop"bsmith@R1# set commands "set routing-options static route 10.1.10.0/24 next-hop 10.1.3.1"

4. Configure the commit options.

   Configure the log option with a comment describing the configuration changes. The comment is added to the commit logs after a successful commit operation is made through the associated event policy.

   [edit event-options policy update-on-snmp-trap-link-down then change-configuration]bsmith@R1# set commit-options log "updating configuration from event policy update-on-snmp-trap-link-down"

   If you have dual Routing Engines, configure the synchronize option to commit the configuration on both Routing Engines. Include the force option to force the commit on the other Routing Engine, ignoring any warnings. This example does not configure the synchronize and force options.

5. (Optional) Configure the retry count and retry interval.

   In this example, count is set to 5 and the interval is 4 seconds.

   [edit event-options policy update-on-snmp-trap-link-down then change-configuration]bsmith@R1# set retry count 5 interval 4

6. (Optional) Configure the username under whose privileges the configuration changes and commit are made.

   If you do not specify a username, the action is executed as user root.

   [edit event-options policy update-on-snmp-trap-link-down then change-configuration]bsmith@R1# set user-name bsmith

7. Configure a new log file at the [edit system syslog] hierarchy level to record syslog events of facility daemon and severity warning.

   This captures the SNMP_TRAP_LINK_DOWN events.

   [edit system syslog]bsmith@R1# set file syslog-event-daemon-warning daemon warning

8. To test this example, configure a static route to the 10.1.10.0/24 network with a next hop IP address of 10.1.2.1.

   [edit]bsmith@R1# set routing-options static route 10.1.10.0/24 next-hop 10.1.2.1

9. Commit the configuration.

   bsmith@R1# commit
10. Review the [edit routing-options static] hierarchy level of the configuration before disabling the ge-0/3/1 interface, and note the next hop IP address.

    bsmith@R1> show configuration routing-options static
    ...
    route 10.1.10.0/24 next-hop 10.1.2.1;
    ...

11. To manually test the event policy, take the ge-0/3/1 interface temporarily offline to generate the SNMP_TRAP_LINK_DOWN event.

    [edit]bsmith@R1# set interfaces ge-0/3/1 disablebsmith@R1# commit

Results

Verification

Confirm that the configuration is working properly.

• Verifying the Status of the Interface
• Verifying the Commit
• Verifying the Configuration Changes

Verifying the Status of the Interface

Purpose

Verify that the ge-0/3/1 interface is down and that it triggered the SNMP_TRAP_LINK_DOWN event.

Action

Physical interface: ge-0/3/1, Administratively down, Physical link is Down
<output omitted>

Oct 10 18:00:57  R1 mib2d[1371]: SNMP_TRAP_LINK_DOWN: ifIndex 531, ifAdminStatus down(2), ifOperStatus down(2), ifName ge-0/3/1.0

Verifying the Commit

Purpose

Verify that the event policy commit operation was successful by reviewing the commit log and the messages log file.

Action

0   2011-10-10 18:01:03 PDT by bsmith via junoscript
    updating configuration from event policy update-on-snmp-trap-link-down
1   2011-09-02 14:16:44 PDT by admin via netconf
2   2011-07-08 14:33:46 PDT by root via other

...
Oct 10 18:00:57  R1 mib2d[1371]: SNMP_TRAP_LINK_DOWN: ifIndex 531, ifAdminStatus down(2), ifOperStatus down(2), ifName ge-0/3/1.0
Oct 10 18:00:59  R1 file[17575]: UI_COMMIT: User 'bsmith' requested 'commit' operation (comment: updating configuration from event policy update-on-snmp-trap-link-down)
Oct 10 18:01:03  R1 eventd: EVENTD_CONFIG_CHANGE_SUCCESS: Configuration change successful: while executing policy update-on-snmp-trap-link-down with user bsmith privileges

Note: If you configure a different log file, review the file specific to your configuration.

Meaning

The output from the show system commit operational mode command and the messages log file verify that the commit operation, which was made through the event policy under the privileges of the user bsmith, was successful. The show system commit output and messages log file reference the commit comment specified in the log statement at the [edit event-options policy update-on-snmp-trap-link-down then change-configuration commit-options] hierarchy level.

Verifying the Configuration Changes

Purpose

Verify the configuration changes by reviewing the [edit routing-options static] hierarchy level of the configuration after disabling the ge-0/3/1 interface.

Action

bsmith@R1> show configuration routing-options static
...
route 10.1.10.0/24 next-hop 10.1.3.1;
...

Meaning

The configured next hop has been modified by the event policy to the new IP address 10.1.3.1, which has its route through the exit interface ge-0/2/1.

Troubleshooting

• Troubleshooting Commit Errors

Troubleshooting Commit Errors

Problem

...
Oct 10 17:48:59  R1 mib2d[1371]: SNMP_TRAP_LINK_DOWN: ifIndex 531, ifAdminStatus down(2), ifOperStatus down(2), ifName ge-0/3/1.0
Oct 10 17:49:01  R1 file[17142]: UI_LOAD_EVENT: User 'bsmith' is performing a 'rollback'
Oct 10 17:49:01  R1 eventd: EVENTD_CONFIG_CHANGE_FAILED: Configuration change failed: rpc to management daemon failed while executing policy update-on-snmp-trap-link-down with user bsmith privileges

A failed commit might occur if the configuration is locked or if the configuration mode commands have the incorrect syntax or order.

Solution

Check the configuration mode commands at the [edit event-options policy update-on-snmp-trap-link-down then change-configuration commands] hierarchy level, and verify that the syntax and the order of execution are correct.

Additionally, increase the retry count and interval options so that if the configuration is locked, the event policy attempts the configuration changes a specified number of times after the first failed instance.

Example: Changing the Interface Configuration in Response to an Event

It might be necessary to modify the configuration in response to a particular event. Starting with Junos OS Release 12.1, you can configure an event policy to make and commit configuration changes when the event policy is triggered by one or more specific events.

This example uses a real-time performance monitoring (RPM) probe to generate PING_TEST_FAILED events for a given interface. Upon receipt of the first instance of two PING_TEST_FAILED events within a 5-minute period from the configured RPM probe, the event policy executes a change configuration event policy action that modifies the configuration to administratively disable the specified interface. This type of action might be necessary if you have an unstable, flapping interface that is consistently affecting network performance.

• Requirements
• Overview
• Configuration
• Verification

Requirements

• Routing, switching, or security device running Junos OS Release 12.1 or later.

Overview

This example creates an event policy named disable-on-ping-failure. The event policy is configured so that the eventd process listens for PING_TEST_FAILED events generated by a specific RPM probe and associated with the ge-0/3/1 interface . If two PING_TEST_FAILED events occur for the given interface within a 5-minute interval, the event policy executes a change configuration action. The event policy configuration commands administratively disable the interface.

To test the event policy, the example configures an RPM probe that pings the IP address associated with the ge-0/3/1 interface every 60 seconds. In this example, the ge-0/3/1.0 inteface is configured with the IPv4 address 10.1.4.1/26. If the ping fails, the RPM probe generates a PING_TEST_FAILED event. Because multiple RPM tests could be running simultaneously, the event policy matches the owner-name and test-name attributes of the received PING_TEST_FAILED events to the RPM probe owner name and test name. When the RPM probe generates two PING_TEST_FAILED events, it triggers the event policy, which disables the interface.

This policy also demonstrates how to restrict the execution of the same configuration change multiple times because of occurrences of the same event or correlated events. In this example, the trigger on 1 statement specifies that only the first occurrence of two correlated PING_TEST_FAILED events triggers the configuration change. The PING_TEST_FAILED events must occur within a 5-minute interval (300 seconds) to trigger the event policy.

Configuration

Configuring the RPM Probe

CLI Quick Configuration

Step-by-Step Procedure

1. Create an RPM probe named ping-probe-test at the [edit services rpm] hierarchy level to ping the ge-0/3/1 interface.

   [edit services rpm]bsmith@R1# set probe icmp-ping-probe test ping-probe-test

2. Configure the RPM probe to send ICMP echo requests to the ge-0/3/1 interface at IP address 10.1.4.1, and set test-interval to 60 to issue the test every 60 seconds.

   [edit services rpm probe icmp-ping-probe test ping-probe-test]bsmith@R1# set probe-type icmp-ping test-interval 60 target address 10.1.4.1
3. Configure the RPM probe threshold, so that a system log message is generated when the configured threshold is exceeded.
   [edit services rpm probe icmp-ping-probe test ping-probe-test]bsmith@R1# set thresholds successive-loss 1

4. Configure a new log file at the [edit system syslog] hierarchy level to record syslog events of facility daemon and severity info.

   This captures the events sent during the probe tests.

   [edit system syslog]bsmith@R1# set file syslog-event-daemon-info daemon info

5. Commit the configuration.

   bsmith@R1# commit

Results

Configuring the Event Policy

CLI Quick Configuration

Step-by-Step Procedure

1. Create and name the event-policy.

   [edit]bsmith@R1# edit event-options policy disable-on-ping-failure

2. Configure the event policy to match on the PING_TEST_FAILED event if it occurs twice within 5 minutes (300 seconds).

   The trigger on 1 statement specifies that only the first set of correlated PING_TEST_FAILED events triggers this policy.

   The attributes-match statement is set so that the policy triggers only on the PING_TEST_FAILED events generated by the associated RPM probe.

   [edit event-options policy disable-on-ping-failure]bsmith@R1# set events ping_test_failedbsmith@R1# set within 300 trigger on 1bsmith@R1# set attributes-match ping_test_failed.test-owner matches icmp-ping-probebsmith@R1# set attributes-match ping_test_failed.test-name matches ping-probe-test

3. Specify the configuration mode commands that are executed if the event policy triggers.

   Configure each command on a single line, enclose the command string in quotes, and specify the complete statement path.

   [edit event-options policy disable-on-ping-failure then change-configuration]bsmith@R1# set commands "set interfaces ge-0/3/1 disable"

4. (Optional) Configure the retry count and retry interval.

   In this example, count is set to 5, and the interval is 4 seconds.

   [edit event-options policy disable-on-ping-failure then change-configuration]bsmith@R1# set retry count 5 interval 4

5. Configure the commit options.

   Configure the log option with a comment describing the configuration changes. The comment is added to the commit logs after a successful commit operation is made through the associated event policy.

   [edit event-options policy disable-on-ping-failure then change-configuration]bsmith@R1# set commit-options log "updating configuration from event policy disable-on-ping-failure"

   If you have dual Routing Engines, configure the synchronize option to commit the configuration on both Routing Engines. Include the force option to force the commit on the other Routing Engine, ignoring any warnings. This example does not configure the synchronize and force options.

6. (Optional) Configure the username under whose privileges the configuration changes and commit are made.

   If you do not specify a username, the action is executed as user root.

   [edit event-options policy disable-on-ping-failure then change-configuration]bsmith@R1# set user-name bsmith

7. Commit the configuration.

   bsmith@R1# commit
8. Review the output of the show interfaces ge-0/3/1 operational mode command before the configuration change takes place.

   The interface should be enabled.

   bsmith@R1> show interfaces ge-0/3/1
   Physical interface: ge-0/3/1, Enabled, Physical link is Up
     Interface index: 142, SNMP ifIndex: 531
   ...

Results

Verification

Confirm that the configuration is working properly.

• Verifying the Events
• Verifying the Commit
• Verifying the Configuration Changes
• Verifying the Status of the Interface

Verifying the Events

Purpose

To manually test the event policy, take the ge-0/3/1 interface offline until two PING_TEST_FAILED events are generated.

Action

Oct  7 15:48:54  R1 rmopd[1345]: PING_TEST_COMPLETED: pingCtlOwnerIndex = icmp-ping-probe, pingCtlTestName = ping-probe-test
Oct  7 15:49:54  R1 rmopd[1345]: PING_TEST_COMPLETED: pingCtlOwnerIndex = icmp-ping-probe, pingCtlTestName = ping-probe-test
...
Oct  7 15:52:54  R1 rmopd[1345]: RMOPD_ICMP_SENDMSG_FAILURE: sendmsg(ICMP): No route to host
Oct  7 15:52:54  R1 rmopd[1345]: PING_PROBE_FAILED: pingCtlOwnerIndex = icmp-ping-probe, pingCtlTestName = ping-probe-test
Oct  7 15:52:54  R1 rmopd[1345]: PING_TEST_FAILED: pingCtlOwnerIndex = icmp-ping-probe, pingCtlTestName = ping-probe-test
Oct  7 15:52:57  R1 rmopd[1345]: PING_TEST_FAILED: pingCtlOwnerIndex = icmp-ping-probe, pingCtlTestName = ping-probe-test

Verifying the Commit

Purpose

Verify that the event policy commit operation was successful by reviewing the commit log and the messages log file.

Action

0   2011-10-07 15:52:58 PDT by bsmith via junoscript
    updating configuration from event policy disable-on-ping-failure
1   2011-09-02 14:16:44 PDT by admin via netconf
2   2011-07-08 14:33:46 PDT by root via other

Oct  7 15:52:54  R1 rmopd[1345]: RMOPD_ICMP_SENDMSG_FAILURE: sendmsg(ICMP): No route to host
Oct  7 15:52:55  R1 file[9972]: UI_COMMIT: User 'bsmith' requested 'commit' operation (comment: updating configuration from event policy disable-on-ping-failure)
Oct  7 15:52:59  R1 eventd: EVENTD_CONFIG_CHANGE_SUCCESS: Configuration change successful: while executing policy disable-on-ping-failure with user bsmith privileges

Meaning

The output from the show system commit operational mode command and the messages log file verify that the commit operation, which was made through the event policy under the privileges of the user bsmith, was successful. The show system commit output and messages log file reference the commit comment specified in the log statement at the [edit event-options policy disable-on-ping-failure then change-configuration commit-options] hierarchy level.

Verifying the Configuration Changes

Purpose

Verify the configuration changes by reviewing the [edit interfaces ge-0/3/1] hierarchy level of the configuration.

Action

Meaning

The ge-0/3/1 configuration hierarchy was modified through the event policy to add the disable statement.

Verifying the Status of the Interface

Purpose

Review the output of the show interfaces ge-0/3/1 operational mode command after the configuration change takes place.

Action

bsmith@R1> show interfaces ge-0/3/1
Physical interface: ge-0/3/1, Administratively down, Physical link is Down
  Interface index: 142, SNMP ifIndex: 531