Network pros need NAPALM, Ansible network automation skills

As more organizations desire ease and speed in their networks, network automation skills will soon be a top priority for hiring committees.

While Python is a critical and popular programming language for network engineers to know, NAPALM and Ansible are also essential tools that can provide engineers with vendor-agnostic network automation skills. In particular, NAPALM and Ansible skills are beneficial for multivendor environments, according to author Karim Okasha. Together, NAPALM and Ansible can streamline standard, time-consuming manual processes into simplified and vendor-agnostic automated processes.

In his book Network Automation Cookbook, Okasha explores network automation skills with Ansible and how Ansible can work with other automation frameworks, such as NAPALM, to enhance any network engineer's skill set.

Editor's note: The following interview was edited for length and clarity.

How can NAPALM and Ansible network automation skills benefit organizations both separately and together?

Karim Okasha: In an organization with multivendor devices, if you use a platform like Ansible, you still need to use different modules, and each module returns data in a different format. This makes coding and using modules more difficult. NAPALM tries to abstract this.

If you talk to a Cisco, Juniper [Networks] or Arista [Networks] device, [NAPALM] extracts the API you use and returns a common data model, which you can use in logic within the code. It simplifies coding and communication channels with network devices, tries to cover common tasks and gathers information from devices. This greatly simplifies playbooks you write with Ansible for network automation.

Karim Okasha

NAPALM started as a Python framework only. So, if you want to code or utilize NAPALM, you need to go into the Python world. From my experience -- and from what I see in the industry -- a lot of people with network backgrounds are not comfortable learning data structures and how to do things in Python. This is where the combination between NAPALM and Ansible comes in handy.

Ansible is a good starting point for network engineers to go into network automation. It simplifies many tasks that would be hard for a network engineer with a basic understanding of Python. Ansible abstracts all this, and using the power of NAPALM, you can achieve good results and deliver capabilities and use cases to move from manual processes to automation.

Where do NAPALM and Ansible fall short?

Click here to learn more
about this book.

Okasha: All these platforms are open source. There is not currently a support model for them. For an organization accustomed to having everything backed up by a vendor, this is not available right now. [However,] an organization can develop capabilities to support these platforms. When the correct methodology is used, this limitation can be avoided.

NAPALM doesn't cover everything the network team might require, but by leveraging the hundreds of modules available in Ansible, you can build an automation framework using both NAPALM and Ansible.

How can NAPALM and Ansible improve network automation skills for engineers with multiple management tools from different vendors?

Okasha: Let's start with some basic use cases: Collecting network information, doing regular device backups, generating health check reports and collecting backups can be implemented using Ansible and NAPALM very easily.

Next is troubleshooting using Ansible. A typical network engineer needs to shift logic from logging into devices and doing CLI [command-line interface] commands toward logic for building simple playbooks that can be easily maintained and shared across the organization to perform tasks engineers used to.

How can network engineers merge network automation skills with existing network management processes?

Okasha: Most organizations don't have a consistent way to troubleshoot networks. It's dependent on the engineer's skills to build logic in his head and spit some CLI commands on network devices to figure out problems. Automation greatly simplifies this. If all logic is documented in a consistent playbook, a senior engineer or network architect can understand exactly what to check to verify the network is OK.

If this playbook is used by all departments within the organization, this simplifies incident response, which is something typical network management systems cannot do. This is where Ansible can fit in.

And, at this moment, there is no tool available for consistent configuration management for network devices specifically in multivendor environments. Again, this is where tools like Ansible and NAPALM can provide a simple way to configure network devices.

How has network automation changed over time?

Okasha: Network vendors are starting to develop more capabilities within their platforms to simplify network automation. So, instead of using CLI to log in to devices, they provide APIs, which greatly simplify how we interact with devices.

[Also,] vendors are starting to comply with standards for consistent data modeling for network devices. A lot of vendors are adopting open configuration models to implement a given service or capability on devices, which simplifies how to develop code.

On the development side, we see more libraries [developed] to abstract the complexity of getting into network automation. We see more frameworks like NAPALM and Ansible enhance how we automate networks. These efforts are trying to diminish a typical network engineer's barrier for entering automation.

With network automation now and how it was four years back, there is a huge improvement, both in vendor adoption and within the community. Ansible's support for network automation four years back was limited and buggy. Now, it's more robust. It includes capabilities to automate most well-known network vendors, which gives organizations confidence to adopt it.