Scheduled reboot on CX

It is a common task to need to reboot a switch at a pre-defined time, such as early in the morning. The most common reason being to invoke an upgrade. This can be achieved using network automation if done at scale but it may also be necessary for a single switch. This post describes the Aruba CX functionality to achieve this.

The functionality consists of ‘jobs’ and ‘schedules’. These aren’t specific to rebooting a switch. They can achieve some level of automation such as saving/uploading code every night. They are essentially basic scripts (jobs) together with cron jobs (schedules). In the example below the schedule uses the ‘at’ key word but this can be changed in the trigger statement to invoke on a regular basis.

Job

The first task is to define the script this consists of a list of CLI commands and delay statements. In this use case the only line is the cli command to reboot the switch. If you were to make a config change, you’d need the conf command before hand, just as if you were typing yourself. The only difference is that there is no question from the switch to ask if you are sure (e.g. are you sure you want to reboot).

job reboot
10 cli boot system primary

Schedule

The schedule says what job is executed and when. Options are on a regular basis or on a single occurrence. Here are the options:

  trigger on HH:MM daily {count <1-1000> | start YYYY-MM-DD}
  trigger on HH:MM monthly <A:1-31> {count <1-1000> | start YYYY-MM-DD}
  trigger on HH:MM weekly <A:1-7> {count <1-1000> | start YYYY-MM-DD}
  trigger at HH:MM [YYYY-MM-DD]
  trigger every days <1-365> { count <1-1000> | start HH:MM [YYYY-MM-DD] }
  trigger every hours <1-8760> { count <1-1000> | start HH:MM [YYYY-MM-DD] }
  trigger every minutes <30-525600> { count <1-1000> | start HH:MM [YYYY-MM-DD] }

For the one off reboot the config would be:

schedule reboot
job reboot
trigger at 05:00 2022:12:25

That is all that is required. If the timing is valid, the job will execute at the stated time. Check the switch time is correct with show clock in case NTP has failed.

After The Job

There is a small quirk in this functionality. Firstly, each job appears to start with a copy of running config to startup config. So typing the above 5 lines without saving will result in the reboot but with the config remaining in place. This may be because most jobs are repeated and it protects against code going away when people don’t save. For this use case it is a nuisance because you want the job+schedule to self clean.

A second quirk is the schedule will show the next trigger with an erroneous date:

switch2# show schedule

Schedule Name: reboot    
Schedule config
    ---------------
    Description         :
    Enabled             : Yes
    Trigger type        : one-shot
    Transient           : No
    Max trigger count   : 1
    Trigger start date  : 2022-06-30 13:02    
Schedule Status
    ---------------
    Trigger status      : active
    Next trigger time   : Sat Dec 22 17:08:04 580964    
Scheduled Jobs
    --------------
    10  : reboot

One solution if this is a regular use case would be a permanent second job which is scheduled periodically that has CLI commands that erase the reboot job. Note this is just a clean up operation, the spent job+schedule will not cause harm but may cause confusion.