Executing Operational Mode Commands
Operational mode commands cause the router to perform an operation or provide diagnostic output. They allow you to view statistics and information about a routing platform'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:
- JUNOS Interfaces Command Reference
- JUNOS Routing Protocols and Policies Command Reference
- JUNOS System Basics and Services Command Reference
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:[editevent-options]policypolicy-name{events [events];then{execute-commands{commands{"command";}output-filenamefilename;output-format(text | xml);destinationdestination-name;}}}In the
eventsstatement, 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 theset event-options policypolicy-nameevents ?configuration mode command:user@host#set event-options policypolicy-nameevents ?Possible completions:<event>[ Open a set of valuesacct_accounting_ferroracct_accounting_fopen_error...In addition, you can reference internally generated events, which are discussed in Generating Internal Events.
In the
commandsstatement, you can specify multiple operational mode commands to be issued on receipt of an 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 ofpolicy1causes theshow interfacescommand to be issued first, followed by theshow chassis alarmscommand:[edit event-options policy policy1 then execute-commands]user@host#showcommands {"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 theinterface-nameattribute 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 matchesevent. For example, when a policy issues theshow interfaces {$COSD_CHAS_SCHED_MAP_INVALID.interface-name}command,the{$COSD_CHAS_SCHED_MAP_INVALID.interface-name}variable is substituted by theinterface-nameattribute of the most recentCOSD_CHAS_SCHED_MAP_INVALIDevent cached by the eventd 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 syslogeventcommand:user@host>help syslogeventFor example, in the following command output, text in angle brackets (
< >) shows thatclassifier-typeis an attribute of thecosd_unknown_classifierevent:user@host>help syslog cosd_unknown_classifierName: COSD_UNKNOWN_CLASSIFIERMessage: rtsock classifier type <classifier-type> is invalid...Another way to view a list of event attributes is to issue the
setattributes-matchevent?configuration mode command at the[edit event-options policypolicy-name]hierarchy level:[edit event-options policypolicy-name]user@host#set attributes-matchevent?For example, in the following command output, the
event.attributelist shows thatclassifier-typeis an attribute of thecosd_unknown_classifierevent:[edit event-options policypolicy-name]user@host#set attributes-match cosd_unknown_classifier?Possible completions:<from-event-attribute> First attribute to comparecosd_unknown_classifier.classifier-typeIn this
setcommand, there is no space between the event name and the question mark (?).To view a list of all events that you can reference, issue the
setattributes-match?configuration mode command at the[edit event-options policypolicy-name]hierarchy level:[edit event-options policypolicy-name]user@host#set attributes-match ?Possible completions:<from-event-attribute> First attribute to compareacct_accounting_ferroracct_accounting_fopen_error...In the
output-filenamestatement, assign the name of the file to which to write command output for the specified commands. The filename format ishostname_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 beifl-events, and this event policy is triggered three times in one second, the files are named:By default, the command output format is JUNOS Extensible Markup Language (XML). To change the default, include the
output-format textstatement. This causes the command output to be in formatted ASCII text.In the
destinationstatement, 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 Correlating Events Based on Receipt of Other Events Within a Specified Time Interval.