[j-nsp] Generating events based on day of week

[Curtis Call]

> Firstly, I don't want to start "holy war" but... compare it with Cisco
> IOS:
> !
> ip access-list extended acl-Night
>  permit icmp any host 10.0.0.1 time-range Night  [...] !
> time-range Night
>  periodic weekdays 17:00 to 20:00
> !
> 
> Comparison does not look in favour of JunOS. 

Just to clarify, when using the pre-built time-based firewall filter scripts there is no need to write any code at all (you mentioned hundreds of lines of code).  The correct comparison would be the above IOS config versus the below JUNOS config:

set firewall filter acl-Night term night from protocol icmp
set firewall filter acl-Night term night from destination-address 10.0.0.1/32
set firewall filter acl-Night term night apply-macro active-time-range start-time "weekdays 17:00"
set firewall filter acl-Night term night apply-macro active-time-range stop-time "weekdays 20:00"
set firewall filter acl-Night term night then ...

With the following statement also appearing once within the configuration to enable the scripts:
set system scripts commit file cs-time-based-filters.slax


> 
> Secondly, my task was to change policer on interface
> interfaces:
> # show configuration interfaces ge-0/0/0 unit 400 family inet policer
> input pol-50Mbit; output pol-50Mbit;
> 
> I've written small op script that changes these policers and added its
> invocation via cron daemon at the time that I need:
> # ---- Workdays
> 00      08      *       *       1-5     /usr/sbin/cli op change-policer
> interface ge-0/0/0 unit 400 policer-in pol-30Mbit policer-out pol-
> 30Mbit
> 00      20      *       *       1-5     /usr/sbin/cli op change-policer
> interface ge-0/0/0 unit 400 policer-in pol-50Mbit policer-out pol-
> 50Mbit
> 
> And now I do not see any reasons neither to detect day of week or month
> by catching system events and analyzing them nor to write hundreds
> lines of code.

Doing this in a supported fashion using the day-event.slax event script I mentioned does not require any additional script coding at all.  You can configure your event policy to run your script at the times desired.  For example, here is the config needed to run your script at 08:00 on weekdays:

event-options {
    generate-event {
        day-event-time-2 time-of-day "08:00:00 +0000";
    }
    policy weekday-morning {
        events system;
        attributes-match {
            system.message matches "^Day-Event: ((Mon)|(Tue)|(Wed)|(Thu)|(Fri)) .* 08:00$";
        }
        then {
            event-script change-policer.slax {
                arguments {
                    interface ge-0/0/0;
                    unit 400;
                    policer-in pol-30Mbit;
                    policer-out pol-30Mbit;
                }
            }
        }
    }
    event-script {
        file day-event.slax;
    }
}

> 
> Thirdly, my first event script that I've written failed to work right
> away.
> It turned out, that it is a PR 436135: a bug in 9.5R1.8 (thank you
> Curtis for information on that). Not very good impression. Who can
> guarantees that all my big scripts (that do very simple things) will
> stay able to work after next JunOS upgrade?

The script API has the same possibility of bugs as other parts of Junos functionality, so any upgrades should include tests of your script logic as part of your software vetting process.

I agree that Juniper could do a better job of notifying script writers of potential bugs that affect their scripts.  I'll pass that feedback on to the Juniper script folks. 

> 
> Summing up all thesises: simple problems should have simple solutions.
> Matching current date/time in firefall filter or calling some scripts
> at desired time/date are not very complicated, are they?
> 

Whether complicated or not, they are not a current Junos feature.  (And I have no control over the feature roadmap).  I just want to make it clear that it is possible to achieve this today by using scripts, and that the scripts necessary to do so have already been written and can be used freely by others without any modification necessary.

>From my perspective, this illustrates the beauty behind Junos scripts.  It allows us to add functionality above and beyond the capabilities of Junos, in a supported fashion.  Whether we're talking about custom show outputs, event-driven functionality, or unique additions to the commit process. In all cases, the API used is a standard part of Junos, and the hope is that users will take advantage of it.