A virtual network system, method and electronic device

Abstract

The application discloses a virtual network system, method and electronic equipment, and relates to the technical field of computers. Since a first virtual Ethernet module is arranged in a baseboard management controller and a second virtual Ethernet module is arranged in an internal device, the first virtual Ethernet module and the second virtual Ethernet module can perform corresponding protocol conversion on data to be transmitted or received before the data is transmitted through a non-Ethernet link or after the data is received, so as to convert Ethernet data into non-Ethernet data or convert non-Ethernet data into Ethernet data. Therefore, even if the baseboard management controller and the internal device are connected through a non-Ethernet link, application software configured in the baseboard management controller and the internal device can normally use Ethernet data as communication data, without the need of redeveloping the application software, so that the development cost of the application software is reduced, and subsequent maintenance and management are facilitated.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a virtual network system, method and electronic device. Background Technology

[0002] Currently, the Baseboard Management Controller (BMC) of computing devices such as servers is generally connected to internal devices such as graphics cards, smart network cards, and servers via non-Ethernet links. However, current application software typically uses Ethernet data for communication. Therefore, how to enable the BMC to transmit application software communication data with graphics cards, smart network cards, and servers has become a key research topic.

[0003] In related technologies, application software is often redeveloped based on the link type between the BMC and the graphics card, smart network card, and server, which increases the development cost of the application software. Summary of the Invention

[0004] This application provides a virtual network system, method, and electronic device to at least address the problem of increased application software development costs in related technologies.

[0005] This application provides a virtual network system, including: a baseboard management controller and at least one internal device, wherein the baseboard management controller and the internal device are connected via a non-Ethernet link, the baseboard management controller is provided with a first virtual Ethernet module, and the internal device is provided with a second virtual Ethernet module; The baseboard management controller is used to convert Ethernet data into corresponding non-Ethernet data based on the protocol type of the non-Ethernet link, according to the first virtual Ethernet module, when Ethernet data is to be transmitted to the internal device, and transmit the non-Ethernet data to the internal device through the non-Ethernet link. The internal device is used to convert non-Ethernet data into corresponding Ethernet data based on the protocol type of the non-Ethernet link when non-Ethernet data is received through a non-Ethernet link, using a second virtual Ethernet module.

[0006] This application also provides a virtual network method, applied to any of the above-mentioned virtual network systems, the method comprising: When the control board management controller is about to transmit Ethernet data to internal devices, it converts the Ethernet data into the corresponding non-Ethernet data based on the first virtual Ethernet module and according to the protocol type of the non-Ethernet link. Transmit non-Ethernet data to internal devices via a non-Ethernet link; When the internal control device receives non-Ethernet data through a non-Ethernet link, it converts the non-Ethernet data into corresponding Ethernet data based on the protocol type of the non-Ethernet link using the second virtual Ethernet module.

[0007] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described virtual network methods when executing the computer program.

[0008] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described virtual network methods.

[0009] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described virtual network methods.

[0010] Through this application, since a first virtual Ethernet module is set in the baseboard management controller and a second virtual Ethernet module is set in the internal device, the first virtual Ethernet module and the second virtual Ethernet module can perform corresponding protocol conversion on the data to be transmitted or received before transmission through a non-Ethernet link or after receiving data, so as to convert Ethernet data into non-Ethernet data or non-Ethernet data into Ethernet data. Therefore, even if the baseboard management controller and the internal device are connected through a non-Ethernet link, the application software configured in the baseboard management controller and the internal device can use Ethernet data as communication data normally without redeveloping the application software, reducing the development cost of the application software, and facilitating subsequent maintenance and management. Attached Figure Description

[0011] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of the interaction process of the virtual network system provided in the embodiments of this application; Figure 2 A schematic diagram illustrating the data conversion process of an exemplary first virtual Ethernet module provided in this application embodiment; Figure 3 This is a schematic diagram of the structure of the virtual network system provided in the embodiments of this application; Figure 4 This application provides an exemplary schematic diagram of a target internal device access process. Figure 5 A flowchart illustrating the virtual network method provided in this application embodiment; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0014] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0015] Internal devices such as graphics cards and smart network cards are collectively referred to as Service Management Controllers (SMCs). The server-side is also called the Operating System (OS). The SMC and BMC are connected via the Intelligent Platform Management Bus (IPMB), while the OS and BMC are connected via the Keyboard Controller Style (KCS). IPMB and KCS are dedicated link technologies with limited application scope. While IPMB and KCS are commonly used links in the server field and offer stable performance, their significant drawback is their inability to transmit Ethernet data. However, Ethernet is the foundation for many general-purpose software applications, necessitating the development of dedicated software for the BMC and its internal components, which is inconvenient for maintenance and management personnel. To address the aforementioned technical problems, this application provides a virtual network system, including: a baseboard management controller and at least one internal device. The baseboard management controller and the internal device are connected via a non-Ethernet link. The baseboard management controller is equipped with a first virtual Ethernet module, and the internal device is equipped with a second virtual Ethernet module. Because the baseboard management controller has a first virtual Ethernet module and the internal device has a second virtual Ethernet module, these modules can perform corresponding protocol conversions on the data to be transmitted or received before transmission via the non-Ethernet link or after data reception. This allows for the conversion of Ethernet data to non-Ethernet data or vice versa. Therefore, even if the baseboard management controller and the internal device are connected via a non-Ethernet link, the application software configured in both the baseboard management controller and the internal device can still use Ethernet data for communication without requiring redevelopment of the application software. This reduces application software development costs and facilitates subsequent maintenance and management.

[0016] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0017] This application provides a virtual network system that enables application software configured in the baseboard management controller and internal devices to communicate normally using Ethernet data without requiring the application software to be redeveloped. Figure 1 The diagram shown is an interactive flow diagram of a virtual network system provided in an embodiment of this application. The system includes: a baseboard management controller and at least one internal device. The baseboard management controller and the internal device are connected via a non-Ethernet link. The baseboard management controller is provided with a first virtual Ethernet module, and the internal device is provided with a second virtual Ethernet module.

[0018] The baseboard management controller is used to convert Ethernet data into corresponding non-Ethernet data according to the protocol type of the non-Ethernet link based on the first virtual Ethernet module when Ethernet data is to be transmitted to the internal device, and transmit the non-Ethernet data to the internal device through the non-Ethernet link; the internal device is used to convert the non-Ethernet data into corresponding Ethernet data according to the protocol type of the non-Ethernet link based on the second virtual Ethernet module when it receives non-Ethernet data through the non-Ethernet link.

[0019] It should be noted that non-Ethernet links include at least IPMB links and KCS links, and internal devices include at least graphics cards, smart network cards, and servers. The baseboard management controller (BMC) specifies a protocol type for each non-Ethernet link corresponding to a first virtual Ethernet module. For example, the first virtual Ethernet module corresponding to an IPMB link can be called lan-on-ipmb, and the first virtual Ethernet module corresponding to a KCS link can be called lan-on-kcs. The virtual Ethernet module is a driver running on the BMC and the operating system of the internal devices, used to virtualize a standard Ethernet interface.

[0020] Specifically, during runtime, applications on the BMC generate Ethernet data (such as HTTP requests) and prepare to send them to internal devices. At this time, the first virtual Ethernet module in the BMC parses the received data packets (Ethernet data) according to the Ethernet format, extracts the target data content, and repackages the target data content into non-Ethernet data conforming to the dedicated link standard according to the protocol type of the currently used non-Ethernet link (such as IPMB or KCS message format). This repackaged data is then sent to the internal device via the existing non-Ethernet link. After the internal device receives the non-Ethernet data via the non-Ethernet link, the second virtual Ethernet module in the internal device parses the data according to the non-Ethernet link protocol, extracts the target data content, repackages the target data content into a standard Ethernet data packet, and submits the Ethernet data packet to the network protocol stack on the internal device's operating system. This allows it to be normally received and processed by upper-layer Ethernet-based applications.

[0021] Based on the above embodiments, as an implementable approach, in one embodiment, the first virtual Ethernet module is used to establish a first virtual Ethernet interface on the baseboard management controller that is bound to a non-Ethernet link interface, and the functional type of the first virtual Ethernet interface is determined according to the protocol type of the non-Ethernet link.

[0022] Specifically, when Ethernet data is to be transmitted to an internal device, the baseboard management controller transmits the Ethernet data to the first virtual Ethernet interface, parses the Ethernet data according to the Ethernet format based on the first virtual Ethernet interface to obtain the target data content, and encapsulates the target data content into non-Ethernet data according to the function type.

[0023] It should be noted that the first virtual Ethernet interface is the standard Ethernet interface virtualized by the first virtual Ethernet module, and its function types include IPMB and KCS.

[0024] Specifically, such as Figure 2The diagram illustrates an exemplary data conversion process of a first virtual Ethernet module provided in this application embodiment. Taking lan-on-ipmb as an example, the first virtual Ethernet interface it establishes has an IPMB function type. When the first virtual Ethernet module starts running, it establishes this first virtual Ethernet interface, whose function type is IPMB and is bound to an IPMB interface (a non-Ethernet link interface). After initialization, if the corresponding Ethernet interface receives a packet, it parses the data according to the Ethernet format, removes invalid header data, extracts only the original data (target data content), and then encapsulates the original data into an IPMB packet (non-Ethernet data) according to the IPMB format and sends it out from the corresponding IPMB interface. If the IPMB interface receives an IPMB packet, it parses the data according to the IPMB format, removes invalid header data, extracts only the original data, and then encapsulates the original data into an Ethernet packet according to the Ethernet format and sends it out from the corresponding first virtual Ethernet interface. lan-on-ipmb is essentially a translator between IPMB data and Ethernet data.

[0025] Based on the above embodiments, as one possible implementation, in one embodiment, the internal device is further configured to: When Ethernet data is to be transmitted to the baseboard management controller, the Ethernet data is converted into corresponding non-Ethernet data according to the protocol type of the non-Ethernet link based on the second virtual Ethernet module, and the non-Ethernet data is transmitted to the baseboard management controller through the non-Ethernet link.

[0026] Specifically, after the software application on the internal device generates Ethernet data to report status information to the BMC or perform other query operations, the second virtual Ethernet interface created by the second virtual Ethernet module parses the data according to the Ethernet protocol format, strips the header information, extracts the core target data content, and then repackages the target data into non-Ethernet data that conforms to the non-Ethernet link standard according to the protocol type of the non-Ethernet link it is bound to. Finally, it is transmitted to the baseboard management controller through the non-Ethernet link (IPMB bus or KCS interface).

[0027] Based on the above embodiments, as one implementable approach, in one embodiment, the substrate management controller includes a bridging module, which is used for: When the first virtual Ethernet module provided by the baseboard management controller is not unique, the first virtual Ethernet interfaces established by multiple first virtual Ethernet modules are bridged to establish an Ethernet bridge interface, so that the first virtual Ethernet interfaces can be interconnected.

[0028] Internal devices corresponding to different protocol types establish communication through the Ethernet bridging interface.

[0029] Specifically, the lan-on-ipmb module on the BMC creates a virtual Ethernet interface eth1 of type IPMB; the lan-on-kcs module creates a virtual Ethernet interface eth2 of type KCS. After these two modules are initialized, an Ethernet bridge interface br0 can be created based on the bridging module, that is, br0 = eth1 + eth2. The Ethernet bridge interface is also a standard Ethernet interface, and the Linux system has a built-in tool for creating Ethernet bridge interfaces. The function of the Ethernet bridge interface is to implement the function of a physical switch, forwarding data received on one port to other ports. Through this Ethernet bridge interface, the BMC, OS, and SMC form an Ethernet network, and all Ethernet-based programs can run normally, realizing data exchange between the three.

[0030] Based on the above embodiments, as one possible implementation method, such as... Figure 3 The diagram shown is a structural schematic of a virtual network system provided in an embodiment of this application. The system also includes an operation and maintenance terminal for accessing any internal device through the Ethernet bridging interface of the baseboard management controller. The operation and maintenance terminal is connected to the baseboard management controller via an Ethernet link.

[0031] Specifically, such as Figure 3 As shown, the operations and maintenance (O&M) end is the PC, the computer used by O&M administrators. In the SMC, eth0 is an Ethernet link interface virtualized by lan-on-ipmb. Upper-layer software can configure an internal network IP address for this interface, such as "192.168.1.2". In the OS, eth0 is an Ethernet link interface virtualized by lan-on-kcs. Upper-layer software can configure an internal network IP address for this interface, such as "192.168.1.3". In the BMC, eth1 is an Ethernet link interface virtualized by lan-on-ipmb. In the BMC, eth2 is an Ethernet link interface virtualized by lan-on-kcs. In the BMC, br0 is a bridging device that combines eth1 and eth2 using standard functions; br0 is an Ethernet bridging interface, and upper-layer software can configure an internal network IP address for this interface, such as "192.168.1.1". The br0 of the BMC, the eth0 of the SMC, and the eth0 of the OS together form a standard Ethernet network, on which popular and stable functions can run, such as HTTP-based management functions. PCs can indirectly access the SMC or OS via the BMC's Ethernet bridging interface. Maintenance and management personnel can access the BMC's external IP address, for example... Figure 3The IP address 100.14.1.123 on eth0 of the BMC can be used to indirectly access the SMC or OS by adding the port number.

[0032] Accordingly, in one embodiment, the baseboard management controller is used to acquire an internal device access request sent by the operation and maintenance terminal; in response to the internal device access request, determine the target internal device to be accessed by the operation and maintenance terminal based on the target port number carried in the internal device access request; send the internal device access request to the target first virtual Ethernet interface corresponding to the target internal device through the Ethernet bridging interface; based on the target first virtual Ethernet interface, parse the internal device access request according to the Ethernet format to obtain the target request content, encapsulate the target request content into a non-Ethernet request according to the function type of the target first virtual Ethernet interface; and transmit the non-Ethernet request to the target internal device through the non-Ethernet link between the target and the target internal device.

[0033] It should be noted that the processing of internal device access requests by the Baseboard Management Controller (BMC) can be implemented based on the firewall management module, which runs on the BMC. The firewall management module can be implemented using the Linux iptables tool. With the help of the firewall management module, operations and maintenance personnel can indirectly access the SMC or OS via IP address and port number, but the usage method is the same as direct access to the BMC, unifying the access method. For example, if operations and maintenance personnel frequently need to log in to the BMC's management page to perform certain operations or retrieve certain information, they only need to enter the relevant network URL in their browser. Similarly, logging into the SMC's management page through the firewall management module is the same as logging into the BMC's management page; simply add the port number (target port number) to the network URL. The BMC determines the target internal device to be accessed based on the target port number carried in the internal device access request, and then processes the internal device access request accordingly to ensure successful transmission to the target internal device.

[0034] Accordingly, in one embodiment, the target internal device is used to respond to non-Ethernet requests to generate corresponding request-response results; the target second virtual Ethernet interface established based on the target second virtual Ethernet module parses the request-response results according to the Ethernet format to obtain the target response content, and encapsulates the target response content into a non-Ethernet response result according to the functional type of the target second virtual Ethernet interface; the non-Ethernet response result is transmitted to the baseboard management controller through the non-Ethernet link between the baseboard management controller and the baseboard management controller, so that the non-Ethernet response result is converted into an Ethernet response result by the baseboard management controller, and then the Ethernet response result is fed back to the operation and maintenance end through the Ethernet link between the baseboard management controller and the operation and maintenance end.

[0035] For example, such as Figure 4The diagram illustrates an exemplary access process for an internal target device provided in this application, using an example of an operations and maintenance administrator accessing the SMC's page via the BMC's external IP address and port number. The SMC's page normally uses port 443; however, it is assumed that access is indirect via the BMC's port 2443. The firewall management module uses the Linux standard firewall tool iptables to add a rule, modifying incoming packets from BMC's eth0 interface on port 2443 to packets on port 443, and sending them out from br0. br0 will then send the packets out from the IPMB type Ethernet interface eth1. eth1 is bound to the IPMB interface, so the packets will ultimately be sent out from the IPMB interface. The SMC's IPMB interface will then receive the packets and hand them over to the SMC's Ethernet interface eth0, where they will be received and processed by the page module on the SMC. The SMC will send the reply packet (not the Ethernet response result) to the browser out from SMC's eth0. SMC's eth0 is an IPMB type Ethernet interface, so the packets are actually handed over to the IPMB interface and sent out from the IPMB link. This packet will be received by the BMC's IPMB interface, then handed over to its bound Ethernet interface eth1, and then to the Ethernet bridge interface br0. The firewall management module, recognizing that this packet is a reply packet to a request packet sent by the operations and maintenance administrator, will send the packet from the external network interface eth0 to the operations and maintenance administrator's PC. This allows operations and maintenance administrators to access the SMC page via the external IP address and port of the BMC.

[0036] Specifically, in one embodiment, a filter can be set on the Ethernet bridging interface. By setting rules for the filter, the OS can be prohibited from actively accessing the SMC's management interface, preventing compromised OS from attacking SMC devices such as smart network cards. Deep inspection of data packets can also be performed based on predefined security policies, and actions can be taken accordingly. For example, ensuring that only legitimate protocols (such as HTTPS and SSH) run on the Ethernet network, blocking any unauthorized or abnormal protocol traffic; integrating simple signature rules to detect and block known attack behaviors (such as port scanning and specific vulnerability exploitation traffic) in real time; and monitoring traffic rates so that if a sudden surge in traffic from an internal device (such as the OS) is detected within a very short period, an automatic alert can be issued and access temporarily restricted.

[0037] The virtual network system provided in this application embodiment has a first virtual Ethernet module in the baseboard management controller and a second virtual Ethernet module in the internal device. The first and second virtual Ethernet modules can perform corresponding protocol conversion on the data to be transmitted or received before transmission through a non-Ethernet link or after receiving data, so as to convert Ethernet data into non-Ethernet data or non-Ethernet data into Ethernet data. Therefore, even if the baseboard management controller and the internal device are connected through a non-Ethernet link, the application software configured in the baseboard management controller and the internal device can still use Ethernet data as communication data normally without redeveloping the application software, reducing the development cost of the application software, facilitating subsequent maintenance and management, reducing the workload of operation and maintenance personnel, reusing popular Ethernet management functions, and improving software quality.

[0038] Through the above description of the embodiments, those skilled in the art can clearly understand that the system according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0039] This application also provides a virtual network method, applied to the virtual network system provided in the above embodiments.

[0040] like Figure 5 The diagram shown is a flowchart of a virtual network method provided in an embodiment of this application. The method includes: Step 501: When the control board management controller is about to transmit Ethernet data to the internal device, it converts the Ethernet data into the corresponding non-Ethernet data based on the first virtual Ethernet module and according to the protocol type of the non-Ethernet link. Step 502: Transmit non-Ethernet data to the internal device via a non-Ethernet link with the internal device; Step 503: When the internal device receives non-Ethernet data through a non-Ethernet link, it converts the non-Ethernet data into corresponding Ethernet data based on the second virtual Ethernet module and according to the protocol type of the non-Ethernet link.

[0041] For a description of the features in the embodiments corresponding to the virtual network method, please refer to the relevant descriptions in the embodiments corresponding to the virtual network system, which will not be repeated here.

[0042] Embodiments of this application also provide an electronic device, such as... Figure 6 The diagram shown is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, including a processor 10 and a memory 20. The memory 20 stores a computer program, and the processor 10 is configured to run the computer program to perform the steps in any of the above-described virtual network method embodiments.

[0043] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described virtual network method embodiments at runtime.

[0044] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0045] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described virtual network method embodiments.

[0046] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in any of the above-described virtual network method embodiments.

[0047] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0048] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0049] The virtual network system, method, and electronic device provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A virtual network system, characterized in that, include: The system includes a baseboard management controller and at least one internal device. The baseboard management controller and the internal device are connected via a non-Ethernet link. The baseboard management controller is provided with a first virtual Ethernet module, and the internal device is provided with a second virtual Ethernet module. The non-Ethernet link includes at least an IPMB link and a KCS link. The internal device includes at least a graphics card, a smart network card, and a server. The baseboard management controller is used to, when Ethernet data is to be transmitted to the internal device, convert the Ethernet data into corresponding non-Ethernet data based on the first virtual Ethernet module and according to the protocol type of the non-Ethernet link, and transmit the non-Ethernet data to the internal device through the non-Ethernet link; The internal device is used to convert non-Ethernet data into corresponding Ethernet data based on the second virtual Ethernet module, according to the protocol type of the non-Ethernet link, when receiving non-Ethernet data through the non-Ethernet link. The baseboard management controller includes a bridging module, which is used for: When the first virtual Ethernet module provided by the baseboard management controller is not unique, the first virtual Ethernet interfaces established by multiple first virtual Ethernet modules are bridged to establish an Ethernet bridge interface, so that each first virtual Ethernet interface can be interconnected. The system also includes: The operation and maintenance terminal is used to access any of the internal devices through the Ethernet bridge interface of the baseboard management controller; The operation and maintenance terminal is connected to the baseboard management controller via an Ethernet link; The baseboard management controller is used for: Obtain the internal device access request sent by the operation and maintenance terminal; In response to the internal device access request, the target internal device to be accessed by the operation and maintenance terminal is determined based on the target port number carried in the internal device access request. The internal device access request is sent to the target first virtual Ethernet interface corresponding to the target internal device through the Ethernet bridging interface. Based on the target first virtual Ethernet interface, the internal device access request is parsed according to the Ethernet format to obtain the target request content. According to the function type of the target first virtual Ethernet interface, the target request content is encapsulated into a non-Ethernet request. The non-Ethernet request is transmitted to the target internal device via a non-Ethernet link.

2. The virtual network system according to claim 1, characterized in that, The first virtual Ethernet module is used to establish a first virtual Ethernet interface on the baseboard management controller that is bound to the non-Ethernet link interface. The function type of the first virtual Ethernet interface is determined according to the protocol type of the non-Ethernet link. The baseboard management controller is specifically used for: When Ethernet data is to be transmitted to the internal device, the Ethernet data is transmitted to the first virtual Ethernet interface, and the Ethernet data is parsed according to the Ethernet format based on the first virtual Ethernet interface to obtain the target data content. The target data content is then encapsulated into non-Ethernet data according to the function type.

3. The virtual network system according to claim 1, characterized in that, The internal device is also used for: When Ethernet data is to be transmitted to the baseboard management controller, the Ethernet data is converted into corresponding non-Ethernet data according to the protocol type of the non-Ethernet link based on the second virtual Ethernet module, and the non-Ethernet data is transmitted to the baseboard management controller through the non-Ethernet link.

4. The virtual network system according to claim 1, characterized in that, The target internal device is used for: Respond to the non-Ethernet request to generate the corresponding request response result; Based on the target second virtual Ethernet interface established by the target second virtual Ethernet module, the request response result is parsed according to the Ethernet format to obtain the target response content. According to the functional type of the target second virtual Ethernet interface, the target response content is encapsulated into a non-Ethernet response result. The non-Ethernet response result is transmitted to the baseboard management controller via a non-Ethernet link. The baseboard management controller then converts the non-Ethernet response result into an Ethernet response result and feeds it back to the operation and maintenance terminal via an Ethernet link.

5. The virtual network system according to claim 1, characterized in that, The internal equipment includes at least a graphics card, a smart network card, and a server. The baseboard management controller is configured such that each first virtual Ethernet module corresponds to a protocol type of the non-Ethernet link; Internal devices corresponding to different protocol types establish communication through the Ethernet bridging interface.

6. A virtual network method, characterized in that, Applied to the virtual network system as described in any one of claims 1 to 5, the method comprises: When the control board management controller is about to transmit Ethernet data to an internal device, it converts the Ethernet data into corresponding non-Ethernet data based on the first virtual Ethernet module and according to the protocol type of the non-Ethernet link. The non-Ethernet data is transmitted to the internal device via a non-Ethernet link with the internal device; When the internal device receives non-Ethernet data through the non-Ethernet link, it converts the non-Ethernet data into corresponding Ethernet data based on the protocol type of the non-Ethernet link using the second virtual Ethernet module. The non-Ethernet links include at least IPMB links and KCS links, and the internal devices include at least graphics cards, smart network cards, and servers.

7. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the virtual network method as described in claim 6 when executing the computer program.

Images