Generate Internal Events to Trigger Event Policies
Understanding Internal Events
Internal events are events that you create to trigger an event policy. Internal events are not generated by Junos processes, and they do not have any associated system log messages. You can configure up to 10 internal events, and you can generate an internal event based on a time interval or the time of day. Event policies can match on internal events in the same way that they match on other events.
If you attempt to commit a configuration with more than 10 internal events, the device generates an error, and the commit fails.
To configure an internal event, include the following
statements at the [edit event-options] hierarchy level:
[edit event-options] generate-event { event-name (time-interval seconds <start-time start-time> | time-of-day time) <no-drift>; }
You can configure the time-interval option to generate events at a specific
frequency. You can also configure the time-of-day option to
generate events at a specific time of day. Use the no-drift option
so that the device does not propagate the delay caused in triggering an event to the
triggering of the next event.
The start-time option enables you to specify the start date and time for
interval-based events. Thus, you must configure the start-time
option with the time-interval option. If you configure the
start-time option by itself or with the
time-of-day option, the device generates a commit error, and
the commit fails. For example:
[edit event-options generate-event event-midnight start-time]
'start-time "2020-9-1.16:50:00 -0700"'
'time-interval' is mandatory for 'start-time' configuration
error: commit failed: (statements constraint check failed)
How to Generate Events at a Specific Time of Day
To generate an event at a specific time of day, configure the time-of-day
statement, and specify the time at which the event occurs. A
time-of-day event is relative to the local device time and
you configure the event using 24-hour time format
hh:mm:ss. You can optionally include
a UTC offset to specify a time relative to UTC. The syntax is
hh:mm:ss(+|-)hhmm,
where the sign is plus (+) for east of UTC and minus (-) for west of UTC.
UTC is the time on the 0° longitude meridian, also known as the Greenwich meridian. The standard time in most time zones is an integral number of hours offset from UTC.
If you omit the UTC offset, the device automatically generates the offset for the
time-of-day statement in the configuration based on the
local time zone setting for the device. For example, consider a device that uses
Eastern Standard Time (UTC−05:00) for its local time. The following command
configures an internal event called event-midnight, which is
generated at 12:00 AM (00:00:00) every night.
[edit] user@host# set event-options generate-event event-midnight time-of-day 00:00:00
The resulting configuration automatically includes the device’s offset from UTC.
user@host# show event-options
generate-event {
event-midnight time-of-day "00:00:00 -0500";
}
If you configure the time relative to UTC, and the offset is different from that of the device,
the device automatically converts the time to reflect the device’s local time
and offset from UTC in the configuration. The following example configures an
additional internal event called event-midnight-cst that is
generated every night at 12:00 AM (00:00:00) with an offset that is six hours
behind UTC.
[edit] user@host# set event-options generate-event event-midnight-cst time-of-day 00:00:00-0600
The resulting configuration displays the event using the device's local time and UTC offset.
user@host# show event-options
generate-event {
event-midnight time-of-day "00:00:00 -0500";
event-midnight-cst time-of-day "01:00:00 -0500";
}
If you ship the same device to a different location, and you configure it to use a new time zone, any configured internal events reflect the new local time and time-zone offset. For example:
[edit] user@host# set system time-zone America/Los_Angeles user@host# commit
user@host# show event-options
generate-event {
event-midnight time-of-day "21:00:00 -0800";
event-midnight-cst time-of-day "22:00:00 -0800";
}
If you modify the system time by issuing the set date operational mode command,
we recommend that you also issue the commit full or the
restart event-process command. Otherwise, the device
might not generate a time-of-day internal event at the configured time.
For example, if you configure the device to generate an internal event at 15:55:00, and then you
modify the system time from 15:47:17 to 15:53:00, the device generates the
event when the system time is approximately 16:00 instead of at the
configured time, 15:55:00. You can correct this problem by issuing the
commit full or the restart
event-process command.
Event policies can match on internal events in the same way
that they match on other events. The following example generates an
internal event called it-is-midnight at 12:00 AM (00:00:00)
every night. When the eventd process receives the it-is-midnight event, it triggers the midnight-chores event policy,
which takes certain actions.
[edit event-options]
generate-event {
it-is-midnight time-of-day "00:00:00 -0500";
}
policy midnight-chores {
events it-is-midnight;
then {
... actions ...
}
}
How to Generate Events at Repeated Time Intervals
You can generate an event at repeated intervals, for example, every hour, by configuring the
time-interval statement and specifying the interval
frequency in seconds. The time interval can range from 60 through
2,592,000 seconds. The device generates the first event starting at
approximately one time interval after you commit the configuration.
For example, the following command configures an event called event-every-hour that gets generated every hour:
[edit] user@host# set event-options generate-event event-every-hour time-interval 3600
The following event policy takes certain actions every 3600 seconds when the device generates the
event-every-hour event:
[edit event-options]
generate-event {
event-every-hour time-interval 3600;
}
policy hourly-checks {
events event-every-hour;
then {
... actions ...
}
}
On supported devices, you can optionally configure the date and time at which the device starts
generating interval-based events. Configuring a start time enables the device to
generate events at predictable times, for example, even after a device reboot.
To specify a start time for an event, configure the start-time
option in addition to the time-interval option. The start time
is relative to the local device time. The syntax uses 24-hour time format:
yyyy-mm-dd.hh:mm. For example:
[edit event-options generate-event] user@host# set every-fifteen-minutes time-interval 900 start-time 2020-09-01.16:50
If you do not configure the start-time option, the device generates the first
event at approximately one time interval after you commit the configuration,
depending on the commit operation time. If you configure a start time that
occurs after the commit time, the device generates the first event at the
configured start time, and the next event at one time interval after the start
time, and so on. If you configure a start time that is chronologically before
the commit time, then the device generates the first event at the next time that
is an integral number of time intervals after the start time. Table 1 compares the different scenarios for the initial event times based on the
start time, if configured, and the time at which the configuration is
committed.
|
|
|
Commit time |
First event |
Second Event |
|---|---|---|---|---|
900 |
– |
2020-09-01.17:00:08 |
2020-09-01.17:15:30 |
2020-09-01.17:30:30 |
900 |
2020-09-01.17:10 |
2020-09-01.17:00:08 |
2020-09-01.17:10:00 |
2020-09-01.17:25:00 |
900 |
2020-09-01.16:50 |
2020-09-01.17:00:08 |
2020-09-01.17:05:00 |
2020-09-01.17:20:00 |
900 |
2020-09-01.16:50 |
2020-09-01.17:17:08 |
2020-09-01.17:20:00 |
2020-09-01.17:35:00 |
Similarly, if you configure a start time, the device still generates the next event based on the configured start time even if you reboot the device or restart the event process. Table 2 compares the initial event times after the device is rebooted. As shown in the table, when you specify a start time, the device predictably generates the next event as an integral number of time intervals after the start time. When you do not specify a start time, the next event is one time interval after the device comes back online and starts the event process. In this case, it took several minutes for the device to reboot and start the Junos processes, so the event occurs well after the time for the next expected event.
|
|
First event |
Reboot time |
Next Event |
|---|---|---|---|---|
900 |
– |
2020-09-01.16:50:00 |
2020-09-01.16:55:00 |
2020-09-01.17:13:08 |
900 |
2020-09-01.16:50 |
2020-09-01.16:50:00 |
2020-09-01.16:55:00 |
2020-09-01.17:05:00 |
You can optionally include a UTC offset to specify a start time
relative to UTC by appending (+|-)hhmm to the time, where the sign is plus (+) for east of UTC and minus
(-) for west of UTC, for example, 2020-09-14.11:00‑0800. Even if
you specify a UTC offset, the start-time configuration always displays the time and UTC offset for the device’s
local time zone.
The following example configures the start time with a UTC offset:
[edit event-options generate-event] user#host# set every-twenty-minutes time-interval 1200 start-time 2020-09-16.20:30-0200
The resulting configuration displays the event time and UTC offset for the device’s local time zone.
[edit event-options generate-event] user@host# show every-twenty-minutes time-interval 1200 start-time "2020-9-16.17:30:00 -0500";