How to use The Ansible server in GNS3 SONiC DataCenter

[stordis-toc]

Introduction

Welcome to the STORDIS Ansible server guide.

In this guide, we will show you how to use the Ansible server available in the GNS3 SONiC DataCenter project. The Ansible server is used for automation, configuration management, and validation of the SONiC fabric.

Prerequisites

• Running GNS3 project: "The Enterprise SONiC Datacenter"
• Access to the management server (Ubuntu with Ansible installed)
• Basic knowledge of Ansible
• Established connectivity to SONiC nodes

Ansible Server Overview

The project includes a preconfigured Ubuntu Server that acts as an Ansible control node.

Key components:

• Ansible Engine – used for automation and configuration
• Inventory – predefined list of SONiC devices (Leaf/Spine topology)
• Playbooks – ready-to-use automation scripts

Main directory structure:

SONiC_DC/
├── ansible_configuration
│   ├── ansible.cfg
│   ├── inventory/
|   |   ├── group_vars
|   |   |   ├── sonic
|   |   |   |   ├── sonic_ssh.yaml # ssh connection
|   |   |   |   ├── sonic.yaml # RESTCONF connection
|   |   |   |   └── sonic-vault.yaml # hash file with credentials
|   |   └── hosts # list of all devices
│   └── playbooks/
│       ├──playbooks_yaml_files 
└── venv #Python Virtual environment

Access to Ubuntu Server

Log in to the management server:

Credentials:

• Login: administrator
• Passwd: ZAQ2wsx

ssh administrator@<IP_Addr>

Note Server on ens3 interface have static on, so You need to change it manually on /etc/netplan/50-cloud-init.yaml if needed

After that You will need to ZTP configuration files to IP in files are like the same You configured

path

/var/www/html/sonic/ztp.json

Activate Ansible Enviroment

In Project Dictonary proceed to activate the virtual environment

administrator@ubusrv2404:~/SONiC_DC$ source venv/bin/activate
(venv) administrator@ubusrv2404:~/SONiC_DC$

Example:

Server configuration

Available Automation Use Cases

The Ansible server includes a set of ready-to-use playbooks that demonstrate common SONiC DataCenter operations. These can be used both for automation and as reference examples for building your own workflows.

How to use Playbook?

1. You need to be in the same ansible_configuration dictonary - You need to use command in the same path where ansible.cfg file is

2. Use command like below:

   # to use playbook on all hosts in inventory
   ansible-playbook -i inventory/hosts playbooks/<playbook.yaml> --ask-vault-pass

Example:

(venv) administrator@ubuntu24.04:~/SONiC_DC/ansible_configuration$ ansible-playbook -i inventory/hosts playbooks/test_connection.yaml --ask-vault-pass
Vault password:
PLAY [SONiC Connectivity Check via SSH] ****************************************

TASK [Execute Ping from Switch to Server] **************************************
[WARNING]: Deprecation warnings can be disabled by setting `deprecation_warnings=False` in ansible.cfg.
ok: [leaf-1]
ok: [spine-2]
ok: [spine-1]
ok: [leaf-3]
ok: [leaf-2]
ok: [leaf-4]
ok: [switch-2]
ok: [switch-1]
ok: [switch-3]
ok: [switch-4]

TASK [Display Raw Output (for debugging)] **************************************
(...)

TASK [Final Result Summary] ****************************************************
(...)
TASK [Handle Critical Failure] *************************************************
(...)
PLAY RECAP *********************************************************************
leaf-1                     : ok=3    changed=0    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0
leaf-2                     : ok=3    changed=0    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0
leaf-3                     : ok=3    changed=0    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0
leaf-4                     : ok=3    changed=0    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0
spine-1                    : ok=3    changed=0    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0
spine-2                    : ok=3    changed=0    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0
switch-1                   : ok=3    changed=0    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0
switch-2                   : ok=3    changed=0    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0
switch-3                   : ok=3    changed=0    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0
switch-4                   : ok=3    changed=0    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0

(venv) administrator@ubuntu24.04:~/SONiC_DC/ansible_configuration$ ansible-playbook -i inventory/hosts playbooks/test_connection.yaml --limit leaf-1 --ask-vault-pass

Example output:

VLAN Management

Playbooks related to VLAN operations provide examples of using the RESTCONF API with SONiC:

• add_vlan.yaml - Demonstrates how to create a VLAN, assign parameters, and enable it.
• delete_vlan.yaml - Shows how to safely remove a VLAN, including handling cases where the VLAN does not exist.
• show_vlan.yaml - Retrieves and displays current VLAN configuration from the device.

These playbooks are useful for understanding how SONiC handles Layer 2 segmentation via automation.

Interface verification

• show_int.yaml - Uses CLI commands to display interface status. Useful for operational visibility and troubleshooting.

Connectivity Validation

• test_connection.yaml - A multi-purpose validation playbook that demonstrates:
  • SSH communication with SONiC devices
  • Network reachability checks
  • Debugging output collection
  • Basic error handling logic

This playbook serves as a baseline example for building more advanced health-check workflows.

Automation Architecture and Concepts

The Ansible environment in this project is designed to reflect real-world DataCenter automation practices.

Inventory Structure

The inventory is organized into logical groups:

• sonic_ssh – devices managed via SSH
• sonic_api – devices managed via RESTCONF
• switches – Leaf and Spine topology

This structure allows flexible targeting of automation tasks depending on the protocol and use case.

The tools provides a standardized approach to:

• Day 0 provisioning (initial setup)
• Day 1 configuration (service deployment)
• Repeatable and consistent automation workflows

It separates:

• Inventory (what to configure)
• Playbooks (how to configure)
• Virtual Environment (ansible-venv)

The project uses an isolated Python environment to:

• Avoid dependency conflicts
• Ensure consistent Ansible versions
• Provide a reproducible automation setup

The environment supports ZTP for automatic device onboarding.

This enables:

• Automatic configuration of new SONiC devices
• Reduced manual intervention
• Faster lab and production deployments

Do You have more questions?

If you have any questions, encounter issues, or if any part of the configuration is unclear, please contact STORDIS Technical Support.

Our team will be happy to assist you.

You can reach us via the support portal:

https://support.stordis.com/hc/en-us

For more free resources, visit: https://stordis.com/free-resources/