53. Rescue Configuration
Let’s now talk about rescue configuration. A rescue configuration is a user defined, known good configuration that is designed to restore connectivity in the event of configuration problems. So when you put a Judo’s device and let’s say the active configuration is corrupted, the Junos device will automatically load the rescue configuration file as the active configuration. So the rescue configuration is a working configuration file that can be used to restore the device if the active configuration gets corrupted. Also, having a rescue configuration will save you from having to remember the correct rollback number. Let’s say you’re configuring the device. You’ve made a lot of changes and you’ve made a lot of commits. And now you want to roll back to a state where, you know, everything is working fine. If you’ve committed the configuration a few times, you’ll have a lot of rollback files on your device. And you need to remember the correct back number in order to roll your device back to the working configuration or the desired configuration. Having a rescue configuration will apply a label called Rescue on that configuration file so you can simply see rollback, rescue.
And that will take you back to the working configuration. Let’s say you try to create a rescue configuration, but there already exists one. In that case, the rescue configuration file that is existing on the device will be replaced with the contents of the active configuration. When you create a rescue configuration, it is recommended to include the minimum elements necessary to restore network connectivity. And the command to create a rescue configuration is request system, configuration. Rescue, save. Let’s try this on the terminal. All right, I’m here at the Junos terminal. Before we try to create a rescue configuration, let’s take a look at the system alarm. The command is show system alarms. And here we can see that we have an active alarm which says a rescue configuration is not set. If you’re on a physical s device and you do not have a rescue configuration saved on the device, you will see the alarm signal light up. So to save the rescue configuration, we can use the command request system configuration and the command is rescue save request system configuration, rescue, save a press, enter.
And now we have the configuration saved. So if we did show system alarms, we should see that we now no longer have that alarm active. One thing to make sure is that we test the rescue configuration to see that it is a working configuration and the way to do that is test configuration. And then we need to provide the file name. The rescue configuration is stored under the config directory, which can be viewed using the file list, command file list,/config. And here we can see the rescue configuration. So let’s test it out. The command is test configuration and the pad for that file, which is/config,/rescue press enter. Configuration checks succeeds.
So that means it is a working configuration. Now that we have the rescue configuration saved, if the active configuration gets corrupted, Junos will automatically load this configuration as the active configuration. The rescue configuration can also be used for rollback purposes. So if I go to the configuration mode and let’s do rollback. Question mark. In this case, I do not have any of the rollback files. But you can see here we have the rescue configuration available for rollback. Imagine I had a device that has been configured several times. In that case, I would have so many rollback files. Having a rescue configuration allows me to quickly roll back to the desired configuration. One last thing to keep in mind, the rescue configuration can also be deleted and you might have already seen the command for that. Request system, configuration rescue and the command to delete the rescue configuration is delete request, system, configuration, rescue, delete.
54. Backups
Let’s understand how to configure automated backups on a Junos device. The Junos device can be configured to backup the current configuration using FCP or SICP periodically or after each commit. It is possible to configure multiple archival sites if you specify more than one archival site. The Junos device will attempt to transfer the configuration to the first archive site in the list. Moving to the next site? Only if the transfer fails. For the first site. Once the configuration file is stored to the remote storage device, a system log message is generated confirming success or failure of the transfer. Now, let’s get to the Junos device and understand how to configure archival. All right, I’m here at the Junos device to configure archival will first navigate to edit system archival. So the Iraqi under which archival is configured is edit system archival. Let’s start with said space question mark. So the key word is set configuration. And here we have two options. We can choose to transfer on commit, which means every time the configuration is committed. The configuration will be sent to the archival site. Or we can choose to periodically transfer the configuration at a set frequency. Let’s try the first one. Set configuration transfer interval. Question mark.
And we need to specify the interval in minutes. So, for example, if I said this to one four four 0. That would mean that the configuration is automatically sent to the archival side every 24 hours. Right now, I’m going to set this to set configuration transfer on commit. So every time we commit the configuration, the configuration will be backed up or archived to the archival site. We also need to configure the archive site. Let’s do that. Set configuration archive site. Question mark. And here we need to provide the you are all where we want to upload the configuration. I already have an archival server setup which is using FCP. So I’m going to say FPP Colen double/user name and IP address, space question mark. And the next keyword is password. And I’m going to provide the password of my FPP server. And press enter. Let’s do a show. So we’ve configured this to transfer on commit. And here is the FTB server, you, Aurel and the password. Let’s do a commit. All right. And let’s go back to the operational mode and let’s look at show log messages and we’ll try to match the key word transfer. All right, as we can see, the configuration has been transferred. This is the message that we’re looking at. This is some of the earlier transfers that happened to the server. But we’re looking at this one. This is the latest transfer that has happened. You can see transferred the file name to the remote server. The file name always has a specific naming convention.
The first portion is the hostname, which you can see over here underscore the date, which is why, why? Why, why? M m D.D. underscore hours, minutes and seconds and then the configuration file name so we can see that the configuration has been backed-up. Let’s also verify this from the archival server. I’m here at the archival server and I’m already navigated to the folder that is configured for upload. I’m going to use the less keyword to view the files. And there we can see that the file has been transferred. So archival can be setup in two ways. We can configure it to archive on every commit or we can configure it to archive at a set frequency. All right, I’m here at the Junos device to configure archival Allfirst navigate to edit system archival. This is the Iraqi from which archival is configured. I’ll start with said space question mark. The keyword is configuration. Let’s do a question mark. And you’ll notice here we have two options. We can choose to transfer on commit or we can set a transfer interval, in which case the configuration will be transferred automatically at a set frequency.
So we could do set configuration. Transfer interval, and then we can provide the interval in minutes. So if I did something like this one four four 0 minutes, that means the configuration will be automatically packed up every 24 hours. Right now, let’s do set configuration transfer on commit. This means every time we commit the configuration, the file will be uploaded to the archive site. Press enter. And now we also need to configure an archival site. Let’s do that set configuration archive site. And now we need to provide the Warrell. I already have an FPP server configured, so I’m going to say FTB Colon double/user name at the IP address and the key word is password. And I’m going to provide the password for that user name. Let’s do a show. So now we’ve configured transfer on commit and we have an archival site configured as well. Let’s commit the configuration. And now let’s go back to the operational mode and check out the log file called messages. So let’s do a show log messages and we’re going to try and match the key word transfer. I’ll press enter over here and you can see that we’ve already transferred the file. Here’s the file location and here’s the file name. The file name has a specific format. The first word you see here is the hostname, which we can also see over here. Underscore the date and time. This is the year. The format is y y y y.
And then we have M-m for month Didi’s for date underscore hours, minutes and seconds. Underscore the file name. An important thing to keep in mind is that the time included in the file is in UTC. Let’s also go to the archival server and verify if the file has been uploaded. All right, I’m here at the archival site. I’ve already navigated to the folder that is configured for upload to view the files, I’ll use the command L. S and here we can see the exact same file that was uploaded from the Junos device. So two important things to keep in mind. You can configure archival to occur automatically at a set frequency or upon each commit. So every time you commit the configuration, it will be backed up to an archival site. Also, you can configure multiple archival sites in that case. The system will always try the first archival site. If it fails to upload to the first archival site, that’s when it tries the second one in the list.
