Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configure an Event Policy to Execute Operational Mode Commands

Operational mode commands perform an operation or provide diagnostic output on a device running Junos OS. They enable you to view statistics and information about a device’s current operating status. They also enable you to take corrective actions, such as restarting software processes, taking a Physical Interface Card (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 CLI Explorer.

You can configure an event policy that executes operational mode commands and uploads the output of those commands to a specified location for analysis by including the following statements at the [edit event-options] hierarchy level:

In the events statement, you can list multiple events. If one or more of the listed events occurs, the eventd process executes the operational mode commands configured for the commands statement. 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:

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 triggers the policy. When combined with an attribute name, the variable resolves to the value of the attribute associated with the triggering event. For example, {$$.interface-name} resolves to the interface name associated with the triggering event.

  • {$event.attribute-name}—The single dollar sign with the event name ($event) notation represents the most recent event that matches event. When combined with an attribute name, the variable resolves to the value of the attribute associated with that event. For example, when a policy issues the show interfaces {$COSD_CHAS_SCHED_MAP_INVALID.interface-name} command, the {$COSD_CHAS_SCHED_MAP_INVALID.interface-name} variable resolves to the interface name associated with the most recent COSD_CHAS_SCHED_MAP_INVALID event cached by the event process.

  • {$*.attribute-name}—The dollar sign with the asterisk ($*) notation represents the most recent event that matches any of the correlating events. The variable resolves to the value of the attribute associated with most recent event that matches any of the correlated events specified in the policy configuration.

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 command:

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

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:

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

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:

When the eventd process executes the commands, it uploads the file with the command output to the location specified in the destination statement. In the destination statement, include a destination name that is configured at the [edit event-options destinations] hierarchy level. For more information, see Example: Define Destinations for File Archiving by Event Policies.

In the output-filename statement, define a descriptive string that will be included in the filename. Each uploaded file also includes the hostname and timestamp in the filename to ensure that the each filename is unique. If a policy is triggered multiple times in a 1-second period, an index number is appended to the filename to ensure that the filenames are still unique. The index number range is 001 through 999.

Starting in Junos OS Release 14.1R3, the naming convention and format for the output file generated by eventd are changed. When eventd executes the commands defined at the [edit event-options policy policy-name then execute-commands commands] hierarchy level and generates a file containing the command output, the name of the file depends on the version of Junos OS running on the device. Prior to Junos OS Release 14.1R3, the filename has the following naming convention:

Starting in Junos OS Release 14.1R3, the filename places the output-filename string after the timestamp.

For example, on a device named r1 running Junos OS Release 14.1R3 or a later release, if you configure the output-filename statement as ifl-events, and this event policy is triggered three times in 1 second, the files are named:

  • r1_20060623_132333_ifl-events

  • r1_20060623_132333_ifl-events_001

  • r1_20060623_132333_ifl-events_002

By default, the command output format is Junos Extensible Markup Language (XML). Configure the output-format text statement to format the command output as ASCII text.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
14.1R3
Starting in Junos OS Release 14.1R3, the naming convention and format for the output file generated by eventd are changed.