product
Application for evaluation machine
[SONiC Workshop Presentation Report] Pre-configuration verification using SONiC actual hardware and GNS3 SONiC VS ~Using a generated AI agent to support environment setup and verification~
This article is based on a presentation given at the SONiC workshop held on June 19, 2026.
The SONiC Workshop is an event aimed at fostering communication in Japanese about SONiC, an open-source NOS (Network Operating System).
Click here for details on SONiC Workshop Japan 2026.
In this session, Taro Sasaki, an engineer at the OpenNetworking Business Promotion Department of Macnica Finesse Company, introduced an initiative to improve construction and operational efficiency by using a SONiC VS (Virtual Switch) environment built on GNS3 as a "safety valve between the AI and the actual device" to mitigate the risks of configuration changes in the SONiC environment, allowing for reliable use even if the AI makes a configuration error.
If you would like to receive the presentation materials, please download them from the link below.
speaker
Taro Sasaki
Macnica, Inc. Macnica Finesse Company
Third Division, Open Networking Business Promotion Department
SONiC Support Engineer
A "three-layer model" for safely utilizing AI
The most important message in this lecture is, AI agent × SONiC VS × This is a three-layer model of the actual device.
In this model,
① AI Agent Ansible Playbook or VS/ Support for setting up the environment on actual hardware
② SONiC VS Freely test and debug in your environment.
③ Apply only verified settings to the actual device.
We will adopt this approach.
What is particularly important is, AI The goal is to absorb hallucination (misinformation) in a virtual environment.
For network operations AI When utilizing it, AI The phenomenon of hallucination, where plausible lies are told, poses a significant challenge in ensuring the security of network operations.
To solve these industry-wide challenges, the methods presented in this analysis can be utilized. AI The settings generated by Playbook Even if there is an error, first VS By performing operational checks in an environment, it is possible to prevent impact on the production network.
The key message of this presentation is: "Don't just blindly trust AI, use it to its fullest potential. Leave the verification of its accuracy to Ansible + VS." is.
Common challenges in network operations
Are you, the reader of this article, facing any of the following challenges in network operations?
1. Pre-verification of network configuration changes due to the addition of a new tenant.
In data centers, for new customers and new services VRF, VLAN The task of adding routing settings occurs frequently.
On the other hand, communication disruptions and service disruptions due to configuration errors must be avoided at all costs.
<Challenges>
• Risk of configuration changes in the production environment
- Insufficient testing equipment and testing time
2. Automation and verification of network design changes when adding GPU clusters.
AI Learning infrastructure and HPC In the environment, GPU Network configuration changes frequently occur when adding servers. This is especially true in multi-tenant environments. VRF or VLAN This will require the addition of [something] and changes to route control.
<Challenges>
- Request for infrastructure expansion in a short period of time
- Shortage of network personnel
AI Concerns about the reliability of the settings generated by [the system/tool].
3. Standardization of network change operations for multiple customers
SIer For network service providers, managing different network environments for each customer presents significant challenges in maintaining the quality of configuration changes and reducing the workload involved.
<Challenges>
• Different setup procedures for each customer
• Operation that relies on veterans
- Increased workload for reviews and verification
These issues ultimately lead to configuration errors, procedural mistakes, and the risk of failures in the production environment. The system we will introduce here aims to solve all of these problems at once.
Why GNS3 and SONiC VS?
First, let me explain why we're combining GNS3 and SONiC VS.
Advantages of GNS3
GNS3 (Graphical Network Simulator 3) is a tool for virtualizing and emulating network devices.
You can test network configurations using virtual routers and switches. By using GNS3, you can reproduce a topology equivalent to that of a real network and even perform connectivity tests.
<Download GNS3 >
The installer can be downloaded from the official GitHub repository below.
https://github.com/GNS3/gns3-gui/releases/tag/v2.2.54
Benefits of SONiC VS
On the other hand, SONiC VS has the following features:
- Allows for pre-verification without occupying the actual device.
・SONiC 's CLI can be used as is.
- By matching the HwSKU to the actual device, the port configuration can be standardized.
- Even if the AI generates incorrect settings, it will not affect the actual device.
- Bugs can be identified in VS and then applied to the actual device.
These advantages make it an ideal environment for configuration verification and automated testing.
Comparison of VS and actual hardware
So, how close is the VS configuration to the actual hardware?
The table below compares Visual Studio (VS) and a physical machine from the perspective of Docker containers.
In the Broadcom SONiC v4.5.1 environment, 20 Docker containers are common to both the physical machine and Visual Studio. The main functions of the control plane and application layer, such as FRR, LLDP, STP, SNMP, and Telemetry, are configured almost identically.
The differences mainly lie in ASIC-related components, and it can be used as a sufficient substitute for the actual hardware for configuration verification purposes.
architecture
From here on, we will present the results of the verification we conducted. First, let me introduce the overall structure.
The client PC shown above has the AI agent, SSH, and GNS3 client installed.
The server is in the middle, running SONiC VS v4.5.1 on a GNS3 server. The Ansible environment is also built on this server.
Below is the actual Edgecore AS7726-32X, running the same Broadcom SONiC v4.5.1 as VS. The key point is that the versions of the actual device and VS are the same, so the same Ansible Playbook works on both.
The operational setup prior to the changes, as confirmed by the verification, was a simple configuration with only VLAN 10 under the default VRF.
Here,
New VRF (Vrf_a)
VLAN20
This adds a configuration that prevents tenants from communicating with each other.
Verification flow
Actual machine and VS The verification using the following method 4 You can proceed step by step.
1. Obtain the actual device settings.
2. VS Reflected
3. VS Verify the changes above.
4. Apply the verified settings to the actual device.
At this time, VS The same applies to both the computer and the actual machine. Ansible Playbook In order to use, VS A key feature is that you can directly apply the results you've verified in the environment to the production environment.
Automation design with Ansible
Next, I will introduce the four types of Playbooks used in the Ansible design that supports the testing environment.
A Playbook consists of four types: "Sync," "Precheck," "Change," and "Test." Each has a clear role, ensuring safe and highly reproducible configuration changes.
Furthermore, the execution procedure is standardized using a Makefile, which helps prevent operational errors.
First, "Sync Playbook" synchronizes the settings of the actual device to SONiC VS.
It consists of two Play sessions: Play 1 retrieves the configuration file from the actual device, and Play 2 applies it to Visual Studio.
Only application layer settings such as VRF and VLAN are extracted using a whitelisting method and reflected in the VS environment.
This allows us to recreate a state close to that of the actual device in a virtual environment, laying the foundation for subsequent testing.
The following "Precheck Playbook" will function as a safety gate.
We directly access the SONiC CONFIG_DB (Redis) to check if the VRFs and VLANs we plan to add already exist.
In a real-world environment, rigorous checks prevent the application of settings under unexpected conditions, while in a Visual Studio environment, it can be used for reporting purposes. This design allows the same Playbook to be used in different ways depending on the application.
In the following "Change Playbook," we will actually perform the configuration changes.
The-c option of sonic-cli is used to split one command into one task. Furthermore, the scope of changes is minimized by not modifying the existing default VRF or VLAN10 at all, and only adding the necessary configurations. In addition, a mechanism is incorporated in which the Playbook itself verifies the changes by referencing CONFIG_DB again after the configuration is applied.
The final "Test Playbook" automates the process of verifying the operation after the settings have been applied.
By combining verification using the show command with checking the contents of CONFIG_DB, we can even check routing separation by VRF. Furthermore, we can automatically check whether VLAN10 is missing from the VRF table and whether VLAN20 exists on the tenant VRF side.
By executing these four Playbooks in order, you can automate a series of tasks including "reproducing the actual device settings," "preliminary checks," "setting changes," and "operation verification."
Here are the actual test results.
As intended, pings are successful only within the same tenant VRF, and communication across VRFs is blocked. This confirms that the routing isolation we designed is working correctly on the actual device. The results we verified in VS were reproduced exactly on the actual device.
This system allows for the secure verification of AI-generated playbooks and configurations, realizing an operational model of "verifying through the system rather than blindly trusting the AI."
More detailed information on the results of this verification can be downloaded here.
Utilization of Generative AI Agents
In this project, we utilized multiple generative AI services tailored to different applications.
Google Antigravity
It is used to support infrastructure construction, such as setting up a GNS3 environment and configuring SSH. The GNS3 setup, which is usually complicated and involves many steps, is guided by the AI.
Claude Code
It is used for setting up the Ansible environment, implementing Playbooks, and supporting debugging. The Playbooks introduced here were also generated by AI, and debugging progressed by feeding back the results of the operation verification in the VS environment.
Microsoft Copilot
It can be used to support presentation structuring and scenario creation.
Don't just trust AI, make full use of it.
Finally, what actually happened in this verification AI Examples of configuration errors due to hallucination, and even AI Here's why it can be useful.
The following errors were observed during this instance:
・SONiC VRF I don't understand the naming conventions. VRF Name suggestion
・Requirements for SONiC CIDR Proposal for subnet mask notation instead of notation.
However, all of these SONiC VS The issue was detected in the environment beforehand and did not affect the production environment.
This case is, VS but" AI This proves that it functions as a "safety valve" between the actual machine and the system. AI Even if a configuration error occurs, you can still use it with peace of mind.
Summary
In this presentation, we introduced a pre-configuration verification mechanism using GNS3 and SONiC VS, as well as practical approaches for safely utilizing generative AI.
especially,
GNS3 + SONiC VS can be used as an AI testing ground.
VS acts as a safety valve between the AI and the actual machine.
- By combining it with automation using Ansible, you can use AI with confidence.
This point is a valuable concept for many network operators.
Now, more than ever, as the use of generative AI accelerates, it's crucial to adopt an approach that goes beyond simply "believing" in AI and instead focuses on "verifying and fully utilizing its mechanisms."
The three-layer model utilizing SONiC VS provided a highly insightful and practical example.
To everyone who has read this article, let's safely conduct pre-verification using the three layers of AI agent x VS x actual device, and enjoy a Happy SONiC Life!
Inquiry
Macnica will deliver solutions that address the challenges of OpenNetworking and maximize customer benefits.
If you have any inquiries regarding SONiC, or any other Macnica OpenNetworking products such as white-Box switches, or if you require technical advice, please feel free to contact us using this form.
Related information
[Lecture Report Part 1] Broadcast Network Switch Hands-on Seminar: Learning Network Fundamentals and the Characteristics of Broadcast Networks with White Box Switches - Network Fundamentals
[Lecture Report Part 1] SONiC Hands-on Seminar: Learning the Basics of Open Network OS Operations with White Box Switches
SONiC Workshop: Asking a Generative AI About SONiC Source Code
Click here for list of materials
In addition to introducing products handled by Macnica,
We publish materials related to open networking, such as BGP cross network automatic construction files and network operation test evaluation reports.
Click here for details
Click here for the manufacturer's page.
Broadcom, Inc.
We are an industry leader in both semiconductor solutions and infrastructure software, and provide products in a wide range of areas including data centers, networks, broadband, wireless communications, storage, and security.
Edgecore Networks
We continue to be a pioneer in open networking by developing and selling products related to OpenNetworking/white Box switches.
IP Infusion
As a market leader among open networking providers, we provide reliable network solutions to over 600 customers, including carriers, service providers, and data centers.
Inquiry/Document request
In charge of Macnica Edgecore Networks
- TEL：045-470-9831
- E-mail：projectmonstar@macnica.co.jp
Weekdays: 9:00-17:00