Ansible allows you to manage many different networking devices, including Arista EOS, Cisco ASA, Cisco IOS, Cisco IOS XR, Cisco NX-OS, Dell OS 6, Dell OS 9, Dell OS 10, Extreme EXOS, Extreme IronWare, Extreme NOS, Extreme SLX-OS, Extreme VOSS, F5 BIG-IP, F5 BIG-IQ, Junos OS, Lenovo CNOS, Lenovo ENOS, MikroTik RouterOS, Nokia SR OS, Pluribus Netvisor, VyOS, and OS, which supports NETCONF. As you can imagine, there are various ways we can make Ansible communicate with them.

Also, we have to remember that Ansible networking modules run on the controller host (the one where you issued the ansible command), while usually, the Ansible modules run on the target host. This difference is important because it allows Ansible to use different connection mechanisms based on the target device type. Remember that even when you have a host that has SSH management capabilities (which many switches have), Ansible, by very virtue of running its modules on the target host, needs the target host to have Python installed. Most switches (and embedded hardware) lack Python environments, and so we must make use of other connection protocols. The key ones supported by Ansible for network device management are given here.

There are five main connection types that Ansible uses for connecting to those network devices, as follows:

• network_cli
• netconf
• httpapi
• local
• ssh

When you create a connection with your networking device, you need to choose the connection mechanism based on the ones supported by your devices and your needs:

• network_cli is supported by the majority of modules and it is the most similar to the way Ansible usually works with the non-networking modules. This mode uses a CLI via SSH. This protocol creates a persistent connection at the beginning of the configuration and keeps it alive for the whole duration of the task so that you don't have to provide credentials for every subsequent task.
• netconf is supported by very few modules (at the time of writing, these modules are just OSes that support NETCONF and Junos OS). This mode uses XML via SSH, so basically, it applies XML-based configurations to the device. This protocol creates a persistent connection at the beginning of the configuration and keeps it alive for the whole duration of the task so that you don't have to provide credentials for every subsequent task.
• httpapi is supported by a few modules (at the time of writing, these are Arista EOS, Cisco NX-OS, and Extreme EXOS). This mode uses the HTTP API that the device publishes. This protocol creates a persistent connection at the beginning of the configuration and keeps it alive for the whole duration of the task so that you don't have to provide credentials for every subsequent task.

• Local is supported by the majority of devices but is a deprecated mode. This is basically a vendor-dependent connection mode that may require some vendor packages to be used. This mode does not create a persistent connection, so at the start of every task, you will need to pass the credentials. When possible, avoid this mode.
• ssh must not be forgotten in this section. Although a large number of devices depend upon the connection modes listed here, a new breed of devices is being created that run Linux natively on white box switch hardware. One such example is Cumulus Networks, and as the software is Linux-based, all configuration can be performed over SSH, as if the switch was actually just another Linux server.

Knowing how Ansible connects to and communicates with your networking hardware is important as it gives you the understanding you need to build your Ansible playbooks and debug issues when things go wrong. In this section, we covered the communication protocols you will come across when working with networking hardware. We will build on this in the next section by looking at the fundamentals of starting out on our network automation journey with Ansible.