Ansible for Networks

Consistency of all systems in the infrastructure is maintained.

Applications are deployed automatically on a variety of environments.

Ansible works by connecting to your nodes and pushing out small programs, called "Ansible modules" to them. These programs are written to be resource models of the desired state of the system. Ansible then executes these modules (over SSH by default), and removes them when finished.

Your library of modules can reside on any machine, and there are no servers, daemons, or databases required. Typically you'll work with your favorite terminal program, a text editor, and probably a version control system to keep track of changes to your content.

Fundamentally ansible controller uses ssh to connet to the target nodes, and then run python scripts on the target host that accomplish the tasks offered by the module being run. That implies that the target hosts need to have python interpreter available, and located in a directory that ansible will be able to find it.

This then is a problem if ansible will be running python commands on the network switch or router. That is why Netork Modules use a different approach.

So, ansible ad-hoc and ansible playbooks that call network modules, such as the ios_interface module.

Here is a yaml playbook file, devnet.yml that uses two cisco networking modules, ios_banner and ios_interface

• Cisco provided ansible modules: Cisco's ansible modules are grouped under:
  • aci
  • asa
  • dcnm
  • intersight
  • ios
  • iosxr
  • meraki
  • mso
  • nae
  • nso
  • nxos Note: nxos-nxapi has been deprecated by ansible.netcommon.httpapi
  • ucs

  These are all downloadable from https://galaxy.ansible.com/cisco.

  That means anyone can automate cisco devices using ansible without learning python. That's because while the ansible modules themselves are written in python, to use ansible you don't need to modify those modules, just use them.

Before starting make this change to /etc/ansible.cfg: Uncomment host_key_checking = False so that you do NOT need to copy ssh keys to the cisco devices in devnet ahead of time. In fact, Cisco Devnet won't allow it anyway, so you MUST set host_key_checking = False

As described on docs.ansible.com, there are multiple communication protocols available to manage network node, because network modules execute on the control node instead of on the managed nodes.

Options are:

• XML over SSH
• CLI over SSH
• API over HTTPS

Depending on the vendor and model, you may forced to use one protocol, or have a choice of protocols. The most common protocol is CLI over SSH. You set the communication protocol with the ansible_connection variable:

• ansible.netcommon.network_cli
• ansible.netcommon.netconf
• ansible.netcommon.httpapi
• local

The ansible_connection is mandatory for network modules

• note: ansible.netcommon.httpapi deprecates eos_eapi and nxos_nxapi

For ansible network modules, you MUST also have the network_os set to the correct vendor.

*

- name: show ip int brief
  ios_command:
    commands:
      - show ip int brief
      - show ip route 0.0.0.0
      - show ip neigh
    provider:
      host: 5.5.5.5
      post: 22
      authorize: yes
      auth_pass: Cisco
      username: admin
      password: cisco123
    register: if_data

- name: ip int brief output
  debug:
    var: if_data['stdout_lines'][0]

- name: Add a banner
  ios_banner: 
    banner: login   # as opposed to other banners available on cisco routers
    text: |
      This router is part of DevNet.  Please play nice
    state: present

- name: Add a loopback interface 27
  ios_interface: 
    name: loopback27
    state: present

- name: Merge provided configuration with device configuration
  ios_interfaces:
    config:
      - name: GigabitEthernet0/
        description: 'Configured and Merged by Ansible Network'
        enabled: True
      - name: GigabitEthernet0/3
        description: 'Configured and Merged by Ansible Network'
        mtu: 2800
        enabled: False
        speed: 100
        duplex: full
    state: merged

tasks:
- name: Gather ios facts with ios_facts module
  ios_facts:
    provider:
      host: 5.5.5.5
      post: 22
      authorize: yes
      auth_pass: Cisco
      username: admin
      password: cisco123

- name: find IOS version
  debug:
    var: ansible_net_version

- name: display me your hostnmae
  debug:
    var: ansible_net_hostname

---
- name: Add loopbacks on all my nxos switches
  hosts: nxosswitches
  connection: local
  gather_facts: no
  tasks:
    - name: Create loopback
      with_items: "{{local_loopback}}"
      nxos_interfaces:
      interface: "{{item.name}}"
        mode: layer3
        description: "{{item.desc}}"
        admin_state: down
    - name: Configure new loopback interfaces
      with_items: "{{local_loopback}}"
      nxos_l3_interfaces:
        config:
        - name: "{{item.name}}"
          ipv4:
          - address: "{{item.ip_address}}"
            state: merged

With this example, we must also have the variables to pass into items So, the vars directory has this:

nxos_switch1.yml
---
local_loopback:
  - name: Loopback1
    desc: Ansible created loopback 1 interface
    ip_address: 192.168.1.1/24
  - name: Loopback2
    desc: Ansible created loopback 2 interface
    ip_address: 192.168.2.1/24


nxos_swtich2.yml
---
  - name: Loopback3
    desc: Ansible created loopback 3 interface
    ip_address: 192.168.3.1/24
  - name: Loopback4
    desc: Ansible created loopback 4 interface
    ip_address: 192.168.4.1/24

Placed in the top level directory of each project I am working on:

[defaults] inventory = ./inventory retry_filesenabled = False

[ssh_connection] pipelining = True

The roles are the collections of commands that can be run on hosts. The roles are stored in specific directories, each of which have specific sub-directories. Ansible will execute the commands stored in specific directories on a target machine. The direcotries are all stored on the controller / local machine.

• Roles are written in YAML.
• Self-contained and portable
• Used for common configurations
• Enforcement of standards
• called from a playbooks

The top level directory is the roles directory. Each role is stored in a subdirectory of the roles directory. Each role directory must at least contain a folder called tasks which contains a file called main.yml

(venv-ansible) ansible@c8host ~/Ansible-CentOS[653] $
tree .
.
├── ansible.cfg
├── base-utils.yml
├── hosts
├── playbooks
│   ├── dnf-delete.yml
│   ├── dnf-install-list.yml
│   ├── dnf-install-list.yml~
│   ├── dnf-list.yml
│   ├── dnf-updateall.yml
│   ├── dnf-update-specifics.yml
│   └── dnf-update.yml
└── roles
    ├── apache-LAMP
    │   ├── defaults
    │   ├── files
    │   ├── tasks
    │   │   └── main.yml
    │   ├── tests
    │   └── vars
    ├── basic-utils
    │   ├── defaults
    │   ├── files
    │   │   └── bash.bashrc
    │   ├── tasks
    │   │   ├── install-utils.yml
    │   │   ├── main.yml
    │   │   └── zintis-note.txt
    │   ├── tests
    │   └── vars
    ├── each-dir-is-a-role.txt
    ├── install-pb.yml
    └── mailservers
	├── defaults
	├── files
	├── tasks
	│   └── main.yml
	├── tests
	└── vars

20 directories, 22 files

If I want to run a basics-playbook.yml you must be at the level above the roles directory. Even if the basics-playbook.yml file is in playbooks sub-directory. Best to run it as: ansible-playbooks playbooks/basic-playbook.yml

In stead of having /etc/ansible.cfg as the only file, create a new directory structure for each project, and put the ansible.cfg file in the top level of that new directory. Following that, instead of using the default /etc/ansible/hosts file, you can create a hosts file in the ./inventory subdirectory as well.

Summarizing:

1. a new folder per project
2. ansible.cfg in the top directory
3. ./inventory/hosts as hosts file
4. ./group_vars

Placed in the top level directory of the project:

[defaults] inventory = ./inventory retry_filesenabled = False

[ssh_connection] pipelining = True

Placed in ./inventory/hosts.

localhost  ansible_connection=local
[dnac]
sandboxdnac.cisco.com

[dnac:vars]
user=devnetuser
password=

[iosxr]
sbx-iosxr-mgmt.cisco.com

[iosxr:vars]
ssh_port=8181
netconf_port=10000
xr_bash_port=8282
user=admin
password=C1sco12345

[routers]
ios-xe-mgmt-latest.cisco.com


[routers:vars]
ansible_user=developer
ansible_password=C1sco12345
ansible_connection=network_cli
ansible_network_os=ios
ansible_port=8181

[mansmeraki]
# do not store your personal API key here, but this is where would go.
#api_key=xxxxxxx
user=zintis@gmail.com
# do not store you personal password here, but this is where it goes.
password=yyyyyyyyyy


[meraki]
user=devnetmeraki@cisco.com
password=ilovemeraki
api_key=6bec40cf957de430a6f1f2baa056b99a4fac9ea0

For the above .yml file, everything defined after a host: is considered a host variable.

finish this

DevNet Code Exchange has this codeexchange link

The DNA Center Inventory plugin will gather all groups (sites) and inventory devices from DNA Center. The hosts are associated with appropriate sites in the hierarchy.

The following host_vars are associated with the network devices:

• ansible_connection : network_cli for ios and nxos devices
• ansible_becomemethod : for ios and nxos types. (enable)
• ansible_become : yes for ios and nxos types.
• ansible_host : using the managementIpAddress from DNA Center
  • conditionally mapped based on control file dna_center.yml.
• ansible_networkos : derived from os below and required for Ansible network_cli connection plugin
• os : network operating system as stored in DNA Center's softwareType
• version : network operating system version as stored in DNA Center's softwareVersion

For example:

• ansible all -m ping
• ansible all -m ping -u zintis
• ansible all -m ping -u zintis –ask-pass
• ansible -m ping all

First as an ad-hoc command:

• ansible -m command -a "hostname" mailservers
• ansible -m command -a "uptime" opsvms
• ansible -m command -a "cat /etc/resolv.conf" opsvms

Then as a playbook: -name: Run a command to show ip routes fill this in…

The ansible setup module is a good way to see what variables ansible has made available to you for the nodes you are asking for. These are called ansible "facts".

ansible -i inventory vm1 -m setup if inventory is giving errors run this: ansible ops -m setup # where ops is a section in the ansible hosts file. And you will see all the variables at your disposal for the vm1 host. Or can say all, if you like.

Now, any variable that comes back from setup, can be used in your playbooks. almost everything… ansible_dns, ansible_ipv4, etc.

IF your playbook has gather_facts: false Then a playbook that ask for stuff like ansible_osfamily or any other of these many facts, the playbook will fail. So set gather_facts: true if you want to use the ansible facts

Can be run this in any playbook to see all available facts. the ansible setup module gives you the "raw" information.

You can reference the ansible facts in a template or playbook as:

• {{ ansible_facts['devices']['xvda']['model'] }}

To reference the node name us:

• {{ ansible_facts['nodename'] }}

The following yml file is a playbook that is confirmed to work on my CML lab:

---
- name: set some banners using ios_banner
  hosts: iosv
  connection: network_cli
  become: true

  tasks:
    - name: add an exec banner
      cisco.ios.ios_banner:
        banner: exec   # as opposed to other banners available on cisco routers
        text: |
          Welcome!  Your credentials have been approved.
          This router is part of Zintis model labs.  Do your worst!!!
          I will just rebuild it if it is pooched.
          .oO0Oo. .oO0Oo. .oO0Oo. .oO0Oo. .oO0Oo. .oO0Oo. .oO0Oo. .oO0Oo. .oO0Oo.
        state: present


    - name: add a login banner
      cisco.ios.ios_banner:
        banner: login   # as opposed to other banners available on cisco routers
        text: |
          Hang on Chuckie!   You had better be sure that you are allowed to access
          this anonymous internet cesspool of filth.  If you know what's good for
          you, close this session now and go watch the hockey game.
          You have been warned!
           <<</>>>  <<</>>>  <<</>>>  <<</>>>  <<</>>>  <<</>>>  <<</>>>  <<</>>>
        state: present


    - name: Add a motd banner
      cisco.ios.ios_banner:
        banner: motd   # as opposed to other banners available on cisco routers
        text: |
          By the way, this banner is maintained using ansbile, specifically
          the cisco.ios.ios_banner module.
          /\/\          /\/\          /\/\          /\/\          /\/\     
           /\            /\            /\            /\            /\      
        state: present


    - name: Remove the slip-ppp banner
      cisco.ios.ios_banner:
        banner: slip-ppp   # as opposed to other banners available on cisco routers
        state: absent

You notice that there is no mention of usernames and passwords. That is because I have them defined in my inventory/hosts file. This is the first of several approaches to passing router credentials to ansible:

1. host:vars Here is the relevant section from my inventory/hosts file:

iosv:
  children:
    eigrp:
    ospf:
  vars:
    ansible_become: yes
    ansible_become_method: enable
    ansible_network_os: cisco.ios.ios
    ansible_connection: network_cli
    ansible_user: ansible
    ansible_password: sedemo
    ansible_python_interpreter: /Users/zintis/bin/python/venv-ansible/bin/python

1. prompt for password interactively. Obivously not good for batch processes, but convenient when you are developing your ansible playbooks:

   ansible-playbook my-cisco-playbook.yml -u ansible -k   
   

   -u specifies the user. I usually set my cisco router user to be "ansible" -k will prompt for the ssh password

2. use a credentials.yml file create a credentials.yml file and store the username and password needed for the SSH connections file: creds.yml

   username: admin
   password: C1sco123!
   

1. setup an Ansible command station on VLAN 4094, with ip addr 192.168.0.0/24
2. create an inventory file that contains descriptions of your devices. This inventory file can also arbitrarily group items as you see fit. An example could be branch_routers, core_routers, access_switches etc…

   file: inventory
   [branch_routers]
   172.17.18.1
   172.17.20.1
   172.17.22.1
   
   [core_routers]
   10.0.5.1
   10.0.6.1
   10.0.10.1
   
   [access_switches}
   192.168.1.1
   192.168.21.1
   192.168.31.1
   192.168.41.1
   
   

3. create a playbook, writtin in YAML format.

   —

   • name: