[Contents] [Prev] [Next] [Index] [Report an Error]

Executing Op Scripts in an Event Policy

Operation scripts (op scripts) are Extensible Stylesheet Transformation (XSLT) scripts that you write and that are run in the command-line interface (CLI). Op scripts can perform any function available through JUNOS XML or JUNOScript remote procedure calls (RPCs). Additionally, you can pass to an op script a set of arguments that you define.

A script can 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 run an op script anytime, simply by issuing the op filename.xsl operational mode command, as described in Configuring Op Scripts. You can also configure a policy that causes op 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 event-options]

policy policy-name {

    events [ events ];

    then {

        event-script filename.xsl {

            arguments {

                name value;

            }

            output-filename filename;

            destination destination-name;

        }

    }

}

In the events statement, you can list multiple events. If one or more of the listed events occurs, the op 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:

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.

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. All scripts that you reference in the event-script statement must be located in the /var/db/scripts/op directory and must be enabled at the [edit system scripts op] hierarchy level. For more information, see Basic Process for Using Op Scripts and Configuring Op 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:

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

user@host> help syslog event

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>

...

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:

  <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 script output for the specified script.

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 router named r1, if you configure the output filename to be ifl-events, and this event policy is triggered three times in one second, the files are named:

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

For a configuration example, see Executing an Op Script in Response to an Event.

[Contents] [Prev] [Next] [Index] [Report an Error]