Cross-device link aggregation communication method and related device

Abstract

The embodiment of the invention provides a cross-device link aggregation communication method and a related device, and relates to the technical field of communication. Obtaining an L3VPN message to be forwarded; when the to-be-forwarded L3VPN message is a protocol message, the to-be-forwarded L3VPN message is sent to other corresponding network equipment through a local aggregation group member link; and when the to-be-forwarded L3VPN message is a data message, determining a forwarding path corresponding to the to-be-forwarded L3VPN message according to the receiving path of the to-be-forwarded L3VPN message, the transmission parameter corresponding to the data flow type to which the to-be-forwarded L3VPN message belongs and the available residual bandwidth of the aggregation group member links corresponding to the two MLAG devices, and forwarding the to-be-forwarded L3VPN message through the forwarding path. Therefore, a cross-device link technology can be adapted to a complex L3VPN service scene, and meanwhile, the flexible allocation capability of bandwidth resources is improved, so that the cross-device link technology can adapt to complex and changeable service requirements, and the resource utilization rate is improved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a cross-device link aggregation communication method and related apparatus. Background Technology

[0002] In current data communication networking practices, with the expansion of network scale and the increasing demands for high availability from services, traditional stacking technology is gradually revealing its architectural limitations. While stacking technology simplifies operation and maintenance by logically merging multiple physical devices into a single device for unified management, its reliance on a single master device to handle all control plane functions leads to significant control plane performance bottlenecks. If the master device fails, the entire system may face the risk of losing control, creating a single point of failure. To address this, the industry is gradually shifting towards MLAG (Multichassis Link Aggregation Group) technology. This technology allows each network device to maintain an independent control plane, exchanging necessary control information and status data only through dedicated Peer-Link links, thereby achieving higher processing performance and stronger fault tolerance. This architecture not only improves system reliability but also enhances horizontal scalability, and therefore has gained widespread acceptance in modern data centers and enterprise core networks.

[0003] While cross-device link aggregation technology outperforms traditional stacking solutions in terms of reliability, its practical application still has certain limitations. Overall, these technologies demonstrate significant inadequacy in addressing the complex networking requirements of L3VPN (Layer 3 Virtual Private Network).

[0004] Specifically, the core idea behind some cross-device link aggregation networking is to achieve state synchronization among downstream devices through a packet replication mechanism. The upstream device acts as the control center for link aggregation, connected to an aggregation group composed of multiple downstream network devices via multiple member links. When the system identifies a packet to be processed as a protocol packet, it replicates the packet and sends it to the corresponding downstream device through each member link of the aggregation group. This approach allows downstream devices to obtain consistent link state information without needing to run additional synchronization protocols with each other, thereby simplifying configuration complexity, reducing deployment costs, and improving the compatibility of link aggregation across different device environments.

[0005] However, this solution has significant limitations in practical applications. It requires single-device or multi-device stacking technology at the network top end and dual-device cross-device link aggregation technology at the bottom end. Primarily designed for pure IP forwarding environments, this solution fails to provide adaptation mechanisms for more complex L3VPN service scenarios, such as Layer 3 VPN environments based on MPLS (Multi-Protocol Label Switching) or SRv6 (Segment Routing support for IPv6). This results in its inability to meet the high reliability and multi-service carrying requirements commonly found in operator or large enterprise private networks. Therefore, this technology is ill-suited to the trend of modern networks moving towards distributed, highly available, and multi-functional convergence.

[0006] Furthermore, the core idea behind other MLAG networking is that when the total bandwidth required for a network device to send packets exceeds the sum of the configured bandwidths of all its aggregation group member interfaces, the device will make load balancing decisions for multiple packets based on its own bandwidth usage ratio. For packets determined to be forwarded by the peer MLAG device, the current MLAG device will send them to the peer MLAG device via the Peer-Link link. The MLAG device receiving these packets will then forward them to the uplink device from its own aggregation group member interface, thereby achieving traffic sharing and resource utilization optimization within the entire aggregation group. The design intent of this mechanism is to improve the overall packet processing efficiency of the aggregation group and avoid packet loss or congestion caused by bandwidth saturation of a single device.

[0007] However, this load balancing method also has significant limitations. When distributing packets, it still relies on traditional hash algorithms based on packet characteristics (such as 5-tuples) and employs a fixed ratio strategy, such as 1:1 equal distribution or allocation based on link bandwidth. This means that packets with the same characteristics will always be mapped to the same physical link for transmission. While this approach can maintain basic balance under a static traffic model, in real-world network environments, the rates of various service flows often exhibit dynamic fluctuations. When a high-bandwidth data flow suddenly increases, the link originally used to carry that traffic quickly becomes saturated, while other links may remain under low load. Because the hash result remains unchanged, the system cannot proactively transfer some of the pressure to idle links, ultimately leading to a significant imbalance between busy and idle periods among multiple aggregation group member links. This rigid scheduling strategy limits the flexible allocation of bandwidth resources, making it difficult to adapt to complex and ever-changing service demands, and affecting the overall network throughput and resource utilization. Summary of the Invention

[0008] In view of this, the purpose of this application is to provide a cross-device link aggregation communication method and related apparatus, so that cross-device link aggregation technology can adapt to complex L3VPN service scenarios, while improving the flexible allocation capability of bandwidth resources, so as to adapt to complex and ever-changing service needs and improve resource utilization.

[0009] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: In a first aspect, this application provides a cross-device link aggregation communication method, applied to any one of two MLAG devices in a cross-device link aggregation group MLAG network, wherein each MLAG device is connected to at least one other network device via an aggregation group member link, the method comprising: Retrieve L3VPN packets to be forwarded; When the L3VPN message to be forwarded is a protocol message, the L3VPN message to be forwarded is sent to the corresponding other network devices through the local aggregation group member link; When the L3VPN message to be forwarded is a data message, the forwarding path corresponding to the L3VPN message to be forwarded is determined according to the receiving path of the L3VPN message to be forwarded, the transmission parameters corresponding to the data stream type to which it belongs, and the available remaining bandwidth of the aggregation group member links corresponding to the two MLAG devices, and the L3VPN message to be forwarded is forwarded through the forwarding path.

[0010] In an optional implementation, determining the forwarding path corresponding to the L3VPN packet to be forwarded based on the receiving path of the L3VPN packet to be forwarded, the transmission parameters corresponding to the data stream type, and the available remaining bandwidth of the aggregation group member links corresponding to the two MLAG devices includes: If the L3VPN message to be forwarded is sent from the peer MLAG device to this MLAG device via the Peer-Link link, then the forwarding path corresponding to the L3VPN message to be forwarded is determined to be the local aggregation group member link; If the L3VPN message to be forwarded is not sent from the peer MLAG device to this MLAG device via the Peer-Link link, then the forwarding path corresponding to the L3VPN message to be forwarded is determined according to the transmission parameters corresponding to the data flow type of the L3VPN message to be forwarded and the available remaining bandwidth of the aggregation group member links corresponding to the two MLAG devices.

[0011] In an optional implementation, the transmission parameters include historical forwarding paths and forwarding rates; determining the forwarding path corresponding to the L3VPN packet to be forwarded based on the transmission parameters corresponding to the data flow type to which the L3VPN packet to be forwarded belongs and the available remaining bandwidth of the aggregation group member links corresponding to the two MLAG devices includes: If the historical forwarding path of the L3VPN packet to be forwarded is the local aggregation group member link, then if the available remaining bandwidth of the local aggregation group member link is greater than a preset threshold, the forwarding path of the L3VPN packet to be forwarded is determined to be the local aggregation group member link. If the available remaining bandwidth of the local aggregation group member link is not greater than the preset threshold, the forwarding path of the L3VPN packet to be forwarded is determined according to the forwarding rate of the L3VPN packet to be forwarded, the available remaining bandwidth of the aggregation group member link corresponding to the peer MLAG device, and the preset threshold. If the historical forwarding path of the L3VPN packet to be forwarded is the Peer-Link link, then if the available remaining bandwidth of the aggregation group member link corresponding to the peer MLAG device is greater than the preset threshold, the forwarding path of the L3VPN packet to be forwarded is determined to be the Peer-Link link. If the available remaining bandwidth of the aggregation group member link corresponding to the peer MLAG device is not greater than the preset threshold, the forwarding path of the L3VPN packet to be forwarded is determined according to the forwarding rate of the L3VPN packet to be forwarded, the available remaining bandwidth of the local aggregation group member link, and the preset threshold.

[0012] In an optional implementation, determining the forwarding path of the L3VPN packet to be forwarded based on the forwarding rate of the L3VPN packet to be forwarded, the available remaining bandwidth of the aggregation group member links corresponding to the peer MLAG device, and the preset threshold includes: If the forwarding rate of the L3VPN packet to be forwarded is less than the difference between the available remaining bandwidth of the aggregation group member link corresponding to the peer MLAG device and the preset threshold, then the forwarding path of the L3VPN packet to be forwarded is determined to be the Peer-Link link. If the forwarding rate of the L3VPN packet to be forwarded is not less than the difference between the available remaining bandwidth of the aggregation group member link corresponding to the peer MLAG device and the preset threshold, then the forwarding path of the L3VPN packet to be forwarded is determined to be the local aggregation group member link. The step of determining the forwarding path of the L3VPN packet to be forwarded based on the forwarding rate of the L3VPN packet to be forwarded, the available remaining bandwidth of the local aggregation group member links, and the preset threshold includes: If the forwarding rate of the L3VPN packet to be forwarded is less than the difference between the available remaining bandwidth of the local aggregation group member link and the preset threshold, then the forwarding path of the L3VPN packet to be forwarded is determined to be the local aggregation group member link. If the forwarding rate of the L3VPN packet to be forwarded is not less than the difference between the available remaining bandwidth of the local aggregation group member link and the preset threshold, then the forwarding path of the L3VPN packet to be forwarded is determined to be the Peer-Link link.

[0013] In an optional implementation, the two MLAG devices are configured with the same L3VPN label for the same L3VPN service, and the method further includes: Receive pending L3VPN messages sent by the other network devices; If a target L3VPN label matching the L3VPN label of the L3VPN packet to be processed is configured locally, then the L3VPN packet to be processed is processed.

[0014] In an optional implementation, the method further includes: In the event of a local aggregation group member link failure, the usage status of the local aggregation group member link and the usage status of the MLAG logical interface corresponding to the local aggregation group member link are set to an unavailable state, and aggregation group member link failure information is sent to the peer MLAG device so that the peer MLAG device sets the usage status of the Peer-Link link to an unavailable state. When the local aggregation group member link is restored to normal, the usage status of the local aggregation group member link and the usage status of the MLAG logical interface corresponding to the local aggregation group member link are set to the available status, and aggregation group member link restoration information is sent to the peer MLAG device so that the peer MLAG device sets the usage status of the Peer-Link link to the available status. In the event of a Peer-Link failure, the Peer-Link's usage status is set to unavailable locally, and in the event of a Peer-Link recovery, the Peer-Link's usage status is set to available locally.

[0015] In an optional implementation, determining the forwarding path corresponding to the L3VPN packet to be forwarded based on the receiving path of the L3VPN packet to be forwarded, the transmission parameters corresponding to the data stream type, and the available remaining bandwidth of the two MLAG devices includes: When the usage status of the aggregation group member links of the two MLAG devices and the usage status of the MLAG logical interfaces corresponding to the aggregation group member links are both available, and the usage status of the Peer-Link link is available, the forwarding path corresponding to the L3VPN message to be forwarded is determined according to the receiving path of the L3VPN message to be forwarded, the transmission parameters corresponding to the data stream type, and the available remaining bandwidth of the two MLAG devices.

[0016] Secondly, this application provides a cross-device link aggregation communication device, wherein any one of two MLAG devices configured in a cross-device link aggregation group MLAG network, each of the MLAG devices being communicatively connected to at least one other network device via an aggregation group member link, the device comprising: The acquisition module is used to acquire L3VPN packets to be forwarded. The forwarding module is used to send the L3VPN message to be forwarded to other corresponding network devices through the local aggregation group member link of the MLAG device when the L3VPN message to be forwarded is a protocol message. The forwarding module is further configured to, when the L3VPN message to be forwarded is a data message, determine the forwarding path corresponding to the L3VPN message to be forwarded based on the receiving path of the L3VPN message to be forwarded, the transmission parameters corresponding to the data stream type to which it belongs, and the available remaining bandwidth of the aggregation group member links corresponding to the two MLAG devices, and forward the L3VPN message to be forwarded through the forwarding path.

[0017] Thirdly, this application provides an MLAG device, including a processor and a memory, wherein the memory stores a computer program executable by the processor, and the processor is used to execute the computer program to implement the method described in any of the foregoing embodiments.

[0018] Fourthly, this application provides a system for networking using cross-device link aggregation group (MLAG), including two MLAG devices as described in the foregoing embodiments.

[0019] Fifthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in any of the foregoing embodiments.

[0020] The cross-device link aggregation communication method and related apparatus provided in this application, when the L3VPN message to be forwarded is a protocol message, allows devices in a cross-device link aggregation group to send the L3VPN message to other corresponding network devices via local aggregation group member links. This restricts protocol messages to be transmitted only on directly connected aggregation group member links, avoiding the transmission of control plane protocol messages on cross-device interconnected Peer-Link links, thereby preventing the formation of cross-protocol neighbor relationships between non-directly connected devices. Furthermore, a differentiated strategy is adopted for processing non-protocol messages, i.e., data messages. When the L3VPN message to be forwarded is a data message, the forwarding path corresponding to the L3VPN message is determined based on the receiving path of the L3VPN message, the transmission parameters corresponding to the data stream type, and the available remaining bandwidth of the aggregation group member links corresponding to the two MLAG devices. The L3VPN message is then forwarded through the forwarding path. The available remaining bandwidth here serves as one of the key bases for dynamic path selection, reflecting the current link's ability to carry new traffic. In this way, by distinguishing between the forwarding behavior of protocol messages and data messages, on the one hand, protocol messages are controlled to be sent only through local aggregation group member links, reducing control plane complexity and device processing pressure; on the other hand, a comprehensive judgment mechanism based on the receiving path, data stream type transmission parameters, and available remaining bandwidth is introduced for data messages to achieve dynamic decision-making on forwarding paths. Therefore, cross-device link aggregation technology can support flexible data forwarding requirements in L3VPN scenarios while maintaining control plane simplicity. In addition, by incorporating available remaining bandwidth into the forwarding path decision factors, MLAG networking is allowed to dynamically adjust traffic distribution according to the actual link load, improving the fine-grained scheduling capability of bandwidth resources, meeting complex and ever-changing business needs, and improving the utilization rate of link resources.

[0021] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0022] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This illustration shows a block diagram of a cross-device link aggregation group provided in an embodiment of this application; Figure 2 A block diagram illustrating a cross-device link aggregation network is shown. Figure 3 Another block diagram of cross-device link aggregation networking is shown; Figure 4 Another block diagram of cross-device link aggregation networking is shown; Figure 5 A block diagram illustrating cross-device link aggregation networking in an L3VPN over MPLS scenario is shown. Figure 6 A block diagram illustrating cross-device link aggregation networking in an L3VPN over SRv6 scenario is shown. Figure 7 A block diagram of a network device provided in an embodiment of this application is shown; Figure 8 This paper illustrates a flowchart of a cross-device link aggregation communication method provided in an embodiment of this application. Figure 9 A functional block diagram of a cross-device link aggregation communication device provided in an embodiment of this application is shown. Detailed Implementation

[0024] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can be arranged and designed in various different configurations.

[0025] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0026] It should be noted that relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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. Without further limitations, 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 the element.

[0027] Figure 1Please refer to the block diagram illustrating a network using MLAG as provided in this application embodiment. Figure 1 The MLAG network includes a first MLAG device and a second MLAG device, which are connected via a Peer-Link link.

[0028] In this embodiment, the system using MLAG networking consists of two MLAG devices. The two MLAG devices cooperate with each other to achieve logical link aggregation, thereby improving network reliability and bandwidth utilization.

[0029] In this architecture, each of the two MLAG devices in the MLAG system establishes a communication connection with at least one other network device. This connection is achieved through aggregation group member links. That is, each MLAG device participating in the aggregation is connected to at least one other network device at the upper or lower layer through one or more physical links. These links are defined as aggregation group member links and undertake the main data forwarding tasks.

[0030] Specifically, the aforementioned aggregated group member links constitute the basic path for the MLAG system's external communication, carrying service traffic between it and other network devices. Under this structure, the MLAG system can be deployed on upper-level nodes, lower-level nodes, or both in the network topology, forming a flexible dual-homed access mode. Each MLAG system group corresponds to a logical interface, which presents uniform external characteristics on all MLAG devices within the group, such as using the same MAC address (Media Access Control Address), thus appearing as a single exit point at the network layer, facilitating routing and forwarding decisions by the peer MLAG devices.

[0031] In one example Figure 2 For a block diagram illustrating MLAG networking, please refer to [link / reference]. Figure 2 In actual network deployment, both upper-level and lower-level nodes can adopt a dual-device, dual-link structure (i.e., upper-level MLAG devices A and B, and lower-level MLAG devices A and B). Each node forms an independent MLAG system, with each MLAG system corresponding to one MLAG logical interface. Furthermore, the two MLAG devices within the same MLAG aggregation group are configured with the same MAC address for this logical interface to ensure consistency and transparency at the link layer. The aggregation group member links are used to carry service traffic with other network devices, including the transmission and reception of L3VPN packets. Peer-Link links do not directly participate in external communication with other network devices; they only serve internal collaboration between MLAG devices within the same group. Upper-level MLAG devices can connect to different lower-level MLAG devices through multiple MLAG groups.

[0032] Figure 3 For another block diagram of MLAG networking, please refer to [link / reference]. Figure 3 In this network architecture, the upper-level nodes consist of two independent devices: upper-level MLAG device A and upper-level MLAG device B, which form an MLAG system through interconnected Peer-Link links. Each MLAG system corresponds to one MLAG logical interface, which is configured with the same MAC address on both upper-level MLAG device A and upper-level MLAG device B to ensure a consistent link-layer identity. Upper-level MLAG device A and upper-level MLAG device B are each connected to lower-level nodes via physical links. These links are defined as MLAG aggregation group member links and undertake the main data transmission tasks. Lower-level nodes adopt a single-device dual-link structure, allowing upper-level MLAG devices to connect to different lower-level node devices through multiple MLAG sets.

[0033] Figure 4 For another block diagram of MLAG networking, please refer to [link / reference]. Figure 4 In this network architecture, the upper-level nodes adopt a single-device dual-link structure, while the lower-level nodes consist of lower-level MLAG device A and lower-level MLAG device B, which form an MLAG through interconnected Peer-Link links. Lower-level MLAG device A and lower-level MLAG device B each establish connections with the upper-level network devices. These connections are defined as MLAG aggregation member links, used to carry the transmission and reception of service traffic. Each MLAG corresponds to one MLAG logical interface, and lower-level MLAG device A and lower-level MLAG device B are configured with the same MAC address for this MLAG logical interface.

[0034] It is worth noting that Peer-Link is mainly used for control plane information exchange, state synchronization, and forwarding data packets under specific conditions. The aggregation group member links focus on communication with other network devices, ensuring that protocol messages such as ARP (Address Resolution Protocol) messages, NDP (Neighbor Discovery Protocol) messages, MPLS LDP (Multiprotocol Label Switching Label Distribution Protocol) messages, OSPFv2 / v3 (Open Shortest Path First version 2 / v3) messages, ISISv4 / v6 (Intermediate System to Intermediate System version 4 / v6) messages, BGP (Border Gateway Protocol) messages, and SRv6 (Segment Routing over IPv6) messages are sent only through the aggregation group member links to establish direct neighbor relationships. This avoids redundant or overlapping control plane sessions between non-directly connected devices, thereby reducing control plane resource consumption and improving overall system processing performance.

[0035] In practical applications, this cross-device link aggregation group supports a variety of L3VPN (Layer 3 Virtual Private Network) networking technologies, including L3VPN over MPLS based on multi-protocol label switching and L3VPN over SRv6 based on segment routing IPv6.

[0036] In one example, as described above Figure 2 Taking MLAG networking as an example, Figure 5 For a block diagram of MLAG networking in an L3VPN over MPLS scenario, please refer to [link / reference]. Figure 5In the L3VPN over MPLS scenario, the upper and lower level MLAG devices act as PE devices (Provider Edge). They run OSPFv2 or ISISv4 routing protocols on the logical interfaces corresponding to the MLAG system, and combine MPLS LDP protocol to establish a transmission channel for the border gateway protocol, establish neighbors for BGP, and then publish L3VPN routing information carrying MPLS labels.

[0037] In the L3VPN over SRv6 scenario, Figure 6 For a block diagram illustrating the MLAG networking scenario under L3VPN over SRv6, please refer to [link / reference]. Figure 6 The upper and lower level MLAG devices run OSPFv3 or ISISv6 routing protocols and SRv6 protocols to establish neighbors for BGP+ and propagate L3VPN routes containing SRv6 SIDs (Segment IDs) through the BGP+ routing protocol to identify different VPN instances.

[0038] Optionally, in Figure 1 On this basis, Figure 7 For a block diagram of the MLAG device provided in the embodiments of this application, please refer to [link / reference]. Figure 7 The MLAG device includes a memory, a processor, and a communication module. These components are electrically connected directly or indirectly to enable data transmission or interaction. For example, they can be electrically connected via one or more communication buses or signal lines.

[0039] Memory is used to store computer programs or data that can be executed by a processor. Memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc.

[0040] The processor is used to read / write data or computer programs stored in memory, and execute the computer program to implement the cross-device link aggregation communication method provided in the embodiments of this application.

[0041] The communication module is used to establish communication connections between the MLAG device and other communication terminals via the network, and to send and receive data via the network.

[0042] It should be understood that, Figure 7 The structure shown is only a schematic diagram of an MLAG device; the MLAG device may also include components such as... Figure 7 The more or fewer components shown, or having the same Figure 5 , Figure 6 The different configurations shown. Figure 7 The components shown can be implemented using hardware, software, or a combination thereof.

[0043] The following is based on the above. Figure 1 Taking any MLAG device as the execution entity, the cross-device link aggregation communication method provided in this application embodiment is described executively with reference to the flowchart. Specifically, Figure 8 For a flowchart illustrating the MLAG communication method provided in this application embodiment, please refer to [link / reference]. Figure 8 The method includes: Step S20: Obtain the Layer 3 VPN packet to be forwarded.

[0044] Step S21: When the L3VPN message to be forwarded is a protocol message, the L3VPN message to be forwarded is sent to the corresponding other network devices through the local aggregation group member link.

[0045] It should be understood that in the network architecture of cross-device link aggregation group (MLAG) networking, the selection of transmission paths for protocol messages has a significant impact on the stability and processing efficiency of the control plane. Protocol messages differ from ordinary data messages. They primarily handle control plane functions such as state synchronization, neighbor discovery, and routing information exchange between network devices. Typical examples include ARP (Address Resolution Protocol) messages, NDP (Neighbor Discovery Protocol) messages, MPLS LDP (Multiprotocol Label Switching Label Distribution Protocol) messages, OSPFv2 / v3 (Open Shortest Path First version 2 / v3) messages, ISISv4 / v6 (Intermediate System to Intermediate System version 4 / v6) messages, BGP (Border Gateway Protocol) messages, and SRv6 (Segment Routing over IPv6) messages.

[0046] During the execution of the above steps, when any MLAG device obtains an L3VPN message to be forwarded in the cross-device link aggregation group, if it determines that the L3VPN message to be forwarded belongs to the aforementioned protocol message type, it will not forward it through the Peer-Link link, but will instead restrict the protocol message to be sent to the corresponding other network devices through the local aggregation group member link.

[0047] Understandably, this processing mechanism is designed to avoid establishing redundant or overlapping protocol neighbor relationships between non-directly connected devices. By strictly constraining the transmission path of protocol messages to local aggregation group member links, it ensures that protocol messages are transmitted only through aggregation group member links, maintaining the clarity and consistency of the control plane topology.

[0048] In other words, by restricting protocol messages to be sent only from the local aggregation group member links, the complexity of the control plane introduced by the existence of Peer-Link links within the cross-device link aggregation group can be avoided. This effectively reduces the possibility of cross-establishment of protocol neighbors between non-directly connected devices, reduces the message processing burden and state maintenance overhead of MLAG devices in the control plane, and thus improves the overall system's operational stability and processing performance.

[0049] Step S22: When the L3VPN message to be forwarded is a data message, determine the forwarding path corresponding to the L3VPN message to be forwarded based on the receiving path of the L3VPN message to be forwarded, the transmission parameters corresponding to the data stream type, and the available remaining bandwidth of the aggregation group member links corresponding to the two MLAG devices, and forward the L3VPN message to be forwarded through the forwarding path.

[0050] As is understandable, the aggregation group member link here refers to the link between the MLAG device and other network devices corresponding to the L3VPN packet to be forwarded.

[0051] In this embodiment, data packets specifically refer to non-protocol packets, that is, user service traffic that does not undertake the functions of control plane neighbor establishment or routing state synchronization. Their forwarding strategy is fundamentally different from that of protocol packets.

[0052] During the execution of the above steps, when any MLAG device obtains an L3VPN packet to be forwarded in the cross-device link aggregation group, if it determines that the L3VPN packet to be forwarded belongs to the data packet type, it will start the forwarding path decision mechanism based on multi-dimensional dynamic parameters.

[0053] Specifically, this mechanism uses the receiving path of the L3VPN packet to be forwarded, the transmission parameters of its data stream type, and the available remaining bandwidth of the aggregation group member links corresponding to the two MLAG devices as input conditions to comprehensively evaluate and determine the optimal forwarding path. That is, whether to send it to the peer MLAG device for forwarding via the Peer-Link link or to forward it directly via the local aggregation group member link.

[0054] Optionally, the two MLAG devices can count the available remaining bandwidth of each of their aggregation group member links in real time and periodically synchronize the status of the cross-device link aggregation group.

[0055] In one possible implementation, the available remaining bandwidth can be the difference between the bandwidth provided by the operator and the actual traffic rate of the current link. That is, if the operator promises a link bandwidth of X bps and the current real-time traffic rate of the link is Y bps, then the currently available remaining bandwidth is (XY) bps.

[0056] In this embodiment, the data stream type can be configured according to actual needs. For example, it can be defined based on one or more packet characteristics such as source IP address / network segment, destination IP address / network segment, IP protocol number, source port, and destination port. Alternatively, it can be customized by the user based on ACL. The MLAG device can perform real-time statistics and synchronization of the transmission parameters of each defined data stream type in the MLAG.

[0057] This method can effectively utilize the bandwidth resources of two independent aggregation group member links while ensuring forwarding efficiency, thereby improving the overall throughput of the link aggregation group.

[0058] It should be noted that, in order to prevent data packets from forming forwarding loops within the cross-device link aggregation group, it is also necessary to explicitly prohibit data packets received from the aggregation group member links from being transmitted back through the Peer-Link link. In this way, while achieving flexible load balancing, the path constraint mechanism ensures the loop-free nature and stability of data forwarding, thus constructing an efficient and reliable cross-device link aggregation data forwarding mechanism in the L3VPN scenario.

[0059] The cross-device link aggregation communication method provided in this application allows devices in a cross-device link aggregation group to send the L3VPN message to other corresponding network devices via local aggregation group member links when the L3VPN message to be forwarded is a protocol message. This restricts the protocol message to be transmitted only on directly connected aggregation group member links, avoiding the transmission of control plane protocol messages on cross-device interconnected Peer-Link links, thereby preventing the formation of cross-protocol neighbor relationships between non-directly connected devices. Furthermore, a differentiated strategy is adopted for processing non-protocol messages, i.e., data messages. When the L3VPN message to be forwarded is a data message, the forwarding path corresponding to the L3VPN message is determined based on the receiving path of the L3VPN message, the transmission parameters corresponding to the data stream type, and the available remaining bandwidth of the aggregation group member links corresponding to the two MLAG devices. The L3VPN message is then forwarded through the forwarding path. The available remaining bandwidth here serves as one of the key bases for dynamic path selection, reflecting the current link's ability to carry new traffic. In this way, by distinguishing between the forwarding behavior of protocol messages and data messages, on the one hand, protocol messages are controlled to be sent only through local aggregation group member links, reducing control plane complexity and device processing pressure; on the other hand, a comprehensive judgment mechanism based on the receiving path, data stream type transmission parameters, and available remaining bandwidth is introduced for data messages to achieve dynamic decision-making on forwarding paths. Therefore, MLAG technology can support flexible data forwarding requirements in L3VPN scenarios while maintaining a simple control plane. In addition, by incorporating available remaining bandwidth into the forwarding path decision factors, MLAG networking allows traffic distribution to be dynamically adjusted according to the actual link load, improving the fine-grained scheduling capability of bandwidth resources, meeting complex and ever-changing business needs, and improving the utilization rate of link resources.

[0060] It should be noted that L3VPN technology relies on label switching mechanisms to complete packet encapsulation and identification. Under MPLS or SRv6 architecture, BGP is responsible for assigning corresponding L3VPN labels to different L3VPN instances. These labels are used to indicate the specific VPN instance to which the packet belongs and are the key basis for the receiving end to correctly decapsulate and process service traffic.

[0061] Research has revealed that current cross-device link aggregation solutions are mostly based on pure IP forwarding or stacking architectures, failing to adequately consider the compatibility issues arising from the separation of the control plane and data plane in an L3VPN environment. Specifically, when both upstream and downstream nodes employ dual-device cross-device link aggregation, if the two devices use different L3VPN labels for the same L3VPN service, the packet cannot be processed correctly. Understandably, due to the lack of constraints on the uniformity of L3VPN labels, related technologies struggle to support seamless data plane collaboration in a dual-device, dual-link architecture.

[0062] To address this issue, in this embodiment, the two MLAG devices in the MLAG networking system can also be configured with the same L3VPN label for the same L3VPN service. Based on this, when any MLAG device receives an L3VPN message to be processed from another network device, if it has a locally configured target L3VPN label that matches the L3VPN label of the message to be processed, then it will process the L3VPN message.

[0063] During the above steps, any MLAG device receives an unprocessed L3VPN message sent by another network device. In this scenario, because the control plane protocol neighbor relationship is only established between peers connected by the local aggregation group member links, and no control plane cross-synchronization is formed within the MLAG, it is possible for a device to receive an L3VPN data packet originally destined for its peer MLAG device.

[0064] To ensure that such cross-path forwarded L3VPN packets can be correctly identified and processed, this embodiment requires, at the configuration level, that two MLAG devices in a system using MLAG networking be configured with the same L3VPN label for the same L3VPN service.

[0065] Optionally, the L3VPN label refers to an MPLS label value or an SRv6 SID.

[0066] Specifically, during the BGP negotiation process, the two MLAG devices that make up the MLAG will uniformly allocate the same MPLS label value or SRv6 SID for the same L3VPN instance using dynamic negotiation or static configuration. This ensures that no matter which device a packet enters or leaves the aggregation group from, the L3VPN label it carries can be accurately matched by the other device.

[0067] Based on this, when a local MLAG device receives an L3VPN packet to be processed from another network device, it first parses the L3VPN label encapsulated in the packet and searches its local configuration information for a target L3VPN label that matches the label. If a match is found, the packet is confirmed to belong to the L3VPN service category that can be processed locally, and the corresponding decapsulation, route lookup, and forwarding actions are then performed; otherwise, it is discarded or reported according to the abnormal packet handling procedure.

[0068] In this embodiment, by unifying the label identification of the same L3VPN service within the MLAG, the packet processing consistency problem caused by the lack of cross-adjacency establishment in the control plane and the existence of cross paths in the forwarding plane is resolved. This mechanism effectively ensures that even if L3VPN traffic that should belong to the peer MLAG device in the same group is received on a member link of the aggregation group, the local MLAG device still has the correct identification and processing capability, thereby realizing seamless collaboration and high-reliability forwarding of the L3VPN data plane in a cross-device environment.

[0069] Furthermore, analysis revealed that current MLAG technology faces the problem of untimely dynamic fault response in L3VPN scenarios. In particular, when the state of local aggregation group member links or Peer-Link links changes, the lack of a fast and reliable link state propagation mechanism may lead to data packets being forwarded to invalid paths, resulting in packet loss, retransmission, or even service interruption.

[0070] To address this issue and improve the response efficiency to dynamic faults, in this embodiment, two MLAG devices can obtain the status of each of their member links in real time and synchronize with their peer MLAG devices. For example, the usage status changes of each aggregation group member link, including available and unavailable. In addition, to avoid the loss of real-time notification information, the usage status needs to be notified to each other periodically.

[0071] In one possible implementation, if a local aggregation group member link fails, the MLAG device can set the usage status of the local aggregation group member link and the usage status of the corresponding MLAG logical interface to an unavailable state, and send aggregation group member link failure information to the peer MLAG device so that the peer MLAG device sets the usage status of the Peer-Link link to an unavailable state. If the local aggregation group member link recovers, the device can set the usage status of the local aggregation group member link and the usage status of the corresponding MLAG logical interface to an available state, and send aggregation group member link recovery information to the peer MLAG device so that the peer MLAG device sets the usage status of the Peer-Link link to an available state.

[0072] It should be understood that during the operation of MLAG, the local aggregation group member links serve as critical physical pathways connecting other devices, and their connectivity directly affects the normal forwarding of service traffic. It should be noted that when any local aggregation group member link fails, it not only affects the external communication capabilities of the local MLAG device but may also impact the feasibility of cross-device traffic forwarding by peer MLAG devices via Peer-Link.

[0073] During the execution of the above steps, once a failure is detected in a local aggregation group member link, the usage status of the failed local aggregation group member link is first set to unavailable to indicate that it currently does not have data forwarding capabilities.

[0074] Building upon this, the usage status of the MLAG logical interface associated with the failed link is further set to unavailable. This logical interface is the unified abstract interface presented to the outside world by the member links. Its status change triggers the response mechanism of the upper-layer protocol stack, such as routing protocol re-convergence or forwarding policy adjustment, thereby prompting the network system as a whole to migrate to a new stable state. At the same time, this MLAG device also immediately sends the aggregation group member link failure information to the peer MLAG device through the Peer-Link link. The peer MLAG device then sets the usage status of the Peer-Link link to ensure real-time synchronization of status changes. The purpose of this is to prevent the peer MLAG device from continuing to redirect data packets that should have been forwarded through the failed link to this MLAG device through the Peer-Link link, avoiding data loss or forwarding black holes caused by path failure.

[0075] Understandably, when the Peer-Link link usage status is set to unavailable, the control plane synchronization mechanism within MLAG will also be suspended, including periodic announcements of the remaining bandwidth available for aggregation group member links, immediate notifications of status changes, and continuous interaction of various transmission parameters.

[0076] It should be understood that during the operation of MLAG, the dynamic changes in link status not only include the occurrence of faults but also cover the critical scenario of fault recovery. It should be noted that when a local aggregation group member link recovers from an outage, if the recovery status is not identified and propagated in a timely manner, network resources may not be effectively reused, affecting overall forwarding efficiency and load balancing capabilities.

[0077] During the execution of the above steps, once the MLAG device detects that the local aggregation group member link has regained connectivity, it first resets the usage status of the link to an available state to indicate that it has normal data transmission capability.

[0078] Building upon this, the usage status of the MLAG logical interface associated with this link is further updated to an available state. This logical interface, as a unified abstract entity presented externally to the two aggregation group member links, triggers response mechanisms from upper-layer protocols such as routing protocols when its state changes. These mechanisms might include republishing reachability information or adjusting forwarding path weights, thereby prompting the network topology to converge towards the optimal state. Simultaneously, this MLAG device immediately sends aggregation group member link recovery information to the peer MLAG device via the Peer-Link link, ensuring that the peer device is aware in real time that the link on its side has been restored, thus resetting the usage status of the Peer-Link link to an available state.

[0079] Understandably, by proactively notifying the peer MLAG device after the local link is restored, the peer MLAG device can reactivate its collaborative forwarding capability with this MLAG device. The significance of this is to restore the cross-device data packet redirection capability, allowing the peer MLAG device to once again forward some traffic to this MLAG device via the Peer-Link link, and then send it out through the restored local aggregation group member link, thereby achieving full utilization of bandwidth resources.

[0080] Furthermore, the restoration of Peer-Link usage status also means the restart of the control plane synchronization mechanism within MLAG, including periodic announcements of remaining available bandwidth for aggregation group member links, immediate notifications of status changes, and continuous interaction of various transmission parameters. Thus, these steps not only achieve the logical state reconstruction after physical link recovery but also ensure the complete restoration of the cross-device collaboration mechanism, allowing data packets to continue to be flexibly scheduled among available paths according to dynamic adjustment strategies, thereby improving network self-healing capabilities and resource utilization in the L3VPN environment.

[0081] In this embodiment, the MLAG device also needs to set the Peer-Link link to an unavailable state locally in the event of a Peer-Link link failure, and set the Peer-Link link to an available state locally when the Peer-Link link is restored to normal operation.

[0082] It should be understood that the Peer-Link link, as a dedicated interconnection channel between two MLAG devices in a system using MLAG networking, undertakes the critical functions of control information exchange, status synchronization, and cross-device forwarding of data packets. It should be noted that the connectivity of this Peer-Link link directly affects the effectiveness of the cross-device collaboration mechanism, and its operational status must be accurately perceived and reflected in the system's forwarding decision logic.

[0083] During the execution of the above steps, when any MLAG device detects a failure in the Peer-Link link between itself and the peer MLAG device, it immediately sets the usage status of the locally maintained Peer-Link link to an unavailable state to indicate that it is currently unable to carry any cross-device communication tasks.

[0084] In this state, the MLAG device will stop sending all data packets via the Peer-Link link to prevent packet loss or retransmission timeouts due to link interruption. Simultaneously, since the Peer-Link link is the only channel for exchanging critical transmission parameters such as available remaining bandwidth and status changes among MLAG devices, its failure means the control plane synchronization mechanism is unreliable. Therefore, the system synchronously suspends bandwidth and status information exchange with the peer MLAG device to avoid making incorrect path selections based on outdated or incomplete information.

[0085] Furthermore, upon detecting the restoration of Peer-Link connectivity, this MLAG device, after confirming link stability, resets the locally maintained link's usage status to available. This operation signifies the reconstruction of cross-device collaborative capabilities, enabling the device to re-enable the Peer-Link link for data forwarding and control information transmission. Specifically, data packets can again be forwarded to the peer MLAG device via the Peer-Link link according to the "dynamic adjustment method," and the peer MLAG device will then complete packet transmission through its local aggregation group member links.

[0086] Simultaneously, the real-time or periodic synchronization mechanism for information such as available remaining bandwidth and status changes of the aggregated member links of the two MLAG devices in the MLAG network also resumes operation, ensuring that both parties can continuously obtain the latest link resource view and support subsequent refined load balancing decisions. This method, by establishing a localized awareness and explicit management mechanism for Peer-Link status, achieves consistency between control plane and data plane behavior in link failure and recovery scenarios, ensuring the system's stability and self-healing capabilities under abnormal conditions.

[0087] Based on this, in order to ensure reliable transmission of messages, the MLAG device can determine the forwarding path of the L3VPN message to be forwarded, based on the receiving path of the L3VPN message to be forwarded, the transmission parameters corresponding to the data stream type, and the available remaining bandwidth of the aggregation group member links of the two MLAG devices, provided that the usage status of the aggregation group member links of the two MLAG devices and the usage status of the MLAG logical interfaces corresponding to the aggregation group member links of the two MLAG devices are both available, and the usage status of the Peer-Link link is also available.

[0088] The following provides a possible implementation method for determining the forwarding path of an L3VPN packet based on the receiving path of the L3VPN packet to be forwarded, the transmission parameters corresponding to the data stream type, and the available remaining bandwidth of the aggregation group member links of the two MLAG devices.

[0089] Specifically, if the L3VPN message to be forwarded is sent from the peer MLAG device to this MLAG device via a Peer-Link link, then the forwarding path corresponding to the L3VPN message to be forwarded is determined to be the local aggregation group member link; if the L3VPN message to be forwarded is not sent from the peer MLAG device to this MLAG device via a Peer-Link link, then the forwarding path corresponding to the L3VPN message to be forwarded is determined according to the transmission parameters corresponding to the data flow type of the L3VPN message to be forwarded and the available remaining bandwidth of the aggregation group member links corresponding to the two MLAG devices.

[0090] It should be understood that in a system architecture using MLAG networking, data packets may reach any MLAG device through two paths: one is direct reception from an upstream device via a local link, and the other is forwarding from another device in the same group via a Peer-Link link. It should be noted that the Peer-Link link, as a dedicated interconnection channel between devices, supports redirecting data traffic that would otherwise be processed by the peer device to the local device for forwarding, thereby achieving collaborative utilization of link resources and seamless switching in fault scenarios. During the execution of the above steps, when an MLAG device obtains an L3VPN packet to be forwarded, it first determines the source of the packet's reception path.

[0091] Specifically, if the L3VPN packet to be forwarded is sent to this MLAG device from the peer MLAG device via a Peer-Link link, it indicates that the packet has already undergone the forwarding path decision of the peer MLAG device and has been actively redirected to this MLAG device to complete forwarding using its normally functioning aggregation group member link. In this case, there is no need to perform complex load balancing calculations again; the forwarding path of the packet can be directly determined as the local aggregation group member link of this device, and it can be sent to the corresponding other network devices. This mechanism not only avoids the processing overhead caused by duplicate decisions but also ensures the consistency and efficiency of traffic scheduling.

[0092] Conversely, if the L3VPN packet to be forwarded is not received from the peer MLAG device via a Peer-Link link, but is sent by an upstream node directly connected to this device, it indicates that the packet has not yet participated in cross-device collaborative scheduling. In this case, a dynamic path selection mechanism needs to be activated. Based on the transmission parameters of the data stream type of the packet, combined with the available remaining bandwidth of the corresponding aggregation group member links between this MLAG device, the peer MLAG device, and other network devices, the optimal forwarding path is comprehensively evaluated and determined.

[0093] The core concept of this embodiment is to construct a hierarchical forwarding decision logic by differentiating the receiving path: for redirected traffic that has already completed path selection by the peer, a fast direct forwarding strategy is adopted; for newly created traffic directly received locally, fine-grained scheduling is performed based on multi-dimensional state information. This effectively reduces the complexity of the control plane and improves the response speed of the data plane while ensuring cross-device collaborative forwarding capabilities. It is especially suitable for the high reliability and high utilization dual-device dual-link networking requirements in L3VPN environments.

[0094] In one possible implementation, the transmission parameters include historical forwarding paths and forwarding rates. Next, a possible implementation is provided on how to determine the forwarding path corresponding to the L3VPN packet to be forwarded based on the transmission parameters corresponding to the data flow type to which the L3VPN packet to be forwarded belongs and the available remaining bandwidth of the aggregation group member links corresponding to the two MLAG devices.

[0095] Specifically, if the historical forwarding path of the L3VPN packet to be forwarded is a local aggregation group member link, then if the available remaining bandwidth of the local aggregation group member link is greater than a preset threshold, the forwarding path of the L3VPN packet to be forwarded is determined to be a local aggregation group member link; if the available remaining bandwidth of the local aggregation group member link is not greater than the preset threshold, the forwarding path of the L3VPN packet to be forwarded is determined according to the forwarding rate of the L3VPN packet to be forwarded, the available remaining bandwidth of the aggregation group member link corresponding to the peer MLAG device, and the preset threshold.

[0096] If the historical forwarding path of the L3VPN packet to be forwarded is a Peer-Link link, then if the available remaining bandwidth of the aggregation group member link corresponding to the peer MLAG device is greater than a preset threshold, the forwarding path of the L3VPN packet to be forwarded is determined to be a Peer-Link link; if the available remaining bandwidth of the aggregation group member link corresponding to the peer MLAG device is not greater than the preset threshold, the forwarding path of the L3VPN packet to be forwarded is determined according to the forwarding rate of the L3VPN packet to be forwarded, the available remaining bandwidth of the local aggregation group member link, and the preset threshold.

[0097] It should be understood that in MLAG networking, the selection of data flow forwarding paths must take into account load balancing, bandwidth utilization, and state consistency. It should be noted that each type of data flow is initially configured to be sent through the local aggregation group member links; this initial decision forms the basis for subsequent dynamic adjustments.

[0098] During the execution of the above steps, when the MLAG device processes the L3VPN packet to be forwarded, it first queries the historical forwarding path information based on the data flow type to which the packet belongs.

[0099] Specifically, if the historical forwarding path of the L3VPN packet to be forwarded is a local aggregation group member link, it is further determined whether the available remaining bandwidth of the local aggregation group member link is greater than a preset threshold. If the condition is met, it means that the local link still has sufficient capacity to carry the traffic, so the original path is maintained, and the forwarding path of the packet is determined to be a local aggregation group member link.

[0100] If the available remaining bandwidth of the local aggregation group member links is not greater than a preset threshold, a secondary evaluation process is initiated: combining the current forwarding rate of the data stream, the available remaining bandwidth of the aggregation group member links of the peer MLAG device, and the same preset threshold, a comprehensive judgment is made as to whether the data stream should be switched to the Peer-Link link for redirection. This mechanism aims to avoid local link overload while making full use of the remaining bandwidth resources of the peer MLAG device.

[0101] Conversely, if the historical forwarding path of the L3VPN packet to be forwarded is a Peer-Link link, then if the available remaining bandwidth of the aggregated group member link of the peer MLAG device is greater than a preset threshold, the existing path can be maintained, and the forwarding path of the packet is determined to be the Peer-Link link between the peer MLAG device and the peer.

[0102] If the available remaining bandwidth of the peer link is lower than or equal to the preset threshold, a back-switch evaluation is triggered: based on the relationship between the forwarding rate of the data flow and the available remaining bandwidth of the local aggregation group member links and the preset threshold, it is determined whether the data flow should be redirected to local forwarding.

[0103] Optionally, the preset threshold can be set according to the actual application.

[0104] The core concept of this embodiment lies in introducing a closed-loop feedback mechanism based on historical paths and real-time link status to achieve dynamic migration of data streams between local aggregation group member links and Peer-Link links. This process uses a preset threshold as the benchmark for determining bandwidth health, combined with the data stream's own rate characteristics, to ensure that adjustments to the forwarding path are neither too frequent nor insensitive.

[0105] Optionally, if the forwarding rate of the L3VPN packet to be forwarded is less than the difference between the available remaining bandwidth of the aggregation group member link corresponding to the peer MLAG device and a preset threshold, then the forwarding path of the L3VPN packet to be forwarded is determined to be a Peer-Link link; if the forwarding rate of the L3VPN packet to be forwarded is not less than the difference between the available remaining bandwidth of the aggregation group member link corresponding to the peer MLAG device and a preset threshold, then the forwarding path of the L3VPN packet to be forwarded is determined to be a local aggregation group member link.

[0106] It should be understood that in MLAG networking, the forwarding path decision of the data flow of one MLAG device needs to be dynamically balanced between the local link load and the link resources of the other MLAG device in order to achieve efficient utilization of the overall bandwidth.

[0107] During the above steps, the forwarding rate of the data flow type of the L3VPN packet to be forwarded is first obtained, and then compared and analyzed in conjunction with the available remaining bandwidth of the aggregated group member links of the peer MLAG device and the preset threshold.

[0108] If the forwarding rate of the L3VPN packet to be forwarded is less than the difference between the available remaining bandwidth of the aggregation group member link of the peer MLAG device and the preset threshold, it indicates that the peer link has sufficient security margin to accommodate the new traffic and will not cause overload risk. In this case, the forwarding path of the packet is determined to be the Peer-Link link with the peer MLAG device, that is, the packet is sent to the peer MLAG device through the Peer-Link, and then forwarded by it through the local aggregation group member link.

[0109] Conversely, if the forwarding rate of the L3VPN packet to be forwarded is not less than the difference between the available remaining bandwidth of the aggregation group member link of the peer MLAG device and a preset threshold, it indicates that even if the peer link currently has idle bandwidth, its remaining capacity is insufficient to safely accept the data stream while ensuring service quality. To avoid transferring the congestion problem to the peer MLAG device, the MLAG device needs to select the local forwarding mode, determine the forwarding path of the packet as the local aggregation group member link, and continue to send it directly to other network devices by this device.

[0110] Furthermore, if the forwarding rate of the L3VPN packet to be forwarded is less than the difference between the available remaining bandwidth of the local aggregation group member link and a preset threshold, then the forwarding path of the L3VPN packet to be forwarded is determined to be the local aggregation group member link; if the forwarding rate of the L3VPN packet to be forwarded is not less than the difference between the available remaining bandwidth of the local aggregation group member link and a preset threshold, then the forwarding path of the L3VPN packet to be forwarded is determined to be the Peer-Link link.

[0111] It should be understood that in MLAG device networking, when the historical forwarding path corresponding to a certain data flow type is a Peer-Link link, the subsequent path selection needs to be dynamically adjusted based on the resource status of the aggregated group member links of the peer MLAG device and the resource status of the local aggregated group member links.

[0112] During the above steps, if it is determined that the historical forwarding path of the L3VPN packet to be forwarded is a Peer-Link link, and the available remaining bandwidth of the aggregation group member link of the current peer MLAG device is lower than a preset threshold, it indicates that the peer MLAG device should not continue to carry this traffic. At this time, the switchback evaluation mechanism is initiated to determine whether the data stream can be switched to the local aggregation group member link.

[0113] Specifically, the forwarding rate of the L3VPN packet to be forwarded is first obtained and compared with the available remaining bandwidth of the local aggregation group member links and a preset threshold. If the forwarding rate of the L3VPN packet to be forwarded is less than the difference between the available remaining bandwidth of the local aggregation group member links and the preset threshold, it indicates that the local link has sufficient safety margin to accept the traffic and has reserved the necessary bandwidth buffer to cope with sudden loads. Under this condition, the forwarding path of the packet is determined to be the local aggregation group member link, that is, the packet is directly sent to other network devices through the aggregation group member link of this MLAG device.

[0114] Conversely, if the forwarding rate of the L3VPN packet to be forwarded is not less than the difference between the available remaining bandwidth of the local aggregation group member links and the preset threshold, it indicates that even if the local link still has idle bandwidth, its remaining capacity is insufficient to securely carry the data stream while ensuring service quality. To prevent local link overload, the original forwarding path needs to be maintained, and the forwarding path of the packet is determined to be the Peer-Link link with the peer MLAG device, and the forwarding continues to be completed by the peer MLAG device.

[0115] The core concept of this embodiment lies in constructing a bidirectional dynamic load balancing mechanism by introducing "available remaining bandwidth minus a preset threshold" as a security admission condition for path switching. This mechanism not only supports migrating traffic to the peer when the local link is congested, but also supports switching traffic back to the local link when the peer link is under excessive pressure, thus realizing mutual backup and collaboration between the two MLAG devices.

[0116] To perform the corresponding steps in the above embodiments and various possible methods, an implementation of a cross-device link aggregation communication device is given below. Further, please refer to... Figure 9 , Figure 9 This is a functional block diagram of a cross-device link aggregation communication device provided in this application embodiment. It should be noted that the basic principle and technical effects of the cross-device link aggregation communication device provided in this embodiment are the same as those in the above embodiments. For the sake of brevity, any parts not mentioned in this embodiment can be referred to the corresponding content in the above embodiments. The cross-device link aggregation communication device includes: an acquisition module and a forwarding module.

[0117] The acquisition module is used to acquire L3VPN packets to be forwarded.

[0118] Understandably, this acquisition module can be used to perform the above step S20.

[0119] The forwarding module is used to send the L3VPN message to be forwarded to other corresponding network devices through the local aggregation group member link of the MLAG device when the L3VPN message to be forwarded is a protocol message.

[0120] Understandably, this forwarding module can be used to perform the above step S21.

[0121] The forwarding module is also used to determine the forwarding path corresponding to the L3VPN message to be forwarded when the L3VPN message to be forwarded is a data message, based on the receiving path of the L3VPN message to be forwarded, the transmission parameters corresponding to the data stream type to which it belongs, and the available remaining bandwidth of the aggregation group member links corresponding to the two MLAG devices, and forward the L3VPN message to be forwarded through the forwarding path.

[0122] Understandably, this forwarding module can be used to perform the above step S22.

[0123] Optionally, the forwarding module is further configured to: if the L3VPN message to be forwarded is sent to the local MLAG device by the peer MLAG device via a Peer-Link link, determine the forwarding path corresponding to the L3VPN message to be forwarded as the local aggregation group member link; if the L3VPN message to be forwarded is not sent to the local MLAG device by the peer MLAG device via a Peer-Link link, determine the forwarding path corresponding to the L3VPN message to be forwarded based on the transmission parameters corresponding to the data flow type of the L3VPN message to be forwarded and the available remaining bandwidth of the aggregation group member links corresponding to the two MLAG devices.

[0124] Optionally, the forwarding module is further configured to: if the historical forwarding path of the L3VPN packet to be forwarded is a local aggregation group member link, then, if the available remaining bandwidth of the local aggregation group member link is greater than a preset threshold, determine the forwarding path of the L3VPN packet to be forwarded as a local aggregation group member link; if the available remaining bandwidth of the local aggregation group member link is not greater than the preset threshold, determine the forwarding path of the L3VPN packet to be forwarded based on the forwarding rate of the L3VPN packet to be forwarded, the available remaining bandwidth of the aggregation group member link corresponding to the peer MLAG device, and the preset threshold; if the historical forwarding path of the L3VPN packet to be forwarded is a Peer-Link link, then, if the available remaining bandwidth of the aggregation group member link corresponding to the peer MLAG device is greater than a preset threshold, determine the forwarding path of the L3VPN packet to be forwarded as a Peer-Link link; if the available remaining bandwidth of the aggregation group member link corresponding to the peer MLAG device is not greater than the preset threshold, determine the forwarding path of the L3VPN packet to be forwarded based on the forwarding rate of the L3VPN packet to be forwarded, the available remaining bandwidth of the local aggregation group member link, and the preset threshold.

[0125] Optionally, the forwarding module is further configured to determine that the forwarding path of the L3VPN packet to be forwarded is a Peer-Link link if the forwarding rate of the L3VPN packet to be forwarded is less than the difference between the available remaining bandwidth of the aggregation group member link corresponding to the peer MLAG device and a preset threshold; and to determine that the forwarding path of the L3VPN packet to be forwarded is a local aggregation group member link if the forwarding rate of the L3VPN packet to be forwarded is not less than the difference between the available remaining bandwidth of the aggregation group member link corresponding to the peer MLAG device and a preset threshold.

[0126] Optionally, the forwarding module is further configured to determine that the forwarding path of the L3VPN packet to be forwarded is the local aggregation group member link if the forwarding rate of the L3VPN packet to be forwarded is less than the difference between the available remaining bandwidth of the local aggregation group member link and a preset threshold; and to determine that the forwarding path of the L3VPN packet to be forwarded is the Peer-Link link if the forwarding rate of the L3VPN packet to be forwarded is not less than the difference between the available remaining bandwidth of the local aggregation group member link and the preset threshold.

[0127] Optionally, the forwarding module is also used to receive L3VPN packets to be processed sent by other network devices; if a target L3VPN label matching the L3VPN label of the L3VPN packet to be processed is configured locally, then the L3VPN packet to be processed is processed.

[0128] Optionally, the cross-device link aggregation communication device also includes a fault handling module.

[0129] This fault handling module is used to, in the event of a local aggregation group member link failure on the MLAG device, set the usage status of the local aggregation group member link and the usage status of the corresponding MLAG logical interface to an unavailable state, and send aggregation group member link failure information to the peer MLAG device so that the peer MLAG device sets the usage status of the Peer-Link link to an unavailable state; when the local aggregation group member link on the MLAG device recovers, it sets the usage status of the local aggregation group member link and the usage status of the corresponding MLAG logical interface to an available state, and sends aggregation group member link recovery information to the peer MLAG device so that the peer MLAG device sets the usage status of the Peer-Link link to an available state; in the event of a Peer-Link link failure, it sets the usage status of the Peer-Link link to an unavailable state locally, and in the event of a Peer-Link link recovery, it sets the usage status of the Peer-Link link to an available state locally on the MLAG device.

[0130] Optionally, the forwarding module is further configured to determine the forwarding path of the L3VPN message to be forwarded based on the receiving path of the L3VPN message to be forwarded, the transmission parameters corresponding to the data stream type, and the available remaining bandwidth of the aggregation group member links of the two MLAG devices, when the usage status of the aggregation group member links of the two MLAG devices and the usage status of the MLAG logical interfaces corresponding to the aggregation group member links are both available, and the usage status of the Peer-Link link is available.

[0131] Optionally, the above modules can be stored in the form of software or firmware. Figure 7 The memory shown is either stored in or embedded in the operating system (OS) of the MLAG device, and can be used by... Figure 7 The processor executes the commands. Meanwhile, the data and program code required to execute these modules can be stored in memory.

[0132] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, can implement the cross-device link aggregation communication method provided in this application.

[0133] In the several embodiments provided in this application, 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 application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains 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.

[0134] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0135] If a function is implemented as a software module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, 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 computer device (which may be a personal computer, a server, or an MLAG device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0136] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A cross-device link aggregation communication method, characterized in that, The method, applied to any one of two MLAG devices in a cross-device link aggregation group MLAG network, wherein each MLAG device is communicatively connected to at least one other network device via an aggregation group member link, comprises: Retrieve L3VPN packets to be forwarded; When the L3VPN message to be forwarded is a protocol message, the L3VPN message to be forwarded is sent to the corresponding other network devices through the local aggregation group member link; When the L3VPN message to be forwarded is a data message, the forwarding path corresponding to the L3VPN message to be forwarded is determined according to the receiving path of the L3VPN message to be forwarded, the transmission parameters corresponding to the data stream type to which it belongs, and the available remaining bandwidth of the aggregation group member links corresponding to the two MLAG devices, and the L3VPN message to be forwarded is forwarded through the forwarding path.

2. The method according to claim 1, characterized in that, The step of determining the forwarding path corresponding to the L3VPN packet to be forwarded based on the receiving path of the L3VPN packet to be forwarded, the transmission parameters corresponding to the data stream type, and the available remaining bandwidth of the aggregation group member links corresponding to the two MLAG devices includes: If the L3VPN message to be forwarded is sent from the peer MLAG device to this MLAG device via the Peer-Link link, then the forwarding path corresponding to the L3VPN message to be forwarded is determined to be the local aggregation group member link; If the L3VPN message to be forwarded is not sent from the peer MLAG device to this MLAG device via the Peer-Link link, then the forwarding path corresponding to the L3VPN message to be forwarded is determined according to the transmission parameters corresponding to the data flow type of the L3VPN message to be forwarded and the available remaining bandwidth of the aggregation group member links corresponding to the two MLAG devices.

3. The method according to claim 2, characterized in that, The transmission parameters include historical forwarding paths and forwarding rates; determining the forwarding path corresponding to the L3VPN packet to be forwarded based on the transmission parameters corresponding to the data flow type of the L3VPN packet to be forwarded and the available remaining bandwidth of the aggregation group member links corresponding to the two MLAG devices includes: If the historical forwarding path of the L3VPN packet to be forwarded is the local aggregation group member link, then if the available remaining bandwidth of the local aggregation group member link is greater than a preset threshold, the forwarding path of the L3VPN packet to be forwarded is determined to be the local aggregation group member link. If the available remaining bandwidth of the local aggregation group member link is not greater than the preset threshold, the forwarding path of the L3VPN packet to be forwarded is determined according to the forwarding rate of the L3VPN packet to be forwarded, the available remaining bandwidth of the aggregation group member link corresponding to the peer MLAG device, and the preset threshold. If the historical forwarding path of the L3VPN packet to be forwarded is the Peer-Link link, then if the available remaining bandwidth of the aggregation group member link corresponding to the peer MLAG device is greater than the preset threshold, the forwarding path of the L3VPN packet to be forwarded is determined to be the Peer-Link link. If the available remaining bandwidth of the aggregation group member link corresponding to the peer MLAG device is not greater than the preset threshold, the forwarding path of the L3VPN packet to be forwarded is determined according to the forwarding rate of the L3VPN packet to be forwarded, the available remaining bandwidth of the local aggregation group member link, and the preset threshold.

4. The method according to claim 3, characterized in that, The step of determining the forwarding path of the L3VPN packet to be forwarded based on the forwarding rate of the L3VPN packet to be forwarded, the available remaining bandwidth of the aggregation group member links corresponding to the peer MLAG device, and the preset threshold includes: If the forwarding rate of the L3VPN packet to be forwarded is less than the difference between the available remaining bandwidth of the aggregation group member link corresponding to the peer MLAG device and the preset threshold, then the forwarding path of the L3VPN packet to be forwarded is determined to be the Peer-Link link. If the forwarding rate of the L3VPN packet to be forwarded is not less than the difference between the available remaining bandwidth of the aggregation group member link corresponding to the peer MLAG device and the preset threshold, then the forwarding path of the L3VPN packet to be forwarded is determined to be the local aggregation group member link. The step of determining the forwarding path of the L3VPN packet to be forwarded based on the forwarding rate of the L3VPN packet to be forwarded, the available remaining bandwidth of the local aggregation group member links, and the preset threshold includes: If the forwarding rate of the L3VPN packet to be forwarded is less than the difference between the available remaining bandwidth of the local aggregation group member link and the preset threshold, then the forwarding path of the L3VPN packet to be forwarded is determined to be the local aggregation group member link. If the forwarding rate of the L3VPN packet to be forwarded is not less than the difference between the available remaining bandwidth of the local aggregation group member link and the preset threshold, then the forwarding path of the L3VPN packet to be forwarded is determined to be the Peer-Link link.

5. The method according to claim 1, characterized in that, The two MLAG devices are configured with the same L3VPN label for the same L3VPN service, and the method further includes: Receive pending L3VPN messages sent by the other network devices; If a target L3VPN label matching the L3VPN label of the L3VPN packet to be processed is configured locally, then the L3VPN packet to be processed is processed.

6. The method according to claim 1, characterized in that, The method further includes: In the event of a local aggregation group member link failure, the usage status of the local aggregation group member link and the usage status of the MLAG logical interface corresponding to the local aggregation group member link are set to an unavailable state, and aggregation group member link failure information is sent to the peer MLAG device so that the peer MLAG device sets the usage status of the Peer-Link link to an unavailable state. When the local aggregation group member link is restored to normal, the usage status of the local aggregation group member link and the usage status of the MLAG logical interface corresponding to the local aggregation group member link are set to the available status, and aggregation group member link restoration information is sent to the peer MLAG device so that the peer MLAG device sets the usage status of the Peer-Link link to the available status. In the event of a Peer-Link failure, the Peer-Link's usage status is set to unavailable locally, and in the event of a Peer-Link recovery, the Peer-Link's usage status is set to available locally.

7. The method according to claim 6, characterized in that, The step of determining the forwarding path corresponding to the L3VPN message to be forwarded based on the receiving path of the L3VPN message to be forwarded, the transmission parameters corresponding to the data stream type, and the available remaining bandwidth of the two MLAG devices includes: When the usage status of the aggregation group member links of the two MLAG devices and the usage status of the MLAG logical interfaces corresponding to the aggregation group member links are both available, and the usage status of the Peer-Link link is available, the forwarding path corresponding to the L3VPN message to be forwarded is determined according to the receiving path of the L3VPN message to be forwarded, the transmission parameters corresponding to the data stream type, and the available remaining bandwidth of the two MLAG devices.

8. A cross-device link aggregation communication device, characterized in that, The apparatus comprises: any one of two MLAG devices configured in a cross-device link aggregation group MLAG network, wherein each MLAG device is communicatively connected to at least one other network device via an aggregation group member link; the apparatus includes: The acquisition module is used to acquire L3VPN packets to be forwarded. The forwarding module is used to send the L3VPN message to be forwarded to other corresponding network devices through the local aggregation group member link of the MLAG device when the L3VPN message to be forwarded is a protocol message. The forwarding module is further configured to, when the L3VPN message to be forwarded is a data message, determine the forwarding path corresponding to the L3VPN message to be forwarded based on the receiving path of the L3VPN message to be forwarded, the transmission parameters corresponding to the data stream type to which it belongs, and the available remaining bandwidth of the aggregation group member links corresponding to the two MLAG devices, and forward the L3VPN message to be forwarded through the forwarding path.

9. An MLAG device, characterized in that, The method includes a processor and a memory, the memory storing a computer program executable by the processor, the processor executing the computer program to implement the method according to any one of claims 1-7.

10. A system using cross-device link aggregation group (MLAG) networking, characterized in that, Includes the MLAG equipment described in claim 9.

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

Images