A message forwarding method and electronic device

Abstract

The application belongs to the technical field of message forwarding, and particularly relates to a message forwarding method and electronic equipment. The message forwarding method is suitable for a message processing platform, and characterized in that the method comprises the following steps: obtaining outer header information of a target message; determining whether there is decapsulation information of the target message in a remote forwarding table according to the outer header information; when it is determined that there is the decapsulation information of the target message in the remote forwarding table, decapsulating the target message according to the decapsulation information to obtain inner header information; and determining a forwarding mode of the target message according to the inner header information and the remote forwarding table. The method solves the problem that in the prior art, in a multi-tenant and large-scale node interconnection scene, a huge workload appears, a configuration period is lengthened, and edge devices or nodes cannot be flexibly added or reduced in the later period. The method reduces state expansion caused by the growth of a running state object, remote nodes and VNI numbers.

Description

Technical Field

[0001] This invention belongs to the technical field of message forwarding, and specifically relates to a message forwarding method and electronic device. Background Technology

[0002] VXLAN has been widely adopted as a standard Layer 2 overlay network technology. By encapsulating outer IP / UDP / VXLAN headers on the Layer 3 underlay network, multiple Layer 2 broadcast domains are mapped to different VNIs, thereby achieving tenant isolation, Layer 2 extension, and cross-node interconnection.

[0003] VPP (Vector Packet Processing) is a software packet processing platform designed for high-performance network forwarding scenarios. Its core feature is the use of vectorized batch processing and graph node scheduling mechanisms on general-purpose processors to organize interface sending and receiving, protocol parsing, table lookup, encapsulation, forwarding, and statistical observation into a composable data plane processing chain.

[0004] On the control plane, operations and maintenance personnel explicitly issue parameters such as local VTEP (endpoint), remote VTEP, VNI, encap FIB (encapsulation and forwarding table), decap (decapsulation) - next via CLI or API to create static VXLAN tunnels (exact match static tunnels). Each tunnel typically corresponds to an independent virtual interface, which is then connected to a bridge domain and participates in local Layer 2 forwarding. Secondly, in the inbound direction, after a packet enters the VXLAN input node, the VXLAN header is first verified. Then, a lookup key is formed using outer (external) source (source address / source field), outer (external) destination (destination address / destination field), FIB (forwarding table), and VNI. If the tunnel lookup table is matched, the packet enters the decapsulation path; if not, it is directly counted as no-such-tunnel (no exact match static tunnel match) and discarded.

[0005] Secondly, in the outbound direction, after selecting a tunnel interface for bridging or forwarding, that tunnel provides local / remote VTEP, VNI, and rewrite information to complete the outer header assembly and forward it along the underlay (bearer network / lower layer 3 network). Finally, in flooding and replication scenarios, multicast flooding (flooding replication) or head-end replication based on a static tunnel set is typically used. That is, remote replication members are pre-configured by the control plane, rather than formed by runtime self-learning.

[0006] In summary, the current VPP technical solution can be described as a VXLAN implementation system that uses static tunnels as the main object, exact matching as the main entry point, interface-driven encapsulation as the main path, and control plane pre-configuration as the main means. VPP can work stably in small- to medium-scale deployments and can meet the traditional VXLAN service requirements of "manual tunnel construction, interface bridging to domains, and tunnel-based forwarding".

[0007] The size of the running objects grows approximately linearly with the number of remote VTEPs * the number of VNIs. In multi-tenant, large-scale node interconnection scenarios, the static per-peer tunnel interface model leads to a rapid expansion of the number of interface objects, FIB tracking objects, configuration items, and operational complexity. If static tunnels are pre-built manually one by one, the workload will be enormous, the configuration cycle will be longer, and it will be impossible to flexibly add or remove edge devices or nodes (VTEPs) later. Summary of the Invention

[0008] This application addresses the problem of rapidly increasing configuration items and operational complexity in multi-tenant, large-scale node interconnection scenarios. It addresses the issue that relying solely on manual pre-construction of static tunnels leads to enormous workload, prolonged configuration cycles, and an inability to flexibly add or remove edge devices or nodes later. The proposed solution enables unknown remote nodes to enter the subsequent learning and forwarding process, eliminating the need for manual pre-construction of static tunnels. This reduces the state expansion of runtime objects caused by the increase in the number of remote nodes and VNIs, while maintaining VXLAN standard compatibility.

[0009] To address the aforementioned technical problems, this application proposes two aspects.

[0010] Firstly, this application proposes a message forwarding method applicable to a message processing platform, characterized by comprising: obtaining outer header information of a target message, wherein the target message is a message for which a static tunnel has not been hit in the message processing platform; determining, based on the outer header information, whether decapsulation information of the target message exists in a remote forwarding table, wherein the remote forwarding table is learned by the message processing platform; when it is determined that decapsulation information of the target message exists in the remote forwarding table, decapsulating the target message according to the decapsulation information to obtain inner header information; and determining the forwarding method for the target message based on the inner header information and the remote forwarding table.

[0011] In some embodiments, determining the forwarding method for the target packet based on the inner header information and the remote forwarding table includes: determining whether the target remote is a learned remote in the remote forwarding table based on the target remote information in the inner header information, wherein the target remote is the remote to which the target packet is ultimately delivered, and the target remote information is the remote information of the target remote; when the target remote is determined to be a learned remote, generating new outer header information based on the target remote information and the address information of the packet processing platform; and forwarding the target packet to the target remote based on the new outer header information.

[0012] In some embodiments, when the target remote end is determined to be an unlearned remote end, the method further includes: determining a first remote end set based on the remote end forwarding table; obtaining a second remote end set preset for the message processing platform; determining a third remote end set to be broadcast based on the first remote end set and the second remote end set; generating an encapsulation packet for each remote end in the third remote end set based on the remote end information of each remote end in the third remote end set and the address information of the message processing platform, and sending each encapsulation packet to the corresponding remote end.

[0013] In some embodiments, when the decapsulation information of the target packet is not present in the remote forwarding table, the method further includes: determining whether the source remote of the target packet belongs to the learning target of the packet processing platform based on the outer header information; when the source remote belongs to the learning target, generating a learning task for the source remote based on the outer header information; and updating the remote forwarding table based on the learning task.

[0014] In some embodiments, determining whether the source remote end of the target message belongs to the learning target of the message processing platform based on the outer header information includes: determining whether the target access point of the target message and the source remote end belong to the learning range of the message processing platform based on a preset second remote end set and the outer header information, wherein the second remote end set is a preset range of manageable remote ends for the message processing platform; when it is determined that the source remote end and the target access point belong to the learning range, determining whether there is suppression information for the source remote end and the target access point based on the outer header information; when there is no suppression information, determining whether there is already a learning task for the source remote end and the target access point based on the outer header information; when there is no learning task, determining that the source remote end and the target access point are the learning targets of the message processing platform.

[0015] In some embodiments, the method further includes updating the most recent usage time of the learned entry each time a learned entry is hit in the remote forwarding table.

[0016] In some embodiments, the method further includes: periodically obtaining the most recent usage time of each learned entry in the remote forwarding table; and updating the remote forwarding table according to the most recent usage time of each learned entry.

[0017] In some embodiments, the method further includes updating each remote end in the second remote end set according to the most recent usage time of each learned entry in the remote forwarding table, wherein the most recent communication time of each remote end is updated.

[0018] In some embodiments, the method further includes: periodically acquiring the most recent communication time of each remote end in the second remote end set; and updating the second remote end set according to the most recent communication time.

[0019] In a second aspect, this application proposes an electronic device including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of any of the methods described in the first aspect.

[0020] This application discloses a message forwarding method applicable to a message processing platform. The method includes: obtaining the outer header information of a target message, wherein the target message is a message for which a static tunnel has not been found on the message processing platform; determining whether decapsulation information of the target message exists in a remote forwarding table based on the outer header information, wherein the remote forwarding table is learned by the message processing platform; when the decapsulation information of the target message is determined to exist in the remote forwarding table, decapsulating the target message according to the decapsulation information to obtain inner header information; and determining the forwarding method for the target message based on the inner header information and the remote forwarding table. This method solves the problem that in multi-tenant, large-scale node interconnection scenarios, the number of configuration items and operational complexity rapidly increase. If static tunnels are pre-built manually one by one, the workload becomes enormous, the configuration cycle is prolonged, and there is no flexible addition or removal of edge devices or nodes later. This enables unknown remote nodes to enter the subsequent learning and forwarding process, instead of relying entirely on manual pre-building of static tunnels one by one. While ensuring VXLAN standard compatibility, it reduces the state expansion of running objects caused by the increase in the number of remote nodes and VNIs. Attached Figure Description

[0021] One or more embodiments are illustrated by way of example with reference to the accompanying drawings, and these illustrative descriptions do not constitute a limitation on the embodiments.

[0022] Figure 1 The main flowchart of a message forwarding method provided in an embodiment of this application; Figure 2 A system structure diagram provided for an embodiment of this application; Figure 3 A flowchart of incoming direction learning and receiving anchor point bootstrapping is provided for an embodiment of this application; Figure 4 A known unicast remote forwarding flowchart is provided for embodiments of this application; Figure 5 A flowchart of BUM first hop discovery and state convergence is provided for an embodiment of this application; Figure 6 This is a schematic diagram illustrating the deployment form and packet flow relationship of the technical solution of this application in the NAT gateway service, provided as an embodiment of this application. Figure 7 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0023] VXLAN has been widely adopted as a standard Layer 2 overlay network technology. By encapsulating outer IP / UDP / VXLAN headers on the Layer 3 underlay network, multiple Layer 2 broadcast domains are mapped to different VNIs, thereby achieving tenant isolation, Layer 2 extension, and cross-node interconnection.

[0024] VPP (Vector Packet Processing) is a software packet processing platform designed for high-performance network forwarding scenarios. Its core feature is the use of vectorized batch processing and graph node scheduling mechanisms on general-purpose processors to organize interface sending and receiving, protocol parsing, table lookup, encapsulation, forwarding, and statistical observation into a composable data plane processing chain.

[0025] On the control plane, operations and maintenance personnel explicitly issue parameters such as local VTEP (endpoint), remote VTEP, VNI, encap FIB (encapsulation and forwarding table), decap (decapsulation) - next via CLI or API to create static VXLAN tunnels (exact match static tunnels). Each tunnel typically corresponds to an independent virtual interface, which is then connected to a bridge domain and participates in local Layer 2 forwarding. Secondly, in the inbound direction, after a packet enters the VXLAN input node, the VXLAN header is first verified. Then, a lookup key is formed using outer (external) source (source address / source field), outer (external) destination (destination address / destination field), FIB (forwarding table), and VNI. If the tunnel lookup table is matched, the packet enters the decapsulation path; if not, it is directly counted as no-such-tunnel (no exact match static tunnel match) and discarded.

[0026] Secondly, in the outbound direction, after selecting a tunnel interface for bridging or forwarding, that tunnel provides local / remote VTEP, VNI, and rewrite information to complete the outer header assembly and forward it along the underlay (bearer network / lower layer 3 network). Finally, in flooding and replication scenarios, multicast flooding (flooding replication) or head-end replication based on a static tunnel set is typically used. That is, remote replication members are pre-configured by the control plane, rather than formed by runtime self-learning.

[0027] In summary, the current VPP technical solution can be described as a VXLAN implementation system that uses static tunnels as the main object, exact matching as the main entry point, interface-driven encapsulation as the main path, and control plane pre-configuration as the main means. VPP can work stably in small- to medium-scale deployments and can meet the traditional VXLAN service requirements of "manual tunnel construction, interface bridging to domains, and tunnel-based forwarding".

[0028] The size of the running objects grows approximately linearly with the number of remote VTEPs * the number of VNIs. In multi-tenant, large-scale node interconnection scenarios, the static per-peer tunnel interface model leads to a rapid expansion of the number of interface objects, FIB tracking objects, configuration items, and operational complexity. If static tunnels are pre-built manually one by one, the workload will be enormous, the configuration cycle will be longer, and it will be impossible to flexibly add or remove edge devices or nodes (VTEPs) later.

[0029] To address the aforementioned shortcomings, this invention proposes a message forwarding method and electronic device. Its core approach is not to further increase the number of static tunnels, but rather to reorganize the system's main object into seven categories: learning-domain, vni_port (VNI logical access point), peer (peer node object), remote_FDB (remote forwarding table), vni_peer (VNI-remote relationship table), discovery_seeds_by_vni (discovery seed set managed by VNI), and decap-anchor (suppression state). The overall logic of this scheme is as follows: First, the learning-domain defines "where to receive and which VNIs to receive"; then, the vni_port (VNI logical entry point) takes on the role of the local VNI entry point; then, the peer (peer node object) takes on the role of sharing the underlay forwarding status of the remote VTEP; then, remote_FDB and vni_pee form a dual-plane structure of "known unicast + remote replication"; at the same time, the per-VNI seed and decap-anchor mechanisms provide controlled discovery and controlled bootstrapping; finally, unified aging and show / clear operations bring the entire process together.

[0030] The following is a detailed description of the implementation details of a message forwarding method in this embodiment. The following content is only for the convenience of understanding and is not necessary for implementing this solution.

[0031] Example 1: like Figure 1 As shown, this application provides a message forwarding method applicable to a message processing platform. The electronic device on which the message processing platform is located can be a server, mobile terminal, computer, cloud platform, etc. The data processing functionality of the production equipment provided in this application embodiment can be implemented by the processor of the electronic device calling program code, wherein the program code can be stored in a computer storage medium. The message forwarding method includes: The core of VXLAN is "MAC in UDP" encapsulation—the original Layer 2 frame is encapsulated into a UDP packet, transmitted over the underlying IP network, and then decapsulated at the destination to restore the original frame. Therefore, when a VPP receives a message, the message is divided into an inner layer and an outer layer. The inner layer stores the sender information and the destination information of the message. The sender is the source remote end mentioned in this application, and the destination is the target remote end.

[0032] However, since the two ends may have the same IP address, end-to-end message transmission between them is not possible. Therefore, existing technologies add an outer layer of encapsulation outside the inner layer. This outer layer does not directly send the message to the target end; instead, it first sends it to a relay end (i.e., the message processing platform, VPP, in this application), and then the relay end sends it to the target end. The process of sending to the relay end and from the relay end to the target end can be considered as one communication from the sender to the relay end and one communication from the relay end to the sender. Therefore, when sending from the sender to the relay end, an outer layer is needed. The header information of the sending end and the relay end is written into the outer header information. When the message processing platform receives the message, it extracts the outer header information and determines whether a corresponding static tunnel exists. If so, the message is decapsulated in the corresponding static tunnel, exposing the inner information. When the message is sent from the relay end to the target end, the inner header information can be read because the message has undergone decapsulation. Therefore, when the corresponding static tunnel is determined using the inner header information, the decapsulated message is recapsulated in the corresponding static tunnel and then sent out. In this process, if no corresponding tunnel is found at any stage, the data packet is discarded. This is the existing VPP technology.

[0033] Because existing technologies require pre-setting values ​​for static tunnels, when facing large-scale node interconnection (where these nodes may be virtual), they face the problem of being regenerated and destroyed as needs arise. Therefore, continuing to use static tunnels inevitably leads to a large workload for manual configuration, inability to respond promptly to user demands, resulting in poor packet flow and rapid expansion of static tunnels. Therefore, this application adds a packet processing channel (i.e., the forwarding method in this application) to the existing static tunnel technology approach. This channel is specifically designed to handle packets that cannot be matched with static tunnels. For packets that are not matched with static tunnels, the new processing channel handles them. This channel is learning-based, meaning it does not require pre-setting too many static tunnels and can automatically learn communication between remote endpoints within a preset range. While theoretically, packet forwarding can be completely implemented based on the technical solution of this application, considering that most existing packet forwarding systems use static tunnel systems, the processing channel in this application can also be used as a supplementary processing channel for static tunnel systems, exhibiting high compatibility with existing technologies.

[0034] Since the static tunnel part is existing technology, this application will skip the existing solution part and focus on describing this application. Therefore, the target message for the outer header information obtained by our S1 is the message that did not hit the static tunnel. In the existing VPP technology, such a message would be discarded.

[0035] Step S1: Obtain the outer header information of the target message, wherein the target message is a message that has not been hit by the static tunnel in the message processing platform.

[0036] Step S2: Determine whether the decapsulation information of the target packet exists in the remote forwarding table based on the outer header information, wherein the remote forwarding table is learned by the packet processing platform.

[0037] Although this process looks like the process of determining whether a tunnel has been hit in the prior art, the remote forwarding table in this application is different from the L2FIB (Layer-2 Forwarding Information Base) in the prior art. The remote forwarding table in this application can be updated automatically in real time, and there are two update methods: one is to update new entries by learning, and the other is to update the reduced entries in the remote forwarding table according to the aging of the recorded entries, thereby avoiding the bloat problem that occurs in the prior art, and also eliminating the need to manually establish static tunnels.

[0038] The following steps S3 illustrate the solution of this application in a process example. In step S3, the solution is described in terms of what to do if an entry is hit in the remote forwarding table and what to do if an entry is not hit.

[0039] Step S3: When it is determined that the decapsulation information of the target packet exists in the remote forwarding table, the target packet is decapsulated according to the decapsulation information to obtain the inner header information.

[0040] In fact, the decapsulation information mentioned here refers to the entry that has been matched in the remote forwarding table. For ease of distinction from the subsequent encapsulation process, it is called decapsulation information. The specific information content is essentially the same: it checks for existence based on remote information and the VNI. Therefore, when a target packet that did not match the static tunnel is matched in the remote forwarding table, it can proceed to the decapsulation path.

[0041] In some embodiments, when the decapsulation information of the target packet is not found in the remote forwarding table, the method further includes: Step S31: Determine whether the source of the target message belongs to the learning target of the message processing platform based on the outer header information.

[0042] However, if the target packet is not found in the remote forwarding table, it means that the packet processing platform has not learned information that matches the source of the target packet. In this case, it should learn based on the target packet. However, at this point, this application needs to further distinguish whether the source of the target packet and the VNI are the learning targets of the packet processing platform.

[0043] In some embodiments, step S31, "determining whether the source of the target message belongs to the learning target of the message processing platform based on the outer header information," includes: Step S311: Determine the target access point of the target message and whether the source remote end belongs to the learning range of the message processing platform based on the preset second remote end set and the outer header information, wherein the second remote end set is a preset range of manageable remote ends for the message processing platform.

[0044] Step S312: When it is determined that the source remote end and the target access point are within the learning range, determine whether there is any suppression information for the source remote end and the target access point based on the outer header information.

[0045] Step S313: When there is no suppression information, determine whether there is already a learning task for the source remote end and the target access point based on the outer header information.

[0046] Step S314: When there is no learning task, determine the source remote end and the target access point as the learning target of the message processing platform.

[0047] In this application, when determining whether the source remote end and the target access point (VNI) are learning targets, it is necessary to judge from three levels. The first level is whether the source remote end and the access point belong to the learning scope of the message processing platform, that is, the second remote end set mentioned in this application. After all, the capabilities of each message processing platform are limited and it is impossible to connect to remote ends indefinitely. Therefore, it is necessary to define a scope for the message processing platform. This scope includes the VNI scope and the remote end scope, where the remote end scope is referred to as the second remote end set.

[0048] If the source and access points of the target packet are within a preset range of the packet processing platform, then the source and access points of the target packet fall within the learning range of the packet processing platform. However, it is still necessary to consider that, although it falls within the learning range, in order to prevent invalid learning or attacks, it is also necessary to further verify whether there is a learning task at present, or whether the combination of the source and access points is within the suppression time.

[0049] Since learning takes time, if a learned entry for the source remote and access point hasn't been created in the remote forwarding table within the learning period, but learning is still in progress, initiating another learning task at this point will inevitably result in duplicate learning, wasting resources. Furthermore, considering the possibility of a remote end sending duplicate packets, this application will temporarily suppress the target to be learned when faced with duplicate packets that miss the remote forwarding table, to avoid disrupting the learning progress. Therefore, this application considers three aspects when determining whether something is a learning target: whether it falls within the learning scope, whether there is an existing learning task, and whether it has been suppressed. Only when all three aspects are met will the source remote and access point be determined as a learning target; otherwise, the packet will be discarded.

[0050] Step S32: When the source remote end belongs to the learning target, generate a learning task for the source remote end based on the outer header information.

[0051] Step S33: Update the remote forwarding table according to the learning task.

[0052] Once the source remote terminal and the access point are identified as learning targets, a learning task can be generated based on the outer header information of the target message. The learning task enables the remote forwarding table to learn, thereby generating learned entries related to the source remote terminal and the access point, thus updating the remote forwarding table.

[0053] That concludes our introduction to updating the remote forwarding table for now. According to the process, since the remote forwarding table has already learned the source remote and access point corresponding to the target packet, when the target packet arrives again, it can correctly match the learned entry in the remote forwarding table and complete the decapsulation operation. Other operations involving deleting and updating the remote forwarding table will be introduced later.

[0054] Step S4: Determine the forwarding method for the target packet based on the inner header information and the remote forwarding table.

[0055] In some embodiments, step S4, "determining the forwarding method for the target packet based on the inner header information and the remote forwarding table," includes: Step S41: Determine whether the target remote end is a learned remote end in the remote end forwarding table according to the target remote end information in the inner header information, wherein the target remote end is the remote end to which the target packet is finally delivered, and the target remote end information is the remote end information of the target remote end.

[0056] Step S42: When the target remote end is determined to be a learned remote end, a new outer header information is generated based on the target remote end information and the address information of the message processing platform.

[0057] Step S43: Forward the target message to the target remote end according to the new outer header information.

[0058] In some embodiments, when the target remote endpoint is determined to be an unlearned remote endpoint, the method further includes: Step S44: Determine the first remote set based on the remote forwarding table.

[0059] Step S45: Obtain the second remote set preset for the message processing platform.

[0060] Step S46: Determine the third remote set to be broadcast based on the first remote set and the second remote set.

[0061] Step S47: Generate an encapsulation packet for each remote end in the third remote end set based on the remote end information of each remote end in the third remote end set and the address information of the message processing platform, and send each encapsulation packet to the corresponding remote end.

[0062] Although steps S1-S3 complete the decapsulation of the target packet, a new encapsulation packet still needs to be generated based on the inner header information of the target packet before being sent to the target remote end. Therefore, after decapsulation, it is necessary to determine how to encapsulate and forward the packet based on the inner header information. Specifically, this application will again call the remote forwarding table to determine whether the packet processing platform has learned the target remote end's entry based on the remote end information of the target remote end and the target packet's Virtual Interface Number (VNI) in the inner header information. Therefore, this application needs to determine whether there are learned entries for the target remote end and the VNI in the remote forwarding table. If so, it can be determined how to forward the target packet, that is, to generate new outer header information based on the target remote end's remote end information, the VNI, and the packet processing platform's port information, and then send it to the target remote end.

[0063] However, if the target remote end information and access point cannot find a learned entry in the remote forwarding table, meaning the packet processing platform doesn't know which remote end to send the target packet to, it will broadcast the target packet, as described in steps S44-S47. First, it needs to determine which remote ends to broadcast to. Then, a corresponding encapsulation packet is generated for each remote end to be broadcast to, and then sent to each remote end respectively; this is the unknown unicast mentioned in this application. Specifically, in this application, when determining which remote endpoints to send target packets to, several remote endpoint sets need to be defined first. The first set is the first remote endpoint set, which consists of remote endpoints already learned in the remote endpoint forwarding table. After all, when an unknown remote endpoint is determined to be unknown, it will certainly not be in the remote endpoint forwarding table. The second set is the second remote endpoint set preset by the packet processing platform, i.e., the second remote endpoint set mentioned in step S311 above. This second remote endpoint set contains all remote endpoints that should be managed by the packet processing platform. This includes remote endpoints that the remote endpoint forwarding table has learned, as well as remote endpoints that the remote endpoint forwarding table has not learned. The remote endpoints that the remote endpoint forwarding table has learned are the first remote endpoint set determined based on the remote endpoint forwarding table. Since unknown unicast is required, unicast must be performed on the remote endpoints that have not been learned in the second remote endpoint set. Therefore, the remote endpoints that have been learned in the second remote endpoint set need to be removed using the first remote endpoint set, leaving only the set of remote endpoints that have not been learned, i.e., the third remote endpoint set.

[0064] Then, based on the remote information of each remote terminal in the third remote terminal set, a corresponding encapsulation packet is generated, and the encapsulation packet is sent to the corresponding remote terminal. To date, this application has solved the following problems in the prior art: 1. The size of runtime objects grows approximately linearly with the number of remote VTEs multiplied by the number of VNIs. In multi-tenant, large-scale node interconnection scenarios, the static per-peer tunnel interface model leads to a rapid expansion of the number of interface objects, FIB tracking objects, configuration items, and operational complexity.

[0065] 2. The existing learning plane mainly learns the relationship from "source MAC to local input interface", and cannot directly express "which remote VTEP corresponds to a certain remote MAC under a certain VNI", which leads to a mechanism mismatch between VXLAN remote learning and traditional Layer 2 learning.

[0066] 3. Decapsulation relies on precise static tunnel hits, which means that unknown remote nodes that have been admitted cannot enter the learning face before they have completed pre-configuration. This results in insufficient self-learning ability and limits the discovery of the first packet and subsequent automatic convergence.

[0067] 4. When a local ARP, ND, broadcast, or unknown unicast occurs for the first time without an existing remote membership, there is a lack of a controlled first-hop discovery exit. It can only rely on static flood (flood replication, the replication method when BUM / unknown unicast) members or multicast, making it difficult to balance automatic discovery and boundary control.

[0068] 5. Underlay routing tracing and adjacency sending are repeatedly maintained around the tunnel, which is not conducive to multiple VNIs sharing the forwarding state of the same remote VTEP, resulting in state redundancy.

[0069] The following technical effects were achieved: 1. While ensuring VXLAN standard compatibility, reduce the state expansion of running objects caused by the increase in the number of remote nodes and VNIs.

[0070] 2. Enables the system to accurately establish the correspondence between remote MAC and remote VTEP at the VNI dimension.

[0071] 3. Enables unknown remote nodes that have been admitted to enter the subsequent learning and forwarding process, instead of relying entirely on manual pre-building of static tunnels one by one.

[0072] 4. Enables broadcasting, multicasting, unknown unicasting, and unknown decapsulation bootstrapping to all be performed within a controlled scope.

[0073] 5. Reduce the resource consumption caused by repeatedly maintaining the underlying forwarding state.

[0074] However, considering that some remote nodes may become obsolete or no longer be used due to user needs, a large number of obsolete learned entries will be stored in the remote forwarding table. Although this learning method can avoid the problem of rapid expansion of the remote forwarding table, a large number of obsolete learned entries will still make the remote forwarding table increasingly bloated. Therefore, in order to further ensure that the remote forwarding table does not expand, this application will also clean up the obsolete learned entries in the remote forwarding table. Similarly, the obsolete remote nodes in the allowed learning range, i.e., the second remote node set, will also be cleaned up.

[0075] Therefore, in some embodiments, the method further includes: Step S51: Each time a learned entry is hit in the remote forwarding table, update the most recent usage time of the hit learned entry.

[0076] In some embodiments, the method further includes: Step S52: Update each remote terminal in the second remote terminal set according to the most recent usage time of each learned entry in the remote terminal forwarding table, wherein the most recent communication time of each remote terminal is updated.

[0077] To determine whether unlearned remote ends and learned entries are obsolete, it's necessary to clarify the activity status of each remote end and learned entry. The most relevant parameter is the last usage time or most recent usage time, i.e., when the learned entry or remote end last communicated with the message processing platform. To determine the last communication time of learned entries and remote ends, the communication time of each communication needs to be recorded, especially the last communication time. Since learned entries in the remote forwarding table are formed by remote end + access point, the table contains the most recent usage time for each remote end and each access point. For a remote end, there are multiple access points. To determine if a remote end is obsolete, all its access points must be obsolete for a certain period of time. Therefore, for each remote end in the second remote end set, the last usage time of each remote end needs to be determined based on the most recent usage time of each learned entry in the remote forwarding table.

[0078] In some embodiments, the method further includes: Step S53: Periodically obtain the most recent usage time of each learned entry in the remote forwarding table.

[0079] Step S54: Update the remote forwarding table according to the most recent usage time of each learned entry.

[0080] Because each learned entry in the remote forwarding table is updated with the latest usage time, it is possible to determine which learned entries in the remote forwarding table have been discarded based on the most recent usage time, and then remove the discarded learned entries from the remote forwarding table to simplify the remote forwarding table.

[0081] In some embodiments, the method further includes: Step S55: Periodically obtain the most recent communication time of each remote end in the second remote end set.

[0082] Step S56: Update the second remote set according to the most recent communication time.

[0083] Furthermore, the second remote set serves as the learning domain of this application. If the learning domain contains a large amount of useless information, it will still lead to bloat. Moreover, when performing unknown unicast, many meaningless unicast transmissions will be performed. Therefore, the second remote set also needs to be updated. When all access points of a remote are not in the remote forwarding table, it means that either the remote has not been learned or the remote has actually been abandoned. Therefore, this application will determine whether any remote has been abandoned based on the most recent communication time of each remote in the second remote set. When it is determined that a remote has been abandoned, the abandoned remote will be removed from the second remote set.

[0084] Therefore, this application can also realize automatic aging, batch cleaning and conditional observation of learning objects when running at large scale, so as to improve the long-term stability and maintainability of the system.

[0085] Because the technical solution in this application can be smoothly integrated into existing deployments without requiring a one-time replacement of all static VXLAN configurations, for critical remote nodes that are already identified, stable, and require accelerated processing, the system can still retain the exact static tunnel and continue to use the exact RX flow offload as the fast path when conditions are met; however, these exact objects only assume compatibility and acceleration responsibilities and are no longer the sole prerequisite for all remote reachability and learning behaviors. According to the current design, the learning, bootstrapping, and membership convergence of unknown remotes are still mainly completed by the ordinary decap path, remote_FDB, vni_peer, and discovery seed. Therefore, the exact path can be retained, but the system no longer requires all remote VTEPs to be pre-built into independent tunnel interfaces one by one.

[0086] Furthermore, for packets that match the exact path, the system will still uniformly switch the decapped ingress to vni_port to avoid the static path and the learning path from branching in the bridging mechanism.

[0087] Example 2: like Figure 2 As shown, this application will use an embodiment to illustrate the systematic approach between steps S1-S56 in this application.

[0088] This invention no longer uses "remote VTEP + VNI = one tunnel interface" as the sole core object, but instead divides the system into three layers: Control and Operations: Responsible for learning-domain, per-VNI discovery-seed, and configuration of show / clear and aging parameters.

[0089] This layer defines what the system is allowed to learn, which remote endpoints it can perform controlled discovery on, and how the learning state is observed and reclaimed. Based on the current documentation and code implementation, the core function of this layer is not to statically expand all tunnels according to "each remote VTEP + each VNI," but rather to first constrain the local VTEP, encap FIB, VNI admission scope, and bridge-domain mapping rules through the learning-domain. Then, it provides a controlled allowlist for first-hop discovery and unknown decap bootstrapping through per-VNI discovery-seed, supplemented by show / clear and background aging mechanisms to manage the suppression states of remote_FDB, vni_peer, discovery-seed, and decap-anchor. In this way, the automatic learning capability always operates within clearly defined policy boundaries, rather than expanding outwards without limit.

[0090] Runtime object layer: includes learning-domain, vni_port, peer, remote_FDB, vni_peer, per-VNI discovery seed, and decap-anchor suppression state.

[0091] This layer is the core state-bearing layer after the control configuration falls into the forwarding plane. It is used to decompose "admission boundary, remote learning, membership replication, sending next hop, and bootstrapping suppression" into independent but collaborative objects. Specifically, learning-domain is responsible for describing the local learnable range, vni_port provides a local logical access point and ingress mechanism for each admitted VNI, peer abstracts the remote VTEP that can be shared by multiple VNIs and its underlay forwarding state, remote_FDB is responsible for recording the mapping from learned {vni_port, MAC} to peer, vni_peer is responsible for describing the activity and BUM membership of remote peers under a certain VNI, per-VNIdiscovery-seed is responsible for providing a controlled initial set of remotes before the learning has fully converged, and the pending / recent state of decap-anchor is used to constrain the concurrency and frequency of unknown remote bootstrapping requests. Through this state reconstruction, the system decomposes the original highly coupled per-peer tunnel interface model into a layered runtime model that is more suitable for large-scale scenarios.

[0092] Data plane processing layer: includes ordinary decap entry, exact flow offload entry, layer 2 bridging / forwarding / flooding nodes, and learn-encap nodes directly encapsulated by {peer, vni}.

[0093] This layer is the execution layer where packets are actually parsed, learned, look up, copied, and encapsulated before being sent. According to the current documentation and code design, the ordinary decap entry point is responsible for VXLAN header verification, learning-domain admission, exact static tunnel hits, and triggering learned decap fallback or decap-anchorbootstrap when a hit occurs. The exact flow offload entry point only accelerates packets with existing exact tunnel hits and does not assume responsibility for discovering unknown remote endpoints. After a packet enters the bridge domain, the Layer 2 bridging, forwarding, and flooding nodes handle known unicasts with local L2 FDB hits and remote_FDB hits, respectively, as well as BUM replication for local members and remote peer sets. When a packet needs to be sent to a remote endpoint, the learn-encap node no longer relies on a single remote tunnel interface but directly generates an outer IP / UDP / VXLAN header based on {peer, vni} and sends it along peer.next_dpo. Thus, while maintaining standard VXLAN compatibility, the data plane gradually transitions from a "packet delivery per tunnel" model to a scalable execution model that delivers packets per shared peer and VNI.

[0094] The relationships between the above objects are as follows: learning-domain determines the local admission boundary and VNI range; vni_port maps admitted VNIs to local logical access points and bridging domains; peer abstracts the remote VTEP relationship shared by multiple VNIs into a unified sending object; remote_FDB and vni_peer are responsible for known unicast and remote replication, respectively; discovery_seeds_by_vni is responsible for first-hop discovery and unknown bootstrapping admission; and the decap-anchor state is responsible for controlling the bootstrapping request frequency and concurrent behavior.

[0095] The key difference between this solution and the closest related technology lies in the fact that the sending path no longer requires "selecting the tunnel interface first and then encapsulating," but instead "locating the peer first by {vni_port, mac}, and then directly encapsulating by {peer, vni}." The receiving path also no longer equates "unknown miss" directly to permanent failure, but instead provides asynchronous rebuilding capabilities under admission and allowlist control. Through this reconstruction, the system achieves a state organization method more suitable for large-scale dynamic networks while retaining compatibility with the standard VXLAN protocol.

[0096] Example 3: like Figure 3 As shown, this application will use an embodiment to explain the process of steps S1-S4 in this application.

[0097] The incoming data plane is executed in the following order: 1. Receive underlay messages, identify UDP 4789, and parse the outer source, outerdestination, encap FIB, and VXLAN VNI.

[0098] 2. Verify whether the VXLAN flag conforms to the standard format; discard it directly if it does not conform.

[0099] 3. Query the learning-domain to determine if {local_VTEP, encap_fib_index, vni} is within the admitted range; if it is not within the admitted range, discard it as "VNI not admitted".

[0100] 4. If an exact static tunnel exists, the existing exact path will be used for decapsulation first. However, after successful decapsulation, the ingress mechanism will be switched to the corresponding vni_port to ensure consistency between the learning and bridging mechanisms.

[0101] 5. If no exact static tunnel exists, query the existing learned decap info to determine if the combination of vni_port and peer already exists for the current {local_VTEP, remote_VTEP, encap_fib_index, vni}. If it already exists, use that combination to continue decapsulation.

[0102] 6. If no existing learned decap info exists, check if the remote_VTEP is in the current VNI's discovery seed allowlist; if not, discard it as "seed not allowed".

[0103] 7. If it is in the allowlist, further check the decap-anchor pending and recent status: 7.1 If the same key is already pending, the main thread will not be restarted again. 7.2 If the same key has just been tried and is still within a short-term suppression window, it will not be initiated again this time; 7.3 Only when it is neither pending nor recent should an asynchronous bootstrap request be sent to the main thread to request the creation or reuse of vni_port and peer.

[0104] 8. After receiving the bootstrap request, the main thread creates or reuses vni_port according to learning-domain and VNI, creates or reuses peer according to {local_VTEP, remote_VTEP, encap_fib_index}, and marks it as decap anchor.

[0105] 9. The first packet can be discarded; when subsequent packets arrive, if the bootstrap has been completed, the new decap anchor combination can be matched and the learning face can continue.

[0106] 10. Once decap is successful, the system will write the packet ingress to vni_port.sw_if_index instead of writing it to the sw_if_index of a remote tunnel interface.

[0107] 11. The system extracts the source MAC from the inner Ethernet frame, learns {vni_port, src_mac} into remote_FDB, and synchronously refreshes the vni_peer activity status and live_mac_count corresponding to {vni_port, peer}.

[0108] 12. After that, the message is sent to l2-input and then enters the existing Layer 2 bridging and forwarding path.

[0109] Through the above steps, the inbound processing achieves a complete closed loop of "admission control, receiver anchor point reconstruction, remote learning, and unified bridging ingress". This closed loop does not require the prior establishment of static tunnel interfaces for all remote nodes, thus possessing large-scale self-learning and self-convergence capabilities.

[0110] Example 4: like Figure 4 As shown, this application uses an embodiment to illustrate the process of steps S41-S43 in Embodiment 1.

[0111] Outgoing direction known unicast forwarding steps For a known unicast message sent from a local node to a remote node, the system executes the following steps in order: 1. Messages enter the bridging domain from the local service interface, BVI, or vni_port.

[0112] 2. First, query the local L2 FDB; if a local member interface is found, send the data along the existing local bridge path.

[0113] 3. If the local L2 FDB is not found, then query the remote_FDB by {vni_port, dst_mac}.

[0114] 4. If remote_FDB is not found, then proceed to the BUM / unknown unicast replication path.

[0115] 5. If remote_FDB is hit, then peer_index and vni_port_index are written to the buffer metadata.

[0116] 6. The message is forwarded to the vxlan4-learn-encap or vxlan6-learn-encap node.

[0117] 7. The learn-encap node reads local_VTEP, remote_VTEP, and next_dpo from the peer object, reads VNI from the vni_port object, and directly generates outer IP / UDP / VXLAN headers on the data plane.

[0118] 8. After generating the outer header, the message is sent to the underlay along peer.next_dpo.

[0119] 9. Peer-level FIB tracing is responsible for automatically rebuilding the next_dpo when the underlay route changes, so that multiple VNIs can share the underlay forwarding state of the same remote VTEP.

[0120] Through the above steps, the sending path is changed from "selecting rewrite by tunnel interface" to "direct encapsulation by {peer,vni}", thereby significantly reducing the interface object expansion caused by the combination of remote VTEP and VNI.

[0121] Example 5: like Figure 5 As shown, this application uses an embodiment to illustrate the process of steps S44-S47 in Embodiment 1.

[0122] For local broadcast, multicast, ARP, ND, and unknown unicast, this invention employs the following remote replication method: 1. First, perform local member copying of the bridging domain to ensure compatibility with existing Layer 2 bridging behavior.

[0123] 2. Next, calculate the remote replication set. The remote replication set consists of two parts: a) vni_peer that is still active; b) The per-VNI discovery seed configured under the current VNI.

[0124] 3. The system performs deduplication and merging on the above two types of members. If a peer already exists as an active vni_peer, its discovery seed identity will not be reused.

[0125] 4. The merged remote replication sets are entered one by one into the learn-encap node to complete head-end replication.

[0126] 5. By default, the system does not perform remote-to-remote flooding on BUM messages received from remote ends to avoid secondary diffusion and loop amplification between remote ends.

[0127] Through the above steps, the system can still perform controlled first-hop discovery using the discovery seed in the early stages when there is no complete learned membership; and after the system is running stably, it can automatically converge to a replication method that uses live vni_peer as the main component and seed as a secondary component.

[0128] Example 6: The technical solution of this application can be applied to cloud NAT gateway product services, where the forwarding service of the NAT gateway is implemented by VPP. Through the elastic learning configuration method of this application, the number and efficiency of VXLAN resource configurations for communication between NAT gateway nodes in the cloud are increased. It can support the NAT gateway to automatically learn and complete the configuration of VXLAN tunnels between 100,000 VPPs and compute nodes, without requiring static configuration. This embodiment illustrates the deployment form and packet flow relationship of the technical solution of this application in the NAT gateway service as follows: Figure 6 As shown.

[0129] The network architecture in the diagram is divided into two layers vertically: the upper layer is the NAT gateway layer, and the lower layer is the compute node layer.

[0130] The forwarding service of the NAT gateway layer is implemented by the packet processing platform (VPP). This platform reconstructs the traditional static tunnel model through runtime objects, supports automatic learning to complete the configuration of 100,000 VXLAN tunnels, without the need for pre-configuring static tunnels one by one. Its specific implementation mechanism is consistent with the technical solution described in Embodiment 2 of this application.

[0131] The connection between the two layers: The VPP of the NAT gateway layer is interconnected with each compute node in the lower layer via VXLAN tunnels. Traditional solutions require pre-establishing a static tunnel interface for each "remote VTEP + VNI" combination; however, in this application, the VPP supports automatic learning to complete the VXLAN tunnel configuration, eliminating the need for static configuration.

[0132] The functional modules and arrows in the diagram represent the interaction logic between the data plane and the control plane of this application, as shown below: Static tunnel configuration (problem area): This refers to the traditional approach that relies on manually pre-building static tunnels one by one. In this approach, the system needs to establish a separate static tunnel interface for each "remote node + VNI" combination, resulting in a severe expansion of runtime objects and a huge workload for configuration in large-scale multi-tenant scenarios.

[0133] Tunnel Learning (Improvement): Characterizes the elastic learning configuration method proposed in this application. This module is embedded in the Message Processing Platform (VPP) and is responsible for automatically completing the discovery of remote nodes, the reconstruction of receiving anchors, and the updating of forwarding tables under the trigger of business traffic, thereby replacing the traditional manual static configuration.

[0134] NAT and routing: auxiliary forwarding modules within the Virtual Packet Processing Platform (VPP). After a VXLAN packet enters through the bearer network, the VPP must first determine the local outgoing interface through routing lookup, and perform address translation through the NAT module if necessary, before entering the core tunnel decapsulation and forwarding process.

[0135] Tunnel encapsulation / tunnel forwarding: These two modules together constitute the core forwarding path of the improved data plane in this application. Unlike traditional static configuration, the encapsulation and forwarding logic in this application directly reuses the remote node object (peer) and the VNI logical interface (vni_port).

[0136] Tunnel encapsulation (i.e., the learning-driven encapsulation node in this application): When the packet processing platform queries the remote forwarding table (remote_FDB) and finds a target remote node, the packet is forwarded to this node. This node directly reads the local endpoint, remote endpoint, and underlying Layer 3 network forwarding adjacency information from the remote node object, and combines it with the VNI value read from the VNI logical access point to directly generate the outer IP / UDP / VXLAN header according to {remote node object, VNI} (the VNI value remains fixed during this process).

[0137] Tunnel forwarding (i.e., the underlying network forwarding path in this application): The encapsulated message is sent to the bearer network (underlay) along the forwarding adjacency information (next_dpo) of the remote node object, and then forwarded to the target computing node via the NAT gateway layer.

[0138] The two types of arrows in the diagram correspond to the data plane message flow path and the control plane learning interaction path, respectively: The solid yellow arrows indicate the data plane packet flow path, with the yellow arrows representing the transmission direction of the packet in the normal forwarding process, divided into outbound and inbound scenarios: Outbound (Compute Node → NAT Gateway → Remote Compute Node): Raw packets generated by virtual machines within the compute node are sent to the VNI logical access point of the packet processing platform via the virtual machine switch. The packet processing platform first queries the local Layer 2 forwarding table (L2 FDB). If no match is found, it queries the remote forwarding table according to {VNI logical access point, destination MAC}. If the remote forwarding table matches, it obtains the corresponding remote node object index, and the packet is forwarded to the tunnel encapsulation module (i.e., the learning-driven encapsulation node in this application). This module directly generates an outer IP / UDP / VXLAN header according to {remote node object, VNI}, and sends it to the bearer network along the tunnel forwarding path (i.e., the underlying network forwarding path in this application), and forwards it to the target compute node via the NAT gateway. If the remote forwarding table does not match (unknown unicast scenario), the packet processing platform generates a flooding encapsulation packet based on the discovery seed set managed by VNI, and sends it to each remote compute node in the allowed list via the NAT gateway.

[0139] Inbound (Remote Compute Node → NAT Gateway → Compute Node): VXLAN packets from the remote node enter the NAT gateway via the bearer network. After being sent to the packet processing platform, the platform verifies the VXLAN header and checks whether a combination of a VNI logical access point and a remote node object already exists, based on {Local Endpoint, Remote Endpoint, Encapsulation Forwarding Table Index, VNI}. If it exists, the packet is directly decapsulated, the outer IP / UDP / VXLAN header is stripped, and the packet is sent inbound to the forwarding path of the corresponding VNI logical access point. The decapsulated original packet is then sent to the target virtual machine within the virtual private cloud of this node via the virtual machine switch.

[0140] It is worth noting that the "VPC VNI-X", "VPC VNI-Y", and "VPC VNI-Z" labels at the lower compute node layer in the diagram correspond to the Virtual Private Cloud (VPC) network in this application. Each VPC corresponds one-to-one with a unique VNI (VXLAN network identifier): one VPC corresponds to one Layer 2 broadcast domain, different VPCs have different VNI values, and they are isolated from each other at Layer 2; when the same VPC communicates across nodes, the VNI value remains fixed, and the VNI value remains consistent throughout the packet encapsulation and decapsulation process to ensure the consistency of the Layer 2 domain. A VPC is the logical bearer network for virtual machines within a compute node. It is connected to the VNI logical access point (vni_port) of the packet processing platform (VPP) through a virtual machine switch. The service traffic generated by the virtual machine enters the forwarding process through the vni_port corresponding to its VPC, and the decapsulated packets are also sent back to the target virtual machine within the VPC through the corresponding vni_port.

[0141] The red dashed arrows indicate the control plane learning interaction path.

[0142] The red arrows represent the controlled learning process unique to this application, which corresponds completely to the ingress learning process in Embodiment 3 of this application: When the message processing platform receives a message that does not hit the static tunnel or the remote forwarding table, it triggers the learning logic: The message processing platform determines whether the source remote is within the learning range allowed by the learning domain based on the outer header information, and whether it is in the allowed list of the discovery seed set managed by VNI; if learning is allowed and there are no pending or recently suppressed decapsulation anchor requests, an asynchronous bootstrapping request is initiated to the main thread; the main thread creates or reuses the VNI logical access point and the remote node object, marking them as decapsulation anchors; after learning is completed, the remote forwarding table is updated, a mapping of {VNI logical access point, source MAC} → remote node object is established, and the active status of the corresponding remote node object in the VNI-remote relationship table is refreshed synchronously; subsequent similar messages can hit the learned entries and enter the normal decapsulation and forwarding process. The red arrow represents the control plane interaction process of "triggering learning → creating decapsulation anchor points → updating remote forwarding tables", which enables unknown remote nodes that meet the admission criteria to enter the subsequent learning and forwarding process without the need for manual pre-building of static tunnels one by one.

[0143] In the above deployment configuration, the technical advantages of this application solution correspond exactly to the effects described in the application documents: The tunnel model is reconstructed to eliminate static dependencies: As the core forwarding engine of the NAT gateway, the packet processing platform no longer relies on the coupled model of "each remote node object + each VNI = one static tunnel interface" with the lower-layer computing nodes. Through the collaboration of the tunnel learning module and the tunnel encapsulation module, the sending path is reconstructed to "first locate the remote node object according to {VNI logical access point, MAC}, and then directly encapsulate it according to {remote node object, VNI}". The underlying three-layer network forwarding state of the same remote node object can be reused by multiple VNIs, which greatly reduces the state bloat caused by the increase in the number of remote nodes and VNIs.

[0144] Ensuring consistency in multi-tenant networks: Business traffic generated by virtual machines enters the packet processing platform through the VNI logical access point corresponding to their respective Virtual Private Cloud (VPC). During cross-node communication, the VNI value is fixed. After decapsulation by the peer packet processing platform, the traffic is delivered to the peer virtual machine through the VNI logical access point with the same VNI, ensuring consistency in the Layer 2 broadcast domain (VPC network).

[0145] Achieving automatic learning for 100,000 tunnels: Through the elastic learning configuration method introduced by the tunnel learning module, the NAT gateway supports automatic learning to complete the configuration of 100,000 VXLAN tunnels without static configuration. This mechanism perfectly adapts to the needs of dynamic node online / offline operation in multi-tenant, large-scale node interconnection scenarios, completely solving the pain points of configuration bloat and poor flexibility in traditional solutions.

[0146] Example 7: Secondly, this application provides an electronic device, such as... Figure 7 As shown, it includes: at least one processor 100; and a memory 200 communicatively connected to the at least one processor 100; wherein the memory 200 stores instructions executable by the at least one processor 100, the instructions being executed by the at least one processor 100 to enable the at least one processor 100 to execute a message forwarding method in the above embodiments.

[0147] The memory and processor are connected via a bus, which can include any number of interconnecting buses and bridges, connecting various circuits of one or more processors and memories. The bus can also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and will not be described further herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by the processor is transmitted over the wireless medium via an antenna, which further receives data and transmits it to the processor.

[0148] The processor manages the bus and general processing, and also provides various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory is used to store data used by the processor during operation.

[0149] In addition, the computer device may include (but is not limited to) a data bus, an input / output (I / O) bus, a display, and input / output devices (e.g., keyboard, mouse, speakers, etc.).

[0150] The processor can communicate with external devices via the I / O bus through wired or wireless networks.

[0151] In one embodiment, the at least one computer-executable instruction may also be compiled into or comprise a software product / computer program product, wherein one or more computer-executable instructions are executed by a processor to perform the steps of the various functions and / or methods in the embodiments described herein.

[0152] Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps 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, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0153] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above-described embodiments are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0154] It should be noted that, in this document, 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. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0155] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0156] In the embodiments provided in this disclosure, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0157] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a controller 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 mobile storage devices, ROMs, magnetic disks, or optical disks.

[0158] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein.

[0159] Those skilled in the art will understand that the above embodiments are specific embodiments for implementing this application, and in practical applications, various changes can be made to them in form and detail without departing from the spirit and scope of this application.

Claims

1. A message forwarding method, characterized in that, Applicable to message processing platforms, characterized in that it includes: Obtain the outer header information of the target message, wherein the target message is a message for which the static tunnel was not hit on the message processing platform; The decapsulation information of the target packet is determined based on the outer header information, wherein the remote forwarding table is learned by the packet processing platform. When it is determined that the decapsulation information of the target packet exists in the remote forwarding table, the target packet is decapsulated according to the decapsulation information to obtain the inner header information; The forwarding method for the target packet is determined based on the inner header information and the remote forwarding table.

2. The method according to claim 1, characterized in that, The step of determining the forwarding method for the target packet based on the inner header information and the remote forwarding table includes: Based on the target remote information in the inner header information, it is determined in the remote forwarding table whether the target remote is a learned remote, wherein the target remote is the remote to which the target packet is ultimately delivered, and the target remote information is the remote information of the target remote. When the target remote end is determined to be a learned remote end, new outer header information is generated based on the target remote end information and the address information of the message processing platform. The target message is forwarded to the target remote end based on the new outer header information.

3. The method according to claim 2, characterized in that, When the target remote endpoint is determined to be an unlearned remote endpoint, the method further includes: The first remote set is determined based on the remote forwarding table; Obtain the second remote set preset for the message processing platform; A third remote set to be broadcast is determined based on the first remote set and the second remote set; Based on the remote information of each remote terminal in the third remote terminal set and the address information of the message processing platform, an encapsulation packet is generated for each remote terminal in the third remote terminal set, and each encapsulation packet is sent to the corresponding remote terminal.

4. The method according to claim 1, characterized in that, When the decapsulation information of the target packet is not found in the remote forwarding table, the method further includes: Based on the outer header information, determine whether the remote source of the target message belongs to the learning target of the message processing platform; When the source remote end belongs to the learning target, a learning task is generated for the source remote end based on the outer header information; The remote forwarding table is updated according to the learning task.

5. The method according to claim 4, characterized in that, The step of determining whether the source of the target message belongs to the learning target of the message processing platform based on the outer header information includes: The target access point of the target message and whether the source remote end belongs to the learning range of the message processing platform are determined according to the preset second remote end set and the outer header information, wherein the second remote end set is a preset range of manageable remote ends for the message processing platform. When it is determined that the source remote end and the target access point are within the learning range, it is determined whether there is any suppression information for the source remote end and the target access point based on the outer header information; When there is no suppression information, determine whether there is already a learning task for the source remote end and the target access point based on the outer header information; When there is no learning task, the source remote end and the target access point are determined as the learning targets of the message processing platform.

6. The method according to claim 5, characterized in that, The method further includes: Each time a learned entry is hit in the remote forwarding table, the most recent usage time of the hit learned entry is updated.

7. The method according to claim 6, characterized in that, The method further includes: Periodically retrieve the most recent usage time of each learned entry in the remote forwarding table; The remote forwarding table is updated based on the most recent usage time of each learned entry.

8. The method according to claim 6, characterized in that, The method further includes: The remote terminals in the second remote terminal set are updated according to the most recent usage time of each learned entry in the remote terminal forwarding table, wherein the most recent communication time of each remote terminal is updated.

9. The method according to claim 8, characterized in that, The method further includes: Periodically obtain the most recent communication time of each remote end in the second remote end set; The second remote set is updated based on the most recent communication time.

10. An electronic device, characterized in that, The method includes a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the method according to any one of claims 1 to 9.

Images