Triggers¶
The trigger feature allows the launching of commands in response to an event. This event can be either an alarm reaching a given severity level, the value of a pushed state leaf meeting certain conditions, or periodic.
Trigger on alarm¶
Both system and user alarms can be used in a trigger. When an alarm reaches the configured severity level, the specified commands are applied to the system.
See also
The command reference for the full list of options.
Trigger on system alarm¶
System alarms (capacity alarms, service alarms, link alarms, etc.) are
available by default. Their names can be found using show alarm inventory.
In this example, a trigger is configured to execute commands when the
fp-conntracks capacity alarm reaches the critical severity level:
vsr running config# / system trigger event conntrack-full on-alarm alarm fp-conntracks severity-level critical
vsr running config#! / system trigger event conntrack-full log true
vsr running config#! / system trigger event conntrack-full commands "
... show alarm list
... "
Here the associated state:
vsr> show state / system trigger
trigger
enabled true
event conntrack-full
enabled true
log true
commands "
show alarm list
"
on-alarm
alarm fp-conntracks
severity-level critical
..
..
..
Trigger on user alarm¶
User alarms are custom alarms defined in the alarm configuration. They allow triggering on arbitrary pushed state leaves.
Let’s start by creating a loopback interface:
vsr running config# / vrf main interface loopback lo1 ipv4 address 1.1.1.1/24
Then, create a user alarm that is raised when an ICMP tracker named ICMP-TRACKER goes down:
vsr running config# / tracker icmp ICMP-TRACKER address 1.1.1.1 vrf main
vsr running config#
vsr running config# / system alarm user-alarm icmp-tracker-down description "Alarm raising when the ICMP tracker ICMP-TRACKER goes down."
vsr running config#! / system alarm user-alarm icmp-tracker-down resource "/tracker/icmp[name='ICMP-TRACKER']/state"
vsr running config#! / system alarm user-alarm icmp-tracker-down severity-level-trigger critical text "Tracker ICMP-TRACKER {value}, alarm {name}"
vsr running config# / system alarm user-alarm icmp-tracker-down severity-level-trigger critical equal down
vsr running config# / system alarm user-alarm icmp-tracker-down severity-level-trigger cleared text "Tracker ICMP-TRACKER {value}"
In this scenario, we have an ICMP tracker named ICMP-TRACKER which is monitored for its operational status. When this ICMP tracker goes down, it raises an alarm. Now, we will add a trigger. When the alarm reaches the critical state, it will be activated. It will configure a loopback interface and display its state:
vsr running config# / system trigger event trigger-icmp-tracker-down on-alarm alarm icmp-tracker-down severity-level critical
vsr running config#! / system trigger event trigger-icmp-tracker-down log true
vsr running config#! / system trigger event trigger-icmp-tracker-down commands "
... edit running
... / vrf main interface loopback lo2 ipv4 address 2.2.2.2/32
... commit
... show state / vrf main interface loopback lo2 ipv4 address"
Here the associated state:
vsr> show state / system trigger
trigger
enabled true
event trigger-icmp-tracker-down
enabled true
log true
commands "
edit running
/ vrf main interface loopback lo2 ipv4 address 2.2.2.2/32
commit
show state / vrf main interface loopback lo2 ipv4 address"
on-alarm
alarm icmp-tracker-down
severity-level critical
..
..
..
Then, disable the interface to trigger the alarm and the event:
vsr running config# / vrf main interface loopback lo1 enabled false
Finally, let’s go check the logs of our event:
vsr> show log service trigger
Mar 23 12:28:55 vsr systemd[1]: Started trigger@trigger-icmp-tracker-down.service - Trigger Command Logger Service for trigger/icmp/tracker/down.
Mar 23 12:28:56 vsr trigger@trigger/icmp/tracker/down[2845]: Configuration committed.
Mar 23 12:28:56 vsr trigger@trigger/icmp/tracker/down[2845]: No data
Mar 23 12:28:56 vsr systemd[1]: trigger@trigger-icmp-tracker-down.service: Deactivated successfully.
The same configuration can be made using this NETCONF XML configuration:
vsr> show config xml absolute / system trigger event trigger-icmp-tracker-down
<config xmlns="urn:6wind:vrouter">
<system xmlns="urn:6wind:vrouter/system">
<trigger xmlns="urn:6wind:vrouter/trigger">
<event>
<name>trigger-icmp-tracker-down</name>
<enabled>true</enabled>
<log>true</log>
<commands>
edit running
/ vrf main interface loopback lo2 ipv4 address 2.2.2.2/32
commit
show state / vrf main interface loopback lo2 ipv4 address</commands>
<on-alarm>
<alarm>icmp-tracker-down</alarm>
<severity-level>critical</severity-level>
</on-alarm>
</event>
</trigger>
</system>
</config>
Trigger periodically¶
It is possible to configure a trigger in a manner similar to a crontab.
Note
The cron time format uses the standard five-field format:
┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of the month (1 - 31)
│ │ │ ┌───────────── month (1 - 12 or Jan, Feb, Mar, Apr, ...)
│ │ │ │ ┌───────────── day of the week (0 - 6 or Sun, Mon, Tue, Wed, ...)
│ │ │ │ │
* * * * *
See also
The command reference for the full list of options.
Here is how to generate a troubleshooting report every day at midnight:
vsr running config# / system trigger event midnight-report on-cron cron "0 * * * *"
vsr running config#! / system trigger event midnight-report commands "
... cmd troubleshooting-report new
... "
Here the associated state:
vsr> show state / system trigger
trigger
enabled true
event midnight-report
enabled true
log false
commands "
cmd troubleshooting-report new
"
on-cron
cron "0 * * * *"
..
..
..
The same configuration can be made using this NETCONF XML configuration:
vsr> show config xml absolute / system trigger event midnight-report
<config xmlns="urn:6wind:vrouter">
<system xmlns="urn:6wind:vrouter/system">
<trigger xmlns="urn:6wind:vrouter/trigger">
<event>
<name>midnight-report</name>
<enabled>true</enabled>
<log>false</log>
<commands>
cmd troubleshooting-report new
</commands>
<on-cron>
<cron>0 * * * *</cron>
</on-cron>
</event>
</trigger>
</system>
</config>
Trigger on resource¶
A pushed leaf can be used in a trigger. The resource must correspond to a pushed leaf; otherwise, it will never be taken into account.
See also
The command reference for the full list of options.
In this example, we’re going to replicate the setup used for the alarm, but this time we will directly implement a trigger without an associated alarm. This approach will help to understand the similarities in configurations:
vsr running config# / system trigger event trigger-icmp-tracker-down on-resource resource "/tracker/icmp[name='ICMP-TRACKER']/state" equal down
vsr running config#! / system trigger event trigger-icmp-tracker-down log true
vsr running config#! / system trigger event trigger-icmp-tracker-down commands "
... edit running
... / vrf main interface physical eth1 mtu 1500
... commit
... "
Here the associated state:
vsr> show state / system trigger
trigger
enabled true
event trigger-icmp-tracker-down
enabled true
log true
commands "
edit running
/ vrf main interface physical eth1 mtu 1500
commit
"
on-resource
resource "/tracker/icmp[name='ICMP-TRACKER']/state"
equal down
..
..
..
The same configuration can be made using this NETCONF XML configuration:
vsr> show config xml absolute / system trigger event trigger-icmp-tracker-down
<config xmlns="urn:6wind:vrouter">
<system xmlns="urn:6wind:vrouter/system">
<trigger xmlns="urn:6wind:vrouter/trigger">
<event>
<name>trigger-icmp-tracker-down</name>
<enabled>true</enabled>
<log>true</log>
<commands>
edit running
/ vrf main interface physical eth1 mtu 1500
commit
</commands>
<on-resource>
<resource>/tracker/icmp[name='ICMP-TRACKER']/state</resource>
<equal>down</equal>
</on-resource>
</event>
</trigger>
</system>
</config>