Topic: tech juniper jaut prev next
tech juniper jaut > Module 09: Junos Event Policies and Event Scripts
Events originate as SNMP traps or sytem log messages. The events process receives messages from other processes. Depending on configuration, the event process may take an action: logging, running a script, etc..
Find attributes by:
The easiest way is to look at a recent occurence of the event.
show log messages | match SNMP
More information (all attributes) can be displayed in the log by running;
set system syslog file messages structured-data
Enabling ‘traceoptions’ under ‘event-options’ can be resource-intensive and is usually done on a lab device;
event-options {
traceoptions {
file event-trace;
flag events;
flag policy;
}
}
Events can be generated from the command line for testing. Note that ‘logger’ is not officially supported and should not be used in production;
start shell
logger -e VRRPD_NEW_MASTER
The device can be configured to generate recurring events;
event-options {
generate-event {
VRRPD_NEW_MASTER time-interval 60;
MY_CUSTOM_EVENT_1 time-of-day "07:00:00 +0000";
}
}
Event policies are like if/then filters. They are processed in order. If a policy matches, then further policies will still be processed, unless the action is ‘ignore’. Event names are case-insensitive.
Here is a complete example to run some ‘show’ commands, save the output to a file, and securely copy the file to a remote server;
event-options {
policy monitor-device {
events MY_CUSTOM_EVENT_1;
then {
execute-commands {
commands {
"show system core-dumps";
"show chassis alarms";
}
output-filename cmds.txt;
destination server1;
output-format text;
}
}
}
destinations {
server1 {
archive-sites {
"scp://lab@.../var/tmp" password "...";
}
}
}
}
The ‘events’, ‘within’, and ‘attributes-match’ are logically ANDed. Multiple listed events are ORed. The ‘within’ option looks back and sees whether an event happened previously. This example ignores events when a router becomes the VRRP master within two minutes of the interface coming up;
event-options {
policy interface-up {
events vrrpd_new_master;
within 120 events snmp_trap_link_up;
attributes-match {
snmp_trap_link_up.interface-name equals vrrpd_new_master.interface-name;
}
then {
ignore;
}
}
}
More parameters can be given in the ‘within’ clause. If multiple events of different types listed in ‘events’ are received, they all count as the same type for this purpose. Events in each of the ‘events’ and ‘not events’ lines are ORed in both cases. Lines are ANDed together;
within <seconds> {
events ...;
not events ...;
trigger [on | after | until] count;
}
Multiple ‘within’ clauses can be specified and are again ANDed together. The ‘attributes-match’ clause can be combined with events in the ‘within’ clause. Only the most recent event of each type received is used.
If all the matching criteria are met, all of the ‘then’ clause is executed;
then {
change-configuration ...;
event-script ...;
execute-commands ...;
ignore;
priority-override ...;
raise-trap;
upload ...;
}
Commands can be executed in order;
then {
execute-commands {
commands {
"show vrrp"
}
output-filename ...;
destination ...;
output-format text;
}
}
Attributes can be referenced like variables when executing commands, either from the most recent event of a specified type, or the event which triggered the policy, or from the most recent event that matches any of the correlating events;
{$event.attribute-name}
{$$.attribute-name}
{$*.attribute-name}
For example, when the VRRP master changes, we are probably interested only in the event that triggered the policy;
event-options {
policy vrrpd {
events vrrpd_new_master;
then {
execute-commands {
commands {
"show vrrp interface {$$.interface-name}"
}
}
...
}
}
}
For example; changing a static route when the next hop goes down;
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/0/1;
}
then {
change-configuration {
retry count 5 interval 4;
commands {
"delete routing-options static route ... next-hop";
"set routing-options static route ... next-hop ...";
}
user-name ...;
commit-options {
log ...;
}
}
}
}
}
Execute an op or event script as a then action;
event-script record-commit.slax {
arguments {
user "{$$.username}";
message "{$$.message}";
}
output-filename cmds.txt;
destination server1;
output-format text;
}
The script must have been declared first;
event-options {
event-script {
file record-commit.slax
}
}
raise-trap StatementInstruct the device to raise an SNMP trap with the Juniper specific trap ‘jnxSyslogTrap’ in the MIB ‘juniperMIB.jnxTraps’. The event’s attributes appear in the trap as attribute/value pairs.
...
then {
raise-trap;
}
...
snmp {
community public;
trap-group NMS {
targets {
...;
}
}
}
upload StatementUpload a file to a server, with an optional delay;
then {
upload filename /var/tmp/*core* destination server1 {
transfer-delay 30;
}
}
ignore StatementUse the ignore statement to stop further processing. Note that events
ignored in this way will not be entered into Syslog.
Dampening slows down instances of events that have occurred repeatedly within a
short period of time. To clarify, within 60 means ‘60 seconds’, not 60
events;
event-options {
policy dampen-policy {
events event1;
within 60 events event1;
then {
ignore;
}
}
}
Op scripts can be run interactively through the CLI or through an event policy. Event scripts are triggered only by an event policy. Therefore, op scripts should be written to expect interactive input. However, when testing event scripts, they must be triggered using an event policy (such as by using ‘logger’, see ‘Generating Events’).
Both SLAX and Python event scripts receive the triggering event and a list of received events matching the correlating events as input. In Python, these are in the following objects, which can be queried using XPath;
from junos import Junos_Trigger_Event
from junos import Junos_Received_Events
Remember, unsigned Python scripts must be specifically enabled;
system {
scripts {
language python;
}
}
It is sometimes useful to define the event policy which triggers the script in
the script itself. Use the special event-definition variable, assigning to
it the XML definition of the event policy. The XML definition of the event
policy can be found by configuring it as normal, and running show | display
xml. Event policies defined in event scripts are evaluated after any
statically configured event policies and do not appear in the system
configuration.
Policies defined in scripts can be refreshed with;
request system scripts event-scripts reload
Arguments can be passed statically from the configuration;
event-script work.py {
arguments {
arg1 val1;
}
}
It is safer to store configuration in the configuration and pass it to event scripts than to keep it in the scripts.
event-script {
file ... {
remote-execution {
remote-hostname {
username ...;
password ...;
}
}
}
}
In Python, these details appear in the result of
Junos_Remote_Execution_Details(). The Junos PyEZ library is then used as
normal to connect to the remote device and run commands. In SLAX, they appear
as event-script-input/remote-execution-details.
Including the traceoptions statement under event-options will log
statements into the /var/log/eventd file. Files are rotated through
eventd.0.gz, etc.. Various flags can be configured; flag all records all
events.
Event script processing can also be logged to the /var/log/escript.log file.
Similarly, they are rotated through escript.log.0.gz, etc.. Include the
traceoptions flag output statement under event-options event-script to
enable logging.
By default, Junos runs Python scripts under nobody.nobody. Alternatively,
the user can be specified with python-script-user ... under event-options
event-script file ....