Skip to main content

Ansible Collection Deployment Guide and Practical Case
for AI Data Center

Preface

This document serves as a deployment guide and practical case manual for the AsterNOS Ansible Collection. It aims to assist network engineers and automation operations personnel in quickly deploying the Collection environment on control nodes. Furthermore, it facilitates the implementation of declarative Playbooks for various operations such as batch configuration deployment, status collection, image upgrades, and patch management for AsterNOS data center switches.

Intended Audience

This guide is intended for network engineers and operation and maintenance personnel of AsterNOS switches. After reading this manual, you will be able to:

  • Install Ansible and the asterfusion.asternos Collection on a control node;
  • Write Inventory lists and variable files to organize configuration parameters by device role;
  • Write Playbooks to manage switches through the three core states: merged / deleted / gathered;
  • Deploy common data center network configurations, such as VLANs, interfaces, and routing protocols, in batches.

Before reading this guide, you are expected to have basic Linux command-line skills and fundamental networking knowledge.

1. Background

As data centers continue to expand and network topologies become increasingly complex, the configuration management of network devices faces growing challenges. Manually logging in to the CLI of each device to perform configuration is not only inefficient, but also prone to human error, which can introduce configuration mistakes and network failures. As a mature automation O&M tool, Ansible has become the preferred solution in the field of network automation, thanks to its declarative configuration model and rich module ecosystem.

To enable standardized, large-scale, and automated management of AsterNOS switches, Asterfusion has released the AsterNOS Ansible Collection. Built on the mature network_cli framework, this Ansible Collection provides a full-stack set of resource modules covering interfaces, VLANs, routing protocols, system firmware, and patch management, and supports operations such as merged, deleted, and gathered, helping you build an efficient and reliable automation O&M system.

This guide is intended for network engineers and O&M personnel working with AsterNOS switches. After reading this guide, you will be able to:

  • Install Ansible and the asterfusion.asternos Collection on a control node;
  • Write Inventory lists and variable files to organize configuration parameters by device role;
  • Write Playbooks to manage switches through the three core states: merged / deleted / gathered;
  • Deploy common data center network configurations, such as VLANs, interfaces, and routing protocols, in batches.

Before reading this guide, you are expected to have basic Linux command-line skills and fundamental networking knowledge.

2. Environment Requirements

2.1 Control Node Requirements

The control node is the server or virtual machine that runs Ansible and this Collection. It must meet the following requirements:

Table 2-1 Control node environment requirements
ComponentMinimum VersionRecommended Version
Operating SystemLinuxUbuntu 22.04
Python3.63.9+
Ansible2.92.15+
ansible.netcommon5.0.0Latest version
SSH ClientOpenSSH 7+OpenSSH 8+

2.2 Managed Node Requirements

The managed nodes are Asterfusion data center switches running AsterNOS. The requirements are as follows:

  • AsterNOS version: R0409 series or later
  • SSH access is enabled, and the management port IP is reachable from the control node
  • A local user account with administrator privileges (used for SSH login and configuration delivery)
  • The switch CLI supports the Klish framework (Cisco-like IOS syntax)

2.3 Network Requirements

  • SSH connectivity (TCP port 22) between the control node and the switches
  • SNMP (optional): used only for facts collection

3. Ansible Collection Installation Guide

This chapter provides two installation methods. Method 2 (Docker image installation) is recommended, as it enables rapid deployment and reduces dependency configuration.

3.1 Method 1: Install from a Locally Built tar Package

After preparing a Linux server or virtual machine, use this method if you prefer to install the Ansible environment and related dependencies yourself. Complete the following steps in order:

3.1.1 Install Python and pip

If Python and pip are already installed and meet the version requirements, you can skip this step.

Install python and pip before ansible collection

3.1.2 Install Ansible

Install Ansible using pip.

sonic@asterfusion:~$ pip3 install ansible

# Verify the installation; Ansible 2.15+ version information should be displayed
sonic@asterfusion:~$ ansible –version
ansible [core 2.17.14]
  config file = None
  configured module search path = [‘/root/.ansible/plugins/modules’, ‘/usr/share/ansible/plugins/modules’]
  ansible python module location = /usr/local/lib/python3.10/dist-packages/ansible
  ansible collection location = /root/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/local/bin/ansible
  python version = 3.10.12 (main, Jun 22 2026, 18:55:27) [GCC 11.4.0] (/usr/bin/python3)
  jinja version = 3.1.6
  libyaml = True

3.1.3 Install the ansible.netcommon Dependency

Install the general-purpose ansible.netcommon collection. ansible.netcommon provides the network_cli connection plugin, which is a prerequisite for running this Ansible Collection. Version >= 5.0.0 is required.

sonic@asterfusion:~$ ansible-galaxy collection install ansible.netcommon

3.1.4 Install the AsterNOS Collection

Obtain the pre-built tar package asterfusion-asternos-1.1.1.tar.gz from the relevant personnel, and install the Ansible Collection from the tar package.

After downloading and uploading the tar package, run the following command to install it:

sonic@asterfusion:~$ ansible-galaxy collection install asterfusion-asternos-1.1.1.tar.gz –force

The –force parameter overwrites an installed version with the same name; using this parameter ensures that the latest version is installed.

3.1.5 Verify the Installation

Check whether Ansible and the Collection are installed successfully.

Expected output: asterfusion.asternos 1.1.1

root@asterfusion:~# ansible-galaxy collection list | grep asterfusion
asterfusion.asternos 1.1.1

3.2 Method 2: Install via Docker Image

Asterfusion provides a Docker image file pre-installed with Ansible, the ansible.netcommon dependency, and the asterfusion.asternos Collection. After loading the image with docker load, it is ready to use, with no need to install Ansible or dependency libraries yourself.

3.2.1 Obtain the Image File

Obtain the Docker image file asternos-ansible-v1.0.tar from the relevant personnel.

3.2.2 Load the Docker Image

After transferring the image file to the control node server, run the following command to load the image.

sonic@asterfusion:~/ycw$ sudo docker load -i asternos-ansible-v1.0.tar


# View the loaded images
sonic@asterfusion:~$ docker images

3.2.3 Create the Container

sonic@asterfusion:~$ docker run -d \
–name asternos-ansible \
-w /var/test/ansible \
–network host \
–privileged \
asternos-ansible:v1.0

3.2.4 Enter the Container and Verify

After the container is created, enter the container:

sonic@asterfusion:~$ docker exec -it asternos-ansible bash

Verify the Ansible version in the container:

root@asterfusion:/var/test/ansible# ansible –version
ansible [core 2.16.3]
  config file = None
  configured module search path = [‘/root/.ansible/plugins/modules’, ‘/usr/share/ansible/plugins/modules’]
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  ansible collection location = /root/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/bin/ansible
  python version = 3.12.3 (main, Mar 23 2026, 19:04:32) [GCC 13.3.0] (/usr/bin/python3)
  jinja version = 3.1.2
  libyaml = True

Verify that the Ansible Collection is installed:

root@asterfusion:/var/test/ansible# ansible-galaxy collection list | grep asterfusion
asterfusion.asternos 1.1.1

4. Pre-configuration

Before writing and running Playbooks, you need to prepare and configure the ansible.cfg and inventory files. If Ansible was installed via the Docker image, the ansible.cfg and inventory files have already been created in the /var/test/ansible/asternos-playbooks directory in the container. If the Ansible Collection was installed from a locally built tar package, you need to create these two files yourself.

4.1 Create the Ansible Configuration File

ansible.cfg is the project-level configuration file of Ansible. When you run a Playbook to deploy switch configurations, Ansible reads this file first to override the global default settings. It can specify the host inventory path, plugin search directories, SSH connection timeout, and so on. Create the ansible.cfg file in the asternos-playbooks working directory:

root@asterfusion:/var/test/ansible/asternos-playbooks# cat ansible.cfg

[defaults]
inventory = ./inventory
host_key_checking = False
retry_files_enabled = False
stdout_callback = yaml
interpreter_python = auto_silent
timeout = 120
[collections]
collections_paths = ~/.ansible/collections:/usr/share/ansible/collections
[persistent_connection]
connect_timeout = 120
command_timeout = 120 

4.2 Create the Device Inventory File

inventory is the Ansible host inventory file. It defines the IP list of the managed devices and the username and password used to log in to the devices. When executing a Playbook, Ansible uses this file to determine which devices to operate on and how to connect to them. You can also define configuration variables in this file and reference them directly during configuration delivery. Create the inventory file in the asternos-playbooks working directory:

root@asterfusion:/var/test/ansible/asternos-playbooks# cat inventory

# AsterNOS switch inventory. The following is an example; replace with the actual IPs.
[asternos_switches]
spine01 ansible_host=10.250.0.171
leaf161 ansible_host=10.250.0.161
leaf128 ansible_host=10.250.0.128
[asternos_switches:vars]
ansible_network_os=asterfusion.asternos.asternos
ansible_user=admin
ansible_password=asteros
ansible_connection=ansible.netcommon.network_cli
ansible_become=no
ansible_host_key_checking=False
ansible_ssh_host_key_checking=False

Description of the key parameters in the inventory file:

Table 4-1 Description of inventory file parameters
ParameterDescription
ansible_connectionConnection method; ansible.netcommon.network_cli delivers configuration via CLI commands
ansible_userSSH login username
ansible_network_osSpecifies the network device type; must be asterfusion.asternos.asternos
ansible_becomeWhether to escalate privileges; usually set to no
ansible_passwordSSH login password

4.3 Test Connectivity

After the pre-configuration is complete, use the following command to test connectivity with the switches. For example, you can use the facts module to collect switch platform information:

root@asterfusion:/var/test/ansible/asternos-playbooks# ansible leaf161 -m asterfusion.asternos.asternos_facts -a ‘gather_subset=platform’
leaf161 | SUCCESS => {
    “ansible_facts”: {
        “ansible_net_gather_network_resources”: [],
        “ansible_net_gather_subset”: [],
        “ansible_net_platform_fan”: [
            {
                “direction”: “1”,
                “name”: “FAN”,
                “presence”: “green”,
                “speed”: “DRAWER”,
                “status”: “FAN”,
                “timestamp”: “1F 10680RPM intake Present OK 20260730 11:06:43”
            },
            {
                “direction”: “1”,
                “name”: “FAN”,
                “presence”: “green”,
                “speed”: “DRAWER”,
                “status”: “FAN”,
                “timestamp”: “1R 9480RPM intake Present OK 20260730 11:06:43”
            },
            {
                “direction”: “2”,
                “name”: “FAN”,
                “presence”: “green”,
                “speed”: “DRAWER”,
                “status”: “FAN”,
                “timestamp”: “2F 11040RPM intake Present OK 20260730 11:06:45”
            },
            {
                “direction”: “2”,
                “name”: “FAN”,
                “presence”: “green”,
                “speed”: “DRAWER”,
                “status”: “FAN”,
                ……

5. Writing and Executing Playbooks

5.1 Writing a Playbook

A Playbook is an Ansible configuration file that uses YAML format to describe the tasks to be executed on devices. After the pre-configuration is complete, you can start writing Playbooks in the asternos-playbooks directory to execute specific tasks. The following is a complete Playbook example that demonstrates how to configure the hostname:

– name: config switches hostname
  hosts: asternos_switches
  gather_facts: no
  tasks:
    – name: config hostname
      asterfusion.asternos.asternos_hostname:
        config:
          hostname: “sonic-leaf”
        state: merged

Key elements:

  • hosts: the hosts on which the configuration is executed. It can be a single host or a group of hosts defined under asternos_switches in the inventory file, or asternos_switches itself, which means all hosts participate in the task execution.
  • gather_facts: by default, Ansible implicitly collects facts (CPU, memory, OS, etc.) from the target hosts at the beginning of each Playbook and stores them in the ansible_facts variable. With this parameter set, Ansible skips this step and only executes the tasks explicitly defined in the Playbook, improving execution efficiency.
  • asternos.asternos_<module_name>: the name of the module invoked during task execution
  • config: module configuration parameters
  • state: typically merged/deleted/gathered, for adding or deleting configuration

5.2 Executing a Playbook

After writing the Playbook, you can start executing it. The following example writes a Playbook in the container to configure an interface IP address on a switch. The Playbook content is as follows:

root@asterfusion:/var/test/ansible/asternos-playbooks# cat config_interface.yml
– name: Configure Layer 3 Interfaces
  hosts: leaf161
  gather_facts: no
  tasks:
    – name: Configure Interface IP
      asterfusion.asternos.asternos_l3_interfaces:
        config:
          – name: “0/1”
            ipv4:
              – address: “10.1.1.1/24”
        state: merged

Execute the specified Playbook:

root@asterfusion:/var/test/ansible/asternos-playbooks# ansible-playbook config_interface.yml

PLAY [Configure Layer 3 Interfaces] *****************************************************************


TASK [Configure Interface IP] ***********************************************************************
changed: [leaf161]


PLAY RECAP ******************************************************************************************
leaf161 : ok=1 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

Log in to the switch and check the configuration under interface 0/1. The IP address is configured successfully:

sonic# configure
sonic(config)# interface ethernet 0/1
sonic(config-if-0/1)# show this
!
interface ethernet 0/1
 fec rs
 mtu 9216
 speed 25000
 ip address 10.1.1.1/24

5.3 Execution Parameters

When executing a Playbook, you can also specify some optional parameters to facilitate troubleshooting and problem location.

Table 5-1 Description of common Playbook execution parameters
ParameterDescriptionFull Name/FormatDescriptionApplicable Scenario
-v / -vvv–verboseOutputs detailed logs. -v shows the delivered CLI commands; -vvv shows the complete connection and debugging logs.Debugging and troubleshooting
-l–limitLimits the execution targets. Supports a single device name, wildcards (such as leaf*), or a comma-separated device list.Gray release, single-device testing
-C–-checkCheck mode. Calculates and simulates the configuration to be delivered without actually writing it to the device.Safe rehearsal before changes
-D–-diffDiff comparison. Shows the differences before and after the configuration change; usually used together with -C or -v.Reviewing configuration changes

The -v parameter executes with detailed output. You can see the logs printed during execution, such as the actually executed configuration commands, which is very helpful for troubleshooting. With the -vvv parameter, you can see even more detailed log output.

root@asterfusion:/var/test/ansible/asternos-playbooks# ansible-playbook config_interface.yml -v
Using /var/test/ansible/asternos-playbooks/ansible.cfg as config file
PLAY [Configure Layer 3 Interfaces] *****************************************************************


TASK [Configure Interface IP] ***********************************************************************
changed: [leaf161] => changed=true
commands:
– interface ethernet 0/1
– no switchport
– ip address 10.1.1.1/24
– exit


PLAY RECAP ******************************************************************************************
leaf161 : ok=1 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

The -l parameter can limit the execution scope. If the inventory file defines a large number of switches, but the Playbook tasks should only be executed on one or some of them, you can use the -l parameter.

root@asterfusion:/var/test/ansible/asternos-playbooks# ansible-playbook config_interface.yml -l leaf161
PLAY [Configure Layer 3 Interfaces] *****************************************************************


TASK [Configure Interface IP] ***********************************************************************
changed: [leaf161]

PLAY RECAP ******************************************************************************************
leaf161 : ok=1 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
root@asterfusion:/var/test/ansible/asternos-playbooks#

Execute the Playbook tasks on all leaf switches:

root@asterfusion:/var/test/ansible/asternos-playbooks# ansible-playbook config_interface.yml -l leaf*

Execute the Playbook tasks on specific switches:

root@asterfusion:/var/test/ansible/asternos-playbooks# ansible-playbook config_interface.yml -l “leaf161,leaf128”

Check mode execution: the module calculates the commands to be delivered and outputs them, but does not actually modify the device configuration. Combined with the –diff and -v parameters, you can also view the detailed differences of the configuration change. This can be used to preview configuration changes before formal execution; the actual support depends on the module used.

root@asterfusion:/var/test/ansible/asternos-playbooks# ansible-playbook config_interface.yml –check –diff -v
Using /var/test/ansible/asternos-playbooks/ansible.cfg as config file
PLAY [Configure Layer 3 Interfaces] *****************************************************************

TASK [Configure Interface IP] ***********************************************************************
changed: [leaf161] => changed=true
commands:
– interface ethernet 0/1
– no switchport
– ip address 10.1.1.1/24
– exit

PLAY RECAP ******************************************************************************************
leaf161 : ok=1 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

6. Use Cases

6.1 Obtaining Basic Switch Information

By writing and executing Playbook tasks, you can collect switch information in batches. An example is as follows:

root@asterfusion:/var/test/ansible/asternos-playbooks# cat get_info.yml
– name: Collect AsterNOS switches info
  hosts: asternos_switches
  gather_facts: no
  tasks:
    – name: Gather device information
      asterfusion.asternos.asternos_facts:
        gather_subset:
          – default
          – platform
      register: result

After execution, switch platform-related information can be collected in batches.

6.2 Batch Configuration Deployment

You can deliver configurations to switches in batches, including hostname, VLAN, physical interfaces, Layer 3 interfaces, BGP, and so on. This example shows how to chain multiple resource modules in a single Playbook to complete a full set of configurations in one execution. The process is as follows:

  • Configure the device hostname
  • Create VLANs and configure description information
  • Configure description information for physical interfaces
  • Add interfaces to VLANs
  • Configure the IP address of the uplink interface
  • Configure BGP settings such as the AS number, router ID, and neighbor information
  • The following configuration parameters are examples only. In actual deployment, define them separately through the Inventory or variable files according to the device role, management address, and network topology.

– name: Batch configuration distribution
  hosts: asternos_switches
  gather_facts: no
  tasks:
    – name: Configure hostname
      asterfusion.asternos.asternos_hostname:
        config:
          hostname: “{{ inventory_hostname }}”
          router_type: “{{ ‘spine’ if ‘spine’ in inventory_hostname else ‘leaf’ }}”
        state: merged


    – name: Create VLAN
      asterfusion.asternos.asternos_vlans:
        config:
          – vlan_id: 10
            description: “Management”
            mac_learning: true
          – vlan_id: 20
            description: “Server”
            mac_learning: true
          – vlan_id: 30
            description: “Storage”
            mac_learning: true
        state: merged


    – name: Configure ethernet interface
      asterfusion.asternos.asternos_interfaces:
        config:
          – name: “0/1”
            description: “Uplink to Spine”
            enabled: true
            speed: “25000”
            mtu: 9216
          – name: “0/2”
            description: “Downlink to Server”
            enabled: true
            mtu: 9216
        state: merged


    – name: Configure L2interface
      asterfusion.asternos.asternos_l2_interfaces:
        config:
          – name: “0/2”
            mode: trunk
            trunk:
              allowed_vlans: [10, 20, 30]
          – name: “0/3”
            mode: access
            access:
              vlan: 20
        state: merged


    – name: Configure L3 interface IP address
      asterfusion.asternos.asternos_l3_interfaces:
        config:
          – name: “vlan10”
            ipv4:
              – address: “10.1.10.1/24”
        state: merged


    – name: Configure BGP
      asterfusion.asternos.asternos_bgp_global:
        config:
          as_number: 65141
          router_id: “10.1.1.1”
          neighbors:
            – neighbor_address: “10.1.1.2”
              remote_as: 65002
              bfd: true
        state: merged


    – name: Save configuration
      asterfusion.asternos.asternos_config:
        save_when: always

6.3 Deleting Switch Configuration

The state: deleted parameter in a Playbook defines a deletion operation, which can delete specific configuration items. The following example deletes a VLAN that is already configured on a switch. After execution, you can log in to the switch to verify that the VLAN has been deleted successfully.

root@asterfusion:/var/test/ansible/asternos-playbooks# cat delete_vlan.yml
– name: delete VLANs
  hosts: leaf161
  gather_facts: no
  tasks:
    – name: delete VLAN
      asterfusion.asternos.asternos_vlans:
        config:
          – vlan_id: 10
        state: deleted

root@asterfusion:/var/test/ansible/asternos-playbooks# ansible-playbook delete_vlan.yml -v
Using /var/test/ansible/asternos-playbooks/ansible.cfg as config file
PLAY [delete VLANs] *********************************************************************************


TASK [delete VLAN] **********************************************************************************
changed: [leaf161] => changed=true
commands:
– no interface vlan 10
– no vlan 10


PLAY RECAP ******************************************************************************************
leaf161 : ok=1 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

6.4 Saving Configuration

When the configuration needs to be saved after a change, use the asternos_config module:

root@asterfusion:/var/test/ansible/asternos-playbooks# cat save_config.yml
– name: Save configuration
  hosts: asternos_switches
  gather_facts: no
  tasks:
    – name: Save switches running-configuration
      asterfusion.asternos.asternos_config:
        save_when: always

save_when options: always saves the configuration every time; never (default) never saves; changed saves only when there are changes; modified saves when the configuration is modified. changed is recommended.

6.5 Issuing CLI Commands Directly

When the existing function modules do not fully cover specific configuration requirements, you can use the config module directly to execute CLI commands. For example, to configure Ucentral-related settings, execute the Playbook below.

root@asterfusion:/var/test/ansible/asternos-playbooks# cat config_ucentral.yml
– name: Configure Ucentral
  hosts: leaf161
  gather_facts: no
  tasks:
    – name: Config ucentral
      asterfusion.asternos.asternos_config:
        lines:
          – feature ucentral state enable
          – feature ucentral autorestart enable
          – ucentral-client server 10.126.1.100 vrf mgmt
        save_when: always

Configure the device timezone:

root@asterfusion:/var/test/ansible/asternos-playbooks# cat config_clock.yml
– name: Configure timezone
  hosts: asternos_switches
  gather_facts: no
  tasks:
    – name: Config timezone
      asterfusion.asternos.asternos_config:
        lines:
          – clock timezone Asia/Shanghai

When executing commands that involve interactive secondary confirmation (such as a [y/N] prompt), you can use prompt to match the echo after the command is executed, and use answer to enter y/N. The following is a Playbook that executes the reload command and enters y to confirm the operation. The reload operation may cause service interruption; perform it with caution.

– name: reload switch
  hosts: leaf161
  gather_facts: no
  tasks:
    – name: Reload switch
      ansible.netcommon.cli_command:
        command: reload
        prompt: “Clear running config and reload saved config”
        answer: “y”

6.6 Batch Version Upgrade

In actual network management, system image upgrades often need to be performed on multiple switches. Take the following Playbook for batch version upgrade as an example. The process is as follows:

  • Obtain the device type
  • Transfer the corresponding image file to the switch according to the device type
  • Verify whether the MD5 value of the image meets expectations
  • Save the device configuration
  • Perform the image installation, upgrading 10 switches at the same time
  • After the image installation is complete, reboot the devices
  • After the devices recover, log in to the switches to check the version information
  • By default, 5 devices are upgraded at the same time. Setting the serial parameter to 1 in the Playbook executes the upgrade one device at a time; setting the serial parameter to 10 upgrades 10 switches at the same time.

Before executing the upgrade Playbook, you need to upload the switch images to the Ansible working directory in advance.

– name: Upgrade switch

  hosts: asternos_switches

  gather_facts: no

  serial: 10

 

  tasks:

    # 1. Get platform info

    – name: Get ASIC_TYPE

      ansible.netcommon.cli_command:

        command: “system cat /etc/sonic/sonic-environment”

      register: sonic_env

 

    # 2. Get ASIC_TYPE

    – name: Parse ASIC_TYPE

      set_fact:

        asic_type: “{{ sonic_env.stdout | regex_findall(‘ASIC_TYPE=(\\S+)’) | first }}”

 

    – name: Validate supported ASIC_TYPE

      assert:

        that:

          – asic_type | length > 0

          – asic_type in [‘marvell’, ‘innovium’]

        fail_msg: |

          ERR–not supported ASIC_TYPE: ‘{{ asic_type }}’

          Only support marvell / innovium ,abort task！

        success_msg: “ASIC_TYPE: {{ asic_type }}”

 

 

   # 3. Choose bin

    – name: choose image

      set_fact:

      image_bin: “{{ ‘AsterNOS_V3.1_R0409P01-FL.bin’ if asic_type =​= ‘marvell’ else ‘AsterNOS_V3.1_R0409P01-FL.bin’ }}”

    # 4 upload images

    – name: Upload image to switch via SCP

      command: |

        sshpass -p ‘{{ ansible_password }}’ scp

        -o StrictHostKeyChecking=no

        -o UserKnownHostsFile=/dev/null

        “{{ playbook_dir }}/{{ image_bin }}”

        “{{ ansible_user }}@{{ ansible_host }}:/home/admin/{{ image_bin }}”

      delegate_to: localhost

      register: upload_result

 

    – name: Calculate MD5 of uploaded image on switch

      command: |

        sshpass -p ‘{{ ansible_password }}’ ssh

        -o StrictHostKeyChecking=no

        -o UserKnownHostsFile=/dev/null

        {{ ansible_user }}@{{ ansible_host }}

        “md5sum /home/admin/{{ image_bin }} | awk ‘{print $1}'”

      delegate_to: localhost

      register: md5_result

 

      # 4.2 Set the expected MD5 value, example data, please replace it with actual data

    – name: Set expected MD5 based on ASIC type

      set_fact:

        expected_md5: “{{ ‘f115b5ded0deefb6ede65602bd27e11b’ if asic_type != ‘marvell’ else ’69dd9d4b7dd1e34783a776eec5bd2682′ }}”

 

     # 4.3 Verify the MD5, abort and report an error if it does not match

    – name: Verify MD5 checksum

      fail:

        msg: |

          MD5 checksum mismatch!

          Expected : {{ expected_md5 }}

          Got      : {{ md5_result.stdout }}

          File     : /home/admin/{{ image_bin }}

          Upgrade aborted to prevent corruption.

      when: (md5_result.stdout | trim) != expected_md5

 

    # 5. Save configuration

    – name: Save switches running-configuration

      asterfusion.asternos.asternos_config:

        save_when: always

 

    # 6. Upgrade images

    – name: Switch System update Image

      asterfusion.asternos.asternos_image:

        config:

          bin_file: “{{ image_bin }}”

        state: merged

 

    # 7. reboot

    – name: Safe Reboot Switch

      asterfusion.asternos.asternos_reboot:

        confirm: true

 

    # 8. wait 600s

    – name: Wait 600 seconds after reboot

      wait_for:

        timeout: 600

      delegate_to: localhost

 

    # 9.Check version

    – name: Check SONiC version

      ansible.netcommon.cli_command:

        command: show version

      register: ver

 

    – name: Assert expected version

      ansible.builtin.assert:

        that:

          – “‘Software, Version 3.1, R0409P01’ in ver.stdout”

        fail_msg: “Version mismatch! Got: {{ ver.stdout_lines[0] }}”

        success_msg: “Version check passed”

6.7 Installing Patches

When switches need to have patches installed, you can also write a Playbook to perform patch installation in batches. Refer to the following content. The process is as follows:

  • Copy the patch file to the /home/admin directory of the switch
  • Perform the patch installation

– name: Install System Patch
  hosts: asternos_switches
  gather_facts: no
  tasks:
    – name: Copy patch file to device
      ansible.netcommon.net_put:
        src: ./files/patch.bin
        dest: /home/admin/patch.bin


    – name: Install patch
      asterfusion.asternos.asternos_patch:
        file_name: patch.bin
        remote_dir: /home/admin
        install_args: “-i”

Ready to Implement?

Explore our detailed implementation guides to turn these white paper insights into real-world networking solutions. From RoCE to Zero-Touch Provisioning, we’ve got you covered.

Explore Configuration Guides