Ansible Playbook for Network OS Upgrade with pre and post checks

-

You have 100s of network switches or routers that you need to upgrade. How much time would it take for you to do the upgrades? There are a lot number of sub-tasks involved while upgrading IOS image of a Cisco router or a switch.

This time of upgradation can be reduced through automation from various Enterprise Configuration Management tools that also have ability to upgrade network OS. Though these tools give an easy to use graphical interface, but this requires you to have appropriate license and also restricts you to customize your upgrade process.

Ansible is one of the tool that can be used and the upgrade process can also be customized to include any tasks that you want, e.g. taking pre-checks, post-checks and then comparing them and highlighting the differences, etc.

Following is the Ansible-playbook for IOS upgradation, that includes following sub-tasks. More tasks can be included as per need.

IOS upgrade tasks included in the playbook

  1. Verify the current version of OS version
  2. Decide whether to upgrade the IOS of device or not.
  3. Backup the running configuration of device
  4. Take pre and post checks of defined commands.
  5. Upload IOS image file from ftp to the device
  6. Change boot variable on device and save the config.
  7. Reload the device to boot with new IOS image
  8. Compare pre and post-checks and display the difference

First of all create a file that will include variables, which will be referred by the ansible-playbook

vi ios_upgrade_vars.yml

---
# variables used for IOS upgrade playbook
upgrade_ios_version: 16.09.05
upgrade_ios_image: image.bin
ftp_user:
ftp_password:
ftp_server:
precheck_path:
postcheck_path:

Now following is the ansible-playbook to upgrade the IOS.
---
# Ansible Playbook to upgrade Cisco IOS. Created by Prashant Sahu (Network Galaxy) http://www.networkgalaxy.org


- name: Upgrade Cisco IOS
  hosts: ios-xe-01 
  connection: network_cli
  vars_files:
    - ~/ios_upgrade_vars.yml
  tasks:
    - name: Checking current IOS version
      ios_facts:

    - name: Comparing Installed and Expected IOS version
      debug:
        msg:
        -  "Current version is {{ ansible_net_version}}"
        -  "Upgrade image is {{ upgrade_ios_version }}"


    - name: Deciding whether the IOS will be upgraded or not
      debug:
        msg: "{% if ansible_net_version == upgrade_ios_version %} Current IOS version is up to date. Upgrade would be skipped for this host {% else %} Current Image version is different than the upgrade image and will be upgraded {% endif %}"


    - name: End the play for the host if device os version is up to date
      meta: end_host
      when: ansible_net_version == upgrade_ios_version


    - name: Backing up the running configuration to local file
      ios_config:
        backup: yes

    - name: Writing Memory on device
      ios_config:
        save_when: always



    - name: Reading 'show ip route' ouput
      cli_command:
        command: show ip route
      register: ip_route_pre
     
    - name: Copying 'show ip route' ouput to local file
      copy:
        content: "{{ ip_route_pre.stdout }}"
        dest: "{{ precheck_path }}{{ inventory_hostname }}_route-precheck"


    - name: Reading 'show ip interface brief' ouput
      cli_command:
        command: show ip interface brief
      register: interface_ip_pre
     
    - name: Copying 'show ip interface brief' ouput to local file
      copy:
        content: "{{ interface_ip_pre.stdout }}"
        dest: "{{ precheck_path }}{{ inventory_hostname }}_interface-ip-precheck"


    - name: Copying IOS image to bootflash of device. This may take time.....
      ios_command:
        commands: 
          -  command: "copy ftp://{{ftp_user}}:{{ftp_password}}@{{ftp_server}}/{{ upgrade_ios_image }} flash:{{ upgrade_ios_image }}"
             prompt: 'Destination filename [{{ upgrade_ios_image}}]?'
             answer: "\r"
      vars:
        ansible_command_timeout: 600


    - name: Changing Boot Variable to new image
      ios_config:
        parents: boot-start-marker
        commands:
          - boot system flash {{ upgrade_ios_image }}
          - boot system flash {{ ansible_net_image }}
        match: exact
        before:
          - no boot system
        save_when: always



    - name: Reloading the Device
      cli_command:
        command: "reload"
        check_all: True
        prompt:
          - "Save?"
          - "reload?"
          - "confirm"
        answer:
          - 'yes'
          - 'yes'
          - 'y'
     
    - name: reset the connection
      meta: reset_connection
    - name: wait for network device to come back up
      wait_for_connection:
        delay: 100
        connect_timeout: 1200 



    - name: Comparing Installed and Expected IOS version
      debug:
        msg:
          -  Expected image after the upgrade is {{ upgrade_ios_version }}
          -  Current version is {{ ansible_net_version }}



    - name: Upgrade Result
      debug:
        msg: "{% if ansible_net_version == upgrade_ios_version %} IOS Upgrade is complete! {% else %} IOS upgrade is not successul. Please check logs on {{ inventory_hostname }} {% endif %}"


    - name: Reading 'show ip route' ouput
      cli_command:
        command: show ip route
      register: ip_route_post
     
    - name: Copying 'show ip route' ouput to local file
      copy:
        content: "{{ ip_route_post.stdout }}"
        dest: "{{ postcheck_path }}/{{ inventory_hostname }}_route-postcheck"

    - name: Reading 'show ip interface brief' ouput
      cli_command:
        command: show ip interface brief
      register: interface_ip_post
     
    - name: Copying 'show ip interface brief' ouput to local file
      copy:
        content: "{{ interface_ip_post.stdout }}"
        dest: "{{ postcheck_path }}{{ inventory_hostname }}_interface-ip-postcheck"

- name: Comparing Pre and Post outputs
  hosts: localhost
  gather_facts: no
  vars_files:
    - ~/ios_upgrade_vars.yml
  tasks:
    - name: Comparing pre and post routes
      copy:
        src: "{{ postcheck_path }}{{ inventory_hostname }}_route-postcheck"
        dest: "{{ precheck_path }}{{ inventory_hostname }}_route-precheck"
      check_mode: yes
      diff: yes
     
    - name: Comparing pre and post interface IP
      copy:
        src: "{{ postcheck_path }}{{ inventory_hostname }}_interface-ip-postcheck"
        dest: "{{ precheck_path }}{( inventory_hostname }}_interface-ip-precheck"
      check_mode: yes
      diff: yes










Comments

Post a Comment

Popular posts from this blog

Anyconnect SSL-Client VPN with Self-signed Certificate on Cisco ASA

-
Image
The Cisco AnyConnect Secure Mobility Solution provides a comprehensive, highly secure enterprise mobility solution. the Cisco AnyConnect Secure Mobility Solution continues to lead with next-generation security and encryption, including support for the Suite B set of cryptographic algorithms, and support for IPv6 networks. More importantly, it adapts its tunneling protocol to the most efficient method. In the present scenario, we have to configure Anyconnect SSL remote access VPN for Sales department and Engineering department of a company. Engineering users will have to be provided with access to web server as well as FTP server, while sales users may only have access to the web server.
Read more

Filtering Routes in BGP using Route-maps and Prefix-list

-
Image
Order of preference of attributes in BGP The order of preference varies based on whether the attributes are applied for inbound updates or outbound updates. For inbound updates the order of preference is:     route-map     filter-list     prefix-list, distribute-list For outbound updates the order of preference is:     prefix-list, distribute-list     filter-list     route-map NOTE: The attributes prefix-list and distribute-list are mutually exclusive, and only one command (neighbor distribute-list or neighbor prefix-list) can be applied to each inbound or outbound direction for a particular neighbor. Scenario: We own the AS500 and advertising a network block of 192.0.2.0/24 and 180.179.179.0/16 to two different ISPs.
Read more

Open Shortest Path First (OSPF)

-
Image
The Open Shortest Path First (OSPF) is an Interior Gateway Protocol used to distribute routing information within a single Autonomous System. OSPF is a Link State routing protocol and has following features. Fast convergence VLSM support Scalable to large networks Stub capabilities Authenticaion Efficiency (Sends only hello messages to maintain neighbor relationship) Route tagging capabilities Uses multicast for routing updates. Specifications                              Protocol type            Link-state               Administrative Distance            110                                          Metric            Cost                             Authentication            None, Clear-text, MD5                                Seed metric            20 for all redistributed routes and 1 for BGP routes.      Multicast address used by All             224.0.0.5   Multicast add. used by DR/BDR             225.0.0.6                                            RFC       
Read more

IKEv2 IPsec Site-to-Site VPN configuration on Cisco ASA 8.4(x)

-
Image
Though the crypto IKEv2 proposal command looks similar to the IKEv1 crypto isakmp policy command, there are many differences in how IKEv2 negotiates. Unlike IKEv1, the authentication method and SA lifetime are not negotiable in IKEv2, and they cannot be configured in the IKEv2 proposal. Also the IKEv2 proposal configuration supports specifying multiple options for each transform type and we can configure different pre-shared-key for local and remote authentication. Pseudo-Random Function (PRF) algorithm  is the same as the integrity algorithm, and hence, it is not configured separately. Our goal is to configure site-to-site or l2l IKEv2 IPsec VPN between ASA1 and ASA2 which are running IOS 8.4(2). IP addressing scheme is mentioned in the network diagram.
Read more

IPsec VPN as a Backup for Point-to-Point Link using IP SLA

-
Image
There may be times when you wish to access your remote site even when the point-to-point link (lease line) to that site is down. This is possible if you have also an internet connection to that site. You can configure an IPsec VPN between both the sites. But the problem is that even if you configure IPsec VPN on both the locations, the VPN will never come up when the point-to-point connection goes down. This is because even though that point-to-point connection is down, the interface status of firewall will always remain up due to devices of ISP in between and thus the static route will not let the incoming traffic to match the interesting traffic for IPsec VPN. So the solution to this problem is either to configure dynamic routing protocols or IP SLA. Cisco IP SLA monitor can be used to track the reachability of other location. Here is an example of such scenario using Cisco IP SLA monitor. If you need the gns3 lab for this or have any queries, you can leave your queries and email ID
Read more

Border Gateway Protocol (BGP)

-
Image
Introduction Border Gateway Protocol is an Exterior Gateway Protocol (EGP) used for routing between the autonomous systems. It is the protocol which is used to to make core routing decisions on the internet. BGP has two flavours, eBGP and iBGP. eBGP is routing between the autonomous systems and iBGP is routing within an autonomous systems. BGP is a path-vector routing protocol and has following features: Reliable updaes (TCP -based, port 179) Triggered updates only Rich metric Scalable to massive networks   Specifications              Protocol Type                Path-vector                    eBGP AD                20                     iBGP AD                200               Update Mode                Triggered only                     Transport                TCP/179              Authentication                None, md5                            RFC                RFC 4271 Default Timers                       Holddown time          180 seconds              
Read more

Cisco ASA Active/Active Failover Configuration

-
Image
Active/Active failover is only available to security appliances in multiple context mode. In an Active/Active failover configuration, both security appliances can pass network traffic. In Active/Active failover, you divide the security contexts on the security appliance into failover groups. A failover group is simply a logical group of one or more security contexts. You can create a maximum of two failover groups on the security appliance. The admin context is always a member of failover group 1. Any unassigned security contexts are also members of failover group 1 by default. We have already seen the configuration for Active/Standby failover in the previous article. This article focuses on how to configure an Active/Active Failover configuration on ASA Security Appliance. Network Diagram  (Physical Topology)
Read more

Bypassing Proxy Server in Google Chrome

-
Image
There may be times when you might want to use Google Chrome and do not wish to use the proxy settings for which you are bound to use in Internet Explorer because of your company policies. If you try to change proxy settings in Google Chrome, by default it will open the System Internet Properties dialogue box, and most of the times, change in proxy setting options is restricted by domain group policy. So here is an alternate way to remove or disable proxy settings in Google Chrome.
Read more

Cisco ASA Active/Standby Failover Configuration

-
Image
The security appliance supports two failover configurations: Active/Active Failover and Active/Standby Failover. Each failover configuration has its own method to determine and perform failover. With Active/Active Failover, both units can pass network traffic. This lets you configure load balancing on your network. Active/Active Failover is only available on units that run in multiple context mode. With Active/Standby Failover, only one unit passes traffic while the other unit waits in a standby state. If Active unit fails, secondary will take over and starts forwarding the traffic. When Secondary becomes active, it will also change it's interface IP address and mac address as well.  In Active/Standby configuration, virtually all of the configuration from the active unit is replicated to the secondary unit through a failover cable. This article focuses on how to configure an Active/Standby Failover in ASA Security Appliance. Prerequisites Hardware Requirements The two
Read more