save entire device config after service deployment
the customer would like to save the (entire) configs of the devices affected by a VPN service deployment to a FTP server for backup.
We see (on the devices) that at the end of pushing the configs to the devices NSO implicitly does a "write memory" on the devices it changed. But this behaviour lies outside the service logic. Is there a way to tell NSO to do e.g. a "write network" (to a specific FTP server) at that same moment?
Or can this only be achieved using ReactiveFastmap (i.e. doing sth. specific after the cb_create callback has executed, more precisely: after pushing the config(s) to the device(s) )?
The customer also has an Alias configured on the devices ("save") which already executes the appropriate command to save the config to a backup server. So this could be used too I guess.
Important is that the customer wants the "save to backup server" step done automatically after successful deployment of the service.
This is an interesting question. I've had several customers (as have others i'm sure) who wish to back up their full device configs periodically. What you're asking for seems to be mixing device and NSO operations. I don't see a device type listed - i.e. NED type - many have ned-settings to modify default behavior - the one you note is that "write-mem" is done at the completion of the service commit. E.g. for the cisco-ios NED (CLI) (see the README file...):
This ned-setting is used to configure when/if an applied configuration is saved to the device. Three values are supported:
on-commit - Save configuration immediately after the config has been successfully applied on the device. If an error occurs when saving the whole running config will be rolled back (default).
on-persist - Save configuration during the NED persist handler. Called after the config has been successfully applied and commited If an error occurs when saving an alarm will be triggered. No rollback of the running config is done.
disabled - Disable saving the applied config to persistent memory.
- cisco-ios write memory-method <string>
This setting is used to change how the NED writes config to a device. The default is "write memory". ...<snip>...
I have not tested the last one - not sure if this can assist you - i think it would "replace" the write-mem command and not be "in addition to it".... you would like to have both, correct?
** caution -- i think is worth noting: since the operation (ftp out to some server) may take time, it seems like this is not ideal to call from a service (due to the lock taken).
You don't mention how the service is executed; if it's coming out of a NB portal, you may simply call an action immediately after successful service deployment - where the action executed a live-status call to the device, creating a time-stamped file name etc. and doing the file transfer. This action could be triggered via a kicker as well. whether the "live-status" call specifies the exact command or an "alias" on the device is irrelevant - it could call any device command.
If only the diff is needed, enabling device trace could do this. If a capturing a complete configuration is required, a subscriber app could do that. Note that the subscriber would be triggered to run inside the transaction lock, and if the configs are large, saving them within the lock would significantly reduce the number of transactions you could get executed in a given time. A kicker could be used to trigger the saving to happen outside the transaction, but this runs the risk of changes to a device happening while the save is in progress. If periodic backups of all the device configs are required, getting the full config from NSO at regular intervals might be a better option. This could be done using the backup-mechanism, or using e.g. get-config on /devices/device/config . They too take the lock, but since they would do that for all devices at once and only run at some interval chosen by the user, the performance impact is likely much lower.
It is best practice to avoid storing your secrets (e.g., passwords and shared keys) in plain text, either on NSO or on the device. In NSO, we support multiple encrypted data types that are encrypted using a local key. Similarly, many devices such as Cisco...
Cisco Developer Days, September 14-15, 2021
On Tuesday next week, we will open the doors to the 11th Cisco Developer Days!
If you have not registered for the free, virtual event, do it now!
What can you expect?
We have a packed 2-day agen...
In the blog post series called "Unlocking Performance in your NSO System" we talked about the need to measure performance and to profile the performance in order to identify bottlenecks. We didn't go into any details about how to do this. Last year at the...
Finally, as you may have seen in the News & Announcement, we have opened the landing page for the next Developer Days event in September! The September 14/15 event is the first in a series of three virtual events in the three regions (EMEAR/US/Asia Pa...
We are excited to announce that our call for speakers for our upcoming Developer Days events is open!
Automation is a journey in itself and no two journeys are alike. Planning and preparation are a must for any major project. Having an open mind to u...