Cloud communication method and device, equipment, storage medium and product

Abstract

The embodiment of the invention discloses a cloud communication method and device, equipment, a storage medium and a product, and the method comprises the steps: achieving media access control address learning between an on-cloud host and an off-cloud host through boundary gateway protocol speaking equipment based on a media access control address table proxy address resolution protocol request; an extensible virtual local area network tunnel is established between the under-cloud extensible virtual local area network switch and the on-cloud two-layer gateway device; packaging a two-layer data message through the extensible virtual local area network tunnel to realize two-layer data message transmission from the network under the cloud to the network on the cloud; and decapsulating the two-layer data message through the extensible virtual local area network tunnel to realize two-layer data message transmission from the network on the cloud to the network under the cloud.

Description

Technical Field

[0001] This application relates to, but is not limited to, the field of cloud computing network technology, and in particular to a cloud communication method, apparatus, device, storage medium, and product. Background Technology

[0002] As businesses continue to expand, many organizations choose to migrate some of their workloads to the cloud to take advantage of the elasticity, flexibility, and cost-effectiveness offered by cloud computing. However, critical applications and data often remain residing in on-premises data centers, leading to a growing need for communication between the cloud and on-premises environments. Enterprises typically want to maintain the isolation of their internal networks while ensuring secure and efficient communication with cloud resources.

[0003] Existing technologies typically rely on Layer 3 network interconnection solutions for cloud-on-premises communication, such as leased lines or Elastic IPs (EIPs) to achieve cross-network communication. These methods are usually based on IP routing and tunneling technologies, such as IPsec or GRE tunnels, to establish connections between the cloud and on-premises networks. However, Layer 3 interconnection solutions require cloud and on-premises networks to use different IP address ranges, which may lead to enterprises having to re-plan their network architecture when migrating services, increasing configuration complexity and potential error risks. Summary of the Invention

[0004] In view of the above, embodiments of this application provide at least one cloud communication method, apparatus, device, storage medium, and product.

[0005] The technical solution of this application embodiment is implemented as follows: On one hand, embodiments of this application provide a cloud communication method, the method comprising: By using the border gateway protocol speaking device to parse protocol requests based on the media access control address table proxy address, media access control address learning between cloud hosts and on-premises hosts is achieved; Establish a scalable virtual LAN tunnel between an on-premises scalable virtual LAN switch and a cloud-based Layer 2 gateway device. Layer 2 data packets are encapsulated through the scalable virtual LAN tunnel to enable Layer 2 data packet transmission from the on-premises network to the cloud network; The scalable virtual LAN tunnel decapsulates Layer 2 data packets, enabling Layer 2 data packet transmission from the cloud network to the on-premises network.

[0006] On the other hand, embodiments of this application provide a cloud communication device, the device comprising: The processing module is used to resolve protocol requests based on the Media Access Control Address Table proxy address through the border gateway protocol speaking device, thereby enabling media access control address learning between cloud hosts and on-premises hosts. Establish a scalable virtual LAN tunnel between an on-premises scalable virtual LAN switch and a cloud-based Layer 2 gateway device. The communication module is used to encapsulate Layer 2 data packets through the scalable virtual local area network tunnel to realize Layer 2 data packet transmission from the on-premises network to the cloud network; The scalable virtual LAN tunnel decapsulates Layer 2 data packets, enabling Layer 2 data packet transmission from the cloud network to the on-premises network.

[0007] In another aspect, embodiments of this application provide a computer device, including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the cloud communication method described above.

[0008] In another aspect, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements some or all of the steps in the cloud communication method described above.

[0009] In another aspect, embodiments of this application provide a computer program including computer-readable code. When the computer-readable code is run in a computer device, the processor in the computer device executes some or all of the steps for implementing the cloud communication method described above.

[0010] In another aspect, embodiments of this application provide a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the cloud communication method described above.

[0011] This application embodiment achieves Media Access Control address learning through Border Gateway Protocol (BGP) proxy address resolution protocol requests, establishes a scalable virtual LAN tunnel, and uses this tunnel to encapsulate and decapsulate Layer 2 data packets, ultimately achieving efficient interoperability between Layer 2 networks on and off the cloud. This ensures dynamic synchronization of network addresses and reliable data transmission, improves the flexibility of user network planning, supports service migration without changing existing IP configurations, and enhances network scalability and isolation.

[0012] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this application. Attached Figure Description

[0013] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0014] Figure 1 A schematic diagram illustrating the implementation process of a cloud communication method provided in this application embodiment; Figure 2 This is one of the schematic diagrams of the architecture of a cloud communication method provided in an embodiment of this application; Figure 3 A second schematic diagram of the architecture of a cloud communication method provided in an embodiment of this application; Figure 4 This is the third schematic diagram of the architecture of a cloud communication method provided in an embodiment of this application; Figure 5 One of the logical schematic diagrams of a cloud communication method provided in an embodiment of this application; Figure 6 A second logical schematic diagram of a cloud communication method provided in an embodiment of this application; Figure 7 This is a schematic diagram of the composition structure of a cloud communication device provided in an embodiment of this application; Figure 8 This is a schematic diagram of the hardware entity of a computer device provided in an embodiment of this application. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0016] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0017] The terms “first / second / third” are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that “first / second / third” may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0018] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this application.

[0019] This application provides a cloud communication method that can be executed by a processor of a computer device. The computer device can refer to a server, laptop computer, tablet computer, desktop computer, smart TV, set-top box, mobile device (such as a mobile phone, portable video player, personal digital assistant, dedicated messaging device, portable gaming device, etc.). Figure 1 This is a schematic diagram illustrating the implementation process of a cloud communication method provided in an embodiment of this application, as shown below. Figure 1 As shown, the method includes: Step 101: The border gateway protocol speaking device resolves the protocol request based on the media access control address table proxy address, thereby enabling media access control address learning between cloud hosts and on-premises hosts.

[0020] In this embodiment, a Border Gateway Protocol (BGP) speaking device refers to a router running the BGP protocol in the network, responsible for exchanging routing information with other BGP speaking devices to determine the optimal transmission path for data packets. A Media Access Control (MAC) address table is a database storing the mapping relationship between MAC addresses and their corresponding ports or network locations, used to guide the forwarding of data frames. Address Resolution Protocol (ARP) is a network protocol used to resolve network layer addresses to data link layer addresses, such as mapping IP addresses to MAC addresses. A cloud-based host refers to a virtual machine or computing instance located in a cloud computing environment, while an on-premises host refers to a physical or virtual device located in a local data center. MAC address learning is the process by which network devices dynamically acquire and update MAC address and port mappings to optimize data forwarding.

[0021] The system listens for Address Resolution Protocol (ARP) requests from both cloud-based and on-premises hosts via a Border Gateway Protocol (BGP) speaking device. When an on-premises host needs to access a cloud host but lacks an ARP cache, the on-premises BGP speaking device directly replies with an ARP response based on its pre-built Media Access Control (MAC) address table, providing the target host's MAC address. Similarly, when a cloud host sends an ARP request, the system responds through the open virtual switch flow tables on the compute nodes. These flow tables are generated based on the IP address and MAC address mapping uploaded to the server by the cloud BGP speaking device. The BGP speaking device, acting as an ARP proxy, processes requests and updates the MAC address table, ensuring that cloud-based and on-premises hosts can dynamically learn each other's MAC addresses, thereby supporting efficient data communication.

[0022] Step 102: Establish a scalable virtual LAN tunnel between the on-premises scalable virtual LAN switch and the cloud-based Layer 2 gateway device.

[0023] In this embodiment, the on-premises Scalable Virtual LAN switch is a network device located in the local data center. As a Scalable Virtual LAN terminal, it is responsible for encapsulating and decapsulating Layer 2 data packets. The cloud-based Layer 2 gateway device is a virtual network element in the cloud computing environment, acting as a Scalable Virtual LAN terminal and a border gateway protocol speaking device, managing cloud network traffic. The Scalable Virtual LAN tunnel is a virtual Layer 2 network channel built on a Layer 3 network, which achieves transparent cross-network communication by encapsulating Layer 2 data packets for transmission between the cloud and on-premises environments.

[0024] The system configures and establishes a Scalable Virtual LAN (VLAN) tunnel between an on-premises Scalable VLAN switch and a cloud-based Layer 2 gateway device. The on-premises Scalable VLAN switch, acting as a Scalable VLAN endpoint, negotiates tunnel parameters, such as the Virtual Network Identifier (VNIC) and tunnel endpoint addresses, with the cloud-based Layer 2 gateway device. The system uses software-defined networking (SDN) technology to automatically deploy the tunnel configuration, ensuring a stable tunnel connection. The Scalable VLAN tunnel encapsulates Layer 2 data packets based on the User Datagram Protocol (UDP), allowing the on-premises and cloud networks to logically behave as a single Layer 2 domain. After the tunnel is established, the system verifies connectivity, preparing for subsequent data packet encapsulation and decapsulation operations.

[0025] Step 103: Encapsulate Layer 2 data packets through the Scalable Virtual LAN tunnel to achieve Layer 2 data packet transmission from the on-premises network to the cloud network.

[0026] In this embodiment, the Scalable Virtual Local Area Network (VLAN) tunnel is the virtual network channel established in step 102, used to transmit encapsulated data packets between the cloud and on-premises environments. Layer 2 data packets are data links layer data frames, containing a Media Access Control (MAC) header and a payload, used for direct communication within a local area network (LAN). On-premises network refers to the network environment of a local data center, while cloud network refers to the virtual network space of a cloud computing platform.

[0027] When the system receives Layer 2 data packets from an on-premises host on the on-premises Scalable Virtual LAN (SVLAN) switch, it performs encapsulation operations based on pre-configured SVLAN parameters. The encapsulation process includes adding an SVLAN header, a User Datagram Protocol (UDP) header, and an External IP header, converting the original Layer 2 data packet into an SVLAN packet. The system uses a Virtual Network Identifier (VNIC) to identify the target virtual network, ensuring correct packet routing within the tunnel. The encapsulated packet is then transmitted to the cloud-based Layer 2 gateway device via the SVLAN tunnel. Upon receiving the packet, the cloud-based Layer 2 gateway device temporarily stores it and prepares for decapsulation; however, this step only completes encapsulation and transmission; decapsulation is handled in subsequent steps. Through this process, the system achieves efficient forwarding of Layer 2 data packets from the on-premises network to the cloud network.

[0028] Step 104: Decapsulate Layer 2 data packets through the Scalable Virtual LAN tunnel to achieve Layer 2 data packet transmission from the cloud network to the on-premises network.

[0029] In this embodiment, the Layer 2 data packet is a data frame at the data link layer, containing a media access control header and a payload. Cloud network refers to the virtual network space of a cloud computing platform, while on-premises network refers to the network environment of a local data center.

[0030] When the system receives a Layer 2 data packet from a cloud host or a Scalable Virtual LAN (VLAN) packet transmitted in step 103 from the cloud Layer 2 gateway device, it looks up the configuration of the corresponding on-premises VLAN tunnel based on the VLAN identifier and IP address in the packet. The system performs a decapsulation operation, removing the VLAN header, UDP header, and external IP header to restore the original Layer 2 data packet. The decapsulated packet is then forwarded to the target on-premises host via the on-premises VLAN switch according to the Media Access Control (MAC) address table. The system ensures that the decapsulation process is efficient and accurate, supporting complete Layer 2 data packet transmission from the cloud network to the on-premises network, enabling bidirectional communication.

[0031] This application embodiment achieves Media Access Control address learning through Border Gateway Protocol (BGP) proxy address resolution protocol requests, establishes a scalable virtual LAN tunnel, and uses this tunnel to encapsulate and decapsulate Layer 2 data packets, ultimately achieving efficient interoperability between Layer 2 networks on and off the cloud. This ensures dynamic synchronization of network addresses and reliable data transmission, improves the flexibility of user network planning, supports service migration without changing existing IP configurations, and enhances network scalability and isolation.

[0032] In some embodiments, prior to step 101, the method further includes: Step 201: Configure border gateway protocol speaking devices in both the on-premises network and the cloud network, and establish neighbor relationships between the border gateway protocol speaking devices through the multi-protocol border gateway protocol.

[0033] In this embodiment, the system deploys Border Gateway Protocol (BGP) speaking devices in both the on-premises and cloud networks. These devices operate as routers running the Multiprotocol Border Gateway Protocol (MPGP). The system establishes neighbor relationships between the on-premises and cloud-based BGP speaking devices using MPGP. Establishing these neighbor relationships involves session negotiation and parameter configuration between the devices to ensure reliable exchange of routing information. The system uses MPGP extension mechanisms to support Layer 2 network information exchange. After neighbor relationships are established, the BGP speaking devices periodically send keep-alive messages to maintain connection stability.

[0034] Step 202: Synchronize network layer reachability information through the neighbor relationship between the border gateway protocol speaking devices. The network layer reachability information includes the mapping relationship between media access control addresses and Internet protocol addresses.

[0035] In this embodiment, the system exchanges network layer reachability information through established neighbor relationships between Border Gateway Protocol (BGP) speaking devices. The BGP speaking devices use Multiprotocol Border Gateway Protocol (MPGP) update messages to synchronize network layer reachability information; these messages contain mappings between Media Access Control (MAC) addresses and Internet Protocol (IP) addresses. The system parses fields in the network layer reachability information, such as MAC and IP addresses, and stores this information in a local database. The synchronization process is dynamic; when a new address mapping appears in the network, the BGP speaking device immediately broadcasts the update through neighbor relationships to ensure information consistency.

[0036] Step 203: Construct a media access control address table based on the network layer reachability information.

[0037] In this embodiment, the system constructs a Media Access Control Address (MAC) table based on the mapping relationship between MAC addresses and Internet Protocol (IP) addresses extracted from network layer reachability information. The system parses the MAC address and IP address fields from the network layer reachability information and adds these entries to the MAC table. The construction process includes verifying the validity of the mapping relationship, such as checking the address format and uniqueness. The system then distributes the updated MAC table to relevant network components, such as switches and routers. The construction of the MAC table is continuous; the system periodically refreshes it based on new network layer reachability information to reflect changes in network topology.

[0038] This application embodiment synchronizes Media Access Control (MAC) address and Internet Protocol (IP) address information through a Border Gateway Protocol (BGP) speaking device and a Multi-Protocol Border Gateway Protocol (MPB), constructing a dynamically updated MAC address table to ensure accurate forwarding of data packets in cloud and on-premises networks. This improves the flexibility of network planning and communication efficiency, while also supporting seamless service migration and network expansion.

[0039] In some embodiments, step 201 includes: Step 2011: Configure the multi-protocol border gateway protocol parameters for the scalable virtual LAN switch and the virtualized Layer 2 gateway device, wherein the scalable virtual LAN switch is deployed in the on-premises network and has border gateway protocol speaking function, and the virtualized Layer 2 gateway device is deployed in the cloud network and has border gateway protocol speaking function.

[0040] In this embodiment, the system first configures the MP-BGP parameters of the scalable virtual LAN switch, including setting its role as a BGP speaker, defining supported address families such as EVPN, and IP address information. Simultaneously, the system configures the MP-BGP parameters of the virtualized Layer 2 gateway device, specifying its BGP speaker functionality, route reflector settings, and neighbor connectivity details. These configurations ensure that on-premises and cloud devices can recognize each other and prepare to establish a BGP session, laying the foundation for subsequent route switching.

[0041] Step 2012: Establish a session connection between the scalable virtual LAN switch and the virtualized Layer 2 gateway device using the transmission protocol specified by the preset standard.

[0042] In this embodiment, the system uses a preset transport protocol, such as TCP, to initiate a connection request between the scalable virtual LAN switch and the virtualized Layer 2 gateway device. The system handles the handshake process, including sequence number synchronization and window size negotiation, to establish a stable BGP session. Once the connection is established, the system confirms the session state and provides a communication channel for the exchange of routing capability information.

[0043] Step 2013: Exchange routing capability information between the scalable virtual LAN switch and the virtualized Layer 2 gateway device.

[0044] In this embodiment, the system, through an established session connection, enables the Scalable Virtual LAN switch to send its routing capability information, including supported EVPN address families and routing attributes, to the virtualized Layer 2 gateway device. Simultaneously, the system enables the virtualized Layer 2 gateway device to respond with its routing capabilities, confirm compatibility, and negotiate session parameters. This process ensures that both devices understand each other's routing capabilities, preparing for subsequent synchronization of MAC address and IP address information.

[0045] Step 2014: Verify the neighbor status between the scalable virtual LAN switch and the virtualized Layer 2 gateway device.

[0046] In this embodiment, the system periodically checks the BGP neighbor status between the scalable virtual LAN switch and the virtualized Layer 2 gateway device, verifying connection activity by sending and receiving Keepalive messages. The system analyzes status information, such as session timeouts or error counts, to detect any anomalies. If the status is normal, the system confirms that the neighbor relationship has been established; otherwise, the system triggers a reconnection mechanism to ensure the reliability of the control plane.

[0047] Step 2015: Maintain a persistent session connection between the Scalable Virtual LAN Switch and the Virtualized Layer 2 Gateway Device.

[0048] In this embodiment, the system keeps the BGP session between the scalable VLAN switch and the virtualized Layer 2 gateway device active by periodically sending Keepalive messages and maintaining route updates. The system monitors session parameters, such as keep-alive time and retransmission interval, and dynamically adjusts them to respond to network changes. This ensures the persistence of MP-BGP neighbor relationships and supports real-time MAC address table synchronization and routing information propagation.

[0049] This application embodiment achieves efficient control plane communication between on-premises and cloud network devices through systematic configuration, establishment, and maintenance of MP-BGP neighbor relationships. These steps ensure real-time synchronization of MAC address, VLAN ID, and IP address information, providing a reliable routing foundation for VXLAN tunnels. This enhances the flexibility, scalability, and automation of Layer 2 network interconnection, supporting seamless migration of on-premises and cloud services.

[0050] In some embodiments, step 202 includes: Step 2021: Monitor media access control address change events for virtual machines in the cloud and on-premises hosts.

[0051] In this embodiment, the system continuously monitors the network interface status of virtual machines in the cloud and on-premises hosts to detect changes in media access control addresses. When a virtual machine or host updates its media access control address, the system automatically triggers an event capture mechanism to record the change type and timestamp. This process utilizes a software-defined network controller or agent to collect network status data in real time, ensuring that change events are promptly identified and forwarded to the processing module.

[0052] Step 2022: Generate a Type 2 route advertisement containing the mapping relationship between Media Access Control addresses and Internet Protocol addresses.

[0053] In this application embodiment, Type 2 route advertisement is a routing message format based on the Multiprotocol Border Gateway Protocol, used to propagate association information between Media Access Control addresses and Internet Protocol addresses.

[0054] Based on detected Media Access Control (MAC) address change events, the system automatically constructs a Type 2 route advertisement. This advertisement includes fields such as MAC address, Internet Protocol (IP) address, route distinguisher, and next-hop address, encapsulated in a standard format. The system uses a route generation module to populate the necessary attributes, ensuring the advertisement accurately reflects the current network topology and providing a data foundation for subsequent transmission and synchronization.

[0055] Step 2023: Transmit the Type 2 route advertisement to the peer border gateway protocol speaking device via a multi-protocol border gateway protocol session.

[0056] In this embodiment, the system sends the generated Type 2 routing advertisement to the peer border gateway protocol speaking device through an established multi-protocol border gateway protocol session. The transmission process utilizes the border gateway protocol's update message mechanism to ensure reliable advertisement delivery. The system verifies session state and network connectivity to prevent data loss and supports a retransmission mechanism to handle transmission failures.

[0057] Step 2024: Parse the Media Access Control Address field and Internet Protocol Address field in the received Type 2 routing advertisement.

[0058] In this embodiment, the system parses the Type 2 routing advertisement received from the peer border gateway protocol speaking device, extracting the Media Access Control Address (MAC) and Internet Protocol Address (IPA) fields. The parsing module decodes the advertisement structure using the protocol specification, verifies the integrity and validity of the fields, and converts the extracted data into an internal format for subsequent processing.

[0059] Step 2025: Update the local storage record of media access control addresses and Internet protocol addresses mapping.

[0060] In this embodiment, the system updates the locally stored mapping records based on the parsed Media Access Control (MAC) address and Internet Protocol (IP) address. The update process includes adding new entries, modifying existing entries, or deleting invalid entries to ensure the records are consistent with the network status. The system uses database operations or caching mechanisms to maintain data accuracy and triggers synchronized changes in relevant modules to support network forwarding decisions.

[0061] This application's embodiments ensure the real-time performance and accuracy of Layer 2 network communication through automated monitoring, notification generation, protocol transmission, data parsing, and record updates. This enhances network planning flexibility, supports seamless migration and interoperability, and simultaneously improves network scalability and management efficiency.

[0062] In some embodiments, after step 2025, the method further includes: Step 2026: When a media access control address is detected to be invalid, a type 2 route revocation message is generated.

[0063] In this embodiment, the system first detects a Media Access Control (MAC) address failure event, for example, by monitoring network interface status or the aging mechanism of the MAC address table. Based on the failed MAC address information, the system generates a Type 2 route revocation message. This message contains specific flags indicating that the receiver should delete the corresponding MAC address entry. The system ensures that the revocation message format conforms to the Multiprotocol Border Gateway Protocol (MPBTP) standard, including the MAC address, Internet Protocol (IP) address, and related label fields to accurately identify the entry that needs to be revoked.

[0064] Step 2027: Transmit the Type 2 route revocation message to the peer border gateway protocol speaking device via a multi-protocol border gateway protocol session.

[0065] In this embodiment, the system encapsulates a Type 2 route revocation message into a standard border gateway protocol update message through an established multi-protocol border gateway protocol session. The system uses the session's transport mechanism, such as a Transmission Control Protocol (TCP)-based connection, to send the message to the peer border gateway protocol speaking device. Upon receiving the message, the peer device verifies message integrity and updates its local Media Access Control (MAC) address table according to the revocation flag, deleting invalid entries to ensure network path accuracy and avoid invalid data forwarding.

[0066] This application embodiment automatically detects the failure of the Media Access Control address and synchronously cancels the information. The system can quickly respond to network changes, reduce invalid data forwarding, and improve network reliability and resource utilization.

[0067] In some embodiments, step 203 includes: Step 2031: Extract media access control address entries from the network layer reachability information.

[0068] In this embodiment, the system first parses the received network layer reachability information data packet, identifies and extracts the media access control address (MAC) entries. The system uses a protocol parsing module to traverse the network layer reachability information fields, locates the MAC-related data, and separates it into independent entries. The system ensures that the extraction process follows the format specifications of the border gateway protocol, for example, obtaining the MAC and Internet Protocol (IP) address fields from Type 2 routes. After extraction, the system temporarily stores the MAC entries in a buffer for subsequent processing steps.

[0069] Step 2032: Verify the validity and integrity of the media access control address entry.

[0070] In this embodiment, the system calls a verification module to check the extracted Media Access Control (MAC) address entries. The system verifies whether the MAC address format conforms to Ethernet standards, for example, checking if the address is a 48-bit hexadecimal value. The system checks the completeness of the entry, confirming that all necessary fields are present and the data is not corrupted, for example, verifying whether the Internet Protocol (IP) address is valid and matches the MAC address. The system also checks whether the entry comes from a trusted source by comparing it with the authentication information of the Border Gateway Protocol (BGP) session. If the entry is invalid or incomplete, the system discards the entry and logs an error; otherwise, the entry is marked as verified.

[0071] Step 2033: If the media access control address entry is verified, the media access control address entry is written into the media access control address table storage area.

[0072] In this embodiment, after a media access control address entry passes verification, the system writes it to the media access control address table storage area. The system uses a data writing module to insert the entry into the table according to a predefined format, such as storing the media access control address and its associated Internet Protocol address as key-value pairs. The system ensures the atomicity of the write operation, prevents data loss or conflicts, and updates the index of the storage area to optimize query performance. After the write is complete, the system triggers a notification mechanism to inform other modules that the media access control address table has been updated.

[0073] Step 2034: Establish the correspondence between media access control addresses and virtual network identifiers to obtain the media access control address table.

[0074] In this embodiment, the system establishes a mapping between media access control addresses (MAC addresses) and virtual network identifiers (VNs) based on the written MAC address entries. The system extracts VN information from the entries, for example, from Virtual Extensible LAN (VEX) configuration or routing attributes, and associates it with the MAC addresses. The system constructs a MAC address table, organizing entries using VNs as indexes to support efficient lookup and updates. For example, the system uses a hash table to store the mapping relationship, ensuring rapid matching of MAC addresses and VNs during data forwarding. After establishment, the MAC address table is synchronized to network devices for use in actual communication processes.

[0075] This application implements efficient extraction, verification, storage, and mapping construction of media access control address entries, ensuring the accuracy and real-time performance of the media access control address table. This provides a reliable data foundation for Layer 2 communication between the cloud and on-premises environments, supports dynamic learning and updating of media access control addresses, reduces the complexity of network configuration, improves communication flexibility and efficiency, and enhances network isolation and manageability in multi-tenant environments.

[0076] In some embodiments, after step 2034, the method further includes: Step 2035: Set the time-to-live parameter for the media access control address entry.

[0077] In this embodiment of the application, the system first configures the time-to-live parameter of each entry in the media access control address table. This parameter is defined in time units (such as seconds or minutes). The system records the creation or update time of the entry through an internal timer or clock module, and stores the time-to-live parameter in association with the current timestamp to ensure that each entry has a clear validity period identifier.

[0078] Step 2036: Periodically check the activity status of entries in the Media Access Control Address Table.

[0079] In this embodiment of the application, the system starts a timed task module to traverse all entries in the media access control address table at a preset period (e.g., every 30 seconds). The system calculates the difference between the current time and the last active time by querying the last used timestamp or data packet counter of the entry, and compares it with the lifetime parameter to determine whether the entry is in an active state.

[0080] Step 2037: Remove invalid media access control address entries that have exceeded the time-to-live parameter.

[0081] In this embodiment of the application, an invalid media access control address entry refers to a MAC address record whose time-to-live has expired and has not been updated in the active state check. The removal operation involves deleting these entries from the address table and releasing the associated storage resources.

[0082] Based on the inspection results of step 2036, the system identifies entries that have exceeded the lifespan parameter. The system calls the data management module to execute deletion commands to clear these invalid entries. At the same time, the system updates the address table index and cache to ensure that subsequent data forwarding is based only on valid entries, avoiding resource waste or incorrect routing.

[0083] This application embodiment achieves dynamic optimization of the Media Access Control Address Table by systematically setting lifetime parameters, periodically monitoring active status, and automatically cleaning up invalid entries. This reduces storage redundancy and forwarding errors, improves network communication efficiency and reliability, and enhances the system's adaptability to network topology changes.

[0084] In the embodiments of this application, In some embodiments, step 101 includes: Step 1011: Listen for Address Resolution Protocol (ARP) request packets in the network.

[0085] In this embodiment, the system deploys a monitoring module on the network interface, which scans incoming and outgoing data packets in real time. The system examines the protocol header of each data packet to identify packets of type Address Resolution Protocol (ARP) requests. Once such packets are detected, the system caches or forwards them to the resolution module to ensure that no requests are missed. The monitoring process is based on predefined filtering rules, such as focusing only on traffic within a specific subnet or virtual LAN, to improve efficiency.

[0086] Step 1012: Parse the target Internet Protocol address in the Address Resolution Protocol Request data packet.

[0087] In this embodiment, the system uses a protocol parsing engine to process captured Address Resolution Protocol (IP) request packets. The engine decapsulates the Ethernet frame and IP header of the packet, and reads the target Internet Protocol (IP) address field. The system verifies whether the address format conforms to standards, such as checking whether it is a valid IPv4 or IPv6 address. The parsing result is stored in a temporary buffer for use in subsequent steps, ensuring data integrity and accuracy.

[0088] Step 1013: Query the media access control address record in the media access control address table that corresponds to the target Internet Protocol address.

[0089] In this embodiment, the system accesses a Media Access Control (MAC) address table, which may be stored in memory or a distributed database. The system uses the target Internet Protocol (IP) address resolved in step 1012 as the key to perform an index lookup operation. The query process includes comparing address fields; if a matching record is found, the system retrieves the corresponding MAC address and its status information. If no match is found, the system may trigger error handling or wait for an update to ensure the real-time nature of the query results.

[0090] Step 1014: When a valid Media Access Control (MAC) address record is found, generate an Address Resolution Protocol (ARP) response data packet.

[0091] In this embodiment, the system constructs an Address Resolution Protocol (ARP) response data packet based on the retrieved valid Media Access Control (MAC) address records. The system sets the source MAC address of the data packet to the query result, the destination address to the requester's MAC address, and populates the protocol type field. The generation process includes calculating a checksum and encapsulating an Ethernet header to ensure the data packet conforms to network standards. The system uses templates or dynamic code to generate the response to optimize performance.

[0092] Step 1015: Send the Address Resolution Protocol (ARP) response data packet to the ARP requester.

[0093] In this embodiment, the system sends the generated Address Resolution Protocol (ARP) response data packet through the network interface. The system determines the requester's Media Access Control (MAC) address and encapsulates the data packet into an Ethernet frame using a routing table or forwarding engine. The sending process includes setting priorities, handling congestion control, and ensuring that the data packet is transmitted through a physical or virtual network link. The system monitors the sending status and retryes or logs any failures to ensure reliability.

[0094] The embodiments of this application enable the system to automatically listen for, parse, and respond to Address Resolution Protocol (ARP) requests, quickly build and update the Media Access Control (MAC) address table, reduce network latency and broadcast traffic, improve the efficiency and reliability of Layer 2 network communication, and support seamless integration with cloud and on-premises environments.

[0095] In some embodiments, after step 1015, the method further includes: Step 1016: If no valid Media Access Control address record is found, forward the Address Resolution Protocol (ARP) request to other network nodes.

[0096] In this embodiment, the system first checks the locally stored Media Access Control (MAC) address table. If no valid record matching the target IP address is found, the system generates an Address Resolution Protocol (ARP) request message. This request message contains the target IP address and the source MAC address. The system forwards the request to other network nodes, such as adjacent switches or routers, via broadcast or multicast. Upon receiving the request, other network nodes respond according to their own address tables or propagate it further, ensuring that the request covers potential target devices. The system uses standard network protocols to encapsulate and transmit the request, ensuring data integrity and reachability.

[0097] Step 1017: Record the correspondence between Address Resolution Protocol (ARP) requests and responses for network optimization.

[0098] In this embodiment, the system monitors network traffic and captures Address Resolution Protocol (ARP) requests and their corresponding response packets. The system parses the IP address and Media Access Control (MAC) address mapping in the response packet and associates this mapping with the metadata of the original request (such as sending time and source device identifier) ​​and stores it in a database. The system uses this record to update its local MAC address table and analyzes historical data to identify frequent request patterns, automatically adjusting forwarding or caching strategies. For example, the system can prioritize high-frequency mapping requests, reduce broadcast traffic, and thus improve overall network resource utilization.

[0099] This application's embodiments achieve efficient media access control address learning and updating by dynamically forwarding Address Resolution Protocol (ARP) requests and recording response relationships. This reduces network broadcast storms, optimizes address resolution latency, and enhances the reliability and scalability of Layer 2 networks.

[0100] In some embodiments, step 102 includes: Step 1021: Configure the tunnel interface parameters of the on-premises scalable virtual LAN switch.

[0101] In this embodiment, specific parameter values ​​for the tunnel interface are set for the on-premises scalable virtual LAN switch. Based on a predefined network plan, the system inputs a VXLAN network identifier to distinguish different virtual networks, specifies the source IP address as the interface address of the on-premises switch, the destination IP address as the address of the cloud-based Layer 2 gateway device, and configures a standard VXLAN port number. The system applies these parameters through a software-defined network controller or command-line interface to ensure the tunnel interface is in a ready state, providing the basic configuration for subsequent tunnel establishment.

[0102] Step 1022: Configure the tunnel interface parameters of the cloud-based Layer 2 gateway device.

[0103] In this embodiment, the system performs a configuration process on the cloud-based Layer 2 gateway device, inputting a VXLAN network identifier that matches the on-premises switch to ensure network consistency. The system sets the local IP address to the gateway device's interface address and the peer IP address to the on-premises Scalable Virtual LAN switch address, applying the same VXLAN port configuration. The system completes parameter deployment through a centralized management platform or automated scripts, enabling the cloud tunnel interface to correctly respond to on-premises communication requests.

[0104] Step 1023: Negotiate tunnel establishment parameters between the on-premises scalable virtual LAN switch and the cloud-based Layer 2 gateway device.

[0105] In this embodiment, configuration information is exchanged between an on-premises scalable virtual LAN switch and a cloud-based Layer 2 gateway device. The system compares the parameter ranges supported by both parties, determines compatible timeout values ​​to prevent connection interruption, negotiates the maximum transmission unit to optimize data packet size, and selects a unified encryption and authentication method to ensure security. The system confirms parameter consistency through interactive messages, providing a reliable negotiation basis for tunnel establishment.

[0106] Step 1024: Verify the network connectivity between the on-premises scalable VLAN switch and the cloud-based Layer 2 gateway device. Establish a bidirectional communication tunnel between the on-premises scalable VLAN switch and the cloud-based Layer 2 gateway device.

[0107] In this embodiment, the system performs connectivity checks, sending probe packets from the on-premises Scalable Virtual LAN switch to the cloud-based Layer 2 gateway device, and receiving responses to confirm path continuity. Based on the verification results, the system initializes the tunnel establishment process, encapsulating Layer 2 packets using the VXLAN protocol to create a symmetrical communication channel between the on-premises and cloud devices. The system ensures the tunnel supports full-duplex data transmission, achieving underlying connectivity between the on-premises and cloud networks.

[0108] Step 1025: Set the encapsulation protocol parameters for the Scalable Virtual LAN Tunnel.

[0109] In this embodiment, the system configures the specific protocol attributes of the extensible virtual LAN tunnel, specifies the virtual network identifier in the VXLAN header to match network segments, sets the service type field in the outer IP header to optimize traffic priority, and adjusts the checksum mechanism of the User Datagram Protocol. The system applies parameters through the protocol stack to ensure that all Layer 2 packets passing through the tunnel are encapsulated according to a unified standard, guaranteeing the integrity and efficiency of data transmission.

[0110] Step 1026: Monitor the operational status and quality indicators of the Scalable Virtual LAN Tunnel.

[0111] In this embodiment, the system continuously monitors the operational data of the Scalable Virtual Local Area Network (VLAN) tunnel, collects connection status to detect interruption events, tracks data flow to confirm transmission activity, and records error counts for fault analysis. The system calculates bandwidth utilization to assess resource usage, measures latency and packet loss rate to determine network performance, and analyzes jitter values ​​to ensure stability. The system outputs reports through a monitoring interface, supporting timely adjustments and maintenance of tunnel operation.

[0112] This application embodiment achieves stable and efficient Layer 2 communication between on-premises and cloud networks through systematic configuration, negotiation, verification, and monitoring of tunnel parameters. It supports seamless data migration and flexible network planning, while ensuring communication quality and reliability through status monitoring.

[0113] In some embodiments, step 103 includes: Step 1031: Receive raw Layer 2 data packets from the on-premises network.

[0114] In this embodiment, the system receives raw Layer 2 data packets from the on-premises network through the network interface of the cloud-based Layer 2 gateway device. These packets are sent by on-premises devices such as VXLAN switches and transmitted to the cloud environment via physical or logical links. The system verifies the integrity of the packet format, ensuring it conforms to the Ethernet frame standard, including checking the frame header structure and checksum, in preparation for subsequent processing. This step serves as the initial entry point for data flowing into the cloud, ensuring that the packets can be further parsed and forwarded.

[0115] Step 1032: Parse the destination media access control address of the original Layer 2 data packet.

[0116] In this embodiment, the system decodes the received raw Layer 2 data packets and reads the destination Media Access Control (MAC) address field in the Ethernet frame header. This process involves parsing the frame structure, locating the address, and extracting the binary data and converting it into a standard format. The system verifies the address validity, for example, by checking whether it is a broadcast, multicast, or unicast address, ensuring that it conforms to network protocol specifications. The parsing result is used to subsequently query the MAC address table to determine the packet forwarding path.

[0117] Step 1033: Query the media access control address table to obtain the virtual network identifier corresponding to the destination media access control address.

[0118] In this embodiment, the system accesses a locally stored media access control address table and uses the parsed destination media access control address as the key for lookup. This table is dynamically updated via the MP-BGP protocol and contains address mappings synchronized between the cloud and on-premises environments. The system matches address entries and retrieves the corresponding virtual network identifier. If no match is found, the packet is discarded or error handling is triggered. The query result provides a virtual network identifier for selecting an appropriate VXLAN tunnel.

[0119] Step 1034: Select the corresponding Scalable Virtual LAN tunnel based on the virtual network identifier.

[0120] In this embodiment, the system queries the tunnel configuration database based on the acquired virtual network identifier to match the corresponding Scalable Virtual Local Area Network (VLAN) tunnel. This database stores tunnel endpoint information, such as the IP addresses of cloud-based L2GW and on-premises VXLAN switches. The system applies routing policies, such as load balancing or priority, to select an active tunnel. The selection process ensures that the tunnel is bound to the virtual network identifier, guaranteeing that packets are transmitted on the correct logical path.

[0121] Step 1035: Add an Extensible Virtual LAN Encapsulation header to the original Layer 2 data packet.

[0122] In this embodiment, the system encapsulates the original Layer 2 data packets by adding an extensible Virtual Local Area Network (VXLAN) encapsulation header. This header includes a Virtual Network Identifier (VNI) field, an outer IP header (source: on-premises device IP, destination: cloud L2GW IP), and a UDP port. The system calculates the checksum and updates the packet length to ensure the encapsulated packet conforms to the VXLAN protocol standard. The encapsulation process converts the Layer 2 packet into a data unit that can be transmitted over a Layer 3 network, enabling communication across cloud boundaries.

[0123] Step 1036: Transmit the encapsulated data packet through the selected Scalable Virtual LAN tunnel.

[0124] In this embodiment, the system sends encapsulated data packets to the cloud environment through a selected scalable virtual LAN tunnel. The transmission process utilizes IP network routing mechanisms to forward packets based on the tunnel endpoint address. The system monitors the tunnel status to ensure link availability, for example, by maintaining the connection through heartbeat detection. The packets are relayed through intermediate network devices and finally reach the L2GW device in the cloud, completing the data transfer from on-premises to the cloud.

[0125] Step 1037: Receive the encapsulated data packets at the Layer 2 gateway device in the cloud and perform the decapsulation operation.

[0126] In this embodiment, the cloud-based Layer 2 gateway device receives encapsulated data packets transmitted through a tunnel, verifies their integrity, and then performs decapsulation. The system parses the Extensible Virtual LAN (AVL) encapsulation header, extracting the virtual network identifier and the original Layer 2 data packet. After removing the outer header, the system uses the inner destination Media Access Control (MAC) address and the AVL identifier to query the flow table to determine the host machine where the target virtual machine resides. The decapsulated packet is forwarded to the corresponding host machine, and guided by the OVS flow table to the final virtual machine, completing the cloud processing.

[0127] This application's embodiments dynamically manage address mapping by parsing and querying the Media Access Control (MAC) address table, combined with VXLAN tunnel encapsulation and decapsulation, ensuring that packets maintain Layer 2 characteristics during cross-environment transmission. This supports seamless migration of services to the cloud without modifying private IP addresses or network configurations, improving the flexibility and compliance of network planning, while optimizing communication performance and scalability.

[0128] In some embodiments, this application configures BGP Speakers both on-premises and in the cloud, and establishes neighbor relationships using MP-BGP to synchronize MAC addresses, VLAN IDs, and IP addresses between the on-premises and cloud environments. When a BGP Speaker learns a new MAC address, it announces this information to other Speakers via BGP, enabling the entire network to quickly learn and update its MAC address table. Furthermore, the BGP Speaker can act as a proxy for ARP (Address Resolution Protocol) or ND (Neighbor Discovery), assisting in handling ARP requests. A VXLAN tunnel is established between the on-premises VXLAN switch and the cloud L2GW. Through the encapsulation and decapsulation of Layer 2 packets via the VXLAN tunnel, interoperability between the on-premises and cloud Layer 2 networks is achieved.

[0129] In some embodiments, such as Figure 2 As shown, the L2GW network element interacts with the SDN server to pull the virtual machine IP and MAC address in the cloud. This information is used to build a Type 2 route advertisement to the on-premises BGP speaker, allowing the on-premises network to learn the MAC address of the cloud.

[0130] When L2GW, acting as a cloud-based BGP speaker, receives a Type 2 route from an on-premises BGP speaker, the message contains the IP and MAC mappings of the on-premises host. The IP and MAC addresses in the route are resolved and sent to the server, which then saves this information to the database.

[0131] The host controller then retrieves the saved MAC addresses from the server to distribute flow tables to OVS.

[0132] In some embodiments, refer to Figure 3The on-premises VXLAN switch acts as both the on-premises BGP speaker and the on-premises VXLAN terminal (i.e., the on-premises VTEP). The on-premises virtual network element (L2GW) acts as both the on-premises VTEP and the on-premises BGP speaker. The two BGP speakers establish a neighbor relationship via MP-BGP for synchronizing BGP NLRI. When there are MAC address updates, additions, or deletions on either the on-premises or cloud virtual machines, they communicate with each other via Type 2 routing, establishing a MAC address and IP address mapping between the cloud and on-premises systems.

[0133] Type 2 routes, also known as MAC Advertisement Routes, are primarily used to advertise and learn the MAC address information of remote sites. When a speaker in the cloud or on-premises receives a frame with an unknown MAC address, it generates a Type 2 route and propagates it to the other party via BGP. This route contains the MAC address and its corresponding IP address, thus completing the construction of the MAC address table for the other party in the cloud or on-premises environment.

[0134] Type 2 routing format: <rt-type> : <route-type> <rd> <esi> <mac-address> <ip-address> <mpls-label> <next-hop> <rt-type>This indicates the route type; for Type 2 routes, the value is 0x02. <route-type>This indicates the specific type of route; for Type 2 routes, its value is 0x01. <rd>It is the Route Distinguisher, used to distinguish the same route across different VRFs; <esi>It is the Ethernet Segment Identifier, used to identify an Ethernet segment; <mac-address>and <ip-address>These are the MAC address and the IP address, respectively. <mpls-label>It is an MPLS tag; <next-hop>This is the next-hop address. This application primarily focuses on the MAC address and IP address fields.

[0135] When a MAC address becomes inactive or invalid for some reason (such as interface downtime or MAC address aging), it sends a Type 2 route withdrawal message. This message contains the previously advertised MAC address, IP address, and associated MPLS label information. The speaker receiving this message removes the corresponding entry from its MAC address table, ensuring that it will not attempt to forward traffic through invalid paths again.

[0136] The format of a MAC Withdrawal Route is similar to that of a normal MAC Advertisement Route, but it carries a special flag indicating that this is a reversal message. Specifically, the format of a MAC Withdrawal Route is as follows: <rt-type> : <route-type> <rd> <esi> <mac-address> <ip-address> <mpls-label> <next-hop> <withdraw-flag> in, <withdraw-flag>This is a flag indicating that this is a revocation message. In an actual BGP update message, this flag may manifest as a specific attribute or field value, instructing the receiver to delete rather than add or update the corresponding MAC address entry.

[0137] With MAC Withdrawal Route, MAC address tables can be dynamically adjusted both in the cloud and on-premises environments. In some embodiments, refer to Figure 4 When an on-premises host needs to access the cloud, if the host does not have an ARP cache at this time, it sends an ARP request. When the ARP request reaches the on-premises BGP speaker, the BGP speaker replies with an ARP reply based on the constructed MAC address table.

[0138] When a cloud host needs to access an on-premises server, if the host does not have an ARP cache, it sends an ARP request. The cloud ARP request is answered by the OVS flow table of the compute node. The flow table of the compute node is shown in the architecture diagram above, and it is generated by the compute node based on the IP and MAC address sent to the server by L2GW.

[0139] In some embodiments, refer to Figure 5 The on-premises to cloud communication process is as follows: When a Layer 2 packet from the on-premises reaches the VXLAN switch, the VXLAN switch encapsulates the packet according to its VXLAN configuration. When the VXLAN packet reaches the L2GW in the cloud, the L2GW decapsulates the packet to expose the inner Layer 2 packet. The L2GW then uses the target IP address and VNI to find the host machine of the VM to which the corresponding VPC belongs. The L2GW then encapsulates the packet onto the corresponding host machine. The host machine forwards the packet to the appropriate VM according to the flow table, thus completing the Layer 2 packet forwarding from on-premises to the cloud.

[0140] In some embodiments, refer to Figure 6 The cloud-to-on-premises communication process is as follows: When a Layer 2 packet from the cloud reaches the L2GW, the L2GW finds the corresponding VXLAN tunnel configuration to the on-premises machine based on the packet's VNI and IP address. It then encapsulates the VXLAN packet according to the configuration. After the VXLAN packet reaches the on-premises machine, the on-premises VXLAN switch decapsulates the packet to expose the Layer 2 packet. The VXLAN switch then forwards the packet to the corresponding on-premises machine based on the port number corresponding to the MAC address. This completes the Layer 2 packet forwarding from the cloud to the cloud.

[0141] Layer 2 communication technology for both cloud and on-premises environments provides the capability to build such networks. Users can migrate their services to the cloud without changing their private IP addresses, and existing interoperability services require no configuration modifications. Therefore, users can migrate some services to the cloud without altering their existing network plans. Compared to other Layer 3 interoperability technologies such as leased lines and EIP, Layer 2 communication offers customers greater flexibility in network planning.

[0142] Achieving Layer 2 interoperability between the cloud and on-premises networks allows for more flexible planning of both cloud and on-premises networks.

[0143] Interoperability can be achieved even when there are network segment conflicts between cloud and on-premises environments.

[0144] In certain specific scenarios, only specific network segments are allowed for network planning, which is more in line with regulatory requirements.

[0145] Migrating from on-premises to the cloud does not require changing the IP address.

[0146] This application establishes neighbor relationships between on-premises BGP speakers and cloud-based BGP speakers using MP-BGP. On-premises and cloud systems mutually advertise ARP routes, including MAC addresses, VLAN IDs, and IP addresses, via BGP. When a BGP speaker learns a new MAC address, it announces this information to other speakers via BGP, enabling the entire network to quickly learn and update its MAC address table. Additionally, the BGP speaker can act as an ARP (Address Resolution Protocol) or ND (Neighbor Discovery) proxy, assisting in handling ARP requests. On-premises VXLAN switches and cloud-based L2GWs establish VXLAN tunnels, allowing on-premises and cloud systems to encapsulate and decapsulate Layer 2 packets via these tunnels, thus achieving interoperability between the on-premises and cloud Layer 2 networks.

[0147] Some embodiments of this application can achieve the following technical effects: Implementing MAC address announcements between cloud and on-premises environments via BGP Speaker: This application achieves synchronization of MAC addresses, VLAN IDs, and IP addresses between cloud and on-premises environments by configuring BGP Speakers separately in the on-premises and cloud environments and establishing neighbor relationships using MP-BGP. This effectively solves the problem of MAC address table construction during Layer 2 communication between cloud and on-premises environments.

[0148] Layer 2 packet interoperability via VXLAN tunnels: This application establishes VXLAN tunnels on-premises and in the cloud to encapsulate and decapsulate Layer 2 packets, enabling efficient interoperability of Layer 2 packets between the cloud and on-premises environments, thereby improving the flexibility and convenience of user network planning.

[0149] This application uses BGP Speaker to proxy ARP requests, enabling MAC address learning between cloud and on-premises hosts and solving the problem of MAC address learning between cloud and on-premises hosts.

[0150] Based on the foregoing embodiments, this application provides a cloud communication device, which includes various units and modules included in each unit, which can be implemented by a processor in a computer device; of course, it can also be implemented by specific logic circuits; in the implementation process, the processor can be a central processing unit (CPU), a microprocessor unit (MPU), a digital signal processor (DSP), or a field programmable gate array (FPGA), etc.

[0151] Figure 7 This is a schematic diagram of the composition structure of a cloud communication device provided in an embodiment of this application, such as... Figure 7 As shown, the cloud communication device 30 includes: Processing module 301 is used to learn media access control addresses between cloud hosts and on-premises hosts by using a border gateway protocol speaking device to resolve protocol requests based on the media access control address table proxy address. Establish a scalable virtual LAN tunnel between an on-premises scalable virtual LAN switch and a cloud-based Layer 2 gateway device. Communication module 302 is used to encapsulate Layer 2 data packets through the scalable virtual local area network tunnel to realize Layer 2 data packet transmission from the on-premises network to the cloud network; The scalable virtual LAN tunnel decapsulates Layer 2 data packets, enabling Layer 2 data packet transmission from the cloud network to the on-premises network.

[0152] In some embodiments, the processing module 301 is further configured to: Configure border gateway protocol speaking devices in both the on-premises network and the cloud network, and establish neighbor relationships between the border gateway protocol speaking devices through the multi-protocol border gateway protocol. Network layer reachability information is synchronized through the neighbor relationship between the speaking devices of the border gateway protocol, and the network layer reachability information includes the mapping relationship between media access control addresses and Internet protocol addresses; A media access control address table is constructed based on the network layer reachability information.

[0153] In some embodiments, the processing module 301 is further configured to: Configure the multi-protocol border gateway protocol parameters for the scalable virtual LAN switch and the virtualized Layer 2 gateway device, wherein the scalable virtual LAN switch is deployed in the on-premises network and has border gateway protocol speaking function, and the virtualized Layer 2 gateway device is deployed in the cloud network and has border gateway protocol speaking function; A session connection is established between the scalable virtual LAN switch and the virtualized Layer 2 gateway device using a transmission protocol specified by a preset standard. Exchange routing capability information between the scalable virtual LAN switch and the virtualized Layer 2 gateway device; Verify the neighbor status between the scalable virtual LAN switch and the virtualized Layer 2 gateway device; Maintain a persistent session connection between the scalable virtual LAN switch and the virtualized Layer 2 gateway device.

[0154] In some embodiments, the processing module 301 is further configured to: Monitor media access control address change events for virtual machines in the cloud and on-premises hosts; Generate a Type 2 route advertisement containing a mapping between Media Access Control addresses and Internet Protocol addresses; The Type 2 route advertisement is transmitted to the peer border gateway protocol speaking device via a multi-protocol border gateway protocol session; Parse the Media Access Control address field and Internet Protocol address field in the received Type 2 routing advertisement; Update the local storage record of media access control addresses and Internet protocol addresses mappings; In some embodiments, the processing module 301 is further configured to: When a media access control address is detected to be invalid, a type 2 route revocation message is generated; The Type 2 route revocation message is transmitted to the peer border gateway protocol speaking device via a multi-protocol border gateway protocol session.

[0155] In some embodiments, the processing module 301 is further configured to: Extract media access control address entries from the network layer reachability information; Verify the validity and completeness of the media access control address entries; If the media access control address entry is verified, the media access control address entry is written into the media access control address table storage area. A media access control address table is obtained by establishing the mapping between media access control addresses and virtual network identifiers.

[0156] In some embodiments, the processing module 301 is further configured to: Set the time-to-live (TTL) parameter for media access control address entries; Regularly check the activity status of entries in the media access control address table; Remove invalid media access control address entries that have exceeded their time-to-live (TTL) parameter.

[0157] In some embodiments, the communication module 302 is further configured to: Listen for Address Resolution Protocol (ARP) request packets in the network; Parse the target Internet Protocol address in the Address Resolution Protocol Request packet; Query the media access control address table for the media access control address record corresponding to the target Internet Protocol address; When a valid Media Access Control address record is found, an Address Resolution Protocol (ARP) response packet is generated. The Address Resolution Protocol (ARP) response data packet is sent to the ARP requester.

[0158] In some embodiments, the communication module 302 is further configured to: When no valid Media Access Control address record is found, the Address Resolution Protocol (ARP) request is forwarded to another network node. Recording the mapping between Address Resolution Protocol (ARP) requests and responses is used for network optimization.

[0159] In some embodiments, the communication module 302 is further configured to: Configure the tunnel interface parameters of the on-premises scalable virtual LAN switch; Configure the tunnel interface parameters of the cloud-based Layer 2 gateway device; Negotiate tunnel establishment parameters between the on-premises scalable virtual LAN switch and the cloud-based Layer 2 gateway device; Verify the network connectivity between the on-premises scalable virtual LAN switch and the cloud-based Layer 2 gateway device; establish a bidirectional communication tunnel between the on-premises scalable virtual LAN switch and the cloud-based Layer 2 gateway device. Configure the encapsulation protocol parameters for the scalable virtual LAN tunnel; Monitor the operational status and quality metrics of scalable virtual LAN tunnels.

[0160] In some embodiments, the communication module 302 is further configured to: Receive raw Layer 2 data packets from the on-premises network; Parse the destination media access control address of the original Layer 2 data packet; Query the media access control address table to obtain the virtual network identifier corresponding to the destination media access control address; Select the corresponding Scalable Virtual LAN tunnel based on the virtual network identifier; Add an Extensible Virtual LAN Encapsulation header to the original Layer 2 data packet; Encapsulated data packets are transmitted through the selected Scalable Virtual LAN tunnel; The encapsulated data packets are received at the Layer 2 gateway device in the cloud, and the decapsulation operation is performed.

[0161] This application embodiment achieves Media Access Control address learning through Border Gateway Protocol (BGP) proxy address resolution protocol requests, establishes a scalable virtual LAN tunnel, and uses this tunnel to encapsulate and decapsulate Layer 2 data packets, ultimately achieving efficient interoperability between Layer 2 networks on and off the cloud. This ensures dynamic synchronization of network addresses and reliable data transmission, improves the flexibility of user network planning, supports service migration without changing existing IP configurations, and enhances network scalability and isolation.

[0162] The descriptions of the apparatus embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. In some embodiments, the functions or modules included in the apparatus provided in this application can be used to perform the methods described in the method embodiments above. For technical details not disclosed in the apparatus embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0163] It should be noted that, in the embodiments of this application, if the above-described cloud communication method is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, mobile hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware, software, or firmware, or any combination of hardware, software, and firmware.

[0164] This application provides a computer device including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the above-described method.

[0165] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements some or all of the steps in the above-described method. The computer-readable storage medium can be transient or non-transient.

[0166] This application provides a computer program including computer-readable code, wherein when the computer-readable code is executed in a computer device, a processor in the computer device performs some or all of the steps in the above-described method.

[0167] This application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0168] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referred to interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0169] It should be noted that, Figure 8 This is a schematic diagram of a hardware entity of a computer device in an embodiment of this application, such as... Figure 8 As shown, the hardware entity of the computer device 700 includes: one or more processors 701, a communication interface 702, and a memory 703, wherein: Processor 701 typically controls the overall operation of computer device 700.

[0170] Communication interface 702 enables computer devices to communicate with other terminals or servers over a network.

[0171] The memory 703 is configured to store instructions and applications executable by the processor 701, and can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data, and video communication data) in the processor 701 and various modules in the computer device 700. It can be implemented using flash memory or random access memory (RAM). Data transfer between the processor 701, the communication interface 702, and the memory 703 can be performed via bus 704. Only one processor is shown in the figure; each processor 100 includes one or more cores.

[0172] It should be noted that the computer device may include multiple processors 701, and each processor 701 can interact with each other through aggregated communication methods such as all-to-all, all-gather, or all-reduce. The processors 701 may be central processing units (CPUs), graphics processing units (GPUs), embedded neural network processing units (NPUs), tensor processing units (TPUs), data processing units (DPUs), accelerated processing units (APUs), floating-point processing units (FPUs), or application-specific integrated circuits (ASICs). The processors may also be single-core or multi-core processors. The processor may consist of a CPU and hardware chips. The hardware chips may be ASICs, PLDs, or combinations thereof. The PLDs may be complex programmable logic devices (CPLDs), FPGAs, generic array logic (GALs), or any combination thereof. The processor can also be implemented using logic devices with built-in processing logic, such as FPGAs or digital signal processors (DSPs).

[0173] The communication interface 702 can be a wired interface or a wireless interface, used to communicate with other modules or devices. The wired interface can be an Ethernet interface, a local interconnect network (LIN), etc., and the wireless interface can be a cellular network interface or a wireless LAN interface, etc.

[0174] Memory 703 can be non-volatile memory, such as read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Memory 703 can also be volatile memory, which can be random access memory (RAM) used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synclink dynamic random access memory (SLDRAM), and direct rambus RAM (DRRAM), direct rambus DRAM (DRDRAM), and rambus DRAM.

[0175] The 704 bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. < / next-hop> < / mpls-label> < / ip-address> < / mac-address> < / esi> < / rd> < / route-type> < / rt-type> < / esi> < / rd> < / next-hop> < / mpls-label> < / ip-address> < / mac-address> < / esi> < / rd> < / route-type> < / rt-type>

Claims

1. A cloud communication method, characterized in that, The method includes: By using the border gateway protocol speaking device to parse protocol requests based on the media access control address table proxy address, media access control address learning between cloud hosts and on-premises hosts is achieved; Establish a scalable virtual LAN tunnel between an on-premises scalable virtual LAN switch and a cloud-based Layer 2 gateway device. Layer 2 data packets are encapsulated through the scalable virtual LAN tunnel to enable Layer 2 data packet transmission from the on-premises network to the cloud network; The scalable virtual LAN tunnel decapsulates Layer 2 data packets, enabling Layer 2 data packet transmission from the cloud network to the on-premises network.

2. The method according to claim 1, characterized in that, Before the step of the border gateway protocol speaking device making a proxy address resolution protocol request based on the media access control address table to achieve media access control address learning between cloud hosts and on-premises hosts, the method further includes: Configure border gateway protocol speaking devices in both the on-premises network and the cloud network, and establish neighbor relationships between the border gateway protocol speaking devices through the multi-protocol border gateway protocol. Network layer reachability information is synchronized through the neighbor relationship between the speaking devices of the border gateway protocol, and the network layer reachability information includes the mapping relationship between media access control addresses and Internet protocol addresses; A media access control address table is constructed based on the network layer reachability information.

3. The method according to claim 2, characterized in that, The step of configuring border gateway protocol speaking devices in both the on-premises and cloud networks, and establishing neighbor relationships between these devices via the multi-protocol border gateway protocol, includes: Configure the multi-protocol border gateway protocol parameters for the scalable virtual LAN switch and the virtualized Layer 2 gateway device, wherein the scalable virtual LAN switch is deployed in the on-premises network and has border gateway protocol speaking function, and the virtualized Layer 2 gateway device is deployed in the cloud network and has border gateway protocol speaking function; A session connection is established between the scalable virtual LAN switch and the virtualized Layer 2 gateway device using a transmission protocol specified by a preset standard. Exchange routing capability information between the scalable virtual LAN switch and the virtualized Layer 2 gateway device; Verify the neighbor status between the scalable virtual LAN switch and the virtualized Layer 2 gateway device; Maintain a persistent session connection between the scalable virtual LAN switch and the virtualized Layer 2 gateway device.

4. The method according to claim 2, characterized in that, The synchronization of network layer reachability information between speaking devices via the border gateway protocol, wherein the network layer reachability information includes a mapping relationship between media access control addresses and internet protocol addresses, including: Monitor media access control address change events for virtual machines in the cloud and on-premises hosts; Generate a Type 2 route advertisement containing a mapping between Media Access Control addresses and Internet Protocol addresses; The Type 2 route advertisement is transmitted to the peer border gateway protocol speaking device via a multi-protocol border gateway protocol session; Parse the Media Access Control address field and Internet Protocol address field in the received Type 2 routing advertisement; Update the local storage media access control address to Internet protocol address mapping record.

5. The method according to claim 4, characterized in that, The method further includes: When a media access control address is detected to be invalid, a type 2 route revocation message is generated; The Type 2 route revocation message is transmitted to the peer border gateway protocol speaking device via a multi-protocol border gateway protocol session.

6. The method according to claim 2, characterized in that, The step of constructing a media access control address table based on the network layer reachability information includes: Extract media access control address entries from the network layer reachability information; Verify the validity and completeness of the media access control address entries; If the media access control address entry is verified, the media access control address entry is written into the media access control address table storage area. A media access control address table is obtained by establishing the mapping between media access control addresses and virtual network identifiers.

7. The method according to claim 6, characterized in that, The method further includes: Set the time-to-live (TTL) parameter for media access control address entries; Regularly check the activity status of entries in the media access control address table; Remove invalid media access control address entries that have exceeded their time-to-live (TTL) parameter.

8. The method according to claim 1, characterized in that, The method of using a border gateway protocol speaking device to perform media access control address learning between cloud hosts and on-premises hosts based on a media access control address table proxy address resolution protocol request includes: Listen for Address Resolution Protocol (ARP) request packets in the network; Parse the target Internet Protocol address in the Address Resolution Protocol Request packet; Query the media access control address table for the media access control address record corresponding to the target Internet Protocol address; When a valid Media Access Control address record is found, an Address Resolution Protocol (ARP) response packet is generated. The Address Resolution Protocol (ARP) response data packet is sent to the ARP requester.

9. The method according to claim 8, characterized in that, The method further includes: When no valid Media Access Control address record is found, the Address Resolution Protocol (ARP) request is forwarded to another network node. Recording the mapping between Address Resolution Protocol (ARP) requests and responses is used for network optimization.

10. The method according to claim 1, characterized in that, The establishment of a scalable virtual LAN tunnel between the on-premises scalable virtual LAN switch and the cloud-based Layer 2 gateway device includes: Configure the tunnel interface parameters of the on-premises scalable virtual LAN switch; Configure the tunnel interface parameters of the cloud-based Layer 2 gateway device; Negotiate tunnel establishment parameters between the on-premises scalable virtual LAN switch and the cloud-based Layer 2 gateway device; Verify the network connectivity between the on-premises scalable virtual LAN switch and the cloud-based Layer 2 gateway device; establish a bidirectional communication tunnel between the on-premises scalable virtual LAN switch and the cloud-based Layer 2 gateway device. Configure the encapsulation protocol parameters for the scalable virtual LAN tunnel; Monitor the operational status and quality metrics of scalable virtual LAN tunnels.

11. The method according to claim 1, characterized in that, The process of encapsulating Layer 2 data packets through the scalable virtual LAN tunnel to achieve Layer 2 data packet transmission from the on-premises network to the cloud network includes: Receive raw Layer 2 data packets from the on-premises network; Parse the destination media access control address of the original Layer 2 data packet; Query the media access control address table to obtain the virtual network identifier corresponding to the destination media access control address; Select the corresponding Scalable Virtual LAN tunnel based on the virtual network identifier; Add an Extensible Virtual LAN Encapsulation header to the original Layer 2 data packet; Encapsulated data packets are transmitted through the selected Scalable Virtual LAN tunnel; The encapsulated data packets are received at the Layer 2 gateway device in the cloud, and the decapsulation operation is performed.

12. A cloud communication device, characterized in that, The method includes: The processing module is used to resolve protocol requests based on the Media Access Control Address Table proxy address through the border gateway protocol speaking device, thereby enabling media access control address learning between cloud hosts and on-premises hosts. Establish a scalable virtual LAN tunnel between an on-premises scalable virtual LAN switch and a cloud-based Layer 2 gateway device. The communication module is used to encapsulate Layer 2 data packets through the scalable virtual local area network tunnel to realize Layer 2 data packet transmission from the on-premises network to the cloud network; The scalable virtual LAN tunnel decapsulates Layer 2 data packets, enabling Layer 2 data packet transmission from the cloud network to the on-premises network.

13. A computer device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the program, it implements the cloud communication method according to any one of claims 1 to 11.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the cloud communication method according to any one of claims 1 to 11.

15. A computer program product, the computer program product comprising a non-transitory computer-readable storage medium storing a computer program, characterized in that, When the computer program is read and executed by a computer, it implements the steps in the cloud communication method according to any one of claims 1 to 11.

Images