Kron Scheduling
Kron scheduling in Cisco IOS is a very powerful and helpful tool. It's basically a set of predefined commands scheduled to run at a certain time or at certain intervals.
This is extremely helpful when you want to do some work, but do not want to access into the router (like 1am for example). It can also be used to perform recurring actions like saving it's config, or rebooting at specific times, and many other tasks.
Another helpful tip is to set your router or switch up to reboot at a specific time prior to any config work being done. Then, in case some changes you are making remotely just happen to lock you out of the router, it'll reboot automatically for you. In that case, as long as you have not saved your config, it will get to the reboot time you set up in advance with Kron, then reboot and restore everything to the last saved config. This greatly reduces the chances of long down times and having to dispatch a tech to the site just to reboot the router and get you access again. (The same can be accomplished with the "reload in..." command where you specify minutes before it power cycles, but this page is about Kron Scheduling :-)
Schedule an automatic reboot of the router or switch
kron occurrence REBOOT in 20 recurring <-- schedules the router to reboot in 20 minutes and to reoccur every 10 minutes.
policy-list REBOOT <-- Policy list that the scheduler will reference for the predefined commands
- or -
kron occurrence REBOOT at 5:00 recurring <-- schedules the router to reboot at 5am everyday
policy-list REBOOT
!
kron policy-list REBOOT <-- Policy list that the occurrence commands above reference
cli RELOAD <-- Command #1
cli YES <-- Command #2
This can be used for virtually any type of configuration that is needed... Adding VLAN's, changing IP's & default-gateway's, turning up or down ports, building trunks etc... The key is to make sure you have all the commands needed to perform the tasks, and make sure they are in the correct context and configuration areas. To be safe, it is always best to test your command script in a lab or non-production environment before you try it on the real thing. And... as stated above, you can also incorporate an automatic reboot scheduled for after the Kron script in case something breaks and you no longer have access into that device.
Kron scheduling in Cisco IOS is a very powerful and helpful tool. It's basically a set of predefined commands scheduled to run at a certain time or at certain intervals.
This is extremely helpful when you want to do some work, but do not want to access into the router (like 1am for example). It can also be used to perform recurring actions like saving it's config, or rebooting at specific times, and many other tasks.
Another helpful tip is to set your router or switch up to reboot at a specific time prior to any config work being done. Then, in case some changes you are making remotely just happen to lock you out of the router, it'll reboot automatically for you. In that case, as long as you have not saved your config, it will get to the reboot time you set up in advance with Kron, then reboot and restore everything to the last saved config. This greatly reduces the chances of long down times and having to dispatch a tech to the site just to reboot the router and get you access again. (The same can be accomplished with the "reload in..." command where you specify minutes before it power cycles, but this page is about Kron Scheduling :-)
Schedule an automatic reboot of the router or switch
kron occurrence REBOOT in 20 recurring <-- schedules the router to reboot in 20 minutes and to reoccur every 10 minutes.
policy-list REBOOT <-- Policy list that the scheduler will reference for the predefined commands
- or -
kron occurrence REBOOT at 5:00 recurring <-- schedules the router to reboot at 5am everyday
policy-list REBOOT
!
kron policy-list REBOOT <-- Policy list that the occurrence commands above reference
cli RELOAD <-- Command #1
cli YES <-- Command #2
This can be used for virtually any type of configuration that is needed... Adding VLAN's, changing IP's & default-gateway's, turning up or down ports, building trunks etc... The key is to make sure you have all the commands needed to perform the tasks, and make sure they are in the correct context and configuration areas. To be safe, it is always best to test your command script in a lab or non-production environment before you try it on the real thing. And... as stated above, you can also incorporate an automatic reboot scheduled for after the Kron script in case something breaks and you no longer have access into that device.