Switch emulator construction method, device, computer equipment and program product

Abstract

Embodiments of the present application are applicable to the technical field of computers, and provide a switch simulator construction method and device, computer equipment and program product, the method comprising: obtaining a simulation configuration file of a target switch, the simulation configuration file comprising configuration information of a simulation switch, the configuration information comprising the number, type, connection relationship and initial configuration of the simulation switch; based on the configuration information, obtaining network transmission configuration of the target switch, the network transmission configuration comprising a data forwarding mode and a network protocol; creating a corresponding network namespace for the simulation switch, the network namespace being used to construct an execution environment corresponding to the simulation switch; based on a base image of the target switch, generating a plurality of simulation switches of the target switch under a plurality of different platforms in the network namespace, the plurality of simulation switches being configured based on the network transmission configuration. Through the above method, the use cost of the switch can be reduced.

Description

Technical Field

[0001] This application belongs to the field of data processing technology, and in particular relates to a method, apparatus, computer equipment and program product for constructing a switch emulator. Background Technology

[0002] With the development of network technology, switches, as core network devices, have become increasingly complex in function and employ a wide variety of protocols. In real-world network environments, physical switches are highly dependent on hardware, resulting in high costs, complex deployment and maintenance, and making them difficult to use on a large scale for teaching, testing, and research. Furthermore, physical switches face significant environmental limitations. They require dedicated server rooms, consume a lot of power, generate significant noise, and are difficult to deploy flexibly. Upgrades and iterations of physical switches are slow. Hardware update cycles are long, making it difficult to quickly adapt to new technologies and protocols. Physical switches also suffer from compatibility issues. Different manufacturers produce physical switches with significantly different configurations, inconsistent protocol implementations, and poor interoperability. Summary of the Invention

[0003] In view of this, embodiments of this application provide a method, apparatus, computer equipment, and program product for constructing a switch emulator, in order to reduce the cost of using switches.

[0004] The first aspect of this application provides a method for constructing a switch emulator, including: Obtain the simulation configuration file of the target switch. The simulation configuration file includes the configuration information of the simulation switch, including the number, type, connection relationship and initial configuration of the simulation switch. Based on the configuration information, obtain the network transmission configuration information of the target switch; A corresponding network namespace is created for the simulated switch. The network namespace is used to construct the execution environment corresponding to the simulated switch. The network namespace is configured according to the network transmission configuration information. Based on the base image of the target switch, multiple simulated switches of the target switch on multiple different platforms are generated in the network namespace.

[0005] In one possible implementation, the simulation configuration file is input by the user through a configuration entry point, which can be implemented through multiple different configuration interfaces.

[0006] In one possible implementation, the network transmission configuration includes a data forwarding method and a network protocol, and obtaining the network transmission configuration of the target switch based on the configuration information includes: The configuration information is parsed to obtain the network protocol and the data forwarding method, which includes physical address learning, virtual LAN processing, port status management, traffic control and link aggregation.

[0007] In one possible implementation, different data forwarding methods have corresponding software modules, and the data forwarding method is implemented by loading the software modules.

[0008] In one possible implementation, the network namespace has a list of network devices, a protocol stack, a routing table, network filtering constraints, sockets, and network status information, and each of the emulated switches has a corresponding network namespace.

[0009] In one possible implementation, the target switch has a unique corresponding base image, and the generation of multiple simulated switches of the target switch on multiple different platforms in the network namespace based on the base image of the target switch includes: Generate a simulation image corresponding to the base image according to the format of the target platform; Configure the corresponding virtual driver and description file for the simulation image to obtain the corresponding simulation switch.

[0010] In one possible implementation, the method further includes: Based on the status information of the target switch, the data forwarding mode of the simulated switch is updated. The status information includes port status, routing table information, and session data.

[0011] A second aspect of this application provides a switch emulator construction apparatus, including: The configuration acquisition module is used to acquire the simulation configuration file of the target switch. The simulation configuration file includes the configuration information of the simulation switch, including the number, type, connection relationship and initial configuration of the simulation switch. A communication transmission configuration module is used to obtain the network transmission configuration information of the target switch based on the configuration information. A network namespace creation module is used to create a corresponding network namespace for the simulated switch. The network namespace is used to construct the execution environment corresponding to the simulated switch. The network namespace is configured according to the network transmission configuration information. The simulated switch generation module is used to generate multiple simulated switches of the target switch on multiple different platforms in the network namespace based on the base image of the target switch.

[0012] A third aspect of this application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect above.

[0013] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect above.

[0014] A fifth aspect of this application provides a computer program product that, when run on a computer device, causes the computer device to perform the method described in the first aspect.

[0015] Compared with the prior art, the embodiments of this application have the following advantages: In this embodiment, when constructing a simulated switch, a simulation configuration file of the target switch can be obtained. The simulation configuration file includes the configuration information of the simulated switch, including the number, type, connection relationships, and initial configuration of the simulated switches. Based on the configuration information, a protocol stack corresponding to the deployment of the target switch is generated. A corresponding network namespace is created for the protocol stack, and the network namespace is used to construct the execution environment corresponding to the simulated switch. Based on the base image and configuration information of the target switch, multiple simulation images of the target switch on multiple different platforms are generated. In the network namespace, based on the multiple simulation images, multiple simulated switches corresponding to different platforms are generated. Applying the method in this embodiment, multiple simulation images of different virtual platforms can be converted from the base image, reducing development difficulty. Each switch can exist independently in its corresponding network namespace, thereby achieving lightweight, high-performance network isolation of the network namespace. This embodiment can decouple the hardware and software forwarding model, thereby abstracting the switch forwarding logic into a configurable software module, supporting flexible expansion and customization. This embodiment can provide a user configuration entry point, thereby supporting simulator cluster management, status monitoring, and fault injection. Constructing a simulated switch based on this embodiment can reduce the cost of using the switch. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0017] Figure 1 This is a flowchart illustrating the steps of a switch emulator construction method provided in an embodiment of this application; Figure 2 This is a schematic diagram of a switch emulator construction system provided in an embodiment of this application; Figure 3 This is a schematic diagram of a switch emulator construction device provided in an embodiment of this application; Figure 4 This is a schematic diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0018] In the following description, specific details such as particular system architectures and technologies are set forth for illustrative purposes and not for limiting purposes, in order to provide a thorough understanding of the embodiments of this application.

[0019] With the rapid development of network technology, switches, as core devices in the network architecture, are constantly expanding in function and becoming increasingly rich in protocol types, leading to continuously increasing demands on their performance, compatibility, and scalability. In practical applications, physical switches have many inherent drawbacks. On the one hand, they are highly dependent on hardware, have high procurement costs, and complex deployment and maintenance processes, making them difficult to apply on a large scale in scenarios such as teaching and training, product testing, and technology research and development. On the other hand, they face significant environmental limitations, relying on dedicated computer room environments, resulting in high power consumption, high operating noise, and insufficient deployment flexibility. Furthermore, physical switches have long upgrade and iteration cycles, making it difficult to quickly adapt to emerging new technologies and protocols. The configuration methods of devices from different manufacturers vary significantly, protocol implementation standards are not unified, and interoperability between devices is poor, further increasing the difficulty of network construction and maintenance. While existing network simulation tools can achieve basic network simulation functions, they still have significant shortcomings. They not only rely on device images provided by specific manufacturers, making it impossible to flexibly customize switch operating behavior according to actual needs, but also have low simulation accuracy, making it difficult to accurately reproduce the chip-level forwarding logic of switches. In addition, these tools do not support flexible deployment across multiple formats and platforms, have insufficient network isolation capabilities, and cannot stably build large-scale, high-density simulated network environments. Therefore, there is an urgent need to propose a method for building a switch simulator that can accurately simulate the forwarding logic of a switch, support multi-platform adaptation and deployment, and have good scalability, so as to solve various problems existing in the current technology and meet the network simulation needs in multiple scenarios.

[0020] The technical solution of this application will be described below through specific embodiments.

[0021] Reference Figure 1 The diagram illustrates a step-by-step flowchart of a switch emulator construction method provided in this application embodiment, which may specifically include the following steps: S101, Obtain the simulation configuration file of the target switch. The simulation configuration file includes the configuration information of the simulation switch, including the number, type, connection relationship and initial configuration of the simulation switch.

[0022] The execution subject of this embodiment can be a computer device, which can be a personal terminal, server, mobile terminal, tablet computer, etc. This application does not limit the specific type of computer device.

[0023] The simulation configuration file is entered by the user through a configuration entry point, which can be accessed through multiple different configuration interfaces.

[0024] Configuration entry points can include command-line interfaces, graphical interfaces, etc. For example, computer devices can provide a CLI (command-line interface) similar to that of commercial switches, supporting configuration and expert modes. Computer devices can also provide a web-based graphical interface, allowing users to visualize topology drag-and-drop, configure devices, and monitor real-time traffic graphs. Computer devices can provide a complete RESTful API (interface designed according to REST specifications), and all CLI and Web UI (Web User Interface) operations can be implemented through the API, facilitating integration with external automation systems (Ansible, Terraform, internal CI / CD platforms).

[0025] The above configuration information can be used to define the entire simulation network using a declarative YAML or JSON format (topology description language). The configuration information describes the number, type, interconnections, and initial configuration of all simulation switches. The orchestration engine can parse this configuration information, automatically create a complete simulation network environment within minutes by calling the underlying API, and automatically clean up after the experiment.

[0026] S102, Based on the configuration information, obtain the network transmission configuration information of the target switch.

[0027] The data forwarding methods described above can include data forwarding logic. The configuration of this logic can be achieved by loading kernel modules or efficient user-space polling libraries.

[0028] The configuration of data forwarding logic can include the configuration of the port state machine, which can accurately simulate the link state (UP / DOWN), negotiation mode (auto-negotiation, forced rate / duplex), and error counter of each physical port (corresponding to a veth endpoint).

[0029] The configuration of data forwarding logic can include MAC address learning and aging configuration to maintain the Software Forwarding Table (FIB). It supports static MAC configuration, dynamic learning, port-based MAC address limit, and configurable aging time.

[0030] The configuration of data forwarding logic can include a VLAN processing pipeline. The emulated switch can fully simulate the 802.1Q standard, including tag processing (receive direction: tagged / untagged / priority-tagged; transmit direction: tag / untag / pcp re-tagged), default VLAN, and VLAN filtering for access ports, trunk ports, and hybrid ports.

[0031] Furthermore, the data forwarding logic can include a Layer 2 forwarding domain system. It performs lookup-based forwarding based on the destination MAC address and VLAN ID, and supports flooding rules for broadcast, multicast, and unknown unicast frames.

[0032] In addition, advanced functional simulations are available. For example, Link Aggregation (LACP): Simulates the creation of link aggregation groups, member port management, and hash-based traffic allocation. Spanning Tree Protocol (STP / RSTP / MSTP): Runs a complete protocol state machine, calculates port roles and states, and blocks loop ports. Flow Control (QoS): Simulates traffic classification, tagging (DSCP, 802.1p), queue scheduling (SP, WRR), traffic shaping, and rate limiting based on port, VLAN, MAC, and IP. Access Control Lists (ACLs): Supports L2-L4 ACL rule matching and actions (allow, deny, redirect, log).

[0033] Computer devices can implement a series of standard, purely user-space network protocol stacks. For example: Layer 2 protocols: LLDP (Link Layer Discovery Protocol), LACP (Link Aggregation Control Protocol), and STP series protocols. Layer 3 protocols: A complete TCP / IP protocol stack, supporting static routing and dynamic routing protocols such as OSPFv2 / v3, BGP-4, and RIP. VRRP / VRRPv3 is supported for virtual router redundancy. Tunneling and overlay networks: Support for encapsulation and decapsulation of tunneling protocols such as VXLAN and GRE, simulating VTEP functionality. Management protocols: Implementation of SSHv2 server, SNMP agent (supporting v2c / v3), and NETCONF / YANG model, providing a management experience consistent with real devices.

[0034] In addition, the computer device can parse user configurations (via CLI or API) and distribute the configurations to the forwarding logic layer and protocol stack layer; collect status information from each layer (port statistics, routing tables, session counts, etc.); process events reported by the protocol stack layer (such as BGP neighbor status changes), and update the forwarding layer's policies accordingly. This layer adopts a microservice design, and each protocol module can be started, stopped, and upgraded independently.

[0035] S103, create a corresponding network namespace for the emulated switch. The network namespace is used to construct the execution environment corresponding to the emulated switch. The network namespace is configured according to the network transmission configuration information.

[0036] Each network namespace has its own independent list of network devices, IPv4 / IPv6 protocol stack, routing table, iptables / nftables rules, sockets, and network state information. ARP entries in instance A will not be leaked to instance B or the host machine.

[0037] Each service port of the simulated switch is implemented as one end of a vethpair device (named, for example, eth0), which resides in the instance's unique network namespace; the other end (named, for example, veth-...) <instance-id>-0) remains on the host machine or in a dedicated "topology connection" namespace for use with ports or external networks of other instances. This mechanism provides inter-process communication performance close to physical line speed.

[0038] By combining LinuxControlGroups (cgroups), independent forwarding and bandwidth limits can be imposed on each simulation instance within a network namespace, enabling fine-grained resource management and fair scheduling.

[0039] S104, Based on the base image of the target switch, generate multiple simulated switches of the target switch on multiple different platforms in the network namespace.

[0040] This embodiment provides a unified, minimal base operating system image (in .bin format), which includes the core simulation engine and minimal dependency libraries.

[0041] Depending on the target platform, the appropriate tools can be invoked. For example, to generate a .qcow2 format file for QEMU / KVM, the tool will create a blank qcow2 disk, write the .bin image, and automatically configure metadata including optimized settings such as the virtio-net driver.

[0042] Tools can be used for driver injection and configuration adaptation. For example, for VMware platforms (target formats .vmdk or .ova), the tool automatically injects VMwareTools compatible drivers and vmxnet3 virtual network adapter driver configuration files. For Hyper-V (.vhdx), it injects Linux integration service drivers. For VirtualBox (.vdi), it injects VirtualBoxGuestAdditions drivers. For container platforms (Docker images outputting as .tar.gz), it builds a lightweight container image containing emulator binaries and necessary capabilities configurations using a Dockerfile.

[0043] Then, description files conforming to the specifications of each platform are automatically generated, such as OVF descriptor (for OVA), Vagrantfile (for VagrantBox), and KubernetesYAML manifest (for container deployment).

[0044] Based on the base image, simulation images for different platforms can be obtained. For example, virtual machine disk formats suitable for QEMU, VMware, Hyper-V, and VirtualBox can be generated, along with complete OVA / OVF packages and container images that can be directly imported into Docker or Kubernetes. This enables "build once, run anywhere," solving the fragmentation problem of multi-platform deployment.

[0045] Each emulated switch can have a corresponding network namespace. A network namespace can contain a list of network devices, protocol stacks, routing tables, network filtering constraints, sockets, and network status information.

[0046] In this embodiment, multiple simulation images for different virtual platforms can be converted from the base image, reducing development difficulty. Each switch can exist independently in its corresponding network namespace, thereby achieving lightweight, high-performance network isolation. This embodiment decouples the hardware and software forwarding model, abstracting the switch forwarding logic into a configurable software module that supports flexible expansion and customization. This embodiment provides a user configuration entry point, enabling emulator cluster management, status monitoring, and fault injection.

[0047] Reference Figure 2 The diagram illustrates a switch emulator construction system provided in an embodiment of this application. Figure 2 As shown, the external interface layer, multi-platform runtime adaptation layer, network kernel space isolation layer, protocol stack control and forwarding layer, and simulator management and control layer work together to achieve high-precision simulation of switch forwarding logic, multi-platform adaptation and deployment, kernel-level network isolation, complete simulation of protocol stack, and centralized unified management and control.

[0048] The external interface layer provides physical and virtual ports for the simulation switch to interact with external networks or other simulation devices, including switch ports and packet sending interfaces. These serve as access points and forwarding exits for data packets entering the simulation system, meeting the port access requirements of different virtualization platforms.

[0049] The multi-platform runtime adaptation layer is an adaptation layer between the simulation system and the underlying virtualization and container platforms. It enables cross-platform deployment capabilities of building once and running on multiple platforms. It can convert and adapt a unified base image into an image format that can be recognized by various virtualization platforms and container platforms, and supports direct deployment and operation on various virtualization platforms and container platforms, thus solving the fragmentation problem of multi-platform deployment.

[0050] The network kernel space isolation layer serves as the foundational support layer for achieving high-performance, high-density simulation. By creating an independent network namespace for each simulated switch instance, each instance possesses independent network devices, protocol stacks, routing tables, firewall rules, and network status information, ensuring complete isolation of network data between different simulated switch instances and preventing interference. High-speed data transmission channels are established between simulated switch instances via virtual interfaces, and cross-namespace packet forwarding is accomplished using a mirrored packet mapping mechanism. Simultaneously, a resource management mechanism independently limits the forwarding capabilities and bandwidth of each simulated switch instance, ensuring stability and fair resource allocation in the high-density simulation environment.

[0051] The protocol stack control and forwarding layer is the core functional layer of the simulated switch, responsible for simulating the working mechanisms of the control plane and data plane of a real switch. The control plane runs various standard network protocol stacks, including Layer 2 protocols, Layer 3 protocols, tunneling protocols, and management protocols, performing functions such as protocol negotiation, route calculation, topology maintenance, and device management. The data plane simulates the forwarding behavior of a real switch chip, including port status management, media access control address learning and aging, virtual LAN processing, Layer 2 forwarding decisions, link aggregation, spanning tree protocol, flow control, and access control lists. It also maintains the forwarding database, routing table, and virtual extensible LAN forwarding table, performing packet reception, parsing, forwarding, and filtering operations, achieving forwarding logic consistent with a real switch.

[0052] The simulator management and control layer serves as the global control center for the entire simulation system. It is responsible for the unified management of various network namespaces and protocol stack instances, supports the issuance of configuration commands, device management, status monitoring, fault handling, and lifecycle management, and provides multiple interface access capabilities. It can be operated and managed through command line, graphical interface, program interface, etc., to realize the rapid construction, batch configuration, real-time monitoring, and automatic cleanup of simulation networks, and support the efficient operation and maintenance of large-scale simulation network environments.

[0053] The external interface layer, multi-platform runtime adaptation layer, network kernel space isolation layer, protocol stack control and forwarding layer, and simulator management and control layer work together to achieve high-precision forwarding simulation, multi-platform deployment, kernel-level isolation, full protocol stack simulation and unified management and control, meeting the needs of large-scale, high-fidelity network simulation for teaching, research and development, testing, operation and maintenance drills, security simulation and other purposes.

[0054] The external interface layer is located at the bottom layer of the architecture. It is the entry and exit point for data interaction and signal transmission between the simulation system and external networks, real devices, and simulation nodes. It undertakes functions such as message sending and receiving, link awareness, port configuration, and signal conversion. It is a key layer connecting the virtual network and the external environment, and directly determines the stability, compatibility, and bandwidth performance of the simulation system's external interaction.

[0055] The external interface layer includes the SWP (switchport) series of port layers, packet sending interface layer, port management layer, physical signal adaptation layer, link status detection layer, port parameter configuration layer, and data transmission and reception buffer layer.

[0056] The SWP series port layer provides standardized virtual ports for emulated switches, replicating the port form and function of real switches. It includes SWP1, SWP2 to SWPN, and can be expanded as needed. The SWP port layer supports Ethernet frame transmission and reception, is compatible with 10Mbps, 100Mbps, 1Gbps, and 10Gbps speeds, and supports full-duplex / half-duplex switching and MDI / MDI. The X-axis automatically flips over, allowing connection to interfaces of real network cards, virtual network cards, physical switches, routers, servers, and other devices, enabling seamless integration between the simulated network and the external network. The SWP port layer employs virtualized hardware abstraction technology to simulate port registers, status registers, rate control registers, and flow control registers. It supports dynamic port UP / DOWN switching, rate negotiation, flow control, VLAN (Virtual Local Area Network) binding, MAC (Media Access Control) address learning, port mirroring, rate limiting, storm suppression, and other real port functions, ensuring behavior completely consistent with a real switch.

[0057] The packet sending interface layer is adapted for Hyper. A dedicated interface layer for V (Microsoft Virtualization Platform) to solve Hyper-V. Addressing issues such as incompatibility between Hyper-V virtual network architecture and standard Ethernet ports, format differences, and adaptation limitations, ensuring Hyper-V's security. Stable transmission and reception in a Hyper environment. Packet sending interface layer deeply adapted to Hyper. Virtual switches, virtual network interface cards, and VLAN isolation mechanisms support packet encapsulation, parsing, forwarding, and decapsulation, and are compatible with Hyper-V. V-bandwidth management, security isolation, and QoS (Quality of Service) control. The packet sending interface layer functionality is consistent with the SWP port layer; only the underlying driver and transport protocol are specific to Hyper. V-customized optimization eliminates platform barriers and expands deployment scope.

[0058] The port management layer is responsible for all port initialization, resource allocation, status monitoring, fault detection, configuration distribution, resource reclamation, and lifecycle management. It supports dynamic port expansion and is suitable for scenarios such as small-scale teaching, medium-scale testing, and large-scale data centers, supporting the concurrent operation of thousands of ports. The port management layer collects port status, speed, traffic, error packets, packet loss, and cache utilization in real time, displays the data visually and issues alerts, supports fault location and isolation, and ensures continuous interaction.

[0059] The physical signal adaptation layer converts virtual port signals to real physical signals, resolving differences in signal formats, electrical characteristics, and transmission protocols between virtual and physical environments. This ensures that virtual port signals can be recognized by real devices, and real device signals can be processed by virtual ports. The adaptation layer supports electrical ports, optical ports, Fibre Channel, and virtual network signals, performing level conversion, impedance matching, timing calibration, encoding / decoding, and format conversion. It is compatible with standards such as IEEE 802.3, IEEE 802.1Q, and IEEE 802.1p, eliminating barriers to virtual-physical interaction.

[0060] The link state detection layer monitors port link UP / DOWN, negotiation results, connectivity, latency, jitter, packet loss rate, and error rate in real time. It employs ARP (Address Resolution Protocol) probing, ICMP (Internet Control Message Protocol) ping, LLDP (Link Layer Discovery Protocol) interaction, physical signal detection, and virtual connection detection to accurately detect link interruptions, faults, quality degradation, and negotiation failures. It triggers alarms and reports them to the simulator management and control layer, supporting link switching, traffic scheduling, and fault diagnosis to reduce the impact of faults.

[0061] The port parameter configuration layer provides static, dynamic, batch, and template configuration capabilities, covering basic parameters, protocol parameters, traffic parameters, security parameters, QoS parameters, and advanced function parameters. Basic parameters include name, number, rate, duplex, status, and MDI / MDI. X. Description; Protocol parameters include VLAN, MAC, ARP, LLDP, STP (Spanning Tree Protocol), and LACP (Link Aggregation Control Protocol); Traffic parameters include bandwidth, rate limiting, storm suppression, statistics, and mirroring; Security parameters include MAC filtering, ARP anti-spoofing, DHCP anti-spoofing, and ACL (Access Control List); QoS parameters include priority, queue scheduling, bandwidth allocation, marking, and congestion control; Advanced parameters include aggregation, redundancy, virtualization, acceleration, and cache size. The configuration layer supports real-time application, save-and-load, backup and restore, access control, and batch deployment. Configuration is available via CLI (Command Line Interface), WebUI (Web User Interface), and RESTful API, adapting to complex and refined needs.

[0062] The data transceiver caching layer provides message caching, queue management, traffic scheduling, and congestion control to resolve issues such as mismatched transmit and receive rates, sudden surges, latency jitter, and congestion, ensuring orderly, complete, stable, and efficient transmission. The caching layer employs multi-level caching: input, output, high-priority, low-priority, and emergency caching, with dynamically configurable capacity supporting tens of gigabytes of cache to meet large-scale high-concurrency demands. Scheduling algorithms include SP, WRR, WFQ, and DRR, prioritizing control, management, and critical business messages, allocating resources rationally, and preventing low-priority traffic from preempting. The caching layer monitors occupancy, queue length, queuing latency, and overflow counts, providing congestion warnings and implementing scheduling strategies, rate limiting, and dropping low-priority messages to prevent overflow and packet loss. Read / write latency is at the microsecond level, improving transmission efficiency.

[0063] The multi-platform runtime adaptation layer, located above the external interface layer, serves as a bridge between the simulation system and the underlying virtualization and container platforms. It enables a single build for multi-platform operation, supporting QEMU (QuickEmulator), VMware (Virtualization Platform), Docker (Container Engine), and Hyper-V. V-deployment solves the problem of cross-platform fragmentation.

[0064] The adaptation layer uses a unified base image (.bin binary image, containing the simulation core engine and minimal dependency libraries) as its source, and completes format conversion, driver injection, and metadata generation through an automated conversion pipeline. The input is a single .bin image; processing consists of three steps: format recognition and packaging, creating a blank disk according to the target platform and writing it to the image, and configuring virtio. Optimize metadata such as .NET drivers; driver injection and adaptation, VMware injection of vmxnet3 drivers and VMware Tools, Hyper-Hyper Injecting Linux integration service drivers into VirtualBox, injecting enhanced drivers into VirtualBox, and building lightweight images with capabilities configured based on Dockerfiles using Dockerfiles; metadata generation automatically generates OVF, Vagrantfile, and KubernetesYAML. Outputs are .qcow2, .vmdk, .vhdx, .vdi, .ova, and .tar.gz images, adapting to mainstream platforms, enabling a single build for multiple platforms, reducing maintenance costs and improving delivery efficiency.

[0065] The network kernel space isolation layer is located above the multi-platform runtime adaptation layer and is the foundation of high-density, high-stability simulation. It achieves strong instance-level isolation through Linux network namespaces. Each simulated switch instance has an independent network space, namely network space 1 and network space 2, with independent network devices, protocol stacks, routing tables, iptables / nftables, sockets, network status, and ARP entries are not leaked and do not interfere with each other.

[0066] Instances establish high-speed channels through vethpairs (virtual Ethernet interface pairs, labeled CPU ports in the diagram). One end resides in an independent namespace (eth0), while the other remains on the host machine or in the topology namespace. Mirrored data packets are forwarded across these namespaces at near-physical line speed. Combined with cgroups (ControlGroups), independent forwarding capabilities, bandwidth limits, and CPU / memory quotas are implemented to ensure fair scheduling and stable operation in high-density scenarios.

[0067] The protocol stack control and forwarding layer is located above the network kernel space isolation layer. It is the core of the simulated switch, coordinating the control plane and data plane to simulate the forwarding and protocol processing of a real switch.

[0068] The protocol stack layer includes Protocol Stack 1 and Protocol Stack 2. User space implements Layer 2, Layer 3, tunneling, and management protocols: LLDP, LACP, STP / RSTP / MSTP; OSPF (Open Shortest Path First), BGP (Border Gateway Protocol), VRRP (Virtual Router Redundancy Protocol); VXLAN (Virtual Extensible Local Area Network), GRE (Generic Routing Encapsulation); SSHv2, SNMP, NETCONF / YANG, providing a consistent experience with real device management.

[0069] The forwarding layer simulates ASIC (Application Specific Integrated Circuit) behavior. The kernel implements port state machines, MAC learning and aging, VLAN pipelines, Layer 2 forwarding decisions, LACP, STP, QoS, and ACLs. It maintains the FDB (Forwarding Database), route table, and VXLAN forwarding table, and performs MAC learning, VLAN tag processing, ACL filtering, and traffic scheduling. The control plane updates policies based on protocol events and generates tap (virtual network terminal) devices, achieving chip-level forwarding simulation.

[0070] The simulator management and control layer is located at the top level and serves as the global control center. It uniformly manages the network space, protocol stack, and simulation instances, and supports CLI command issuance, device configuration, status monitoring, and lifecycle management.

[0071] Multiple interface access: CLI compatible with commercial switches, including configuration / expert mode; WebUI supports topology drag and drop, configuration, and real-time traffic monitoring; RESTful API covers all functions, connecting to Ansible, Terraform, CI / CD (Continuous Integration / Continuous Deployment), and is suitable for manual, educational, and automated testing.

[0072] Topology description and orchestration: YAML / JSON declarative files define the number, type, connection, and initial configuration of devices; the orchestration engine parses and calls the API, enabling batch deployment, configuration, monitoring, and automatic cleanup within minutes, supporting rapid delivery and reuse of large-scale simulations.

[0073] It should be noted that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0074] Reference Figure 3 The diagram illustrates a switch emulator construction device according to an embodiment of this application, which may specifically include a configuration acquisition module 31, a communication transmission configuration module 32, a network namespace establishment module 33, and a simulated switch generation module 34, wherein: The configuration acquisition module 31 is used to acquire the simulation configuration file of the target switch. The simulation configuration file includes the configuration information of the simulation switch, including the number, type, connection relationship and initial configuration of the simulation switch. The communication transmission configuration module 32 is used to obtain the network transmission configuration information of the target switch based on the configuration information. The network namespace creation module 33 is used to create a corresponding network namespace for the simulated switch. The network namespace is used to construct the execution environment corresponding to the simulated switch. The network namespace is configured according to the network transmission configuration information. The emulation switch generation module 34 is used to generate multiple emulation switches of the target switch on multiple different platforms in the network namespace based on the base image of the target switch.

[0075] In one possible implementation, the simulation configuration file is input by the user through a configuration entry point, which can be implemented through multiple different configuration interfaces.

[0076] In one possible implementation, the network transmission configuration includes a data forwarding method and a network protocol, and obtaining the network transmission configuration of the target switch based on the configuration information includes: The configuration information is parsed to obtain the network protocol and the data forwarding method, which includes physical address learning, virtual LAN processing, port status management, traffic control and link aggregation.

[0077] In one possible implementation, different data forwarding methods have corresponding software modules, and the data forwarding method is implemented by loading the software modules.

[0078] In one possible implementation, the network namespace has a list of network devices, a protocol stack, a routing table, network filtering constraints, sockets, and network status information, and each of the emulated switches has a corresponding network namespace.

[0079] In one possible implementation, the target switch has a unique corresponding base image, and the generation of multiple simulated switches of the target switch on multiple different platforms in the network namespace based on the base image of the target switch includes: Generate a simulation image corresponding to the base image according to the format of the target platform; Configure the corresponding virtual driver and description file for the simulation image to obtain the corresponding simulation switch.

[0080] In one possible implementation, the method further includes: Based on the status information of the target switch, the data forwarding mode of the simulated switch is updated. The status information includes port status, routing table information, and session data.

[0081] Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 4 As shown, the computer device 4 in this embodiment includes: at least one processor 40 ( Figure 4 (Only one is shown in the diagram), memory 41, and computer program 42 stored in said memory 41 and executable on said at least one processor 40, which, when executed, implements the steps in any of the above method embodiments.

[0082] The computer device 4 can be a desktop computer, laptop, handheld computer, or cloud computing device, etc. This computer device may include, but is not limited to, a processor 40 and a memory 41. Those skilled in the art will understand that... Figure 4 The computer device 4 is merely an example and does not constitute a limitation on the computer device 4. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0083] The processor 40 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0084] In some embodiments, the memory 41 may be an internal storage unit of the computer device 4, such as a hard disk or memory of the computer device 4. In other embodiments, the memory 41 may be an external storage device of the computer device 4, such as a plug-in hard disk, SmartMediaCard (SMC), SecureDigital (SD) card, or FlashCard equipped on the computer device 4. Furthermore, the memory 41 may include both internal and external storage units of the computer device 4. The memory 41 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 41 can also be used to temporarily store data that has been output or will be output.

[0085] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the various method embodiments above.

[0086] This application provides a computer program product that, when run on a computer device, enables the computer device to perform the steps described in the above-described method embodiments.

[0087] The embodiments described above are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for constructing a switch emulator, characterized in that, include: Obtain the simulation configuration file of the target switch. The simulation configuration file includes the configuration information of the simulation switch, including the number, type, connection relationship and initial configuration of the simulation switch. Based on the configuration information, obtain the network transmission configuration information of the target switch; A corresponding network namespace is created for the simulated switch. The network namespace is used to construct the execution environment corresponding to the simulated switch. The network namespace is configured according to the network transmission configuration information. Based on the base image of the target switch, multiple simulated switches of the target switch on multiple different platforms are generated in the network namespace.

2. The method of claim 1, wherein, The simulation configuration file is input by the user through a configuration entry point, which can be implemented through multiple different configuration interfaces.

3. The method of claim 1, wherein, The network transmission configuration includes data forwarding methods and network protocols, the base Based on the configuration information, obtain the network transmission configuration of the target switch, including: The configuration information is parsed to obtain the network protocol and the data forwarding method, which includes physical address learning, virtual LAN processing, port status management, traffic control and link aggregation.

4. The method of claim 1, wherein, Different data forwarding methods have corresponding software modules, and the data forwarding method is implemented by loading the software module.

5. The method as described in claim 1, characterized in that, The network namespace contains a list of network devices, a protocol stack, a routing table, network filtering constraints, sockets, and network status information. Each of the simulated switches has a corresponding network namespace.

6. The method according to any one of claims 1-5, characterized in that, The target switch has a unique corresponding base image. Based on the base image of the target switch, multiple simulated switches of the target switch are generated in the network namespace on multiple different platforms, including: Generate a simulation image corresponding to the base image according to the format of the target platform; Configure the corresponding virtual driver and description file for the simulation image to obtain the corresponding simulation switch.

7. The method as described in claim 6, characterized in that, The method further includes: Based on the status information of the target switch, the data forwarding mode of the simulated switch is updated. The status information includes port status, routing table information, and session data.

8. A device for constructing a switch emulator, characterized in that, include: The configuration acquisition module is used to acquire the simulation configuration file of the target switch. The simulation configuration file includes the configuration information of the simulation switch, including the number, type, connection relationship and initial configuration of the simulation switch. A communication transmission configuration module is used to obtain the network transmission configuration information of the target switch based on the configuration information. A network namespace creation module is used to create a corresponding network namespace for the simulated switch. The network namespace is used to construct the execution environment corresponding to the simulated switch. The network namespace is configured according to the network transmission configuration information. The simulated switch generation module is used to generate multiple simulated switches of the target switch on multiple different platforms in the network namespace based on the base image of the target switch.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1-7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-7.

Images