Ascender config as code with network backups to Git and point-in-time rollback
This demo shows how Ascender can treat network configuration as code while keeping a safety net. Greg Sowell, a network engineer for most of his career, frames the problem with a familiar scenario: a midnight change window passes every test, then at 8 a.m. users report trouble and the fastest fix is a rollback. His approach backs up device configurations to a git repository before every change and tags point-in-time snapshots that any device can be restored to.
The configuration itself is stored in standard show run format rather than a data model, because that is what engineers are used to reading and it avoids splitting every access list line into separate variables. A parse function in the network modules turns the text into a data model in memory at run time. Each concern, such as ACLs, DNS, NTP and SNMP, lives in its own small job template, and a workflow chains them together: tagged backup first, then the configuration templates in parallel, then testing across roughly 60 Cisco Nexus switches.
The rollback workflow reuses the exact same playbooks without modification, prompting through a survey for the git tag to restore and pushing that snapshot back out. Sowell verifies the change and the rollback by checking name servers on a Nexus 9k, and closes on idempotency: playbooks can run repeatedly and only change what differs.
Key takeaways
- Back up network configurations to a git repository before every change, with tags marking point-in-time snapshots for rollback.
- Storing configs in standard show run format keeps them readable and avoids modeling every ACL line as a separate variable.
- A parse function in modern network modules converts show run text into an in-memory data model at run time.
- Breaking ACL, DNS, NTP and SNMP configuration into separate job templates lets a workflow chain them like reusable building blocks.
- The rollback workflow uses the identical playbooks; it only skips the backup step and clones the repository at the chosen tag.
- Because the playbooks are idempotent, they can run any number of times and change devices only when the configuration differs.
Questions this video answers
How do you roll back a network configuration change with Ascender?
Every change workflow first backs up device configs to git with a tag. To roll back, find the tag created before the change in the repository, launch the rollback workflow, and enter that tag in the survey prompt. The workflow clones the repository at that tag and pushes the earlier configuration to the affected devices using the same playbooks.
Why store network configs in show run format instead of a data model?
The show run format is what network engineers already read and understand. Modeling something like an access list would require a separate variable for every line number, permit statement and host address, which is far less succinct. Network modules include a parse function that converts the text into a data model in memory when needed.
What does idempotency mean for network automation?
An idempotent playbook inspects the current configuration and makes a change only when the device does not already match the desired state. It can run repeatedly without breaking anything, unlike hand-written change scripts that could cause problems if run more than once.
This video is part of the Ascender Pro playlist. Browse every CIQ video by product and topic.
Transcript
hey everybody I'm Greg Sowell and I'm here with another CI Cube demo today I'm going to be showing you how to use Ascender to do configuration as code on your network equipment but before you do that you're going to do a backup to a git repository and in addition to that you're going to be doing point in time backups so that you can actually roll back to any point in time on any of your equipment so why is this useful I have been a network engineer for most of my career and a lot of times we will do say midnight change Windows you'll do
those change Windows you'll run through all of your tests everything looks clean but then at 8 AM when users start showing up all of a sudden something's wrong right we can't figure it out quickly we just need to do a roll back so this allows you to put that point in time back in there if you select the affected devices and do your configuration roll back so we're going to demonstrate doing all of that so taking a look at a cinder here I've got my configuration as code playbooks in here so if you see job template that equates to a Playbook and again these are
all in public get repositories there's a rather a blog post associated with this so you can see how all these pieces move and work so I'm really just kind of giving you the run through here but I digress configurations code really means we store the configuration in a file format right or it could be retrieved from like a configuration management database whatever it happens to be and we're really just saying hey Network equipment make sure you're configured in this fashion that's really what we're doing so I've got several job templates each doing a discrete task and so I really break it into little bite-sized pieces
right so here is the access list configuration DNS ntp server SNMP right so I break them into little bite-sized pieces and I do that because I'm going to integrate them all into what's called a workflow so right here workflow job template I'm going to pop into the visualizer to give you an idea of what that looks like and so first thing we do is a workflow each one of these boxes is really an individual Playbook right so if I start making them reusable kind of like little chunks like Lego bricks for example I could start snapping them into all different workflows so here I'm doing
View full transcriptHide full transcript
my network backup and I in my network backup have the option to do it tagged or untagged right so untagged is just going to be let me just do a regular backup if I do a tag it does that point in time spot so that I can always pull back from there so next I'm going to in parallel after this successfully completes I'm going to run all of these configurations and I am actually storing my configurations in standard Show run format on these Cisco devices so I'm going to be configuring some 60 Cisco Nexus switches and so you can see this is what Engineers are
accustomed to seeing right I can store all this information in a data model and that's great but instead I want to see what I'm how I'm accustomed to seeing it right and if I actually did store this access list in a data model each one of these little pieces right whether it's line number whether it's permit IP these host addresses like each one of those has to be saved into a different variable and so it's a lot more succinct to just keep all this stuff in that standard format what I do instead is there's a really cool parse function baked into most of the network
modules these days and so it will take a standard kind of show run config and it will parse it right it'll actually break it into a data model in memory and then I use that to shove back into a Playbook again I break all this down in the the blog post so don't don't fret if it's not all sinking in immediately we are going to run through all these configurations and then last do some testing so let me close that and I will go ahead and go back to my job templates and I will fire off my config one now first it's going to ask
me for my configuration repo so where are these configurations stored So in theory each change window for example could have a different git repository right it doesn't necessarily have to be that it could be a folder within a git repository it's kind of however you want to structure but for the guys of My Demo here I just have a git repository that has my Change Control in there right so what all my configurations look like for the various devices I actually have them baked into files and stuck into this repository so I'm going to say next I'm going to say launch and it's immediately gonna
jump over to the job menu and you're going to see my network git backup running and then it's going to go to these individual pieces and make those changes before it actually makes those changes I'm going to go ahead and do a quick Show run and just look for the name server so in my change file I'm changing the ntp settings and the DNS servers right so I'm going to go ahead and show you what that looks like ahead of time so that you can see the change and then ultimately we'll roll it back in just a moment now that I can see that the
workflow has successfully completed right everything is green I'm going to pop back into my device here and I will issue the exact same command and now I can see that the name servers have actually updated all right so it's now 8 am the users are freaking out um you know for whatever reason we need to roll back the configurations let's do that so I'm going to pop back over to my window here and I'm going to take a look at my network backup git repository so in my repository I've got all of my devices and their configs but I have this little tag section here
and I'm going to pop in you can see that was three minutes ago that this tag was created right that was the initial backup so I'm going to choose that I'm going to pop back into my workflow and I have another workflow created just for doing rollback so I'm going to launch the template and again this information popping up in product to me it's called a survey it's really easy to create these very quickly so I'm going to pop in what was my repo tag that I want to roll back from I'm going to click next I'm going to launch and I'm willing to bet
you're going to recognize this workflow the only thing difference here rather the only different thing here is before we were starting with a network backup and instead we're actually just going straight into the configuration now I'm going to tell you that these configurations are identical there is zero modification to these playbooks right so let that sink in I'm actually doing the configuration change using these playbooks and I'm also doing the rollback using the exact same Playbook so I don't have to make any modifications really all I'm doing is just building a new workflow in this workflow I'm saying Hey I want you to actually build
based on this tag information so now it's going to clone that repository and actually push all those configurations which were the point in time just before I made my initial adjustments all right now my workflow has successfully completed again and I may not have mentioned it before but whenever you're watching a workflow move you can see all the little uh all the little uh Wheels spinning right as they're as they're actually performing and I can go into any one of these and I can click on this individual job and it will take me right into that job template that ran and I can see all
the adjustments that happen inside of here right anything that changed I can actually click on it and get additional detail which is different than running on the command line right because it's very ephemeral it happens once and goes away here I can actually take a look at this and I can see exactly what happened more detailed information which is really good I digress let's pop back over to our Cisco Nexus 9k right this is number three so originally we had uh 8844 and then all twos right we changed that to all eights and then all fives we just perform the rollback so now it should
be again back to the eights fours and the twos so you can see that this can make modification on a fleet of devices really convenient so now that we've saved our configurations to a git repository and it's all in there not only do we get the point in time functionality where we can restore back or really just look and see what things look like at very specific time frames but we get that change control aspect where I can go and I can compare in there right I can see the diff of this is what it was before and this is what it is after whether
it was a subtraction addition just a modification it's all baked in there and easy to use and then also the concept of configuration is code is really simple right I'm just defining make it look like this it will parse my config grab all the relevant sections as it needs and push that into my device so it's kind of a different sort of way to think for our Network people instead of just doing discrete changes now I can maintain configurations and this is how it should look and it will push it also I have to mention this for all of my network brethren we have the
concept of item potency which means it will take a look at the configuration if it is in the existing state it won't make a change I can run it as many times I want and it won't break anything if it needs to make an adjustment it will and that is awesome and game changing so when I used to write my change scripts back in the day I would kind of script that stuff out if I ran it more than once oftentimes it would break it so now you get to run these as much as you want and not worry about it now if you have
any questions comments you would want to tweak this tune this change this to fit your environment love to hear that feedback if you would like to talk more about Cinder or anything else as far as automation or rocky Linux please feel free to reach out to our team so happy configuration it's coding ascending automating getting and we'll see you next time bye
Built for scale. Chosen by the world’s best.
2.75M+
Rocky Linux instances
Being used world wide
90%
Of fortune 100 companies
Use CIQ supported technologies
250k
Avg. monthly downloads
Rocky Linux
9
Enterprise products
Spanning the kernel to the orchestrator
Have questions about your infrastructure?
Talk to a CIQ engineer about Rocky Linux, HPC, and AI infrastructure.