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.
SW upgrade or migration is something you never can escape from so it's better to make it part of your process. The remaining challenge is to determine when to give up what has been working to secure your future needs. Martin and the NSO team will guide y...
There is not a single golden tool that fits all purposes simply because development processes and needs are different. Instead, pick the tooling you need from the Smörgåsbord and build your environment to suit your needs. Shashidhar will guide you throug...
How Verizon Streamlined NSO Development with Continuous Integration
This is a customer success story of how Verizon ITNUC builds a CI chain to streamline the NSO development process. The containerized NSO makes testing several NSO packages in para...
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...