Network Automation – Ansible Learnings Week 3 – Cisco IOS: Obtaining IP Interfaces and creating Loopback Interface

Continuing from my last post, I am moving onto creating an interface and network on this interface. For the sake of testing and speed, I am creating a loopback interface with a basic /24 network attached to it.

Again this is a very static playbook and the point of this post and this playbook is just to prove I can do what I want to do and that I have understood what I have been reading. If you have been reading my posts, this is how I like to learn and how my brain absorbs new learnings – getting stuck in!

Later posts, I will develop my skills further and leverage the powers of group vars, templates etc…

Create_network_01.yaml

---
 - name: Obtain current IP Interfaces
   connection: network_cli
   gather_facts: false
   hosts: NV-NET-LAB1-R1
   vars:
     ansible_password: !vault |
       $ANSIBLE_VAULT;1.1;AES256
 
   tasks:

#Get the current router interfaces

     - name: Obtain current router interfaces
       cli_command:
           command: show ip int br
       register: current_ip_int_br
 
     - name: Display the current IP Interfaces
       debug:
         msg: "{{ current_ip_int_br.stdout }}"
 
#Configure the network interface and configure its IP address

     - name: Create Loopback interface and configure a /24 network ip address
       cli_config:
         config: |
           interface loopback 2
           ip address 192.168.30.1 255.255.255.0
 
#Let handlers do the final actions

       notify:
         - SAVE CONFIGURATION
         - PRINT UPDATED CONFIGURATION
 
#Show the updated interface information as a way of confirming the #playbook has worked

     - name: Obtain updated IP address configuration
       cli_command:
          command: show ip int br
       register: updated_ip_int_br
 
   handlers:
 
     - name: SAVE CONFIGURATION
       cli_command:
         command: write memory
 
     - name: PRINT UPDATED CONFIGURATION
       debug:
         msg: "{{ updated_ip_int_br.stdout }}"

First run through of playbook…

Huzzah!!!

What happens when we run it a second time though?

A screenshot of a computer

Description automatically generated

Well Ansible goes out and reconfigures it and marks it as a configuration changed. I was hoping to see that was OK and recognise no change was needed. So I must say I am at this stage not entirely sure why compared with the NTP configuration (see my previous post – <insert_link> ) where the recap notice no change was required. I will look into this but I can only conjecture it is because it is a multi line config change and that is where I am going wrong if I expected/wanted to see the recap showing that the change was necessary.

I suppose the critical part is to test that I can reach that interface, I should preface, when I run the ping on another network device that there is a EIGRP redistribution already configured to redistribute every network inside of 192.168.0.0/16. That is not a recommended approach but it keeps things simple in a LAB environment. In later posts I will be updating routes and dynamic routing protocols within the playbook as necessary.

Ping Results

NV-NET-LAB1-R2

A screen shot of a clock

Description automatically generated

NV-NET-LAB1-CS1

A close up of a sign

Description automatically generated

As you can see my LAB network is now talking to this configured loopback. Well a loopback is all nice and easy, but what if we need to configure an interface that needs to be also removed from shut down and how can we programmatically confirm the interface is up and routing? These are the next tasks I need to put in my next revision of the playbook.

From there, I will look at group_vars, and how I can replicate this across multiple devices and create multiple loopbacks. This will require some deeper learning in the power of Ansible, but each day is a new day to learn more and I am really loving this journey so far!

Leave a Reply

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