This method of reboot used to cycle the operating system of the router and is done on a schedule.
A cron inside of a Cisco device is referred to as “kron”. The same thing just a different spelling!
A reboot KRON is useful in the following types of scenarios:
I use two different types of Reload KRON for the Cisco routers we have in the our network, these are:
These are self-explanatory. The 12 hourly KRON will reload the router every 12 hours, so twice per day. The 24-hourly KRON will reload the router every 24 hours, so once per day.
The type of reload KRON which should be applied will depend on the failure rate of the router in question. As a rule of thumb, you should try to limit the number of times the router reloads throughout the day because in the event of the router being online and working throughout the reload period this will result in around five minutes downtime per reload period.
I would advise that we first apply the 24-hourly KRON reload script first and if we see further dropouts of the router then increase the KRON interval from 24-hourly to 12-hourly.
To check the existing KRON status of a site and see if the reload KRON is already applied you are able to run the following from the CLI in enable mode:
show kron schedule
show kron schedule
When logged into a router where you wish to apply the KRON ensure you have enabled privileges and run the following:
To get the router to reload every 24 hours run the following commands in enable mode:
config t
kron policy-list reload
cli reload
exit
kron occurrence reload at 0:00 recurring
policy-list reload
exit
exit
copy run start
To get the router to reload every 12 hours run the following commands in enable mode:
config t
kron policy-list reload
cli reload
exit
kron occurrence reload at 0:00 recurring
policy-list reload
exit
kron policy-list reload-1
cli reload
exit
kron occurrence reload-1 at 12:00 recurring
policy-list reload-1
exit
exit
copy run start
In the above two examples we show a direct application of either 12-hourly KRON or the 24-hourly KRON.
By default, the 24-hourly KRON which is applied is the one which runs at router time 00:00 (our time 01:00 depending on season).
If we need to increase the occurrence at which we get the KRON should run we apply the secondary occurrence which is the 12:00 router time one (our time 13:00 depending on season) by running the following in enable mode:
config t
kron policy-list reload-1
cli reload
exit
kron occurrence reload-1 at 12:00 recurring
policy-list reload-1
exit
exit
copy run start
If you wish to decrease the KRON occurrence and the above methods have been followed this should be done by removing the KRON occurrence which runs at 12:00 router time (13:00 depending on season).
You can do this with the following commands in enable mode:
config t
no kron policy-list reload-1
no kron occurrence reload-1 at 12:00 recurring
exit
copy run start
After running you can confirm by running the following:
show kron schedule
To remove KRON from a router we can run the following from the routers CLI:
config t
no kron policy-list reload
no kron occurrence reload at 0:00 recurring
no kron policy-list reload-1
no kron occurrence reload-1 at 12:00 recurring
exit
copy run start
To confirm that KRON has been removed you can run:
show kron schedule
A couple of issues which we may encounter using KRON are:
Let’s say for example the KRON reload 12-hourly is applied on many of your routers that makeup a service. The way the KRON is configured using the above implementation method is through intervals at fixed times.
If 50% of the sites were online at the reload period and reload KRON occurrence knocked these offline for the 5 minutes reload time this would result in many sites lost over that specific period (5 Minutes). This is a risk that is not worth taking so deployment of KRON should only be done as a last resort.
Yes this risk can be mitigated by changing KRON occurrence times of sites with KRON but this would result in a more difficult deployment procedure than the one addressed above and would require a more complex means of tracking, especially if you use this across a whole load of routers.
Lack of tracking could be one possible issue surrounding the use of KRON. The need to report the deployment for site spreadsheet is of paramount importance. Not only will this provide you with a reference point but will eliminate the need for a script to scan the config of the full estate for KRON status.