The Junos archival configuration is a way for the device itself to back up the configuration file to another host. This can be done on a timed interval or when a commit is performed.
The configuration is pretty simple, and you can have it backed up to a file path, or http, ftp, scp, or sftp servers. I prefer an encrypted method so the example below uses an sftp server.
system {
archival {
configuration {
transfer-on-commit;
archive-sites {
"sftp://[email protected]/home/junosbackup/backup" password "HASH REMOVED"; ## SECRET-DATA
}
}
}
}Now that we’ve done that, let’s try another commit.
[edit]
lab@vMX-1# set interfaces ge-0/0/3 description New-Description
[edit]
lab@vMX-1# commit and-quit
commit complete
Exiting configuration mode
lab@vMX-1>Checking the backup server though, we don’t see any files.
junosbackup@linux-1:~/backup$ ls
junosbackup@linux-1:~/backup$In the logs on the Juniper though, we see the following messages.
Nov 22 11:04:59 vMX-1 logger: transfer-file failed to transfer /var/transfer/config/vMX-1_20231122_110449_juniper.conf.gz rc 255
Nov 22 11:04:59 vMX-1 pfed: ACCT_TRANSFER_FILE_FAILED_ITER: Error <65280> uploading file '/var/transfer/config/vMX-1_20231122_110449_juniper.conf.gz'. Remaining retry attempts = 2, retry in 295 seconds...That isn’t a very helpful error message, but it is most likely that the Junos device doesn’t know the ssh key fingerprint of the backup server. You may recall the first time you ssh or sftp to a new server you are asked to accept the fingerprint of the server key.
The easiest way to solve this is to run the ‘set security ssh-known-hosts fetch-from-server’ command.
[edit]
lab@vMX-1# set security ssh-known-hosts fetch-from-server 192.168.20.5
The authenticity of host '192.168.20.5 (192.168.20.5)' can't be established.
ECDSA key fingerprint is SHA256:YdGRCZyLPqh7RvDBNh35BEG1/DxhBz3sIrO3Q8TzGcs.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.20.5' (ECDSA) to the list of known hosts.
[edit]
lab@vMX-1# show security
ssh-known-hosts {
host 192.168.20.5 {
ecdsa-sha2-nistp256-key AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNB130sSA1daJveR9u6zx89R+6MsYOKoStEKtHtygKQwovm+vPj3zFVCjN5XZ6Bq9k97d5/hj1VsuGv8tA/kDg0=;
}
}
[edit]
lab@vMX-1# commit
commit complete
[edit]
lab@vMX-1#Let’s try another commit again.
[edit]
lab@vMX-1# set interfaces ge-0/0/3 description Another-Description
[edit]
lab@vMX-1# commit and-quit
commit complete
Exiting configuration mode
lab@vMX-1>On the backup server we now see the config files have been transferred.
junosbackup@linux-1:~/backup$ ls
vMX-1_20231122_110449_juniper.conf.gz vMX-1_20231122_110805_juniper.conf.gz
junosbackup@linux-1:~/backup$On the Junos device, you should see something similar to this in the messages log file.
Nov 22 11:09:03 vMX-1 logger: transfer-file: Transferred /var/transfer/config/vMX-1_20231122_110449_juniper.conf.gz
Nov 22 11:09:08 vMX-1 logger: transfer-file: Transferred /var/transfer/config/vMX-1_20231122_110805_juniper.conf.gzWhat If The Backup Server Is Unavailable?
To simulate the backup server being unavailable, I shut down its ethernet interface and ran several commits.
The following was visible in the log files.
Nov 22 10:59:50 vMX-1 pfed: ACCT_TRANSFER_FILE_FAILED: Error <256> uploading file '/var/transfer/config/vMX-1_20231122_102326_juniper.conf.gz'
Nov 22 11:04:59 vMX-1 pfed: ACCT_TRANSFER_FILE_FAILED_ITER: Error <65280> uploading file '/var/transfer/config/vMX-1_20231122_110449_juniper.conf.gz'. Remaining retry attempts = 2, retry in 295 seconds...
Nov 22 11:09:55 vMX-1 pfed: ACCT_TRANSFER_FILE_FAILED_ITER: Error <256> uploading file '/var/transfer/config/vMX-1_20231122_110449_juniper.conf.gz'. Remaining retry attempts = 1, retry in 295 seconds...
Nov 22 11:14:50 vMX-1 pfed: ACCT_TRANSFER_FILE_FAILED: Error <256> uploading file '/var/transfer/config/vMX-1_20231122_110449_juniper.conf.gz'You can see the files in /var/transfer/config.
lab@vMX-1> file list /var/transfer/config/
/var/transfer/config/:
vMX-1_20231122_111319_juniper.conf.gz
vMX-1_20231122_111329_juniper.conf.gz
vMX-1_20231122_111345_juniper.conf.gz
vMX-1_20231122_111359_juniper.conf.gz
lab@vMX-1> I then re-enabled the interface on the backup server and waited. The following log messages turned up.
Nov 22 11:20:15 vMX-1 logger: transfer-file: Transferred /var/transfer/config/vMX-1_20231122_111319_juniper.conf.gz
Nov 22 11:20:20 vMX-1 logger: transfer-file: Transferred /var/transfer/config/vMX-1_20231122_111329_juniper.conf.gz
Nov 22 11:20:25 vMX-1 logger: transfer-file: Transferred /var/transfer/config/vMX-1_20231122_111345_juniper.conf.gz
Nov 22 11:21:08 vMX-1 logger: transfer-file: file /var/transfer/config/vMX-1_20231122_111319_juniper.conf.gz not found
Nov 22 11:21:09 vMX-1 pfed: ACCT_TRANSFER_FILE_FAILED_ITER: Error <256> uploading file '/var/transfer/config/vMX-1_20231122_111319_juniper.conf.gz'. Remaining retry attempts = 1, retry in 295 seconds...
lab@vMX-1> Nov 22 11:26:04 vMX-1 pfed: ACCT_TRANSFER_FILE_FAILED: Error <256> uploading file '/var/transfer/config/vMX-1_20231122_111319_juniper.conf.gz'
lab@vMX-1> file list /var/transfer/config/
/var/transfer/config/:
vMX-1_20231122_111359_juniper.conf.gz
lab@vMX-1> For whatever reason, it seems to have gotten confused and tried to transfer a file that doesn’t exist. I did another commit, a commit full in this case, and saw these log messages showing the files had transferred. I confirmed by doing a file list of /var/transfers/config.
Nov 22 11:29:03 vMX-1 logger: transfer-file: Transferred /var/transfer/config/vMX-1_20231122_111359_juniper.conf.gz
Nov 22 11:29:08 vMX-1 logger: transfer-file: Transferred /var/transfer/config/vMX-1_20231122_112855_juniper.conf.gz
lab@vMX-1> file list /var/transfer/config/
/var/transfer/config/:
lab@vMX-1> On the backup server, we can see the following files.
junosbackup@linux-1:~/backup$ ls
vMX-1_20231122_110449_juniper.conf.gz vMX-1_20231122_111329_juniper.conf.gz
vMX-1_20231122_110805_juniper.conf.gz vMX-1_20231122_111345_juniper.conf.gz
vMX-1_20231122_110858_juniper.conf.gz vMX-1_20231122_111359_juniper.conf.gz
vMX-1_20231122_111319_juniper.conf.gz vMX-1_20231122_112855_juniper.conf.gz
junosbackup@linux-1:~/backup$ Conclusions
From what we see above the configuration archival works pretty much as you’d expect it to. When set to transfer-on-commit it will try to copy the config file every time a commit is made.
If it can’t transfer the file for any reason, it holds it in /var/transfer/config/ and retries a few times and failing that waits for the next commit to be run.
The hardest thing about getting this working is getting the configuration right. The archive-sites command is very specific and it’s easy to make a mistake. Initially, I had a colon between the server address and the file path which it did not like.
The other common issue is remembering to set the ssh-known-hosts configuration when using ssh-based protocols such as sftp or scp.