Automate your network with Ansible and NAPALM

2
In the New Era of SDN and NFV and the push towards
network programmability and automation, the usual
method of deploying new changes on the network and
validating the network state after this change will not
scale. The way we interact with the network needs to
be more dynamic and agile, hence we need to use the
same DevOps tools that the sysadmin have been using
to manage the infrastructure and scale their operation.
In this article, we are going to discuss how to use
Ansible and NAPALM to automate network
provisioning and validation. we will outline how Ansible
can be used to perform the following main tasks.
How to automate your network using Ansible and NAPALM
• Generating router configuration from templates.
• Deploying Configuration on different Network OS
and platforms.
• pre and post validation after a network deployment
or change.
In this short guide, we will outline what is Ansible and
the role of NAPALM in network automation how they
can be combined in order to deliver a simple but
powerful network automation for a multi-vendor
environment.
Section I

3
Ansible in its core is an IT Automation tool which is used mainly to
configure IT infrastructure (Bare Metal servers or virtual machines
and even containers), deploy software on those systems and
perform workflow orchestration for the applications running over
the infrastructure. It is part of the Continuous Configuration
Automation tools like Puppet, Chef, and SaltStack which aims to
simplify the management of IT infrastructure and data Centers
through an Infrastructure as a code framework by defining the
state of the infrastructure in human readable definition files.
Ansible is considered a very easy and scalable solution compared
to puppet and Chef since it doesn’t rely on any agent (agentless)
that should be deployed on the remotely managed system. it uses
a PUSH model where the Ansible Server node sends the required
changes to the remote system, this is different from the approach
used by other tools like Puppet or Chef which utilize an agent that
must be installed on the remotely managed device that PULL the
changes required from the Master server. The below diagram
outlines a high-level setup that is used by Ansible to manage a
typical IT infrastructure.
How to automate your network using Ansible and NAPALM Section I

4
As stated earlier Ansible started as an IT automation framework
to manage servers (the operating system and the applications
running on these servers), then it started to support Networking
hardware (especially DC switches). At the early stages, Ansible was
just treating the Network nodes like server and managing them
via SSH, so the Ansible server should login into the managed
network nodes and run the CLI commands on them and report
the output. This diagram outlines the early stages of Ansible interaction
with networking nodes
When you are running Linux as your OS on your DC
Switches (Like the case of Cumulus Linux) you can treat
your network nodes similar to your servers and execute
the same playbooks and workflows to manage them.
This is one of the main drivers for adoption of
Whitboxes and the use of Linux OS as your Network OS.
This approach has many problems since the output from the devices was
unstructured thus Ansible only provides text output from the managed devices
and we had to use again screen scraping and regular expressions to transform
the output to valid data structures that Ansible can use and work with.
Different Ansible modules like ntc-ansible (that uses TextFSM to parse the
output) is used to have a more programmatic approach to do the screen
scraping, however, this was still very tedious.
As the networking vendors started to support APIs interfaces for their
Networking OS (like NETCONF for JunOS, NXAPI for NX-OS or eAPI for Arista),
Ansible started to support these API interfaces to communicate with the
networking devices in order to return structured data that can be easily parsed
into Ansible. So Ansible would translate XML or JSON data returned as the
output from the executed commands into valid Data structures that can then
be used by Ansible as facts or variables to control the execution of the
playbooks. the below diagram outlines the approach that is used now by
Ansible to communicate with networking devices.

5
Output
Network
OS
Juniper
JunOS
Cisco
IOS/IOS-XR
Cisco
Nexus-OS
XML String JSON
NETCONFTransport/
API
SSH NX-API
Ansible
Modules
• junos_command
• junos_config
• junos_facts
Arista
EOS
eAPI
JSON
• ios_command
• ios_config
• ios_facts
* for ios-xr use iosxr_xxx
• nxos_command
• nxos_config
• nxos_facts
• eos_command
• eos_config
• eos_facts
Ansible

6
Ansible uses a very similar approach to represent a common
interface to deal with different networking hardware so it uses the
following most common modules to manage networking nodes.
•
•
•
With this still, every network node returns different output (even if
structured in XML or JSON) and we have to deal with this
differences especially in the returned output from the nodes. The
below output illustrates the difference in the output returned from
JunOS and IOS-XR when requesting the same data (show bgp
summary).
Finally, for some networking equipment (like NX-OS or
Junos) further modules are available that are more
abstracted in terms of configuring the network devices.
So instead of using the default XXX_config module and
type the exact configuration commands to describe the
required configuration that need to be implemented,
new declarative modules are present that just take the
variables that you want (like enable interface, configure
VLAN) and they transform these high-level commands
into device-specific commands that can is sent to the
device.

7
Many might argue that whatever Ansible can do, a python script
can do and this is true. however, Ansible has many advantages
over python for managing networking nodes
• Ansible abstracts many of the difficult python operations in very simple
modules (like creating files, directories, starting NETCONF or SSH sessions).
• Ansible handles error conditions and provides very simple knobs to control
playbook execution when you encounter errors.
• Ansible seamlessly transforms XML or JSON data into python native data
structures (lists and dicts) without dealing with python libraries like lxml or
JSON to decode these data.
• When you start running on a large scale, your python scripts need to be
multi-threaded in order to execute multiple tasks concurrently on multiple
devices, however, Ansible is multi-threaded by nature.
Section I
As a conclusion, Ansible is a complete framework that uses python in its core,
however it abstracts all the complexity of python to the user and provides
easy to use modules to get the job done in the easiest way, thus it lets you
concentrate on the important tasks (like configuring nodes or getting output
from managed nodes) rather than figuring out how to perform a complex
operation in python. However, in order to extend Ansible and implement
complex data transformation and manipulation you will need to know python
and write python code, nevertheless, 70%-80% of the common tasks in
networking can be executed with no python code at all.

8
As we discussed above, the default Ansible modules to
interact with different vendors hardware require
different format (junos_command, ios_command) and
provide a varying output with a different data
structure. So even though that Ansible utilizes the
Vendor API to communicate with the target device, in a
multivendor environment we need to interact with
each API separately in order to manage and get output
from these devices, this is the area which NAPALM
solves. NAPALM (which stands for Network
Automation and Programmability Abstraction Layer
with Multivendor support) tries to deliver a common
API to manage different vendor OS, it is a python
library that utilizes existing python libraries for each
vendor (like Juniper Pyez) to communicate with each
vendor however, it abstracts these different libraries
into a command API libraries which based on the
device OS being managed triggers the correct API call
to the target node.
NAPALM is integrated with Ansible and it provides different
NAPALM modules to interact with different vendor
equipment, below is the most common NAPALM Ansible
modules.
• napalm_get_facts
this is used to get different output
from the devices and return a
common data structure.
• napalm_install_config
this load the configuration into the
managed nodes.

9
PyeZLibrary
Output
netmiko
pyIOSXR
pycsco
Network
OS
Juniper
JunOS
Cisco
IOS/IOS-XR
Cisco
Nexus-OS
XML String JSON
NAPALM
Modules
• napalm_get_facts
• napalm_install_config
NETCONFTransport/
API
SSH NX-API
NAPALM
Modules
NAPALM
NAPALM
• Ansible Facts (Native python Data Structures) common
across all platforms with the same data
Ansible

10
Further NAPALM emulates operation like compare Config and
commit Config which is not available natively by some Networking
OS like Cisco-IOS. Thus, it delivers a common API to interact with
different vendors Network OS. The below diagram outlines the
output of the same operation (get_bgp_neigbors) on both a JunOS
and IOS-XR device and returned output, which clearly outlines the
benefit of having a command API for interacting with the different
Vendor equipment.
In the next section, we will build a sample topology and illustrate
how we can generate the configuration using Ansible and JINJA2
templates, and how to push the configuration to the managed
nodes using NAPALM.

11
In the previous section, we introduced Ansible and
how it can be used to manage network devices and
how to use NAPALM as a common API to manage
multiple vendor equipment. In this section, we will try
to outline how to use Ansible and NAPALM to build a
framework to automate the generation of router
configuration and deployment of this configuration on
the network nodes within the network. with this
framework, we should be able to cover the full lifecycle
of a typical network deployment which covers Design,
deployment, and verification. The below diagram
outlines these three main stages and how we can
leverage Ansible in each stage
This model can be used to in different
scenarios like
Section II
•
•
•
Design
DeployValidate
• Build the Data Model for the Network/Service.
• Generate per node Configuration
Push the configuration to the nodes
Validating the network state against the
Network Design

12
How to automate your network using Ansible and NAPALM Section II
The below diagram outlines the lab Setup
that we will use in order to illustrate Ansible
and NAPALM use.The below setup is build
using Vagrant with VirtualBox as the
Hypervisor to run all these VMs
vSRX is running in packet-
mode thus it should be
considered as router, not a
firewall, it is used in this lab
since it footprint is small (512
MB RAM) while the XRv
require at least 2GB RAM.
192.10.1.101 192.10.1.102 192.10.1.103 192.10.1.104
ge-0/0/1 ge-0/0/1 ge-0/0/1 MgmtEth0/0
192.10.1.10
IOS-XR 6.1.2JunOS 12.1X47-D15.4
Ubuntu 16.04
Vagrant
+
VirtualBox
ge-0/0/4
ge-0/0/2
ge-0/0/3
ge-0/0/2
ge-0/0/2
G0/0/0/0
ge-0/0/3
ge-0/0/3
The Routers are connected to form the
below very simple topology where the vSRX1
is simulating P routers and vSRX2,vSRX3 and
XR4 are PE routers.
vSRX1 vSRX2 vSRX3 XR4
vSRX2
vSRX3
vSRX1 XR4

13
Ansible will be installed on a Linux machine running
Ubuntu 16.04, Ansible can be installed on different
Linux distributions however in this deployment we will
be using Unbuntu.
Ansible uses a simple ini like file to identify the nodes that will be managed by the Ansible server and against which it
will execute the different playbooks. For simple setups, the host and group variables can be associated with those
hosts (like username and password to SSH and NETCONF) in the inventory file. the below snippet is for inventory file
that will be used in the lab (hosts) that identifies the nodes in this topology.
Section II
sudo apt-get update && sudo apt-get install software-properties-common
sudo apt-add-repository ppa:ansible/ansible
sudo apt-get update
sudo apt-get install ansible
We will be installing NAPALM ansible plugin and configuring ansible to look
for NAPALM in the directory where NAPALM is installed
pip install napalm-ansible
touch ~/.ansible.cfg
add the below lines to the file ~/.ansible.cfg using any editor (vi or nano)
[defaults]
library = /usr/local/lib/python2.7/dist-packages/napalm_ansible
[junos]
vSRX1 ansible_host=192.10.1.101
[iosxr]
XR4 ansible_host=192.10.1.104
[junos:vars]
ansible_user=lab
ansible_ssh_pass=lab123
dev_os=junos
[iosxr:vars]
ansible_user=cisco
ansible_ssh_pass=cisco
dev_os=iosxr
Below are some highlighted to describe the Ansible inventory file
• The nodes are grouped into two groups (Junos, iosxr) since this will help us to assign different values for the
variables based on this grouping.
• Each group has different variables assigned to them as shown above [junos:vars] & [iosxr:vars]
• ansible_user & ansible_ssh_pass specify the username & password for SSH session.
• ansible_host specifies the IP address for the managed host

14
Ansible architecture in generating any configuration
template (whether it is a Router configuration or an
HTML document or any text-based template
document) is the same, it uses its template module
which takes two input in order to generate the
output text document.
1. Variables for the data that will be rendered into
the template to generate the output text file. This
data can be specified in a YAML formatted
document or JSON (however YAML is more
human readable) which outline all the data
required to build the output router configuration.
2. JINJA2 template which will have vendor-specific
(JunOS and IOS-XR in our case) configuration
template.
Ansible takes these two input parameters and
outputs the per-node configuration file for each node
within its inventory. The below diagram outlines the
process that Ansible executes in order to generate
the per-node router configuration.
Configuration
Template
JINJA2 Template
(Per Network OS)
Data Model
YAML Document
(Vendor neutral)
Network Inventory
INI File
(Ansible inventory file)
+
Any Host or Group Variables
IOS-XR
Configuration
(XR4)
JunOS
Configuratio
n
(vSRX1/2/3)

15
The network topology that we will build has the
following parameters and design
The above requirements should be translated to a YAML document
that describes the desired network setup. The YAML document
that will be combined with the JINJA2 template is considered the
data model which holds all the parameters which describe the
network topology. This YAML document holds only this information
which is abstracted from the per vendor syntax and this data
model should be combined with the JINJA2 template to output the
per vendor router configuration. The below snippet from outline a
YAML document that describes the network topology that was
outlined in the beginning.
The YAML document on the left clearly
defines two main objects that outline
the above network topology which are
the nodes and the links connecting
these nodes. We define each node
with its main attributes such as name,
mgmt ipaddr and router-id. The links
are described as a point to point
connection between the left and right
nodes with all the attributes is
described as VLAN, cost, IP address
are outlined. Finally, the BGP setup is
also outlined with the specification of a
Route reflector and the clients for the
route reflector and the address
families that will be enabled on all the
routers. We can think of the above
YAML document as the LLD that
describe the overall architecture of the
network.
• IPv4 address with /24 subnet mask will be used on all core
links between the nodes.
• OSPF is the IGP routing protocol using Area 0 and all the links
are configured as point-to-point.
• iBGP is used with vSRX1 acting as the RR between all the
routers and all the routers are in AS 65000.
YAML, JSON or XML are just data
representation/serialization that
defines the data structure and how it
relates to each other. So in the above
YAML document, nodes, is a list where
each item in the list is a dictionary and
same goes for links. Using these data
structure we can access the
information, using for loops defined
either in Ansible or in the JINJA2
template.

16
Although the above YAML document very well describes the
network design, however, to extract the data from this document
to populate the JINJA2 template is very hard, thus we need to have
a per-node data structure in a YAML document that will describe
the same network setup however from the perspective of a single
node (we can think of it as a per Node LLD ). The resulting YAML
document that describes a single node is shown below.
A snippet of the JINJA2 template to create the Junos configuration for all JunOS nodes is shown below, this
snippet only outline the template OSPF configuration for any JunOS device and how it is rendered into the
actual Junos configuration based on the input data model on the left.
Similar below is the IOS-XR JINJA2 template and the resulting router configuration.

17
Below is the Ansible play-book (core-deploy.yml) that
takes both the per-node YAML document (nodes.yml)
that has all the variables for each node as well as the
JINJA2 template (core.j2) and generate the resulting
configuration files
The Ansible play-book is simply a YAML formatted document which has
two plays. First let’s focus on the second play and let’s break each line
• name: Name of the play
• gather_facts no: by default, Ansible try to gather facts on any managed
nodes so as to use these facts during the play execution, however, this
can be done for Linux machines and this is not applicable for network
nodes.
• connection local: as we described before Ansible by default SSH to
remote nodes and run python code and then report the output when
we specify connection local we are instructing Ansible to run the python
code locally on the Ansible server.
• hosts all: specify which hosts to execute the below tasks on, in our case,
we will execute this play on all the hosts in the inventory file.
• This play includes two tasks
• creating the directory to store router configuration (using file
module), this directory is called core_config.
• creating the per-node configuration using the supplied JINJA2
template. we are choosing which template to use (JunOS or
IOS-XR based on the dev_os variable that was set in the
inventory file).

18
Below is the organization of the files in the directory
that hosts the Ansible play-book.
We execute the below command in order to generate the per-node YAML data model
ansible-playbook -i hosts core-deploy.yml --tag model
We execute the below command in order run the playbook in order to generate the required
per node router configuration.
ansible-playbook -i hosts core-deploy.yml --tag template
After this play is executed the directory core_config is populated with all the routers
configuration.Once we have the per-node configuration we can move forward with the
deployment of the configuration using NAPALM.
.
├── core
│ ├── core-model.yml
│ └── core-to-nodes.j2
├── core_config
│ ├── vSRX1-config.txt
│ └── XR4-config.txt
├── core-deploy.yml
├── diff
│ ├── vSRX1-diff.txt
│ └── XR4-diff.txt
├── hosts
├── iosxr
│ └── core.j2
├── junos
│ └── core.j2
└── nodes.yml
The first Play in this playbook is used to
generate the per node data model from
the Core data model and store this in a
YAML document called nodes.yml. we
import all these variables in the second
play to be used to generate the per
node configuration.

19
The last part is to push the generated router configuration to each
node this will be done using the napalm_install_config module
which can be used to push the configuration on different platforms
using an input file which has all the configuration required to be
injected into the managed node. The play-book to push the
configuration is as shown below
This play can perform two actions based on a supplied parameter called commit
• If commit variable is 0, we push the configuration without committing the configuration and build a
configuration diff that will be stored in the directory called diff.
• If the commit variable is 1, we push the configuration and commit the configuration and also storing the
configuration diff in the above-mentioned directory.
The below command push the configuration without committing
ansible-playbook -i hosts core-deploy.yml --tag deploy --e "commit=0“
The below commands push the configuration and commit the configuration
ansible-playbook -i hosts core-deploy.yml --tag deploy --e "commit=1“
After executing the above commands, the configuration should be pushed by Ansible into each router. In the
next section, we will outline how to verify the configuration that was deployed and validate the current state of
the network.
Below is the link to the complete playbook on GitHub
https://github.com/kokasha/NetAutomationExamples.git

20
In the normal workflow that we are all accustomed to, we have a
document (Network Implementation plan) which outline exactly
the change we need to make and on which nodes this change
need to take place. We take what is there in the document and we
apply it on the network. After that, we hopefully do some sanity
validation checks to verify that the change we did is as expected
and that it didn’t break any existing network state.
• It is a manual work, which involves the typing of multiple commands on different
nodes to get the output and compare it with the expected network state.
• If the change is big and involves multiple network elements, the verification can
take a lot of time or we could skip some nodes without validation to save time.
• We are validating the network state after the change and we are the ones who
are comparing the state with the expected network state, thus it is Brune to
human errors.
Section III
All this workflow is error prune and takes a lot of time to be performed as
well as there is no direct correlation between the desired network state and
the network state after the change except in the mind of the engineer who is
performing this change and reporting the results.
So what is wrong with this approach?
Since we automated the deployment of the configuration using Ansible and we now have a clear network
design which is completely abstracted from the Vendor implementation (a YAML document which has all the
parameters to describe the desired network state). We used this data model to build the per-node data model
and from there we generated the vendor-specific router configuration. Having this data model for the desired
network design/state we can use this model to validate the network state after the change. The below diagram
outline the process of automating the network validation and how we can utilize the network data model that
we built in order to validate the network state
In this section, we continue what we have started in the previous two
sections focusing on Network Automation with Ansible and NAPALM.
In the first section, we introduced Ansible and how it is used in
combination with NAPALM to orchestrate a Multi-Vendor network. In
the Second section, we illustrated the process of developing the
configuration template for different Network OS (JunOS and IOS-XR)
and how to use both Ansible and NAPALM to push the configuration
onto these devices. In this section, we will continue with the
Validation part to verify that the configuration that was pushed to the
devices was pushed correctly and as well to verify the state of the
network after this change.
Network Data Model
Node Data Model
Per Vendor Configuration
Network Nodes
Unit testing
Data Model vs Network State
Transformation using
JINJA2 templates
Ansible
Transformation using
JINJA2 templates
Ansible
1
2
Implementation
3 Configuration push
Ansible + NAPALM
Validation
Retrieve network
State after
change
Ansible + NAPALM
Import Data
Model
Ansible
4
5

21
Since we automated the deployment of the configuration using
Ansible and we now have a clear network design which is
completely abstracted from the Vendor implementation (a YAML
document which has all the parameters to describe the desired
network state). We used this data model to build the per-node
data model and from there we generated the vendor-specific
router configuration. Having this data model for the desired
network design/state we can use this model to validate the
network state after the change. The below diagram outline the
process of automating the network validation and how we can
utilize the network data model that we built in order to validate
the network state
How to automate your network using Ansible and NAPALM Section III
With Ansible you can validate practically anything starting from the physical link status, up to network reachability
and protocol level status. However since we are using NAPALM as our common API across different vendors,
NAPALM only defined some getters (show commands and their output) for the most use cases and network
states that need to be validated. In this section, we will use some of them to illustrate how the validation will be
performed. This is realized using NAPALM get_facts module.
This is one of use cases where if you need to add more getters to satisfy a particular use case not covered by
NAPALM , you will need to extend NAPALM using python to implement this extra functionality.
With the help of Ansible and NAPALM we execute some predefined show commands on all the nodes which
were configured to extract the existing network state from these nodes, then we compare the extracted network
state against desired network state extracted from the network data model.

22
Below is the diagram of the desired network that we built in the
previous section.
Below is a snippet from the network data model (nodes.yml) that describes the above network topology and
which we used to build the per-node configuration and that we will use in the validation phase.
After we deployed/pushed the
configuration using Ansible and
NAPALM we will perform the
following validations to verify that
the network state is as expected.
ge-0/0/4
ge-0/0/2
ge-0/0/3
ge-0/0/2
ge-0/0/2
G0/0/0/0
ge-0/0/3
ge-0/0/3
vSRX2
vSRX3
vSRX1 XR4

23
We are going to perform the validation using the following procedure
• Connect to the devices and retrieve the required output from each device
using NAPALM getters.
• Run specific task(s) (using Assert module to compare between two inputs and
reporting success or failure) to compare between the retrieved network state
and the desired network state. These tasks can be referred to as unit tests to
validate the network state.
Below is the break down for the Ansible play-book that will perform all the above actions.
Get Network state using NAPALM get_facts module, we are using multiple getters which will
execute different show commands on the nodes and retrieve this info and register these data
into different data structures.
Verify that all the core interfaces referenced in the data model are
operational.
Verify that network is connected as expected using LLDP information.
Validate that the IP address and subnet mask on all the interfaces is
configured correctly as per the network data model.
Validate that the BGP sessions are established as per the design.
Validate Network reachability between the different nodes within the
topology to validate data plane reachability.

24
Below is an example of the lldp_neigbour data_strucutre returned by NAPALM
for vSRX1 node.
Below set of tasks, load the Network data model that we built previously and set some facts that we
will use to compare the network state against the Network Design (Data model).
First unit test to validate that all the interfaces are operational, we are getting the parameters from the
data model and passing it into the returned NAPALM facts and verifying that the output is as expected.
If the output if not true (link is down) then this task will fail and the below message will be printed to
notify us that this task has failed.
Second unit test to validate that the correct LLDP neighbor is correctly reported from the output of
lldp_neigbour
“napalm_lldp_neighbors” : {
“ge-0/0/2.0” : [
{
“hostname” : “vSRX2”
“port” : “ge-0/0/2.0”
}
],
“ge-0/0/3.0” : [
{
“hostname” : “vSRX3”
“port” : “ge-0/0/2.0”
}
]
}

25
The final play is to ping from every node to every other node in the topology to validate the end to end
reachability between all the nodes. This in this task we are using NAPALM ping module to perform this
check, however, this only applies to JunOS devices and it is not supported on the IOS-XR.
Third unit test to validate that the router has the correct IP address configured and
the correct subnet mask
Last unit test in this play to validate that router has the correct BGP neighbors
configured and that they are operational.

26
In order to validate as well the reachability from the point of view of the IOS-XR node,
we will revert back to the normal iosxr Ansible modules to execute the ping and
inspect the result to see if the ping is successful. Since this module is using SSH to
connect to the devices and perform the action, the return output is not well
structured and we need to do pattern matching to validate that the ping is successful
(unlike the JunOS case where even the ping produce a structured return value).
When we run this playbook we will get one of the following outcomes.
• Either all our unit tests (assert statements) are successful thus we can be sure
that our implementation was successful and that the current network state
matches our desired network design.
• Some of the unit tests will fail and we can troubleshoot to understand why this
occurred and fix it, then we run the validation script again to validate the state of
the network.
This framework provides assurance and reporting to the overall process of network/service provisioning
and the validation is fully automated and we don’t need to tweak the validation data that need to be
checked since it is automatically extracted from the Network design and we are validating the network
state against this information. Thus in case we modify or add any node or any configuration in our
design we don’t need to change anything in the validation script. The only changes that we might do to
this part are adding more validation testing cases (validating OSPF, Validating LDP, etc…).
In the last section, I will outline the process of adding a new service (Internet Access or L3VPN) to this
network and validation of that service.
With over 15 years of experience, specialized in the Design and
operation of large-scale IP backbone networks, with a strong focus
on SP Core/Edge Solutions across multiple vendors. I have strong
knowledge in SDN and NFV solutions across different domains like
DC SDN solutions and WAN SDN solutions from multiple vendors.
Lately, I have been focused on network automation with python and
other automation frameworks like Ansible to automate configuration
deployment and verifying network state.

Automate your network with Ansible and NAPALM

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Automate your network with Ansible and NAPALM

Similar to Automate your network with Ansible and NAPALM (20)

Recently uploaded

Recently uploaded (20)

Automate your network with Ansible and NAPALM