Part 2: Configuration. Juniper Networks Junos OS

“Example: Triggering a Policy Based on Event Count” on page 96

policy-name

within

seconds]

trigger

(after | on | until) event-count;

The software counts the number of times the triggering event occurs. A triggering event can be any event configured at the [edit event-options policy policy-name events] hierarchy level. You can configure the following options:

• after event-count —The policy is executed when the number of matching events received equals event-count plus one.

• on event-count —The policy is executed when the number of matching events received equals event-count.

• until event-count —The policy is executed each time a matching event is received and stops being executed when the number of matching events received equals event-count.

For a configuration example, see

Using Regular Expressions to Refine the Set of Events That Trigger a Policy

You can use regular expression matching to specify more exactly which events cause a policy to be executed.

To specify the text string that must appear in an event attribute for the policy to be executed, include the matches statement at the [edit event-options policy policy-name attributes-match] hierarchy level, and specify the regular expression which the event attribute must match:

[edit

“Example: Controlling Event Policy Using a Regular

policy-name

attributes-match

]

event.attribute-name

matches

regular-expression;

When you specify the regular expression, use the notation defined in POSIX

Standard 1003.2 for extended (modern) UNIX regular expressions. Explaining regular expression syntax is beyond the scope of this document.

Table 3 on page 16

specifies which character or characters are matched by some of the regular expression operators that you can use in the matches statement. In the descriptions, the term term refers to

Event Automation and Event Policy Developer Guide either a single alphanumeric character or a set of characters enclosed in square brackets, parentheses, or braces.

NOTE: The matches statement is not case-sensitive.

Table 3: Regular Expression Operators for the matches Statement

Operator Matches

. (period)

* (asterisk)

+ (plus sign)

? (question mark)

| (pipe)

One instance of any character except the space.

Zero or more instances of the immediately preceding term.

One or more instances of the immediately preceding term.

Zero or one instance of the immediately preceding term.

One of the terms that appear on either side of the pipe operator.

! (exclamation point)

^ (caret)

$ (dollar sign)

Any string except the one specified by the expression, when the exclamation point appears at the start of the expression. Use of the exclamation point is specific to Junos OS.

The start of a line, when the caret appears outside square brackets.

One instance of any character that does not follow it within square brackets, when the caret is the first character inside square brackets.

The end of a line.

[ ] (paired square brackets)

One instance of one of the enclosed alphanumeric characters. To indicate a range of characters, use a hyphen ( - ) to separate the beginning and ending characters of the range. For example, [a-z0-9] matches any letter or number.

( )

(paired parentheses)

One instance of the evaluated value of the enclosed term. Parentheses are used to indicate the order of evaluation in the regular expression.

For a configuration example, see

Expression” on page 90

Generating Internal Events to Trigger Event Policies

Internal events are events that you create to trigger a policy to be executed. They are not generated by Junos OS processes, and they do not have any associated system log messages. You can generate an internal event based on a time interval or the time of day.

Chapter 3: Triggering an Event Policy

To generate an event, include the following statements at the [edit event-options] hierarchy level:

[edit

event-name {

seconds;

hh:mm:ss;

}

In the time-interval statement, configure a frequency, in seconds, with which to repeatedly generate an event. The time interval can range from 60 through 2,592,000 seconds.

In the time-of-day statement, configure a time of day for the event to occur. Use the format hh:mm:ss.

NOTE: If you modify the system time by issuing the set date operational mode command, we recommend that you also issue the commit full or the restart event-process command. Otherwise, an internal event based on the time of day might not be generated at the configured time.

For example, if you configure an internal event to be generated at 15:55:00, and then you modify the system time from 15:47:17 to 15:53:00, the event is generated when the system time is approximately 16:00 instead of at the configured time, 15:55:00. You can correct this problem by issuing the commit full or the restart event-process command.

You can configure up to 10 internal events. If you attempt to commit a configuration with more than 10 internal events, Junos OS generates an error, and the commit fails.

For configuration examples, see

“Example: Generating an Internal Event” on page 92 .

Using Nonstandard System Log Messages to Trigger Event Policies

Some of the system log messages that you can reference in an event policy are not listed in the output of the set event-options policy policy-name events ? command. These system log messages have an event ID and a message attribute. Event IDs are based on the origin of the message, as shown in

Table 4 on page 17

Table 4: Event ID by System Log Message Origin

Event IDs Origin

SYSTEM

KERNEL

PIC

PFE

LCC

Messages from Junos daemons and utilities

Messages from the Junos kernel

Messages from physical interface cards (PICs)

Messages from the Packet Forwarding Engine

On a TX Matrix router, messages from a line-card chassis (LCC)

Event Automation and Event Policy Developer Guide

Table 4: Event ID by System Log Message Origin (continued)

Event IDs Origin

SCC On a TX Matrix router, messages from a switch-card chassis (SCC)

To base your event policy on the event types shown in

Table 4 on page 17 , include the

events event-id statement and the attributes-match statement with the event-id.message

matches "message" attribute at the [edit event-options policy policy-name] hierarchy level:

[edit

“Example: Using Nonstandard System Log Messages to Trigger an Event Policy” on page 98

policy-name]

events

event-id;

attributes-match

{

event-id.message

matches

"message";

}

For a configuration example, see

CHAPTER 4

Configuring Event Policy Actions

•

Configuring an Event Policy to Execute Operational Mode Commands on page 19

•

Configuring an Event Policy to Change the Configuration on page 22

•

Executing Event Scripts in an Event Policy on page 37

•

Configuring Event Policies to Ignore an Event on page 41

•

Changing the User Privilege Level for an Event Policy Action on page 42

•

Example: Configuring Event Policies to Raise SNMP Traps on page 43

•

Configuring the System Log Priority of the Triggering Event in an Event Policy on page 46

Configuring an Event Policy to Execute Operational Mode Commands

Operational mode commands request that the device running Junos OS perform an operation or provide diagnostic output. They allow you to view statistics and information about a device’s current operating status. They also allow you to take corrective actions, such as restarting software processes, taking a PIC offline and back online, switching to redundant interfaces, and adjusting Label Switching Protocol (LSP) bandwidth. For more information about operational mode commands, see the following references:

• CLI Explorer

You can configure a policy that causes operational mode commands to be issued and the output of those commands to be uploaded to a specified location for analysis.

To configure such a policy, include the following statements at the [edit event-options] hierarchy level:

[edit

policy-name {

[ events ];

{

{

{

"command";

}

filename;

Event Automation and Event Policy Developer Guide

}

output-format

(text | xml);

“Using Nonstandard System Log Messages to Trigger Event Policies” on page 17 .

destination-name;

In the events statement, you can list multiple events. If one or more of the listed events occurs, the operational mode commands are issued. To view a list of the events that can be referenced in an event policy, issue the set event-options policy policy-name events ?

configuration mode command:

[edit] user@host# set event-options policy policy-name events ?

Possible completions:

<event>

[ Open a set of values acct_accounting_ferror acct_accounting_fopen_error

...

In addition, you can reference internally generated events, which are discussed in

“Generating Internal Events to Trigger Event Policies” on page 16 .

In the commands statement, you can issue multiple operational mode commands upon receipt of a specific event. Enclose each command in quotation marks (“ ”). The eventd process issues the commands in the order in which they appear in the configuration. For example, in the following configuration, the execution of policy1 causes the show interfaces command to be issued first, followed by the show chassis alarms command:

[edit event-options policy policy1 then execute-commands] user@host# show commands {

"show interfaces";

"show chassis alarms";

}

You can include variables in the command to allow data from the triggering event to be automatically included in the command syntax. The eventd process replaces each variable with values contained in the event that triggers the policy. You can use command variables of the following forms:

• {$$.attribute-name}

—The double dollar sign ($$) notation represents the event that is triggering a policy. When combined with an attribute name, the variable is replaced by the value of the attribute name in the triggering event. For example,

{$$.interface-name} stands for the value of the interface-name attribute in the triggering event.

• {$event.attribute-name}

—The {$event.attribute-name} notation represents the most recent event that matches the specified event. The variable is replaced by the value of the attribute name of the most recent event that matches event. For example, when

Chapter 4: Configuring Event Policy Actions a policy issues the show interfaces

{$COSD_CHAS_SCHED_MAP_INVALID.interface-name} command, the

{$COSD_CHAS_SCHED_MAP_INVALID.interface-name} variable is substituted by the interface-name attribute of the most recent COSD_CHAS_SCHED_MAP_INVALID event cached by the event process.

For a given event, you can view a list of event attributes that you can reference in an operational mode command by issuing the help syslog event-name command: user@host> help syslog event-name

For example, in the following command output, text in angle brackets (< >) shows that classifier-type is an attribute of the cosd_unknown_classifier event: user@host> help syslog cosd_unknown_classifier

Name: COSD_UNKNOWN_CLASSIFIER

Message: rtsock classifier type <classifier-type> is invalid

...

You can filter the output of a search by using the pipe (|) symbol. The following example lists the filters that can be used with the pipe symbol: user@host# help syslog | ?

Possible completions:

count Count occurrences

display Show additional kinds of information

except Show only text that does not match a pattern

find Search for first occurrence of pattern

hold Hold text without exiting the --More-- prompt

last Display end of output only

match Show only text that matches a pattern

no-more Don't paginate output

request Make system-level requests

resolve Resolve IP addresses

save Save output text to file

trim Trim specified number of columns from start of line

For more information about using the pipe symbol, see the CLI User Guide.

Another way to view a list of event attributes is to issue the set attributes-match event?

configuration mode command at the [edit event-options policy policy-name] hierarchy level:

[edit event-options policy policy-name] user@host# set attributes-match event ?

For example, in the following command output, the event.attribute list shows that classifier-type is an attribute of the cosd_unknown_classifier event:

[edit event-options policy policy-name] user@host# set attributes-match cosd_unknown_classifier?

Possible completions:

<from-event-attribute> First attribute to compare cosd_unknown_classifier.classifier-type

Event Automation and Event Policy Developer Guide

NOTE: In this set command, there is no space between the event name and the question mark (?).

To view a list of all event attributes that you can reference, issue the set attributes-match

configuration mode command at the [edit event-options policy policy-name] hierarchy level:

[edit event-options policy policy-name] user@host# set attributes-match ?

Possible completions:

<from-event-attribute> First attribute to compare acct_accounting_ferror acct_accounting_fopen_error

...

In the output-filename statement, assign the name of the file to which to write command output for the specified commands. The filename format is

hostname_filename_YYYYMMDD_HHMMSS_index-number

For each uploaded file, a hostname and timestamp ensure that the uploaded files have unique filenames. If a policy is triggered multiple times in a 1-second period, an index number is added to ensure the filenames are unique. The index number range is 001 through 999.

For example, on a device named r1, if you configure the output filename to be ifl-events, and this event policy is triggered three times in 1 second, the files are named:

• r1_ifl-events_20060623_132333

• r1_ifl-events_20060623_132333_001

• r1_ifl-events_20060623_132333_002

By default, the command output format is Junos Extensible Markup Language (XML).

To change this, include the output-format text statement. This causes the command output to be in formatted ASCII text.

In the destination statement, include the destination name that you configured at the

[edit event-options destinations] hierarchy level. For more information, see

“Example:

Defining Destinations for File Archiving by Event Policies” on page 54

For a configuration example, see

“Example: Correlating Events Based on Receipt of Other

Events Within a Specified Time Interval” on page 91 .

Configuring an Event Policy to Change the Configuration

•

Configuring an Event Policy to Change the Configuration Overview on page 23

•

Example: Changing the Configuration Using an Event Policy on page 24

•

Example: Changing the Interface Configuration in Response to an Event on page 30

Chapter 4: Configuring Event Policy Actions

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

Event Automation and Event Policy Developer Guide 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 on page 24

•

Overview on page 24

•

Configuration on page 25

•

Verification on page 27

•

Troubleshooting on page 30

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.

Chapter 4: Configuring Event Policy Actions

CLI Quick

Configuration

set event-options policy update-on-snmp-trap-link-down then change-configuration retry count 5 set event-options policy update-on-snmp-trap-link-down then change-configuration retry interval 4 set event-options policy update-on-snmp-trap-link-down then change-configuration commands "delete routing-options static route 10.1.10.0/24 next-hop" set event-options policy update-on-snmp-trap-link-down then change-configuration commands "set routing-options static route 10.1.10.0/24 next-hop 10.1.3.1" set event-options policy update-on-snmp-trap-link-down then change-configuration user-name bsmith set event-options policy update-on-snmp-trap-link-down then change-configuration commit-options log "updating configuration from event policy update-on-snmp-trap-link-down" set routing-options static route 10.1.10.0/24 next-hop 10.1.2.1

set system syslog file syslog-event-daemon-warning daemon warning

Step-by-Step

Procedure

Configuring the Event Policy

Create and name the event policy.

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

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_down bsmith@R1# set attributes-match snmp_trap_link_down.interface-name matches ge-0/3/1.0

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"

Event Automation and Event Policy Developer Guide

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.

(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

(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

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

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

Commit the configuration.

10.

bsmith@R1# commit

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;

...

Chapter 4: Configuring Event Policy Actions

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 disable bsmith@R1# commit

Results

[edit] event-options { policy update-on-snmp-trap-link-down { events snmp_trap_link_down; attributes-match { snmp_trap_link_down.interface-name matches ge-0/3/1.0;

} then { change-configuration { retry count 5 interval 4; commands {

"delete routing-options static route 10.1.10.0/24 next-hop";

"set routing-options static route 10.1.10.0/24 next-hop 10.1.3.1";

} user-name bsmith; commit-options { log "updating configuration from event policy update-on-snmp-trap-link-down";

}

} routing-options { static { route 10.1.10.0/24 next-hop 10.1.2.1;

}

} system { syslog { file syslog-event-daemon-warning { daemon warning;

}

Verification

Confirm that the configuration is working properly.

•

Verifying the Status of the Interface on page 28

•

Verifying the Commit on page 28

•

Verifying the Configuration Changes on page 29

Event Automation and Event Policy Developer Guide

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 Issue the show interfaces ge-0/3/1 operational mode command. The command output shows that the interface is administratively offline.

bsmith@R1> show interfaces ge-0/3/1

Physical interface: ge-0/3/1, Administratively down, Physical link is Down

Review the contents of the system log file configured in Step

7 . The output shows that

the ge-0/3/1.0 interface went down and generated an SNMP_TRAP_LINK_DOWN event.

bsmith@R1> show log syslog-event-daemon-warning

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.

Chapter 4: Configuring Event Policy Actions

Action Issue the show system commit operational mode command to view the commit log. In this example, the log confirms that the configuration was committed through the event policy under the privileges of user bsmith at the given date and time.

bsmith@R1> show system commit

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

Review the messages log file. Upon receipt of the SNMP_TRAP_LINK_DOWN event, Junos

OS executed the configured event policy action to modify and commit the configuration.

The commit operation occurred under the privileges of user bsmith.

bsmith@R1> show log messages | last 20

...

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 Issue the following operational mode command: 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.

Event Automation and Event Policy Developer Guide

Troubleshooting

•

Troubleshooting Commit Errors on page 30

Troubleshooting Commit Errors

Problem The triggered event policy does not make the specified configuration changes, and the logs verify that the commit was unsuccessful.

bsmith@R1> show log messages | last 20

...

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

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 on page 31

•

Overview on page 31

•

Configuration on page 31

•

Verification on page 35

Chapter 4: Configuring Event Policy Actions

Requirements

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

Overview

This example creates an event policy named disable-interface-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.

CLI Quick

Configuration

Configuring the RPM Probe

set services rpm probe icmp-ping-probe test ping-probe-test thresholds successive-loss

1 set system syslog file syslog-event-daemon-info daemon info

Event Automation and Event Policy Developer Guide

Step-by-Step

Procedure

To configure the RPM probe, which creates the PING_TEST_FAILED events for this example:

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

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

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

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

Commit the configuration.

bsmith@R1# commit

Results

[edit] services { rpm { probe icmp-ping-probe { test ping-probe-test { probe-type icmp-ping; target address 10.1.4.1; test-interval 60;

}

} system { thresholds { successive-loss 1;

} syslog { file syslog-event-daemon-info { daemon info;

}

Chapter 4: Configuring Event Policy Actions

CLI Quick

Configuration

Configuring the Event Policy

To quickly configure this section of the example, copy the following commands, paste them in a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level: set event-options policy disable-interface-on-ping-failure events ping_test_failed set event-options policy disable-interface-on-ping-failure within 300 trigger on set event-options policy disable-interface-on-ping-failure within 300 trigger 1 set event-options policy disable-interface-on-ping-failure attributes-match ping_test_failed.test-owner matches icmp-ping-probe set event-options policy disable-interface-on-ping-failure attributes-match ping_test_failed.test-name matches ping-probe-test set event-options policy disable-interface-on-ping-failure then change-configuration retry count 5 set event-options policy disable-interface-on-ping-failure then change-configuration retry interval 4 set event-options policy disable-interface-on-ping-failure then change-configuration commands "set interfaces ge-0/3/1 disable" set event-options policy disable-interface-on-ping-failure then change-configuration user-name bsmith set event-options policy disable-interface-on-ping-failure then change-configuration commit-options log "updating configuration from event policy disable-interface-on-ping-failure"

Step-by-Step

Procedure

Create and name the event-policy.

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

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-interface-on-ping-failure] bsmith@R1# set events ping_test_failed bsmith@R1# set within 300 trigger on 1 bsmith@R1# set attributes-match ping_test_failed.test-owner matches icmp-ping-probe bsmith@R1# set attributes-match ping_test_failed.test-name matches ping-probe-test

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-interface-on-ping-failure then change-configuration] bsmith@R1# set commands "set interfaces ge-0/3/1 disable"

Event Automation and Event Policy Developer Guide

(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-interface-on-ping-failure then change-configuration] bsmith@R1# set retry count 5 interval 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 disable-interface-on-ping-failure then change-configuration] bsmith@R1# set commit-options log "updating configuration from event policy disable-interface-on-ping-failure"

(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-interface-on-ping-failure then change-configuration] bsmith@R1# set user-name bsmith

Commit the configuration.

bsmith@R1# commit

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

[edit event-options] policy disable-interface-on-ping-failure { events ping_test_failed; within 300 { trigger on 1;

} attributes-match { ping_test_failed.test-owner matches icmp-ping-probe; ping_test_failed.test-name matches ping-probe-test;

}

Chapter 4: Configuring Event Policy Actions

} then { change-configuration { retry count 5 interval 4; commands {

"set interfaces ge-0/3/1 disable";

} user-name bsmith; commit-options log "updating configuration from event policy disable-interface-on-ping-failure";

}

Verification

Confirm that the configuration is working properly.

•

Verifying the Events on page 35

•

Verifying the Commit on page 35

•

Verifying the Configuration Changes on page 36

•

Verifying the Status of the Interface on page 36

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 Review the configured syslog file. Verify that when the RPM probe ping tests fail, the probe generates a PING_TEST_FAILED event.

bsmith@R1> show log syslog-event-daemon-info

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.

Event Automation and Event Policy Developer Guide

bsmith@R1> show system commit

0 2011-10-07 15:52:58 PDT by bsmith via junoscript

updating configuration from event policy disable-interface-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

Review the messages log file. Upon receipt of the PING_TEST_FAILED event, Junos OS executed the configured event policy action to modify and commit the configuration.

The commit operation occurred under the privileges of user bsmith.

bsmith@R1> show log messages | last 20

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-interface-on-ping-failure)

Oct 7 15:52:59 R1 eventd: EVENTD_CONFIG_CHANGE_SUCCESS: Configuration change successful: while executing policy disable-interface-on-ping-failure with user bsmith privileges

[edit event-options policy disable-interface-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 bsmith@R1> show configuration interfaces ge-0/3/1 disable; unit 0 { family inet { address 10.1.4.1/26;

}

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.

Chapter 4: Configuring Event Policy Actions

Action Issue the show interfaces ge-0/3/1 operational mode command. After the event policy configuration change action disables the interface, the output changes from "Enabled" to "Administratively down".

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

Documentation

•

change-configuration on page 105

•

commands (Event Policy Change Configuration) on page 106

•

commit-options on page 108

•

retry (Event Policy) on page 124

•

user-name on page 137

Executing Event Scripts in an Event Policy

Event scripts are Extensible Stylesheet Transformation (XSLT) or Stylesheet Language

Alternative Syntax (SLAX) scripts that you write and that are run when triggered by an event policy. Event scripts can perform any function available through Junos XML or Junos

XML protocol remote procedure calls (RPCs). Additionally, you can pass to an event script a set of arguments that you define.

A script can change the device configuration, build and run an operational mode command, receive the command output, inspect the output, and determine the next appropriate action. This process can be repeated until the source of the problem is determined. The script can then report the source of the problem to you on the CLI.

You can configure an event policy that causes event scripts to be run and the output of those scripts to be uploaded to a specified location for analysis.

To configure such a policy, include the following statements at the [edit event-options] hierarchy level:

[edit

policy-name {

[ events ];

{

filename {

{

argument-name argument-value;

}

filename;

output-format

(text | xml);

“Using Nonstandard System Log Messages to Trigger Event Policies” on page 17 .

destination-name;

}

Event Automation and Event Policy Developer Guide

In the events statement, you can list multiple events. If one or more of the listed events occurs, the event script is executed. To view a list of the events that can be referenced in an event policy, issue the set event-options policy policy-name events ? configuration mode command:

[edit] user@host# set event-options policy policy-name events ?

Possible completions:

<event>

[ Open a set of values acct_accounting_ferror acct_accounting_fopen_error

...

In addition, you can reference internally generated events, which are discussed in

“Generating Internal Events to Trigger Event Policies” on page 16 .

In the event-script statement, you can specify a script to be executed on receipt of an event. The eventd process runs the scripts in the order in which they appear in the configuration. The scripts that you reference in the event-script statement must be located in the /var/db/scripts/event directory on the device’s hard drive or the

/config/scripts/event/ directory on the flash drive. Furthermore, the event scripts must be enabled at the [edit event-options event-script file] hierarchy level. For more information, see Storing and Enabling Scripts.

You can include arguments to the script as name/value pairs. You can include variables in the argument values to allow data from the triggering event to be automatically included in the argument. The eventd process replaces each variable with values contained in the event that triggers the policy. You can use variables of the following forms:

• {$$.attribute-name}

{$$.interface-name} stands for the value of the interface-name attribute in the triggering event.

• {$event.attribute-name}

{$COSD_CHAS_SCHED_MAP_INVALID.interface-name}, the

{$COSD_CHAS_SCHED_MAP_INVALID.interface-name} variable is replaced by the interface-name attribute of the most recent COSD_CHAS_SCHED_MAP_INVALID event cached by the eventd process.

For a given event, you can view a list of event attributes that you can reference by issuing the help syslog event command:

Chapter 4: Configuring Event Policy Actions user@host> help syslog event-name

For example, in the following command output, text in angle brackets (< >) shows attributes of the COSD_CHASSIS_SCHEDULER_MAP_INVALID event: user@host> help syslog COSD_CHASSIS_SCHEDULER_MAP_INVALID

Name: COSD_CHASSIS_SCHEDULER_MAP_INVALID

Message: Chassis scheduler map incorrectly applied to interface

<interface-name>: <error-message>

...

You can filter the output of a search by using the pipe (|) symbol. The following example lists the filters that can be used with the pipe symbol: user@host> help syslog | ?

Possible completions:

count Count occurrences

display Show additional kinds of information

except Show only text that does not match a pattern

find Search for first occurrence of pattern

hold Hold text without exiting the --More-- prompt

last Display end of output only

match Show only text that matches a pattern

no-more Don't paginate output

request Make system-level requests

resolve Resolve IP addresses

save Save output text to file

trim Trim specified number of columns from start of line

For more information about using the pipe symbol, see the CLI User Guide.

Another way to view a list of event attributes is to issue the set attributes-match event ?

configuration mode command at the [edit event-options policy policy-name] hierarchy level:

[edit event-options policy policy-name] user@host# set attributes-match event ?

For example, in the following command output, the event.attribute list shows that error-message and interface-name are attributes of the cosd_chassis_scheduler_map_invalid event:

[edit event-options policy p1] user@host# set attributes-match cosd_chassis_scheduler_map_invalid?

Possible completions:

<from-event-attribute> First attribute to compare cosd_chassis_scheduler_map_invalid.error-message cosd_chassis_scheduler_map_invalid.interface-name

In this set command, there is no space between the event name and the question mark

(?).

To view a list of all event attributes that you can reference, issue the set attributes-match

configuration mode command at the [edit event-options policy policy-name] hierarchy level:

[edit event-options policy policy-name] user@host# set attributes-match ?

Possible completions:

Event Automation and Event Policy Developer Guide

<from-event-attribute> First attribute to compare acct_accounting_ferror acct_accounting_fopen_error

...

By default, the command output format is text. To change this, include the output-format xml statement.

In the optional output-filename statement, assign the name of the file to which to write script output for the specified script.

The filename format is hostname_filename_YYYYMMDD_HHMMSS_index-number.

For each uploaded file, a hostname and timestamp are automatically added to the filename to ensure that the uploaded files have unique filenames. If a policy is triggered multiple times in a 1-second period, an index number is added to ensure the filenames are unique. The index number range is 001 through 999.

For example, on a device named r1, if you configure the output filename to be ifl-events, and this event policy is triggered three times in 1 second, the files are named:

• r1_ifl-events_20060623_132333

• r1_ifl-events_20060623_132333_001

• r1_ifl-events_20060623_132333_002

In the optional destination statement, include the destination name that you configured at the [edit event-options destinations] hierarchy level. For more information, see

“Example: Defining Destinations for File Archiving by Event Policies” on page 54

For the output-filename and destination statements, there are four configuration scenarios:

• You can omit the output-filename and destination statements. This option makes sense when the event script has no output. For example, the event script might execute only request commands, which have no output.

•

You can include the destination statement in the configuration. You omit the output-filename statement in the configuration and specify an output filename in the event script instead. The script output is sent to the destination specified in the configuration. If you do not include the destination statement in the configuration, the script output is not uploaded.

In this scenario, the event policy extracts the filename from the event script. The event script writes the output filename as STDOUT. The XML syntax to use in the event script is:

<event-script-output-filename>filename</event-script-output-filename>

</output>

The <event-script-output-filename> element must be the first child tag within the

<output> parent tag.

Chapter 4: Configuring Event Policy Actions

On a device named device2, configure an event script action with a destination host, and omit the output-filename statement. Define the destination host as ftp://user@device1//tmp.

In the script1.xsl event script, write the following output to STDOUT:

<event-script-output-filename>/var/cmd.txt</event-script-output-filename>

Configure the policy1 event policy as follows:

[edit event-options] policy policy1 { then { event-script script1.xsl { destination host;

}

} destinations { host { archive-sites {

"ftp://user@device1//tmp" password "$9$xkJNbYg4ZDH.oJ.fQnpuSyl"; ##

SECRET-DATA***

}

In this example, the /var/cmd.txt file resides on device device2. The event policy uses the File Transfer Protocol (FTP) to upload this file to the /tmp directory on device device1 .

The event policy reads the output filename /var/cmd.txt from STDOUT. Then the event policy uploads the /var/cmd.txt file to the configured destination, which is the /tmp directory on device device1. The event policy renames the /var/cmd.txt file as device2_cmd.txt_YYYYMMDD_HHMMSS_range .

• You can include the output-filename and destination statements. If you include the output-filename statement in the configuration, you must also include the destination statement in the configuration. In this case, the script output is redirected to the output filename specified in the configuration and is sent to the destination specified in the configuration.

• You can include the output-filename and destination statements, and also specify an output filename directly within the event script. If you do this, the output filename specified in the configuration overrides the output filename specified in the event script.

Configuring Event Policies to Ignore an Event

You can modify a policy to cause particular events to be ignored or to cause all events to be ignored during a particular time interval, to allow for maintenance for example.

To configure such a policy, include the following statements at the [edit event-options] hierarchy level:

[edit

event-options ]

policy

policy-name {

Event Automation and Event Policy Developer Guide

}

events

[ events ];

then

{

ignore ;

}

In the events statement, you can list multiple events. To view a list of the events that can be referenced in an event policy, issue the set event-options policy policy-name events ?

configuration mode command:

[edit] user@host# set event-options policy policy-name events ?

Possible completions:

<event>

[ Open a set of values acct_accounting_ferror acct_accounting_fopen_error

...

“Using Nonstandard System Log Messages to Trigger Event Policies” on page 17 .

In addition, you can reference internally generated events, which are discussed in

“Generating Internal Events to Trigger Event Policies” on page 16 .

If one or more of the listed events occur, a system log message for the event is not generated, and no further policies associated with this event are processed. If you include the ignore statement in a policy configuration, you cannot configure any other actions in the policy.

Changing the User Privilege Level for an Event Policy Action

Only superusers can configure event policies. Event policy actions—such as executing event scripts, uploading files, and executing operational mode commands—are by default executed by user root, because the event process (eventd) runs with root privileges.

In some cases, you might want an event policy action to be executed with restricted privileges. For example, suppose you configure an event policy that executes a script if an interface goes down. The script includes remote procedure calls (RPCs) to change the device configuration if certain conditions are present. If you do not want the script to change the configuration, you can execute the script with a restricted user profile. When the script is executed with a user profile that disallows configuration changes, the RPCs to change the configuration fail.

You can associate a user with each action in an event policy. If a user is not associated with an event policy action, then the action is executed as user root by default.

To specify the user under whose privileges an action is executed, include the user-name statement:

user-name

username;

Chapter 4: Configuring Event Policy Actions

You can include this statement at the following hierarchy levels:

• [edit

policy-name

filename]

• [edit

policy-name

then execute-commands ]

• [edit

policy-name

“Example: Associating an Optional User with an Event

filename (filename | committed) destination destination-name]

NOTE: The username that you specify must be configured at the [edit system login] hierarchy level. For more information, see the Junos OS Administration

Library for Routing Devices.

For a configuration example, see

Policy Action” on page 89

Example: Configuring Event Policies to Raise SNMP Traps

•

Overview of Using Event Policies to Raise SNMP Traps on page 43

•

Example: Raising an SNMP Trap in Response to an Event on page 44

Overview of Using Event Policies to Raise SNMP Traps

SNMP traps enable an agent to notify a network management system (NMS) of significant events by way of an unsolicited SNMP message. You can configure an event policy action that raises traps for events based on system log messages. If one or more of the listed events occur, the system log message for the event is converted into a trap. This enables notification of an SNMP trap-based application when an important system log message occurs. You can convert any system log message (for which there are no corresponding traps) into a trap. This is helpful if you use NMS traps rather than system log messages to monitor your network.

To configure an event policy that raises a trap on receipt of an event, include the following statements at the [edit event-options policy policy-name] hierarchy level:

[edit

policy-name]

[ events ];

{

;

}

The Juniper Networks enterprise-specific System Log MIB, whose object identifier is

{jnxMibs 35}, provides support for this feature.

Event Automation and Event Policy Developer Guide

Example: Raising an SNMP Trap in Response to an Event

This example configures an event policy to raise a trap and to execute an event script in response to an event:

•

Requirements on page 44

•

Overview on page 44

•

Configuration on page 44

Requirements

A device running Junos OS, which is configured for SNMP.

Overview

The following example configures the event policy raise-trap-on-ospf-nbrdown to trigger on the RPD_OSPF_NBRDOWN event, which indicates a terminated OSPF adjacency with a neighboring router. The event policy action raises a trap in response to the event. The device sends a notification to the SNMP manager, if one is configured under the [edit snmp] hierarchy level.

Additionally, the event policy executes the event script ospf.xsl in response to this event and provides the affected interface as an argument to the script. The

$$rpd_ospf_nbrdown.interface-name argument resolves to the interface name associated with the triggering event.

The event script output is recorded in the file ospf-out, and the output file is uploaded to the destination mgmt-archives, which is configured at the [edit event-options destinations] hierarchy level. To invoke an event script in an event policy, the event script must be present in the /var/db/scripts/event directory on the hard drive, and it must be enabled in the configuration.

CLI Quick

Configuration

set event-options policy raise-trap-on-ospf-nbrdown events rpd_ospf_nbrdown set event-options policy raise-trap-on-ospf-nbrdown then raise-trap set event-options policy raise-trap-on-ospf-nbrdown then event-script ospf.xsl arguments interface "{$$rpd_ospf_nbrdown.interface-name}" set event-options policy raise-trap-on-ospf-nbrdown then event-script ospf.xsl

output-filename ospf-out set event-options policy raise-trap-on-ospf-nbrdown then event-script ospf.xsl destination mgmt-archives

Chapter 4: Configuring Event Policy Actions

Step-by-Step

Procedure

Configuring the Event Policy

To configure an event policy that raises a trap on receipt of an event and optionally executes an event script:

Create and name the event-policy.

[edit] user@R1# edit event-options policy raise-trap-on-ospf-nbrdown

Configure the event policy to match on the desired event, which in this example is the RPD_OSPF_NBRDOWN event.

[edit event-options policy raise-trap-on-ospf-nbrdown] user@R1# set events rpd_ospf_nbrdown

Configure the event policy action to raise an SNMP trap in response to the event.

[edit event-options policy raise-trap-on-ospf-nbrdown] user@R1# set then raise-trap

(Optional) Configure additional actions to take in response to the event.

This example executes an event script and uploads the associated output file to a predefined destination.

[edit event-options policy raise-trap-on-ospf-nbrdown] user@R1# set then event-script ospf.xsl arguments interface

{$$rpd_ospf_nbrdown.interface-name} user@R1# set then event-script ospf.xsl output-filename ospf-out destination mgmt-archives

Commit the configuration.

user@R1# commit

Results [edit event-options] policy raise-trap-on-ospf-nbrdown { events rpd_ospf_nbrdown; then { event-script ospf.xsl { arguments { interface "{$$rpd_ospf_nbrdown.interface-name}";

} output-filename ospf-out; destination mgmt-archives;

} raise-trap;

}

Documentation

•

Configuring SNMP on a Device Running Junos OS

•

Interpreting the Enterprise-Specific System Log MIB

Event Automation and Event Policy Developer Guide

Configuring the System Log Priority of the Triggering Event in an Event Policy

•

Understanding the Event System Log Priority in an Event Policy on page 46

•

Example: Configuring the Event System Log Priority in an Event Policy on page 47

Understanding the Event System Log Priority in an Event Policy

Starting with Junos OS Release 12.1, you can configure an event policy to override the default system log priority of a triggering event so that the system logs the event with a different facility type, severity level, or both. To override the priority of the triggering event, configure the priority-override statement at the [edit

Configuring the Log Files on page 48

policy-name

then ]

hierarchy level. To override the facility type with which the triggering event is logged, include the facility statement and the new facility type. To override the severity level with which the triggering event is logged, include the severity statement and the new severity level.

Junos OS processes generate system log messages, or event notifications, to record the events that occur on a routing, switching, or security platform. Each system log message identifies the Junos OS process that generated the message and describes the operation or error that occurred. The Junos OS event process (eventd) receives the event notifications, and configured event policies instruct the eventd process to perform a set of actions upon receipt of specific events or correlated events.

Each system log message belongs to a facility, which groups messages that either are generated by the same source (such as a software process) or concern a similar condition or activity (such as authentication attempts). Each message is also preassigned a severity level, which indicates how seriously the triggering event affects the functions of the routing, switching, or security platform. A message’s facility and severity level are together referred to as its priority. For more information about facility and severity levels, see Junos

OS System Logging Facilities and Message Severity Levels.

When you configure logging on a device for a specific facility and destination, you also specify a severity level. Messages from that facility that are rated at the configured severity level or higher are logged. To log related events with different severity levels in the same log file, you must filter events using the lowest severity level of any of the events from that facility to be logged. This can result in unwieldy log files that are difficult and time-consuming to parse.

For example, Junos OS logs the protocol UP and DOWN events with different severity levels. Both the SNMP_TRAP_LINK_DOWN and SNMP_TRAP_LINK_UP events have a facility of 'daemon', but the SNMP_TRAP_LINK_DOWN event has a severity level of

'warning', and the SNMP_TRAP_LINK_UP event has a severity level of 'info'. Normally, when you configure a system log file, you must filter events to that file using the lower severity level of 'info' in order to log both of the events.

The event policy priority-override statement enables you to customize the priority of the triggering event so that it is logged using a different facility type and severity level. Suppose you configure a system log file to filter events of facility 'daemon' and severity 'notice’, and you have event policies that trigger on the RPD_ISIS_ADJDOWN and RPD_ISIS_ADJUP events. When the system generates an RPD_ISIS_ADJDOWN message reporting that the

Chapter 4: Configuring Event Policy Actions

IS-IS adjacency with a neighboring router was terminated, this message is logged.

However, if the system subsequently generates an RPD_ISIS_ADJUP event notification reporting that the IS-IS adjacency has been restored, by default, the message is not logged, because it has a lower severity level of 'info'. In the event policy that triggers on the RPD_ISIS_ADJUP event, you can configure the associated priority so that the triggering

RPD_ISIS_ADJUP event is logged with a severity level of 'notice' and is captured in the configured log file.

NOTE: Event policies are executed in the order in which they appear in the configuration. When you configure multiple event policies to override the priority of the same event, the event is logged based on the priority set by the last executed event policy to change it.

Example: Configuring the Event System Log Priority in an Event Policy

It is necessary to log events when monitoring, managing, and troubleshooting routing, switching, and security devices. Starting with Junos OS Release 12.1, you can configure an event policy to override the priority of its triggering event so that it is logged based on a different facility type and severity level. This enables the event to be logged even if the system filters events to the destination log file using a different facility type or a higher severity level.

This example simulates an SNMP_TRAP_LINK_UP event for a specific interface. Upon receipt of the event, the event policy overrides the severity level of the event so that it is captured in the configured log file.

•

Requirements on page 47

•

Overview on page 47

•

Configuration on page 48

•

Verification on page 50

Requirements

•

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

• Interface is configured and active. This example uses the ge-0/3/1.0 interface.

Overview

This example configures two log files to capture events of facility 'daemon'. One log file is configured to filter for events of severity 'warning' or higher, and the second log file is configured to filter for events of severity 'info' or higher.

The configured event policy triggers on the SNMP_TRAP_LINK_UP event for interface ge-0/3/1.0. The example generates an SNMP_TRAP_LINK_DOWN event followed by an

SNMP_TRAP_LINK_UP event for the ge-0/3/1.0 interface. The SNMP_TRAP_LINK_DOWN event, which has a severity level of 'warning' is captured in both configured log files. Upon receipt of the SNMP_TRAP_LINK_UP event, the event policy overrides the severity level of the event to 'warning' so that it is also captured in the log file that filters for events of

Event Automation and Event Policy Developer Guide

48 severity 'warning'. By default, if the event policy does not override the severity level of this event, it is only captured in the log file that filters for the severity level 'info'.

CLI Quick

Configuration

•

•

Verifying the Default System Log Priority of the Events on page 49

•

Configuring the Event Policy on page 49

set event-options policy log-on-snmp-trap-link-up then priority-override severity warning

Step-by-Step

Procedure

Configuring the Log Files

Configure two log files at the [edit system syslog] hierarchy level to record events of facility daemon.

Configure one log to record events of severity 'info' or higher and one log file to record events of severity 'warning' or higher.

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

Commit the configuration.

bsmith@R1# commit

To manually test the logging of the events, take the ge-0/3/1.0 logical interface temporarily offline, and then bring it back up.

This generates an SNMP_TRAP_LINK_DOWN event followed by an

SNMP_TRAP_LINK_UP event.

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

Results

[edit] system { syslog { file syslog-event-daemon-info { daemon info;

} file syslog-event-daemon-warning { daemon warning;

Chapter 4: Configuring Event Policy Actions

}

Verifying the Default System Log Priority of the Events

Purpose Verify that the system generated the SNMP_TRAP_LINK_DOWN and

SNMP_TRAP_LINK_UP events for the ge-0/3/1.0 interface, and note where each event is logged.

Action Review the contents of the syslog-event-daemon-info file configured in Step

of the previous procedure. The output shows that the ge-0/3/1.0 interface was brought down and back up and generated an SNMP_TRAP_LINK_DOWN event followed by an

SNMP_TRAP_LINK_UP event.

bsmith@R1> show log syslog-event-daemon-info

Oct 24 13:22:17 R1 mib2d[1394]: SNMP_TRAP_LINK_DOWN: ifIndex 539, ifAdminStatus

down(2), ifOperStatus down(2), ifName ge-0/3/1.0

...

Oct 24 13:22:29 R1 mib2d[1394]: SNMP_TRAP_LINK_UP: ifIndex 539, ifAdminStatus up(1), ifOperStatus up(1), ifName ge-0/3/1.0

Review the contents of the syslog-event-daemon-warning file configured in Step

of the previous procedure. Because the severity level of the SNMP_TRAP_LINK_UP event is

'info', it does not appear in a log file that is configured to only record events of severity

'warning' or higher. By default, this system log file captures the SNMP_TRAP_LINK_DOWN events, but does not capture the SNMP_TRAP_LINK_UP events.

bsmith@R1> show log syslog-event-daemon-warning

Oct 24 13:22:17 R1 mib2d[1394]: SNMP_TRAP_LINK_DOWN: ifIndex 539, ifAdminStatus

down(2), ifOperStatus down(2), ifName ge-0/3/1.0

Meaning Because the SNMP_TRAP_LINK_UP event has a default severity of 'info', it is not forwarded to log files that are configured to capture events of higher severity.

Step-by-Step

Procedure

Configuring the Event Policy

Create and name the event-policy.

[edit] bsmith@R1# edit event-options policy log-on-snmp-trap-link-up

Configure the events statement.

For this example, the event policy triggers on the SNMP_TRAP_LINK_UP event. Set the attributes-match statement so that the policy triggers only if the

SNMP_TRAP_LINK_UP event occurs for the ge-0/3/1.0 interface.

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

Event Automation and Event Policy Developer Guide

Configure the priority-override event policy action, and include the severity statement with a value of warning.

[edit event-options policy log-on-snmp-trap-link-up] bsmith@R1# set then priority-override severity warning

Commit the configuration.

bsmith@R1# commit

To manually test the event policy, take the ge-0/3/1.0 logical interface temporarily offline, and then bring it back up. This generates an SNMP_TRAP_LINK_DOWN event followed by an SNMP_TRAP_LINK_UP event.

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

Results [edit] event-options { policy log-on-snmp-trap-link-up { events snmp_trap_link_up; attributes-match { snmp_trap_link_up.interface-name matches ge-0/3/1.0;

} then { priority-override { severity warning;

}

Verification

Confirm that the configuration is working properly.

Verifying the Configured System Log Priority of the Events

Purpose Verify that the system generated the SNMP_TRAP_LINK_DOWN and

SNMP_TRAP_LINK_UP events for the ge-0/3/1.0 interface, and note where each event is logged.

Chapter 4: Configuring Event Policy Actions

Action Review the contents of the syslog-event-daemon-warning file. Because the event policy overrides the severity level of the SNMP_TRAP_LINK_UP event, it now appears in the log file that is configured to only record events of severity 'warning' or higher. By default, this system log file captures the SNMP_TRAP_LINK_DOWN events, but does not capture the

SNMP_TRAP_LINK_UP events.

bsmith@R1> show log syslog-event-daemon-warning

Oct 24 13:29:48 R1 mib2d[1394]: SNMP_TRAP_LINK_DOWN: ifIndex 539, ifAdminStatus

down(2), ifOperStatus down(2), ifName ge-0/3/1.0

Oct 24 13:30:02 R1 mib2d[1394]: SNMP_TRAP_LINK_UP: ifIndex 539, ifAdminStatus up(1), ifOperStatus up(1), ifName ge-0/3/1.0

Meaning Although the SNMP_TRAP_LINK_UP event has a severity of 'info', configuring the priority-override statement with a severity of 'warning' causes the event to be forwarded to the system logs with the configured severity level. The event can be captured in logs that filter for a different facility type and a higher severity level.

Documentation

•

Junos OS System Logging Facilities and Message Severity Levels

•

Specifying the Facility and Severity of Messages to Include in the Log

•

facility on page 116

•

priority-override on page 123

•

severity on page 126

Event Automation and Event Policy Developer Guide

CHAPTER 5

Configuring Event Policy File Archiving

•

Event Policy File Archiving Overview on page 53

•

Example: Defining Destinations for File Archiving by Event Policies on page 54

•

Example: Configuring an Event Policy to Upload Files on page 57

•

Configuring the Delay Before Files Are Uploaded by an Event Policy on page 63

•

Configuring an Event Policy to Retry the File Upload Action on page 65

Event Policy File Archiving Overview

Various types of files are useful in diagnosing events. When an event policy action generates output files, you can archive the files for later analysis. Similarly, you might want to archive system files, including system log files, core files, and configuration files, from the time an event occurs.

When an event occurs, you can upload relevant files to a specified location for analysis.

To archive files from an event policy, configure one or more destinations specifying the archive sites to which the files are uploaded. You then reference the configured destinations within event policies.

A transfer delay allows you to specify the number of seconds the event process (eventd) waits before beginning to upload a file or multiple files. A transfer delay helps ensure that a large file, such as a core file, is completely generated before the upload begins.

You can associate transfer delays with a destination and with an event policy action. If you associate a transfer delay with a destination, the transfer delay applies to all file upload actions that use that destination. You can also assign a transfer delay to a single event policy action. For example, you might have multiple event policy actions that use the same destination, and for some of these event policy actions, you want a transfer delay, and for other event policy actions you want no transfer delay. If you configure a transfer delay for a destination, and you also configure a transfer delay for the event policy action, the resulting transfer delay is the sum of the two delays.

Transient network problems can cause a file upload operation to fail. By default, if the file upload operation fails for any reason, the event policy does not retry the upload operation. However, you can configure an event policy to retry the file upload operation a specified number of times if the initial upload fails. You can also configure the time interval between each retry attempt.

Event Automation and Event Policy Developer Guide

Documentation

•

Example: Defining Destinations for File Archiving by Event Policies on page 54

•

Example: Configuring an Event Policy to Upload Files on page 57

•

Configuring the Delay Before Files Are Uploaded by an Event Policy on page 63

•

Configuring an Event Policy to Retry the File Upload Action on page 65

Example: Defining Destinations for File Archiving by Event Policies

This example configures an archive site for event policies. Event policy actions that reference the configured destination upload specified files to that site.

•

Requirements on page 54

•

Overview on page 54

•

Configuration on page 55

•

Verification on page 56

Requirements

This example uses a device running Junos OS. No additional configuration beyond device initialization is required before configuring this example.

Overview

When an event occurs, you can upload relevant files to a specified location for analysis.

To define a destination archive site, include the destinations statement at the [edit event-options] hierarchy level.

[edit

event-options ]

destinations

{

destination-name {

archive-sites

{

url <password password>;

}

“Configuring the Delay Before Files Are Uploaded by an Event Policy” on page 63

seconds;

}

The destination-name is a user-defined identifier, which is referenced by event policies.

You can define multiple destinations with different archive sites.

For each destination, configure one or more archive site URIs, which are the actual sites to which the files are uploaded. If you specify multiple archive site URIs for a given destination, the device attempts to transfer to the first archive site in the list, moving to

Chapter 5: Configuring Event Policy File Archiving the next site in the list only if the transfer fails. Optionally, you can specify a plain-text password for login into an archive site.

Specify the archive site URI as a file URI, an active or passive FTP URI, or a Secure Copy

(SCP) URI. Local device directories are also supported (for example, /var/tmp). When you specify the archive site URI, do not add a forward slash (/) to the end of the URI.

file:<//host>/path ftp://username@host:<port>url-path pasvftp://username@host:<port>url-path scp://username@host:<port>url-path

The format for the destination filename is device-name_filename_YYYYMMDD_HHMMSS.

The transfer-delay statement allows you to specify the number of seconds the event process (eventd) waits before beginning to upload a file or multiple files to that destination. A transfer delay allows you to ensure that a large file, such as a core file, is completely generated before the upload begins. For more information, see

This example configures a new archive destination named mgmt-archives, which can be referenced in event policies for file archiving. The example configures two archive sites for this destination. The first site is the Secure Copy URI

"scp://[email protected]/test" for which a password is configured. The second site is a directory on the local device. The device attempts to transfer to the first archive site in the list, moving to the next site only if the transfer to the first site fails. The example configures a transfer delay of five seconds for all files uploaded to the mgmt-archives archive site.

Configuration

CLI Quick

Configuration

"scp://[email protected]/test" password PaSsWoRd set event-options destinations mgmt-archives archive-sites /var/log set event-options destinations mgmt-archives transfer-delay 5

Step-by-Step

Procedure

Configure a new archive destination named mgmt-archives that can be referenced by event-policies.

Configure the identifier and associated archive sites for each destination.

The device transfers to the first archive site in the list, moving to the next site only if the transfer to the first site fails.

[edit event-options destinations] user@host# set mgmt-archives archive-sites scp://[email protected]/test

Event Automation and Event Policy Developer Guide

user@host# set mgmt-archives archive-sites /var/log

If authentication is required to access any of the archive sites, configure the required plain-text password for that site.

[edit event-options destinations] user@host# set mgmt-archives archive-sites scp://[email protected]/test password PaSsWoRd

(Optional) Configure the transfer delay associated with each destination. The mgmt-archives destination has a transfer delay of five seconds.

[edit event-options destinations] user@host# set mgmt-archives transfer-delay 5

Commit the configuration.

user@host# commit

You can reference configured destinations in an event policy. For information about referencing destinations in event policies, see

“Example: Configuring an Event Policy to Upload Files” on page 57

and

“Configuring an Event Policy to Execute Operational

Mode Commands” on page 19 .

Verification

Verifying the Configuration

Purpose Issue the show configuration event-options operational mode command to review the resulting configuration.

Action user@host> show configuration event-options destinations { mgmt-archives { transfer-delay 5; archive-sites {

"scp://[email protected]/test" password

"$9$z3GRF9tu0IcrKO1bYoGq.0O1IEy"; ## SECRET-DATA

/var/log;

}

Meaning In the sample output, the mgmt-archives destination has two archive sites and a transfer delay of five seconds. You can now reference this destination in event policies. When you reference the mgmt-archives destination in an event policy, specified files are uploaded to the first archive site after a five second delay. If the transfer to the first archive fails, the device attempts to upload the files to the /var/log archive site. For more information about referencing destinations in event policies, see

“Example: Configuring an Event

Policy to Upload Files” on page 57

Note that although the plain-text password is visible when you configure it, the configuration displays the encrypted password.

Chapter 5: Configuring Event Policy File Archiving

Documentation

•

Example: Configuring an Event Policy to Upload Files on page 57

•

Configuring the Delay Before Files Are Uploaded by an Event Policy on page 63

•

Configuring an Event Policy to Retry the File Upload Action on page 65

•

destinations on page 110

Example: Configuring an Event Policy to Upload Files

This example configures event policy actions that upload relevant files to a specified location for analysis.

•

Requirements on page 57

•

Overview on page 57

•

Configuration on page 59

•

Verification on page 63

Requirements

Before you begin:

• Configure the destinations that you will reference in the event policy. See

“Example:

Defining Destinations for File Archiving by Event Policies” on page 54 .

•

Configure the general event policy and triggering events.

Overview

When an event policy action generates output files, you can archive the files for later analysis. Similarly, you might want to archive system files, including system log files, core files, and configuration files, from the time an event occurs. You can configure an event policy to upload existing system files or to upload the output files generated from an invoked event-script or command at the time an event occurs. This section outlines the configuration hierarchies for uploading each of these file types using an event policy.

When you configure an event policy to upload files, you reference configured destinations within the event policy. Specify a destination name that is configured at the [edit event-options destinations] hierarchy level. For more information, see

“Example: Defining

Destinations for File Archiving by Event Policies” on page 54 .

To upload system files to a configured archive site, configure the upload statement at the [edit event-options policy policy-name then] hierarchy level. If the configured events occur, the eventd process executes the upload action.

[edit event-options policy policy-name then]

upload

filename (filename | committed) destination destination-name {

number retry-interval seconds;

seconds;

user-name

username;

}

Event Automation and Event Policy Developer Guide

The upload filename committed destination destination-name statement uploads the committed configuration file.

If desired, you can include multiple upload statements, one for each type of file to be archived. In the filename statement, specify a file or multiple files to be uploaded. You can specify multiple files with one filename configuration statement (sometimes called

filename globbing). For example, to upload all files that are located in the /var/log directory and that start with the messages string, include the following statement: upload filename /var/log/messages* destination destination-name;

When an event policy executes commands in response to an event, you can write the command output to a file. To configure an event policy to upload the generated output file to a configured archive site, include the following statements at the [edit event-options policy policy-name then] hierarchy level:

[edit event-options policy policy-name then]

execute-commands

{

destination-name {

count retry-interval seconds;

seconds;

}

filename;

}

When an event policy executes an event script in response to an event, you can write the script output to a file. To configure an event policy to upload the generated output file to a configured archive site, include the following statements at the [edit event-options policy policy-name then] hierarchy level:

[edit event-options policy policy-name then]

event-script

filename {

destination-name {

count retry-interval seconds;

seconds;

}

“Configuring the Delay Before

filename;

}

The transfer-delay statement listed in each hierarchy defines the time interval that the system waits before uploading the files specified by that event policy action. If you have also configured a transfer delay for the destination at the [edit event-options destinations

destination-name] hierarchy level, the total transfer delay is the sum of the two delays.

For more detailed information about transfer delays, see

Files Are Uploaded by an Event Policy” on page 63

If the first upload attempt fails, retry-count specifies the number of additional times the system attempts to upload the file. The retry-interval specifies the time interval that the system waits between upload attempts. For more information, see

“Configuring an Event

Policy to Retry the File Upload Action” on page 65 .

When an event policy uploads files, the files are named and time-stamped in the following format to ensure unique filenames:

device-name_filename_YYYYMMDD_HHMMSS

Chapter 5: Configuring Event Policy File Archiving

If a policy uploads multiple files within a 1-second period, the software gives each file a unique number as well, as follows:

device-name_filename_YYYYMMDD_HHMMSS_number

The number can be from 001 through 999. For example, if you have an event policy action with output filename rpd-messages on device1, and this event policy is executed three times in 1 second, the files are named as follows:

• device1_rpd-messages_20070623_132333

• device1_rpd-messages_20070623_132333_001

• device1_rpd-messages_20070623_132333_002

In this example, policy1 consists of the following statements, where e1 is the triggering event. The example then configures the event policy to upload a log file and the committed configuration file as well as the output files generated from the execute-commands and event-script actions.

[edit event-options policy policy1] events e1; then { execute-commands { commands {

"show interfaces brief ge-*";

}

} event-script event-script1;

}

Configuration

CLI Quick

Configuration

•

Uploading System Files on page 60

•

Uploading Command Output Files on page 61

•

Uploading Event Script Output Files on page 62

•

Results on page 62

To quickly configure this example, copy the following commands, paste them in a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level: set event-options policy policy1 then upload filename /var/log/messages destination mgmt-archives transfer-delay 4 set event-options policy policy1 then upload filename /var/log/messages destination mgmt-archives retry-count 5 retry-interval 4 set event-options policy policy1 then upload filename /var/log/messages destination mgmt-archives user-name admin set event-options policy policy1 then upload filename /var/log/messages destination mgmt-server set event-options policy policy1 then upload filename committed destination mgmt-archives set event-options policy policy1 then execute-commands output-filename ge-interfaces set event-options policy policy1 then execute-commands destination mgmt-archives transfer-delay 5

Event Automation and Event Policy Developer Guide set event-options policy policy1 then execute-commands destination mgmt-archives retry-count 5 retry-interval 4 set event-options policy policy1 then event-script event-script1 output-filename policy1-script-output set event-options policy policy1 then event-script event-script1 destination mgmt-archives transfer-delay 5 set event-options policy policy1 then event-script event-script1 destination mgmt-archives retry-count 5 retry-interval 4

Step-by-Step

Procedure

Uploading System Files

Configure the event policy policy1 to upload the system file /var/log/messages to the archive sites mgmt-archives and mgmt-server. Additionally, upload the committed configuration to the archive site mgmt-archives. The destination archive sites should already be configured at the [edit event-options destinations] hierarchy level

Configure the upload statement, and include the file to archive and the destination archive site.

[edit event-options policy policy1 then] bsmith@R1# set upload filename /var/log/messages destination mgmt-archives bsmith@R1# set upload filename /var/log/messages destination mgmt-server

To upload the committed configuration file, specify the filename value as committed.

[edit event-options policy policy1 then] bsmith@R1# set upload filename committed destination mgmt-archives

(Optional) Configure the transfer delay associated with each file and destination.

The following configuration mode command sets the transfer delay for the

/var/log/messages file to 4 seconds when uploaded to the mgmt-archives destination. If you have also configured a transfer delay for the destination, the total delay is the sum of the two delays.

[edit event-options policy policy1 then] bsmith@R1# set upload filename /var/log/messages destination mgmt-archives transfer-delay 4

(Optional) Configure the retry count and retry interval associated with a file and destination.

In this example, if the /var/log/messages file fails to upload to the mgmt-archives site, the system attempts the upload up to 5 more times and waits 4 seconds in between each attempt.

[edit event-options policy policy1 then] bsmith@R1#set upload filename /var/log/messages destination mgmt-archives retry-count 5 retry-interval 4

(Optional) Configure the username associated with a file and destination. The system uploads the file using the privileges of the specified user.

[edit event-options policy policy1 then] bsmith@R1#set upload filename /var/log/messages destination mgmt-archives user-name admin

Chapter 5: Configuring Event Policy File Archiving

Commit the configuration.

[edit event-options policy policy1 then] bsmith@R1# commit

Step-by-Step

Procedure

Uploading Command Output Files

When the event policy invokes the execute-commands action, the command output can be written to a file. Configure the event policy policy1 to write command output to a file and upload the generated file to the destination mgmt-archives, which is already configured at the [edit event-options destinations] hierarchy level.

Configure the filename of the generated output file.

[edit event-options policy policy1 then] bsmith@R1# set execute-commands output-filename ge-interfaces

Configure the destination statement to upload the generated file to the desired archive site.

[edit event-options policy policy1 then] bsmith@R1# set execute-commands destination mgmt-archives

(Optional) Configure the transfer delay for each destination.

The following command sets the transfer delay for files uploaded to the mgmt-archives destination to 5 seconds.

[edit event-options policy policy1 then] bsmith@R1# set execute-commands destination mgmt-archives transfer-delay 5

(Optional) Configure the retry count and retry interval associated with each destination.

In this example, if the output file fails to upload to the mgmt-archives site, the system attempts the upload up to 5 more times and waits 4 seconds in between each attempt.

[edit event-options policy policy1 then] bsmith@R1#set execute-commands destination mgmt-archives retry-count 5 retry-interval 4

Commit the configuration.

[edit event-options policy policy1 then] bsmith@R1# commit

Event Automation and Event Policy Developer Guide

Step-by-Step

Procedure

Uploading Event Script Output Files

When the event policy invokes an event script, the script output can be written to a file.

Configure the event policy policy1 to write event-script output to a file and upload the generated file to the destination mgmt-archives, which is already configured at the [edit event-options destinations] hierarchy level. In this example, the event policy invokes an event script named event-script1.

Configure the filename of the generated output file.

[edit event-options policy policy1 then] bsmith@R1# set event-script event-script1 output-filename policy1-script-output

Configure the destination statement to upload the generated file to the desired archive site.

[edit event-options policy policy1 then] bsmith@R1# set event-script event-script1 destination mgmt-archives

(Optional) Configure the transfer delay for each destination.

The following command sets the transfer delay for files uploaded to the mgmt-archives destination to 5 seconds.

[edit event-options policy policy1 then] bsmith@R1# set event-script event-script1 destination mgmt-archives transfer-delay 5

(Optional) Configure the retry count and retry interval associated with each destination.

In this example, if the output file fails to upload to the mgmt-archives site, the system attempts the upload up to 5 more times and waits 4 seconds in between each attempt.

[edit event-options policy policy1 then] bsmith@R1#set event-script event-script1 destination mgmt-archives retry-count 5 retry-interval 4

Commit the configuration.

[edit event-options policy policy1 then] bsmith@R1# commit

Results

[edit event-options policy policy1 then] upload filename /var/log/messages destination mgmt-archives { user-name admin; transfer-delay 4; retry-count 5 retry-interval 4;

} upload filename /var/log/messages destination mgmt-server upload filename committed destination mgmt-archives; execute-commands { commands {

Chapter 5: Configuring Event Policy File Archiving

"show interfaces brief ge-*";

} output-filename ge-interfaces; destination mgmt-archives { transfer-delay 5; retry-count 5 retry-interval 4;

}

} event-script event-script1 { output-filename policy1-script-output; destination mgmt-archives { transfer-delay 5; retry-count 5 retry-interval 4;

}

Verification

Verifying the Upload

Purpose When the configured event triggers the event policy, the system uploads the generated output files and the specified system files to the URL defined in the mgmt-archives destination. On the destination server, verify that all files have been uploaded.

Action On the destination server, verify that all uploaded files are present.

% ls

R1_ge-interfaces_20111209_213452

R1_juniper.conf.gz_20111209_213409

R1_messages_20111209_212941

R1_policy1-script-output_20111209_212619

Meaning Note that the filename format for each file includes the device name, the filename, and the date and time stamp.

If all of the uploaded files are present, the event policy and upload actions are working correctly. If none of the files are uploaded, verify that the destination is configured and that the archive site URL and any required password is entered correctly. For information about configuring destinations, see

“Example: Defining Destinations for File Archiving by

Event Policies” on page 54

. If a portion of the files are missing, configure a longer transfer delay and increase the retry count and retry interval for those files.

Documentation

•

Example: Defining Destinations for File Archiving by Event Policies on page 54

•

Configuring the Delay Before Files Are Uploaded by an Event Policy on page 63

•

Configuring an Event Policy to Retry the File Upload Action on page 65

Configuring the Delay Before Files Are Uploaded by an Event Policy

A transfer delay allows you to specify the number of seconds the event process (eventd) waits before beginning to upload a file or multiple files. A transfer delay allows you to

Event Automation and Event Policy Developer Guide ensure that a large file, such as a core file, is completely generated before the upload begins.

As described in

“Example: Defining Destinations for File Archiving by Event Policies” on page 54

, you can associate a transfer delay with a destination. If you associate a transfer delay with a destination, the transfer delay applies to all file upload actions that use the destination.

In the following example, the some-dest destination is common for both event policies, policy1 and policy2. A transfer delay of 2 seconds is associated with the some-dest destination and applies to uploading the output files to the destination for both event policies.

[edit event-options] policy policy1 { events e1; then { execute-commands { commands {

"show version";

} output-filename command-output.txt; destination some-dest;

}

} policy policy2 { events e2; then { event-script bar.xsl { output-filename event-script-output.txt; destination some-dest;

}

} destinations { some-dest { transfer-delay 2; archive-sites {

"scp://[email protected]/foo/moo" password "password";

}

Suppose you have multiple event policy actions that use the same destination. For some of these event policy actions, you want a transfer delay, and for other event policy actions you want no transfer delay. To assign a transfer delay to a single event policy action, include the optional transfer-delay statement for each action:

seconds;

You can include this statement at the following hierarchy levels:

• [edit

policy-name

filename

destination-name]

Chapter 5: Configuring Event Policy File Archiving

• [edit

policy-name

then execute-commands

destination-name]

• [edit

policy-name

“Example: Assigning a Transfer Delay to an Event Policy

filename (filename | committed) destination destination-name]

If you configure a transfer delay at the [edit event-options destinations destination-name] hierarchy level, and you also configure a transfer delay for the event policy action, the resulting transfer delay is the sum of the two:

Total transfer-delay = transfer-delay (destination) + transfer-delay (event-policy-action)

For a configuration example, see

Action” on page 87 .

Configuring an Event Policy to Retry the File Upload Action

Transient network problems can cause a file upload operation to fail. When this happens, you might want to retry the file upload operation. By default, if the file upload operation fails for any reason, the event policy does not retry the upload operation.

To configure the policy to retry a file upload operation, include the optional retry-count and retry-interval statements:

number retry-interval seconds;

You can include these statements at the following hierarchy levels:

• [edit

policy-name

filename

destination-name]

• [edit

policy-name

then execute-commands

destination-name]

• [edit

policy-name

“Example: Retrying the File Upload Action” on page 95 .

filename (filename | committed) destination destination-name]

The retry-count statement sets the number of times the policy retries the upload operation if the upload fails. The default value for the retry-count statement is 0 and the maximum is 10.

If you include the retry-count statement, you can also include the retry-interval statement, which sets the time interval (in seconds) between each retry.

For a configuration example, see

Event Automation and Event Policy Developer Guide

CHAPTER 6

Configuring Event Policy Privileges

•

Changing the User Privilege Level for an Event Policy Action on page 67

Changing the User Privilege Level for an Event Policy Action

You can associate a user with each action in an event policy. If a user is not associated with an event policy action, then the action is executed as user root by default.

To specify the user under whose privileges an action is executed, include the user-name statement:

user-name

username;

You can include this statement at the following hierarchy levels:

• [edit

policy-name

filename]

• [edit

policy-name

then execute-commands ]

• [edit

policy-name