Often, when it comes to configuring core network devices, these are isolated from the main network via a proxy or jump host. Ansible lends itself well to automating network device configuration as most of it is performed over SSH: however, this is only helpful in a scenario where Ansible can either be installed and operated from the jump host—or, better yet, can operate via a host such as this.

Fortunately, Ansible can do exactly that. Let's assume that you have two Cumulus Networks switches in your network (these are based on a special distribution of Linux for switching hardware, which is very similar to Debian). These two switches have the cmls01.example.com and cmls02.example.com hostnames, but both can only be accessed from a host called bastion.example.com.

The configuration to support our bastion host is performed in the inventory, rather than in the playbook. We begin by defining an inventory group with the switches in, in the normal manner:

[switches]
cmls01.example.com
cmls02.example.com

However, we can now start to get clever by adding some special SSH arguments into the inventory variables for this group. Add the following code to your inventory file:

[switches:vars]
ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p -q bastion.example.com"'

This special variable content tells Ansible to add extra options when it sets up an SSH connection, including to proxy via the bastion.example.com host. The -W %h:%p options tell SSH to proxy the connection and to connect to the host specified by %h (this is either cmls01.example.com or cmls02.example.com) on the port specified by %p (usually port 22).

Now, if we attempt to run the Ansible ping module against this inventory, we can see whether it works:

$ ansible -i switches -m ping all
cmls02.example.com | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
127.0.0.1 app02.example.com
    "ping": "pong"
}
cmls01.example.com | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "ping": "pong"
}

You will notice that we can't actually see any differences in Ansible's behavior from the command-line output. On the surface, Ansible works just as it normally does and connects successfully to the two hosts. However, behind the scenes it proxies via bastion.example.com. 

Note that this simple example assumes that you are connecting to both the bastion host and switches using the same username and SSH credentials (or in this case, keys). There are ways to provide separate credentials for both variables, but this involves more advanced usage of OpenSSH, which is beyond the scope of this book. However, this section intends to give you a starting point and demonstrate the possibility of this, and you are free to explore OpenSSH proxying by yourself. 

Let's now change track  and explore how it is possible to set up Ansible to prompt you for data during a playbook run.