Ansible Interface Playbook (ios_config): Cisco interface config

Here an Ansible Playbook with three different examples how to configure Cisco router interfaces:

1. Static IP address configuration in playbook
2. Configuration comes out of Jinja2 template, can be run dynamic with variables
3. Loop in playbook configures multiple interfaces

There are some disadvantages to work with templates, if you use commands like “no shutdown” to enable the interface. They are not shown in the running-configuration which means Ansible will assume that the configuration is not matching and execute the template again.
Another disadvantage with templates is that you cannot run “before” or “after” commands to remove existing configuration all this needs to be implemented in your Jinja2 template.

Here the Ansible Playbook:

- name: Cisco interface config
  connection: local
  hosts: all
  gather_facts: false
      username: "{{ username }}"
      password: "{{ password }}"
      host: "{{ device_ip }}"
    - name: configure IP address
          - default interface FastEthernet1/0
          - ip address
          - no shutdown
        match: strict
        parents: interface FastEthernet1/0
        provider: "{{ cli }}"

    - name: configure IP out of template
        src: "interfaces.j2"
        provider: "{{ cli }}"

    - name: configure IP with loop
        provider: "{{ cli }}"
          - "default interface {{ item.interface }}"
          - "ip address {{ item.address }}"
          - no shutdown
        parents: "interface {{ item.interface }}"
        - { interface : FastEthernet2/0, address : }
        - { interface : FastEthernet2/1, address : }

Read my new posts about Ansible Playbook for Cisco ASAv Firewall Topology or Ansible Playbook for Cisco BGP Routing Topology.

2 Replies to “Ansible Interface Playbook (ios_config): Cisco interface config”

  1. Great stuff. You state two disadvantages of using ios_config with templates. The first disadvantage states that the idempotent functionally will be broken when using certain options in the template. Since shutdown is shown in the running config, the template can have a condition to only apply “no shutdown” if “shutdown” have been found. Would that solve the first disadvantage?

    The second disadvantage can also be seen as an advantage for it keeps the configuration logic centrally in the template and reusable.

    1. Personally I would prefer and use the Jinja2 templates because it keeps the playbook config short and the same place like you already said. But unfortunately I didn’t figure out a way how to deal with the “shutdown” and “no shutdown” scenarios. You have an idea how to solve this?

      Here is how I used this in the past in my j2 templates:

      {% for item in sub_interfaces %}
      interface Port-channel{{ }}.{{ item.vlan }}
      	 description {{ item.desc }}
      	 encapsulation dot1Q {{ item.vlan }}
               ip vrf forwarding {{ item.vrf }}
      	 ip address {{ item.ip }} {{ item.subnet }}
      	 no shutdown
      {% endfor %} 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.