NAPALM: Integrating Ansible with Network Devices on Software Gone Wild
What happens when network engineers with strong programming background and focus on open source tools have to implement network automation in a multi-vendor network? Instead of complaining or ranting about the stupidities of traditional networking vendors and CLI they write an abstraction layer that allows them to treat all their devices in the same way and immediately open-source it.
What happens when Elisa Jasinska and David Barroso (the masterminds behind this idea) want their library to be called NAPALM? They figure out it stands for Network Automation and Programmability Abstraction Layer with Multivendor support.
Abstraction layers are nice, but they’re useless to most non-programmers unless you can plug them into a readily available tool, so the obvious next step was a plug-in for Ansible that allows anyone to use their tool without writing custom code.
Excited? Listen to Episode 35 of Software Gone Wild and watch their NANOG presentation to get more details and a live demo. To get started, go to NAPALM Github page, download it, and start exploring.
I made something similar at work with operators just putting parameters, afterwards scripts build the inventories, run ansible to get configs and config upload is done by scripts. Unfortunately I am dealing with devices with no atomic changes (IOS) and the more straight forward way is to load on startup and reboot ( I know, is a piece of shit) but the other workaround is using clogin ( parser for cisco) comming with rancid (really wesome network config differences) and paste the commands in the proper order, without breaking nothing in the meantime. The problem is that our scenario is for the WAN not the DC, where much more scenarios than leaf-spine are needed and thats where these tools become complex, and the structure in roles and services is really customer dependant.
For example, what happens if ipfabric role used in the video is not using BGP? new templates and variables are needed... Imagine the variability in the WAN.... Looks like you need programming professional services :)
You can use napalm to build the inventory as well. You will need to have a list of IPs or FQDN's but the get_facts method should be enough to build an initial inventory as you can get hostnames, vendor, models, S/N, etc... In any case, if you want to automate your network you need to have some sort of asset inventory; either in YAML files as in the demo or in some database.
> Imagine the variability in the WAN....
It's a matter of standarizdizing your services. I guess you have a service catalogue or something similar, then you just need roles/templates for each service. And if you don't have a service catalogue maybe you should start by building one ; )
> Looks like you need programming professional services :)
It's just configuration templates, any operator should be able to do it. I understand that building napalm requires some programming knowledge but templating configuration should be easy for any network operator. At the end of the day, most operators just google what they want to do, find a configuration snippet in some blog and then they adapt that snippet for their needs ; )
Also for example some networks have only basic console connections while deploying new pop. Is there a way to deploy these configs through serial connections ?
If you are using ansible check ansible-vault. That can encrypt the plays or var files where you have sensitive data.
> Also for example some networks have only basic console connections while deploying new pop. Is there a way to deploy these configs through serial connections ?
I am afraid not. What we do is we generate the configuration files using the same playbooks but instead of pushing them with NAPALM we bootstrap the switches with ZTP. Then we keep managing the devices normally with NAPALM.
I have preaching Ansible at my new workplace however they use Rancid and a lot free ssh tools to do their automated tasks. I would like to build the case for Ansible however I'm falling short to say Ansible is better than Rancid. Any ideas/recommendations would be helpful.
@George: Ansible is not "a tool to end all tools". It's just another potentially useful tool in your toolbox.
Sometimes it's the best tool for the job, and you should use it (example: automating a series of tasks to be executed in parallel on a large number of devices), sometimes other tools do a better job (Oxidized is definitely better at collecting device configurations).
Always start with "what problem are we trying to solve" and then "what tool in my toolbox would be a best fit". The more tools you have in your toolbox, the easier your life will be.