Method, device and system for establishing a disaster recovery channel

Abstract

The application discloses a method, device and system for establishing a disaster recovery channel, wherein the method comprises the following steps: in response to a processing condition being met, a control device sends a first message to a first device, wherein the first message comprises a first source IP address and a first destination IP address; after the first device receives the first message, the first device establishes a first disaster recovery channel with a second device according to the first source IP address and the first destination IP address, the first device and the second device are backups of each other, and the processing condition is related to a second disaster recovery channel state between the first device and the second device. The method can establish a disaster recovery channel between the first device and the second device, and can also successfully establish a disaster recovery channel when the disaster recovery channel is attacked, thereby improving the security of the disaster recovery channel and ensuring that the first device and the second device can effectively perform data backup.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method, device and system for establishing a disaster recovery channel. Background Technology

[0002] As enterprises continue to expand, data backup on a single device can no longer meet the needs of critical business operations, and backup data may be destroyed due to various factors (such as earthquakes, fires, etc.). Therefore, in order to meet the network reliability requirements of critical businesses, off-site disaster recovery solutions are usually adopted to implement dual-device data backup and business backup: critical business operations are backed up on a backup device deployed off-site, so that when the local device (primary device) fails, the off-site backup device (standby device) can take over the local business, thereby ensuring the continuity of these services.

[0003] Currently, in off-site disaster recovery solutions, when the primary and / or backup devices are attacked, the established disaster recovery channel between them may be disconnected or fail to be established, thus preventing data backup between the primary and backup devices. Therefore, improving the security of the disaster recovery channel between the primary and backup devices remains an unresolved issue. Summary of the Invention

[0004] This application discloses a method, device, and system for establishing a disaster recovery channel, which can improve the security of the disaster recovery channel between the primary device and the backup device, and enable data backup between the primary device and the backup device to proceed smoothly.

[0005] Firstly, this application provides a method for establishing a disaster recovery channel, which includes the following steps:

[0006] In response to the fulfillment of processing conditions, the control device sends a first message to the first device. The first message includes a first source Internet Protocol (IP) address and a first destination IP address. The first message is used to enable the first device to establish a first disaster recovery channel with the second device based on the first source IP address and the first destination IP address. The processing conditions are related to the status of the second disaster recovery channel between the first device and the second device. The first device and the second device are backups for each other.

[0007] In one possible implementation, the above-mentioned processing conditions include: the control device receiving a second message sent by the first device and / or the second device, the second message being used to indicate an anomaly in the second disaster recovery channel.

[0008] In one possible implementation, the aforementioned conditions include: the control device detects an anomaly in the existing second disaster recovery channel between the first device and the second device.

[0009] By implementing the above method, the control device can determine whether the processing conditions are met based on receiving a second message from the first device, or by detecting an anomaly in the existing second disaster recovery channel between the first and second devices. Therefore, when the second disaster recovery channel is abnormal, the control device can promptly determine the anomaly from multiple perspectives, enabling it to quickly send a first message to the first device. This allows the first device to promptly establish a first disaster recovery channel with the second device, thereby reducing data synchronization losses caused by the anomaly of the second disaster recovery channel.

[0010] In one possible implementation, the anomaly of the second disaster recovery channel includes: failure to establish the second disaster recovery channel, disconnection of the second disaster recovery channel, or abnormal performance of the second disaster recovery channel. Understandably, if the second disaster recovery channel fails to establish successfully, the anomaly is considered to be the failure to establish the second disaster recovery channel; if the second disaster recovery channel is successfully established, the anomaly could be the disconnection of the second disaster recovery channel or abnormal performance of the second disaster recovery channel (e.g., the bandwidth of the second disaster recovery channel exceeds the preset bandwidth). When any of these situations occur, the control device will send a first message to the first device, thereby enabling the first device to establish the first disaster recovery channel.

[0011] In one possible implementation, before the control device sends the first message to the first device, the method further includes: the control device obtaining channel parameters, the channel parameters including a second source IP address and a second destination IP address, the second source IP address and the second destination IP address being parameters of the second disaster recovery channel; the control device generating a first source IP address and a first destination IP address based on the second source IP address and the second destination IP address.

[0012] By implementing the above method, the control device generates a first IP address, a first source IP address, and a first destination IP address based on the second source IP address and the second destination IP address included in the channel parameters. This ensures that the channel parameters of the first disaster recovery channel are different from those of the second disaster recovery channel, preventing packets attacking the second disaster recovery channel from attacking the first disaster recovery channel. This improves the security of the first disaster recovery channel and ensures that data backup between the first and second devices can continue.

[0013] In one possible implementation, the channel parameters also include a protocol type, which indicates that the channel parameters are for a disaster recovery channel. Understandably, the control device determines that the channel experiencing the anomaly is the second disaster recovery channel, rather than the ordinary channel (which is not used for data backup), based on the protocol type in the channel parameters.

[0014] In one possible implementation, the above method is applied to a communication system that includes a control plane and a user plane (CU) that are disaggregated, wherein the first device includes a first control plane (CP) device and the second device includes a second CP device.

[0015] When the control device determines that the processing conditions are met, it determines that the second disaster recovery channel is abnormal. Then, the control device sends a first message to the first device, enabling the first device to establish a first disaster recovery channel with the second device and continue to perform data backup between the first device and the second device, thereby reducing the loss caused by the abnormality of the second disaster recovery channel.

[0016] Secondly, this application provides a method for establishing a disaster recovery channel, which includes the following steps:

[0017] The first device receives a first message sent by the control device. The first message includes a first source IP address and a first destination IP address. The first device establishes a first disaster recovery channel with the second device based on the first source IP address and the first destination IP address. The first disaster recovery channel is a channel between the first device and the second device used to achieve data backup. The first device and the second device serve as backups for each other.

[0018] In one possible implementation, before the first device receives the first message sent by the control device, the method further includes: in response to meeting processing conditions, the first device sends a second message to the control device, wherein the second message indicates an anomaly in the second disaster recovery channel, thereby triggering the control device to send the first message to the first device; the processing conditions include one or more of the following: an anomaly in the second disaster recovery channel, or the first device's packet loss rate exceeding a preset threshold; the anomaly in the second disaster recovery channel includes: failure to establish the second disaster recovery channel, disconnection of the second disaster recovery channel, or abnormal performance of the second disaster recovery channel. It is understood that since the second disaster recovery channel is established between the first device and the second device, the first device can detect an anomaly in the second disaster recovery channel. Moreover, when the second disaster recovery channel becomes abnormal due to an attack on the first device, the packet loss rate of the first device will increase; therefore, the first device can also determine that the second disaster recovery channel is abnormal based on the first device's packet loss rate exceeding a preset threshold.

[0019] In one possible implementation, the first device establishes a first disaster recovery channel with the second device based on a first source IP address and a first destination IP address, including: the first device generating a first transmission control protocol (TCP) connection message based on the first source IP address and the first destination IP address, and sending the first TCP connection message to the second device in a preset manner, thereby establishing the first disaster recovery channel, wherein the preset manner includes one or more of the following: preset bandwidth, preset rate; or the first device receives a second TCP connection message sent by the second device, the second TCP connection message including a third source IP address and a third destination IP address, and the first device establishes a TCP connection with the second device based on the fact that the third source IP address is the same as the first source IP address and the third destination IP address is the same as the first destination IP address, thereby establishing the first disaster recovery channel.

[0020] Implementing the above method, when the first device is a client, it generates a first TCP connection packet based on the first source IP address and the first destination IP address, and sends the first TCP connection packet to the second device in a preset manner, thereby establishing a first disaster recovery connection with the second device. When the second device is a client, the first device receives the second TCP connection packet sent by the second device and establishes a first disaster recovery channel with the second device based on the second TCP connection packet. When the first device is a client, because the preset method is high bandwidth and high speed, the time for the second device to receive the first TCP connection packet can be shortened, thereby shortening the establishment time of the first disaster recovery channel and further reducing losses caused by anomalies in the second disaster recovery channel.

[0021] In one possible implementation, the first device includes a target whitelist. Before the first device establishes a first disaster recovery channel with the second device based on the first source IP address and the first destination IP address, the method further includes: the first device updating a second source IP address included in the target whitelist to the first source IP address, and updating a second destination IP address included in the target whitelist to the first destination IP address, with the second source IP address and the second destination IP address corresponding to each other. After updating the target whitelist, the first device determines whether a first TCP connection packet matches the target whitelist. If the first TCP connection packet matches the target whitelist, the first device sends the first TCP connection packet to the second device in a preset manner. If the first TCP connection packet does not match the target whitelist, the first device discards the first TCP connection packet. In this way, the first device can discard packets that attack the first disaster recovery channel, thereby improving the security of the first disaster recovery channel.

[0022] In one possible implementation, the target whitelist is the disaster recovery channel whitelist. When the target whitelist is the disaster recovery channel whitelist, the number of packets that can match the target whitelist will be greatly reduced. This not only shortens the time for the second device to receive the first TCP connection packet and the establishment time of the first disaster recovery channel, but also improves the security of the first disaster recovery channel and further reduces the losses caused by the anomaly of the second disaster recovery channel.

[0023] In one possible implementation, the above method is applied to a communication system including CU separation, where the first device includes a first CP device and the second device includes a second CP device.

[0024] Thirdly, this application provides a control device, which includes a transmitting unit.

[0025] The sending unit is used to send a first message to the first device in response to the fulfillment of the processing conditions. The first message includes a first source Internet Protocol (IP) address and a first destination IP address. The first message is used to enable the first device to establish a first disaster recovery channel with the second device based on the first source IP address and the first destination IP address. The processing conditions are related to the status of the second disaster recovery channel between the first device and the second device. The first device and the second device are backups for each other.

[0026] In one possible implementation, the control device further includes a receiving unit, and the processing conditions include: the receiving unit receives a second message sent by the first device, the second message being used to indicate an anomaly in the second disaster recovery channel.

[0027] In one possible implementation, the control device further includes a processing unit for determining whether processing conditions are met, including: the processing unit for determining that the existing second disaster recovery channel between the first device and the second device is abnormal.

[0028] In one possible implementation, the anomalies of the second disaster recovery channel include: failure to establish the second disaster recovery channel, disconnection of the second disaster recovery channel, or abnormal performance of the second disaster recovery channel.

[0029] In one possible implementation, before the sending unit sends the first message to the first device, the processing unit is further configured to obtain channel parameters, including a second source IP address and a second destination IP address, which are parameters of the second disaster recovery channel; the processing unit is further configured to generate a first source IP address and a first destination IP address based on the second source IP address and the second destination IP address.

[0030] In one possible implementation, the channel parameters also include a protocol type, which indicates that the channel parameters are for a disaster recovery channel.

[0031] In one possible implementation, the control device is applied to a communication system including CU separation, wherein the first device includes a first CP device and the second device includes a second CP device.

[0032] Fourthly, this application provides a first device, which includes a receiving unit and a processing unit.

[0033] The receiving unit is used to receive a first message sent by the control device. The first message includes a first source IP address and a first destination IP address.

[0034] The processing unit is used to establish a first disaster recovery channel with the second device based on the first source IP address and the first destination IP address. The first disaster recovery channel is a channel between the first device and the second device for data backup. The first device and the second device are backups for each other.

[0035] In one possible implementation, the first device further includes a sending unit. Before the receiving unit receives the first message sent by the control device, the sending unit is further configured to send a second message to the control device in response to the fulfillment of processing conditions. The second message is used to indicate that the second disaster recovery channel is abnormal, thereby triggering the control device to send the first message to the first device. The processing conditions include one or more of the following conditions: the second disaster recovery channel is abnormal, or the packet loss rate of the first device exceeds a preset threshold. The second disaster recovery channel abnormality includes: failure to establish the second disaster recovery channel, disconnection of the second disaster recovery channel, or abnormal performance of the second disaster recovery channel.

[0036] In one possible implementation, the processing unit is specifically used to generate a first Transmission Control Protocol (TCP) connection message based on a first source IP address and a first destination IP address. The sending unit is also used to send the first TCP connection message to the second device in a preset manner, thereby establishing a first disaster recovery channel. The preset manner includes one or more of the following: preset bandwidth, preset rate. Alternatively, the receiving unit is also used to receive a second TCP connection message sent by the second device. The second TCP connection message includes a third source IP address and a third destination IP address. The processing unit is specifically used to establish a TCP connection with the second device based on the fact that the third source IP address is the same as the first source IP address and the third destination IP address is the same as the first destination IP address, thereby establishing a first disaster recovery channel.

[0037] In one possible implementation, before the processing unit establishes a first disaster recovery channel with the second device based on the first source IP address and the first destination IP address, the processing unit is further configured to update the second source IP address included in the target whitelist to the first source IP address, and update the second destination IP address included in the target whitelist to the first destination IP address, with the second source IP address corresponding to the second destination IP address.

[0038] In one possible implementation, the target whitelist is the disaster recovery channel whitelist.

[0039] In one possible implementation, the first device is applied to a communication system including CU separation, the first device including a first CP device, and the second device including a second CP device.

[0040] Fifthly, this application provides a control device including a processor and a memory, wherein the processor executes code in the memory to implement the method as described in the first aspect or any alternative manner of the first aspect.

[0041] In a sixth aspect, this application provides a first device including a processor and a memory, the processor executing code in the memory to implement the method as described in the second aspect or any alternative method of the second aspect.

[0042] In a seventh aspect, this application provides a computer-readable storage medium storing computer instructions for implementing the method as described in the first aspect or any alternative method of the first aspect.

[0043] Eighthly, this application provides a computer-readable storage medium storing computer instructions for implementing the method as described in the second aspect or any alternative method of the second aspect.

[0044] Ninthly, this application provides a communication system including a control device, a first device, and a second device. The control device is used to perform the method described as in the first aspect or any optional mode of the first aspect, and the first device is used to perform the method described as in the second aspect or any optional mode of the second aspect. Attached Figure Description

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

[0046] Figure 1 This is a schematic diagram of the structure of a broadband network gateway system with CU separation provided in this application;

[0047] Figure 2 This is a schematic diagram of an off-site disaster recovery system in the CU separation mode provided in this application;

[0048] Figure 3 This is a schematic diagram of a data backup process provided in this application;

[0049] Figure 4 This is a flowchart illustrating a method for establishing a disaster recovery channel provided in this application;

[0050] Figure 5 This is a flowchart illustrating a method for controlling the execution of a device provided in this application;

[0051] Figure 6 This is a schematic diagram illustrating various scenarios that could lead to anomalies in the second disaster recovery channel, as provided in this application.

[0052] Figure 7 This is a schematic diagram illustrating the process of establishing a disaster recovery channel in one possible application scenario provided in this application;

[0053] Figure 8 This is a schematic diagram illustrating the process of establishing a disaster recovery channel in one possible application scenario provided in this application;

[0054] Figure 9 This is a schematic diagram illustrating the process of establishing a disaster recovery channel in one possible application scenario provided in this application;

[0055] Figure 10 This is a schematic diagram of the structure of a control device provided in this application;

[0056] Figure 11 This is a schematic diagram of the structure of a disaster recovery backup device provided in this application;

[0057] Figure 12 This is a schematic diagram of the structure of a network device provided in this application;

[0058] Figure 13 This is a schematic diagram of the structure of a communication network provided in this application. Detailed Implementation

[0059] The technical solutions in the embodiments of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this invention.

[0060] The terminology used in the implementation section of this application is only for explaining specific embodiments of this application and is not intended to limit this application. The terms "first," "second," "third," etc., in this application are used to distinguish identical or similar items with substantially the same function. It should be understood that there is no logical or temporal dependency between "first," "second," and "third," nor is there any limitation on the quantity or execution order.

[0061] To facilitate understanding of the implementation methods of this application, the relevant concepts involved in the embodiments of this application will first be explained.

[0062] (1) CU separation

[0063] With the development of software-defined networking (SDN) and network functions virtualization (NFV) technologies, data communication networks are evolving from a traditional network-centric architecture to a data center-centric architecture. Traditional network equipment is also evolving from specialized to general-purpose. In light of this, CU (Connector-Controller) separation technology has emerged, becoming the next leap in the evolution of many communication systems and gaining recognition from mainstream manufacturers, operators, and standards organizations.

[0064] CU separation refers to a network architecture where the CP (Content Provider) and UP (Uploader) are decoupled. In a CU separation architecture, the CP and UP reside on different hardware devices, or they reside on the same hardware device but are functionally separate. When the CP and UP reside on different hardware devices, the CP and UP devices are two separate and distinct devices. Optionally, the CP and UP devices are distributed and deployed in different locations; for example, the CP device may reside in a cloud data center, while the UP device may be deployed in appropriate locations within the network as needed. When the CP and UP reside on the same hardware device and are functionally separate, the physical entity of the CP device and the physical entity of the UP device are the same device; for example, the CP device and UP device may run on the same host, the same server, or the same terminal.

[0065] In one example, both the CP (Content Provider) and UP (Uploader) devices are implemented using virtualization technology. The CP device can be called a virtual CP (vCP), and the UP device can be called a virtual UP (vUP). For example, the CP device is a virtual machine, and the UP device is a virtual router or virtual switch. In another example, both the CP and UP devices are implemented based on general-purpose physical servers combined with NFV (Network Function Virtualization) technology. The CP and UP devices are two different virtualized network functions (VNFs). For example, both the CP and UP devices are network elements virtualized through x86 servers. In yet another example, the CP device is implemented using virtualization technology, while the UP device is implemented using traditional network equipment. The UP device can be called a physical UP (pUP).

[0066] This application does not limit the quantitative relationship between CP devices and UP devices in the communication system. In one example, the relationship between CP devices and UP devices is one-to-many, that is, one CP device controls multiple UP devices. In another example, the relationship between CP devices and UP devices is one-to-one, that is, one CP device controls one UP device.

[0067] This application does not limit the number of UP devices in the communication system. Optionally, a CU-separated communication system includes multiple UP devices. Optionally, the multiple UP devices in a CU-separated communication system are distributed in different locations. Optionally, the multiple UP devices in a CU-separated communication system collaboratively share forwarding tasks based on a distributed architecture.

[0068] It's worth noting that "CU separation" can have different names. For example, different standards, different versions of the same standard, different vendors, and different application scenarios may use different names for "CU separation." For instance, the term "CU separation" can sometimes also be referred to as "control and forwarding separation," "forwarding and control separation," "control plane and user plane separation," or "control and user separation," etc.

[0069] It is worth noting that "CP" can have different names. For example, different standards, different versions of the same standard, different manufacturers, and different application scenarios may use different names for "CP". For example, the term "CP" can sometimes also be called "CP function (CPF)" or "CP surface". In this article, "CP", "CPF", and "CP surface" are used interchangeably. The term "CP device" refers to any device that implements the CP function.

[0070] It is worth noting that "UP" can have different names. For example, different standards, different versions of the same standard, different manufacturers, and different application scenarios may use different names for "UP". For example, the term "UP" can sometimes also be called "UP function (UPF)" or "UP surface". In this article, "UP", "UPF", and "UP surface" are used interchangeably. The term "UP device" refers to any device that implements the UP function.

[0071] (2) Broadband network gateway (BNG)

[0072] A Broadband Network Node (BNG) is a telecommunications network element used by operators for broadband access, responsible for connecting user equipment to the broadband network. The BNG is primarily responsible for access authentication and IP address allocation.

[0073] (3) BNG system with CU separation

[0074] With the emergence of various internet services, the requirements for the number of user sessions supported by BNG are constantly increasing, as are the user access bandwidth requirements. In particular, the requirements for the BNG system to provide service openness and programmability are becoming increasingly demanding. In view of these needs, SDN or NFV-based architectures decouple the control and forwarding of traditional BNG devices, as well as the software and hardware, thereby forming a CU-separated BNG system.

[0075] like Figure 1 As shown, the CU-separated BNG system extracts and centralizes the user management functions from multiple BNG devices, forming a CP device. The routing and forwarding functions are retained on the BNG devices, forming UP devices. Therefore, the CU-separated BNG system can maintain the original functionality of the BNG while possessing the advantages of the CU-separated architecture. For example, a CU-separated BNG system can have multiple UP devices, with the CP device scheduling the forwarding tasks of these UP devices and allocating resources to them. Therefore, compared to a single-device implementation of the BNG system, the device utilization and reliability of the CU-separated BNG architecture are significantly improved.

[0076] It is worth noting that the "CU-separated BNG system" in the embodiments of this application can have different names. For example, different standards, different versions of the same standard, different manufacturers, and different application scenarios may use different names for the "CU-separated BNG system". For example, the term "CU-separated BNG system" can sometimes also be called "disaggregated BNG (DBNG) system", and correspondingly, the CP device in the CU-separated BNG system can be called DBNG-CP, and the UP device in the CU-separated BNG system can be called DBNG-UP. As another example, the term "CU-separated BNG system" can sometimes also be called "virtual broadband network gateway (vBNG) control plane and user plane disaggregated system (CU system)", i.e., "vBNG CU system", and correspondingly, the CP device in the CU-separated BNG system can be called vBNG-CP, and the UP device in the CU-separated BNG system can be called vBNG-UP. For example, the term "CU-separated BNG system" can sometimes also be called a "virtual broadband remote access server (vBRAS) CU system," or "vBRAS CU system." Correspondingly, the CP device in a CU-separated BNG system can be called vBRAS-CP, and the UP device in a CU-separated BNG system can be called vBRAS-UP. In this article, "DBNG," "vBNG CU system," and "vBRAS CU system" are used interchangeably.

[0077] (4) Whitelist

[0078] The concept of a whitelist is the opposite of a "blacklist." Users listed on a blacklist (e.g., IP addresses, IP packets, emails, viruses, etc.) are not allowed to access the network. Conversely, users listed on a whitelist (e.g., IP addresses, IP packets, emails, etc.) can access the network (with high bandwidth and speed), thus greatly improving network security and speed.

[0079] Next, the applicable business scenarios for the embodiments of this application are described: off-site disaster recovery in CU separation mode, or any other scenario similar to off-site disaster recovery in CU separation mode. It should be understood that the network architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. Those skilled in the art will recognize that with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0080] In the CU separation mode, off-site disaster recovery refers to dual-device backup of CP devices between different data centers (DCs). The two CP devices belong to different DCs, and their primary / standby status is determined based on their configurations. This allows for rapid switching of user services to the standby CP device when the primary CP device or link fails, ensuring service continuity. To enable communication between the two CP devices, multiple disaster recovery channels need to be established: one heartbeat channel and multiple data backup channels. The heartbeat channel is used for configuration synchronization and primary / standby negotiation between the two CP devices; the data backup channels are used for user data backup, with each data backup channel corresponding to one UP device. Since the heartbeat and data backup channels between the two CP devices are used for synchronization between the primary and standby devices, if the disaster recovery channels between the two CP devices are compromised by a security attack, synchronization will be impossible. Therefore, the security of the disaster recovery channels between the two CP devices is crucial for off-site disaster recovery scenarios.

[0081] like Figure 2 As shown, Figure 2 This illustrates an off-site disaster recovery system in the CU separation mode. Figure 2 vCP1 and vCP2 belong to different data centers (DCs). vCP1 is the primary data center (CP) device, and vCP2 is the backup CP device. Between vCP1 and vCP2, there are heartbeat channels, data backup channel 1, data backup channel 2, ..., data backup channel n. The following uses... Figure 2 Taking one disaster recovery channel as an example, the process of data backup between vCP1 and vCP2 is explained. The specific steps are as follows: Figure 3 As shown:

[0082] Step 11: Establish a disaster recovery channel between vCP1 and vCP2.

[0083] In practice, vCP1 and vCP2 establish a disaster recovery channel through a three-way handshake. Taking data backup channel 1 as an example, it can be established as follows: First, configure IP addresses and routing protocols on both vCP1 and vCP2 to ensure the routable reachability of the disaster recovery channel. The IP address of vCP1 is IP1, and the IP address of vCP2 is IP2. Next, since vCP1 is the primary device and vCP2 is the backup device when production site 110 is running normally, vCP2 sends a request to vCP1 to establish data backup channel 1. In one example, this request is a TCP synchronization (SYN) message. After receiving the request, vCP1 sends a response message to vCP2. In one example, this response message is a TCP acknowledge (ACK) message to confirm the request to establish data backup channel 1. After receiving the response message, vCP2 sends an acknowledgment message to vCP1, thus completing the establishment of data backup channel 1. Understandably, the establishment process of the heartbeat channel between vCP1 and vCP2, data backup channel 2, ..., data backup channel n is similar to the establishment process of data backup channel 1 mentioned above, and will not be elaborated here.

[0084] Step 12: vCP1 generates a disaster recovery channel whitelist.

[0085] In practice, vCP1 generates a disaster recovery channel whitelist based on the channel parameters corresponding to the established disaster recovery channels on vCP1. As shown in Table 1, Table 1 shows the channel parameters corresponding to the disaster recovery channels on vCP1. Taking data backup channel 1 as an example, the channel parameters corresponding to data backup channel 1 on vCP1 include the five-tuple information of data backup channel 1 on vCP1, namely the source IP address (IP1), destination IP address (IP2), source port (port 1), destination port (port 2), and protocol type (disaster recovery private protocol number) of data backup channel 1. As is understandable, if data backup channel 1 is a channel established between port 1 on vCP1 and port 2 on vCP2, then the source IP address corresponding to data backup channel 1 on vCP1 is the IP address of vCP1, i.e., IP1; the destination IP address corresponding to data backup channel 1 on vCP1 is the IP address of vCP2, i.e., IP2; the source port corresponding to data backup channel 1 on vCP1 is the port on vCP1, i.e., port 1; the destination port corresponding to data backup channel 1 on vCP1 is the port on vCP2, i.e., port 2; and the protocol type corresponding to data backup channel 1 on vCP1 is the protocol number used by the service messages transmitted in data backup channel 1, i.e., the disaster recovery private protocol number, which is any unassigned protocol number among the IP protocol numbers (e.g., 255).

[0086] Table 1. Channel parameters corresponding to the disaster recovery channel on vCP1

[0087]

[0088] Table 2. Channel parameters corresponding to the disaster recovery channel on vCP2

[0089]

[0090] Understandably, since the disaster recovery channel is established between vCP1 and vCP2, the channel parameters for the same disaster recovery channel are corresponding on vCP1 and vCP2. Table 2 shows the corresponding channel parameters for the disaster recovery channel on vCP2. Combining Tables 1 and 2, it is easy to see that the source IP address on vCP1 is the same as the destination IP address on vCP2, the destination IP address on vCP1 is the same as the source IP address on vCP2, the source port on vCP1 is the same as the destination port on vCP2, the destination port on vCP1 is the same as the source port on vCP2, and the protocol type on vCP1 is the same as the protocol type on vCP2.

[0091] In a specific embodiment, taking Table 3 as an example, Table 3 shows the disaster recovery channel whitelist generated by vCP1 based on the channel parameters of data backup channel 1 on vCP1. The disaster recovery channel whitelist in Table 3 includes the source IP address, destination IP address, source port, destination port, and protocol type. Combined with the channel parameters of data backup channel 1 on vCP1 shown in Table 2, it can be seen that the source IP address, destination IP address, source port, destination port, and protocol type in the disaster recovery channel whitelist shown in Table 3 correspond one-to-one with the source IP address, destination IP address, source port, destination port, and protocol type of data backup channel 1 on vCP1.

[0092] Table 3. Disaster Recovery Channel Whitelist

[0093]

[0094] Step 13: vCP1 determines whether the target packet matches the disaster recovery channel whitelist. When the target packet matches the disaster recovery channel whitelist, vCP1 sends the target packet to vCP2 in a preset manner.

[0095] The target message can be either a heartbeat message or a service message. When the disaster recovery channel is a heartbeat channel, the target message is a heartbeat message; when the disaster recovery channel is a data backup channel, the target message is a service message.

[0096] In its implementation, vCP1 determines whether the target packet matches the disaster recovery channel whitelist. When the service packet matches the disaster recovery channel whitelist, vCP1 sends the target packet to vCP2 through the specified channel. Matching the disaster recovery channel whitelist means that the source IP address, destination IP address, source port, destination port, and protocol number carried in the target packet correspond one-to-one with the source IP address, destination IP address, source port, destination port, and protocol type in the disaster recovery channel whitelist.

[0097] Optionally, the designated channel includes a manually configured central processing unit committed access rate (CPCAR) channel. A CPCAR channel can be understood as a data transmission method that enables high-speed and high-bandwidth data transmission, ensuring that vCP1 can synchronize user data to vCP2 in real time. For example, testing shows that when transmitting service packets using a CPCAR channel, the committed information rate (CIR) can reach 4000 kilobits per second (kbps), while without using a CPCAR channel, the CIR is only 512 kbps.

[0098] Step 14: vCP2 receives the target message and performs data backup between vCP1 and vCP2 based on the target message.

[0099] In practice, if the disaster recovery channel is a heartbeat channel, vCP2, upon receiving the target message, determines whether vCP1 is in a normal working state based on the target message. If the disaster recovery channel is a data backup channel, vCP2, upon receiving the target message, obtains the business-related messages based on the target message and then backs up the relevant business information.

[0100] It can be seen that, Figure 3While the illustrated solution can achieve data backup between vCP1 and vCP2, when vCP1 and / or vCP2 are attacked by TCP, the disaster recovery channel between vCP1 and vCP2 will fail to be established, or the established disaster recovery channel between vCP1 and vCP2 will be disconnected. This will prevent user data from being backed up from vCP1 to vCP2, resulting in significant business losses. For example, if vCP1 and / or vCP2 are attacked by TCP before the disaster recovery channel connection is established, the massive number of attack packets will affect the establishment process of the disaster recovery channel (e.g., the three-way handshake), causing the disaster recovery channel establishment to fail. As another example, if vCP1 is attacked by TCP after the disaster recovery channel between vCP1 and vCP2 has been established, and the attacking TCP packets can match the disaster recovery channel whitelist, the established disaster recovery channel may be disconnected.

[0101] Furthermore, it's understandable that the reason for setting up a disaster recovery channel whitelist in the above scheme is that, to ensure the real-time data backup between the two CPs, the off-site disaster recovery system needs to guarantee sufficient transmission bandwidth for the disaster recovery channel between vCP1 and vCP2. Therefore, vCP1 establishes a disaster recovery channel whitelist for each disaster recovery channel, enabling packets matching the whitelist to be sent to vCP2 with high bandwidth and high speed. However, in the above scheme, vCP1 also generates different whitelists (hereinafter referred to as ordinary whitelists) for other protocols (non-disaster recovery proprietary protocols), and vCP1 will share the same channel (e.g., the CPCAR channel) with packets matching any disaster recovery channel whitelist and packets matching the ordinary whitelist when transmitting to vCP2. This will result in the bandwidth for data backup between vCP1 and vCP2 not being guaranteed. For example, if vCP1 generates 258 disaster recovery channel whitelists and 142 regular whitelists, and the corresponding CIR for this channel is 4000kbps, then if vCP1 sends too many packets to vCP2, and these packets all match the whitelists (including the disaster recovery channel whitelist and the regular whitelist), vCP1 may only be able to send packets used for data backup of vCP1 and vCP2 to vCP2 at a rate of 10kbps. Furthermore, when vCP1 and / or vCP2 are attacked by TCP, if the packets attacking vCP1 and / or vCP2 match the regular whitelists, packets matching the disaster recovery channel whitelist may be dropped or delayed in transmission to vCP2, thus affecting the reliability of data backup.

[0102] To address the aforementioned issues, this application provides a method for establishing a disaster recovery channel. This method utilizes a control device to acquire the real-time status of the disaster recovery channel. When the disaster recovery channel malfunctions due to an attack on the primary and / or backup devices, the IP addresses of the primary and backup devices are dynamically adjusted to ensure the connection of the disaster recovery channel is maintained. This improves the security of the disaster recovery channel and enables smooth data backup between the primary and backup devices. Please refer to [link to details] for further information. Figure 4 , Figure 4 A flowchart illustrating a method for establishing a disaster recovery channel according to this application is shown. This method includes, but is not limited to, the following steps:

[0103] S101: In response to the fulfillment of the first processing condition, the control device sends a first message to the first device.

[0104] In response to the fulfillment of the first processing condition, the control device also sends a second message to the second device.

[0105] The first and second devices serve as backups for each other. During the establishment of a disaster recovery channel between the first and second devices, the first device acts as the client, and the second device as the server. It should be understood that the client is the device attempting to establish a disaster recovery channel with the server, and correspondingly, the server is the device waiting to establish a disaster recovery channel with the client. Alternatively, the first device can be the initiator of the channel establishment, and the second device can be the receiver. In this case, the first device attempts to establish a disaster recovery channel with the second device, and the second device waits to establish a disaster recovery channel with the first device. Optionally, the control device can be a software-defined network (SDN) controller, and the first and second devices can be virtual machines (e.g., vBNG). In a CU-separated communication system, the first and second devices can also be vCP devices, etc., and this application does not specifically limit them. For the CU separation, vCP device, and vBNG in the embodiments of this application, please refer to the introduction of the relevant concepts in the foregoing content; they will not be elaborated upon here.

[0106] The first message includes a first IP address and a second IP address. In one example, the first IP address can be a first source IP address, and the second IP address can be a first destination IP address. The first message is used to enable the first device to establish a first disaster recovery channel with the second device based on the first source IP address and the first destination IP address. The second message includes a second source IP address and a second destination IP address. The second message is used to enable the second device to establish a first disaster recovery channel with the first device based on the second source IP address and the second destination IP address. The first source IP address and the second destination IP address are the same, and the first destination IP address and the second source IP address are the same. The first disaster recovery channel is a channel between the first device and the second device used for data backup. It can be understood that since the first disaster recovery channel is established between the first device and the second device, the source IP address of the first disaster recovery channel on the first device is the IP address of the first device, which is the first source IP address; the destination IP address of the first disaster recovery channel on the first device is the IP address of the second device, which is the first destination IP address. Correspondingly, the source IP address of the first disaster recovery channel on the second device is the IP address of the second device, which is the second source IP address; the destination IP address of the first disaster recovery channel on the second device is the IP address of the first device, which is the second destination IP address. Therefore, in this application, the first source IP address and the second destination IP address are the same, and the first destination IP address and the second source IP address are the same.

[0107] The first processing condition is related to the status of the second disaster recovery channel between the first device and the second device. The status of the second disaster recovery channel includes: the second disaster recovery channel is in a normal connection state, the second disaster recovery channel is in an abnormal state (hereinafter referred to as the second disaster recovery channel abnormality), etc.

[0108] S102: The first device receives the first message sent by the control device and establishes a first disaster recovery channel with the second device based on the first source IP address and the first destination IP address included in the first message.

[0109] In one example, after receiving the first message from the control device, the first device generates a TCP connection packet based on the first source IP address and the first destination IP address in the first message, and sends the TCP connection packet to the second device in a preset manner, thereby establishing a first disaster recovery channel. The preset manner may include one or more of the following: preset bandwidth, preset rate.

[0110] In a specific example, the preset method can be manually set, such as the CPCAR channel mentioned above. Alternatively, the preset method can be dynamically adjusted by the first device based on the current status of the first port (e.g., the throughput of the first port). For example, when the throughput of the first port is large, the preset rate and preset bandwidth are increased, and when the throughput of the first port is small, the preset rate and preset bandwidth are decreased.

[0111] In one example, the first device includes a first target whitelist. After receiving a first message from the control device, the first device updates the first target whitelist according to the first source IP address and the first destination IP address in the first message, and then establishes a first disaster recovery channel with the second device according to the updated first target whitelist.

[0112] In a specific example, the first target whitelist includes a third source IP address and a third destination IP address. The specific process of the first device updating the first target whitelist is as follows: the first device updates the third source IP address included in the first target whitelist to the first source IP address and updates the third destination IP address included in the first target whitelist to the first destination IP address based on the first source IP address and the first destination IP address.

[0113] In a specific example, the process by which the first device establishes a first disaster recovery channel with the second device based on the updated first target whitelist is as follows: The first device generates a TCP connection packet based on the first source IP address and the first destination IP address, and then determines whether the TCP connection packet matches the updated first target whitelist. When the TCP connection packet matches the updated first target whitelist, the first device sends the TCP connection packet to the second device in a preset manner to request the establishment of the first disaster recovery channel; when the TCP connection packet does not match the updated first target whitelist, the first device discards the TCP connection packet. Understandably, when the first device determines whether a TCP connection packet matches the updated first target whitelist, it means whether the five-tuple information carried in the TCP connection packet matches the updated first target whitelist (including source IP address, destination IP address, source port, destination port, and protocol type). Specifically, it means whether the source IP address of the TCP connection packet is the same as the source IP address included in the first target whitelist, whether the destination IP address of the TCP connection packet is the same as the destination IP address included in the first target whitelist, whether the source port of the TCP connection packet is the same as the source port included in the first target whitelist, whether the destination port of the TCP connection packet is the same as the destination port included in the first target whitelist, and whether the protocol number of the TCP connection packet is the same as the protocol number corresponding to the protocol type included in the first target whitelist.

[0114] In a specific example, the first target whitelist is the disaster recovery channel whitelist. Understandably, the updated first target whitelist is also the disaster recovery channel whitelist, as shown in Table 4. Table 4 shows the updated first target whitelist obtained after the first device updates the first target whitelist based on the first source IP address and the first destination IP address.

[0115] Table 4. First Target Whitelist

[0116]

[0117] Optionally, the first target whitelist can include both a disaster recovery channel whitelist and a regular whitelist. The regular whitelist is generated by the first device based on other protocols, i.e., protocols other than the disaster recovery private protocol, such as the Exterior Gateway Protocol (EGP), Interior Gateway Protocol (IGP), etc. As shown in Table 5, Table 5 illustrates a first target whitelist that includes both the disaster recovery channel whitelist and the regular whitelist. The first target whitelist shown in Table 5 is the updated first target whitelist obtained after the first device updates the first target whitelist based on the first source IP address and the first destination IP address. However, it should be noted that compared to the first target whitelist shown in Table 5, the first target whitelist shown in Table 4 can establish the first disaster recovery channel more effectively and securely. The specific reason is that if the first target whitelist includes both the disaster recovery channel whitelist and the general whitelist, then when the first device and / or the second device are subjected to a TCP attack, if the attack packets match the general whitelist, these attack packets will also be transmitted in a preset manner. This will affect the establishment of the first disaster recovery channel, leading to its failure. In this case, the first and second devices need to repeatedly execute the disaster recovery channel establishment method provided in this application to establish the third disaster recovery channel, thereby prolonging the time during which real-time data backup between the first and second devices is not possible. The third disaster recovery channel and the first disaster recovery channel are the same disaster recovery channel used for data backup between the first and second devices. The relationship between the third disaster recovery channel and the first disaster recovery channel is similar to the relationship between the first disaster recovery channel and the second disaster recovery channel, and will not be elaborated further here. In addition, if the primary target whitelist also includes a regular whitelist, then packets matching the regular whitelist will also be transmitted in a preset manner, consuming bandwidth and speed, thereby reducing the transmission rate and bandwidth of packets matching the disaster recovery channel whitelist accordingly.

[0118] Table 5. First Target Whitelist

[0119]

[0120] Understandably, the purpose of the first device sending TCP connection packets to the second device in a preset manner is to enable the second device to receive the TCP connection packets in a timely manner, shortening the time required to establish the first disaster recovery channel, thereby reducing the loss caused by the failure to establish or disconnect the second disaster recovery channel, resulting in the inability to back up data. Furthermore, it is worth noting that although the above embodiment only describes the first device sending TCP connection packets requesting the establishment of the first disaster recovery channel to the second device in a preset manner during the establishment of the first disaster recovery channel, it is understandable that during the establishment of other disaster recovery channels between the first and second devices, the first device will also send TCP connection packets requesting the establishment of other disaster recovery channels to the second device in a preset manner. In other words, during the establishment of any disaster recovery channel between the first and second devices, the first device configures a separate preset method for each disaster recovery channel (or each disaster recovery channel whitelist). The preset method configured by the first device for each disaster recovery channel (or each disaster recovery channel whitelist) can be the same or different. Compared to... Figure 3 In the illustrated scheme, all disaster recovery channel whitelists and all regular whitelists share the same preset method. In this embodiment, the first device configures a preset method separately for each disaster recovery channel (or each disaster recovery channel whitelist), which can ensure that TCP connection packets requesting the establishment of a disaster recovery channel (or packets matching any disaster recovery channel whitelist) can be sent to the second device at high speed and high bandwidth, thereby ensuring the rapid establishment of the disaster recovery channel between the first device and the second device, and further ensuring the real-time data backup between the first device and the second device.

[0121] In a specific implementation, as one example, the first device is equipped with a Remote Data Service (RDS) component and a security component. When the first device receives the first message, the RDS component begins preparing to establish a first disaster recovery channel. Specifically, the RDS component updates the first target whitelist based on the first source IP address and the first destination IP address. Then, the RDS component sends the first target whitelist to the security component. The security component determines whether the TCP connection packet matches the first target whitelist. If the TCP connection packet matches the first target whitelist, the first device sends the first TCP connection packet to the second device in a preset manner.

[0122] S103: The second device establishes a first disaster recovery channel with the first device based on the received second message and TCP connection message.

[0123] In one example, after receiving a second message from the control device, the second device obtains a second source IP address and a second destination IP address. Then, the second device receives a TCP connection packet from the first device, which includes the first source IP address and the first destination IP address. Based on the fact that the second source IP address in the second message matches the first destination IP address in the TCP connection packet, and the second destination IP address in the second message matches the first source IP address in the TCP packet, the second device establishes a TCP connection with the first device, thereby establishing a first disaster recovery channel.

[0124] The following will combine Figure 5 The corresponding steps S201-S202 provide a detailed description of step S101 in the foregoing content.

[0125] S201: The control device determines that the first processing condition is met (i.e., in response to the first processing condition being met).

[0126] In a specific example, the control device determines that a first processing condition is met, including: the control device receiving a third message indicating an anomaly in the second disaster recovery channel between the first and second devices; and / or, the control device detecting an anomaly in an existing second disaster recovery channel between the first and second devices. The anomaly in the second disaster recovery channel includes: failure to establish the second disaster recovery channel, disconnection of the second disaster recovery channel, or abnormal performance of the second disaster recovery channel. It is understood that failure to establish the second disaster recovery channel refers to the failure to establish a second disaster recovery channel before a TCP connection has been established, and disconnection of the second disaster recovery channel refers to the disconnection of an established second disaster recovery channel. Optionally, abnormal performance of the second disaster recovery channel may be that the bandwidth of the second disaster recovery channel exceeds a preset bandwidth. The specific details of this example will be elaborated in Example 1 and Example 2 below.

[0127] S202: The control device generates the first source IP address and the first destination IP address.

[0128] In a specific example, in response to the fulfillment of a first processing condition, the control device generates a first source IP address and a first destination IP address based on the channel parameters. The channel parameters include a third source IP address, a third destination IP address, and a protocol type. The third source IP address and the third destination IP address are parameters for the second disaster recovery channel, and the protocol type indicates that these are parameters for the second disaster recovery channel.

[0129] In a specific example, the control device can obtain channel parameters through one or more of the following methods, so that when the second disaster recovery channel is abnormal, the control device can promptly determine the abnormality of the second disaster recovery channel from multiple aspects, thereby reducing the loss of data synchronization caused by the abnormality of the second disaster recovery channel.

[0130] Firstly, the control device obtains the channel parameters based on the third message, which includes the channel parameters. Therefore, when the control device receives the third message, it can obtain the channel parameters based on it. For a detailed explanation of the third message, please refer to Example 1 below.

[0131] Secondly, the control device obtains the channel parameters based on the established second disaster recovery channel. Specifically, after the second disaster recovery channel between the first device and the second device is established, the control device monitors the second disaster recovery channel in the connected state to obtain the channel parameters of the second disaster recovery channel. Optionally, after the second disaster recovery channel between the first device and the second device is established, the first device and / or the second device periodically send the channel parameters of the second disaster recovery channel to the control device, so that the control device obtains the aforementioned channel parameters.

[0132] In one specific embodiment, the channel parameters also include a protocol type, which indicates that the channel parameters are for a disaster recovery channel. It is understood that the protocol type in the channel parameters of the disaster recovery channel is a disaster recovery private protocol number. The IP protocol number of the disaster recovery private protocol is different from the IP protocol numbers of other protocols. Therefore, the control device determines that the abnormal channel is the second disaster recovery channel, not the ordinary channel (ordinary channels are not used for data backup), based on the protocol type in the channel parameters. Only then will the control device generate a first source IP address and a first destination IP address, thereby enabling the first device to establish a first disaster recovery channel with the second device.

[0133] Understandably, similar to the first disaster recovery channel, the second disaster recovery channel is also established between the first and second devices for data backup. Therefore, the source IP address of the second disaster recovery channel on the first device and the destination IP address of the second disaster recovery channel on the second device are the same (here, the third source IP address); the destination IP address of the second disaster recovery channel on the first device and the source IP address of the second disaster recovery channel on the second device are the same (here, the third destination IP address). Then, in the first source IP address and first destination IP address generated by the control device based on the third source IP address and the third destination IP address, the first source IP address and the third source IP address are different, and the first destination IP address and the third destination IP address are different. Optionally, the first source IP address and the third destination IP address can be the same or different; the first destination IP address and the third source IP address can be the same or different, without specific limitations. For the above reasons, packets attacking the second disaster recovery channel will be unable to attack the first disaster recovery channel, thereby improving the security of the first disaster recovery channel and ensuring that data backup between the first and second devices can continue.

[0134] It is worth noting that the first disaster recovery channel and the second disaster recovery channel in this application are the same disaster recovery channel used for data backup between the first device and the second device. Optionally, the first disaster recovery channel (second disaster recovery channel) can be a heartbeat channel or any other data backup channel. Assuming that both the first and second disaster recovery channels are heartbeat channels, the first and second disaster recovery channels in this application can be understood as follows: the second disaster recovery channel can be understood as the first heartbeat channel established between the first device and the second device, and the first disaster recovery channel can be understood as the second heartbeat channel established between the first device and the second device. Specifically, when the first heartbeat channel establishment fails, or the first heartbeat channel is disconnected, or the first heartbeat channel is pre-disconnected due to performance abnormalities, the second heartbeat channel is established. Understandably, since the first disaster recovery channel and the second disaster recovery channel are the same disaster recovery channel, the source port, destination port, and protocol type of the first disaster recovery channel on the first device are the same as those of the second disaster recovery channel on the first device; the source port, destination port, and protocol type of the first disaster recovery channel on the second device are the same as those of the second disaster recovery channel on the second device.

[0135] S203: The control device sends a first message to the first device.

[0136] In the specific implementation, after the control device generates the first source IP address and the first destination IP address, it generates the first message based on the first source IP address and the first destination IP address, and then sends the first message to the first device so that the first device can establish a first disaster recovery channel with the second device.

[0137] Understandably, the process by which the control device sends a second message to the second device in response to the fulfillment of the first processing condition is similar to the process by which the control device generates the first message, and for the sake of brevity, it will not be described in detail here.

[0138] The following examples, S1 and S2, will explain in detail how the control device determines that the first processing condition is met in step S201.

[0139] Example 1: The control device receives a third message.

[0140] The third message indicates an anomaly in the second disaster recovery channel. This second disaster recovery channel can be an established second disaster recovery channel or a second disaster recovery channel that has failed to be established.

[0141] In one example, the third message is sent by the first device to the control device. Specifically, in response to a second processing condition, the first device sends a third message to the control device. The second processing condition includes one or more of the following: an abnormality in the second disaster recovery channel (including failure to establish the second disaster recovery channel, disconnection of the second disaster recovery channel, or abnormal performance of the second disaster recovery channel), or the packet loss rate of the first device exceeding a first threshold.

[0142] Optionally, the third message is sent by the second device to the control device. Specifically, in response to a third processing condition, the second device sends a third message to the control device. Here, the third processing condition includes one or more of the following conditions: the second disaster recovery channel is abnormal (including failure to establish the second disaster recovery channel, disconnection of the second disaster recovery channel, or abnormal performance of the second disaster recovery channel), or the packet loss rate of the second device exceeds a second threshold.

[0143] The first and second thresholds can be preset by the user or dynamically adjusted by the device based on the status of the corresponding port of the second disaster recovery channel on the device; no specific limitation is made here. Optionally, the first threshold can be the same as or different from the second threshold; no specific limitation is made here.

[0144] Optionally, both the first device and the second device send a third message to the control device to inform the control device that the second disaster recovery channel is abnormal. Specifically, in response to a second processing condition, the first device sends a third message to the control device; in response to a third processing condition, the second device sends a third message to the control device.

[0145] As shown in Table 4, the port corresponding to the second disaster recovery channel on the first device is port 1, and the port corresponding to the second device is port 2. Therefore, the reason for the anomaly of the second disaster recovery channel may be that it has been subjected to a TCP attack, meaning that port 1 and / or port 2 has been attacked by TCP. Taking a TCP attack on port 1 as an example, this attack could be due to a precise TCP packet attack on the first device, or it could be due to a vague TCP packet attack. A precise TCP packet attack refers to a massive number of TCP packets continuously attacking a specific port of the device (here, port 1 of the first device); a vague TCP packet attack refers to a massive number of TCP packets randomly attacking any port of the device (including port 1 of the first device). Similarly, a TCP attack on port 2 could also fall into either of these categories. For a detailed explanation, please refer to the section on TCP attacks on port 1; it will not be repeated here.

[0146] In one example, a vague TCP packet attacking the first device might be an attack packet matching the first target whitelist, and a precise TCP packet attacking the first device might be an attack packet matching the first target whitelist. Similarly, a vague TCP packet attacking the second device might be an attack packet matching the second target whitelist, and a precise TCP packet attacking the second device might be an attack packet matching the second target whitelist. Similar to the first target whitelist, the second target whitelist includes the disaster recovery channel whitelist on the second device corresponding to the second disaster recovery channel. For simplicity, in the following description, a precise TCP packet matching the whitelist (including the first and second target whitelists) will be referred to as a precisely matched packet, and a vague TCP packet matching the whitelist will be referred to as a vaguely matched packet.

[0147] Combined with the reasons for the anomaly of the second disaster recovery channel (such as...) Figure 6 As shown, taking the example of the first device sending a third message to the control device in response to the second processing condition, Example 1 will be explained in detail from the following three aspects:

[0148] (1) Before the establishment of the second disaster recovery channel, the first device and / or the second device were attacked by precisely matched packets.

[0149] In a specific example, if the first device / or the second device is attacked by a precisely matched message before the second disaster recovery channel is established, the second disaster recovery channel will fail to be established. At this time, the first device determines that the second disaster recovery channel has failed to be established, thereby generating a third message and sending the third message to the control device.

[0150] It should be noted that the failure to establish the second disaster recovery channel due to an exact-match packet attack on the first and / or second devices before its establishment is explained as follows: Taking the first device as an example of an exact-match packet attack before the establishment of the second disaster recovery channel, since the exact-match packets can match the first target whitelist, the first device will send a large number of exact-match packets to the second port of the second device in the aforementioned preset manner. Therefore, if the first device is attacked with exact-match packets before the establishment of the second disaster recovery channel, the exact-match packets will affect the normal interaction of TCP handshake packets, causing the three-way handshake to fail to complete properly. Consequently, the TCP connection between the first and second ports cannot be established, and the establishment of the second disaster recovery channel fails. For example, when the first device is attacked by an exact match message, the first device sends a TCP connection message to the second device requesting the establishment of a second disaster recovery channel. When the second device receives the TCP connection message, it returns a message to the first device confirming the establishment of the second disaster recovery channel connection. However, because the first device is attacked by an exact match message, the first device may discard the message returned by the second device, or may be unable to process the message returned by the second device within a preset time, thus causing the establishment of the second disaster recovery channel to fail.

[0151] In another specific example, before the second disaster recovery channel is established, if the first device is attacked by precisely matched TCP packets, the first port will receive a large number of TCP packets in a short period of time. The rate of traffic received on the first port (i.e., the rate of attack traffic) will increase rapidly. When the rate of traffic received on the first port exceeds the committed access rate (CAR) value, packet loss will occur on the first port. When the packet loss rate of the first device exceeds a first threshold, the first device generates a third message and sends it to the control device. This third message includes the protocol type corresponding to the packets dropped by the first device, enabling the control device to determine that the target of the attack is the second disaster recovery channel based on the protocol type of the dropped packets.

[0152] (2) After the second disaster recovery channel is established, the first device and / or the second device are attacked by fuzzy matching messages.

[0153] In a specific example, after the second disaster recovery channel is established, if the first device and / or the second device are attacked by fuzzy matching packets, the bandwidth of the second disaster recovery channel will increase significantly. When the bandwidth on the second disaster recovery channel exceeds the preset bandwidth (i.e., the second disaster recovery channel performance is abnormal), the second disaster recovery channel is at risk of disconnection. To avoid the loss of user data due to the disconnection of the second disaster recovery channel, the first device generates a third message and sends it to the control device. For example, if the first device detects that the bandwidth of the second disaster recovery channel exceeds twice the normal bandwidth within three monitoring periods, the first device determines that the current second disaster recovery channel is about to disconnect. At this time, the first device will generate a third message to inform the control device that the second disaster recovery channel is abnormal.

[0154] It should be noted that the bandwidth of the established second disaster recovery channel is limited (preset bandwidth). If the bandwidth of the second disaster recovery channel exceeds the preset bandwidth, the traffic load on the second disaster recovery channel will be too high, which will lead to packet loss or disconnection of the second disaster recovery channel.

[0155] (3) After the second disaster recovery channel is established, the first device and / or the second device are attacked by precisely matched packets.

[0156] In a specific example, after the second disaster recovery channel is established, if the first device and / or the second device are attacked by a precisely matched message, the second disaster recovery channel will be disconnected. At this time, the first device generates a third message based on the disconnection of the second disaster recovery channel and sends it to the control device.

[0157] In a specific example, if the first and / or second devices are attacked by fuzzy-matching packets before the second disaster recovery channel is established, the second disaster recovery channel can still be established. This is because: the first and / or second ports are only attacked by a subset of fuzzy-matching packets; that is, compared to exact-matching packets, the number of fuzzy-matching packets is smaller, thus reducing the number of attacks on the first and / or second ports. Furthermore, since fuzzy-matching packets can match whitelists, they will be transmitted in a preset mode (e.g., CPCAR channel), which is high-speed and / or high-bandwidth. This significantly shortens the transmission time of fuzzy-matching packets, thereby reducing their impact on the establishment process of the second disaster recovery channel and ensuring its successful establishment. Therefore, fuzzy-matching packets do not affect the establishment of the second disaster recovery channel.

[0158] In another example, a vague TCP packet attacking the first device might also be an attack packet that does not match the first target whitelist, and a precise TCP packet attacking the first device might also be an attack packet that does not match the first target whitelist; similarly, a vague TCP packet attacking the second device might also be an attack packet that does not match the second target whitelist, and a precise TCP packet attacking the second device might also be an attack packet that does not match the second target whitelist. For simplicity, in the following description, a precise TCP packet that does not match the whitelist (including the first target whitelist and the second target whitelist) will be simply referred to as a precise mismatch packet, and a vague TCP packet that does not match the whitelist will be simply referred to as a vague mismatch packet.

[0159] When the first device and / or the second device are attacked by precisely mismatched and / or fuzzy mismatched packets, the first device will first determine whether the packet matches the first target whitelist before sending it to the second device. If the packet matches the first target whitelist, the first device will send the packet to the second device; otherwise, the first device will discard the packet. Therefore, whether the second disaster recovery channel is established before or after its establishment, attacks on the first device and / or the second device by precisely mismatched and / or fuzzy mismatched packets will not affect the second disaster recovery channel or data backup.

[0160] Example 2: The control equipment detects an anomaly in the existing second disaster recovery channel between the first and second devices.

[0161] In practice, after the second disaster recovery channel between the first and second devices is successfully established, the control device will be configured to periodically monitor the status of the second disaster recovery channel. Therefore, the control device can detect anomalies in the existing second disaster recovery channel. Understandably, anomalies in the existing second disaster recovery channel include both disconnection and performance malfunctions.

[0162] Optionally, after the second disaster recovery channel is established, if the first device and / or the second device are attacked by fuzzy matching messages, and the control device detects that the bandwidth on the second disaster recovery channel exceeds the preset bandwidth, the control device determines that the second disaster recovery channel is abnormal.

[0163] Optionally, after the second disaster recovery channel is established, if the first device and / or the second device are attacked by precisely matched packets, the control device will determine that the second disaster recovery channel is abnormal when it detects that the second disaster recovery channel is disconnected.

[0164] To more clearly demonstrate that the disaster recovery channel establishment method provided in this application can effectively improve the security of the disaster recovery channel between the first device and the second device, the embodiments of this application will be illustrated in the following scenarios.

[0165] (1) Before or after the establishment of the second disaster recovery channel, the first device and / or the second device are attacked by fuzzy mismatched messages or exact mismatched messages.

[0166] In this scenario, before sending a message to the second device, the first device first checks if the message matches a first target whitelist. If the message matches the whitelist, the first device transmits the message to the second device using a preset method (e.g., a CPCAR channel); if the message does not match the whitelist, the first device discards the message. Since both fuzzy mismatches and exact mismatches are attack messages that do not match the whitelist, the first device will discard these attack messages when attacked by either type of attack. Furthermore, since the TCP connection request to establish a second disaster recovery channel matches the whitelist, the first device will send this TCP connection request to the second device. In addition, after the second device receives the TCP connection packet, if the second device still needs to return the corresponding acknowledgment packet to the first device to complete the second disaster recovery channel (e.g., a three-way handshake), and the second device is also attacked by fuzzy mismatch packets or exact mismatch packets, in this case, before the second device sends the packet to the first device, the second device will also determine whether the packet matches the second target whitelist in the second device, thereby enabling the second device to discard the attack packet and send an acknowledgment packet to the first device to establish the second disaster recovery channel.

[0167] (2) Before the second disaster recovery channel is established, the first device and / or the second device are attacked by fuzzy matching messages.

[0168] In this scenario, before sending a message to the second device, the first device first determines whether the message matches a first target whitelist. If the message matches the first target whitelist, the first device transmits the message to the second device using a preset method (e.g., a CPCAR channel); if the message does not match the first target whitelist, the first device discards the message. When the first device is attacked by fuzzy-matched messages, since the fuzzy-matched messages are attack messages that match the first target whitelist, the first device transmits the fuzzy-matched messages to the second device using a preset method (e.g., a CPCAR channel). Furthermore, because the preset method uses high speed and / or high bandwidth, the first device can significantly shorten the time it takes to transmit fuzzy-matched messages to the second device, thereby reducing the impact of fuzzy-matched messages on the establishment process of the second disaster recovery channel, ensuring the successful establishment of the second disaster recovery channel. Similarly, when the second device is attacked by fuzzy matching packets, since the fuzzy matching packets are attack packets that match the second target's whitelist, the second device transmits the fuzzy matching packets to the first device in a preset manner. This greatly shortens the time it takes for the second device to transmit the fuzzy matching packets to the first device, thereby reducing the impact of fuzzy matching packets on the establishment process of the second disaster recovery channel and enabling the second disaster recovery channel to be established successfully.

[0169] (3) Before the second disaster recovery channel is established, the first device and / or the second device are attacked by precisely matched packets.

[0170] In this scenario, such as Figure 7 As shown, if the establishment of the second disaster recovery channel fails, the first device and / or the second device send a third message to the control device to inform it of the failure. Then, the control device generates a first message and a second message based on the channel parameters of the second disaster recovery channel included in the third message, and sends the first message to the first device and the second message to the second device. Upon receiving the first message, the first device updates the first target whitelist; upon receiving the second message, the second device updates the second target whitelist. Then, the first device generates a TCP connection packet requesting the establishment of the first disaster recovery channel, and determines whether the TCP connection packet matches the updated first target whitelist. If the TCP connection packet matches the updated first target whitelist, the first device sends the TCP connection packet to the second device in a preset manner (e.g., CPCAR channel), thereby establishing the first disaster recovery channel. In addition, after the second device receives the TCP connection packet, if the second device still needs to return the acknowledgment packet corresponding to the TCP connection packet to the first device in order to complete the establishment of the first disaster recovery channel (e.g., a three-way handshake), the second device first determines whether the acknowledgment packet matches the second target whitelist. When the acknowledgment packet matches the updated second target whitelist, the second device sends the acknowledgment packet to the first device in a preset manner, thereby establishing the first disaster recovery channel.

[0171] (4) After the second disaster recovery channel is established, the first device and / or the second device are subjected to fuzzy matching message attacks.

[0172] In this scenario, such as Figure 8 As shown, after a period of time, the control device will detect that the bandwidth of the second disaster recovery channel exceeds the preset bandwidth. At this time, the control device determines that the performance of the second disaster recovery channel is abnormal. The control device generates a first message and a second message based on the channel parameters obtained by monitoring the second disaster recovery channel when it is in the connected state. The control device sends the first message to the first device and the second message to the second device. After receiving the first message, the first device updates the first target whitelist; after receiving the second message, the second device updates the second target whitelist. Then, the first device generates a TCP connection packet requesting the establishment of the first disaster recovery channel, and determines whether the TCP connection packet matches the updated first target whitelist. When the TCP connection packet matches the updated first target whitelist, the first device sends the TCP connection packet to the second device in a preset manner, thereby establishing the first disaster recovery channel. In addition, after the second device receives the TCP connection packet, if the second device still needs to return the acknowledgment packet corresponding to the TCP connection packet to the first device in order to complete the establishment of the first disaster recovery channel (e.g., a three-way handshake), the second device first determines whether the acknowledgment packet matches the second target whitelist. When the acknowledgment packet matches the updated second target whitelist, the second device sends the acknowledgment packet to the first device in a preset manner, thereby establishing the first disaster recovery channel.

[0173] (5) After the second disaster recovery channel is established, the first device and / or the second device are subjected to a precise matching message attack.

[0174] In this scenario, such as Figure 9As shown, the second disaster recovery channel will be disconnected. At this time, the first device and / or the second device sends a third message to the control device to inform the control device that the second disaster recovery channel is disconnected. Then, the control device generates a first message and a second message based on the channel parameters of the second disaster recovery channel included in the third message, or generates the first message and the second message based on the channel parameters obtained by monitoring the second disaster recovery channel when it is in a connected state. Then, the control device sends the first message to the first device and the second message to the second device. After receiving the first message, the first device updates the first target whitelist; after receiving the second message, the second device updates the second target whitelist. Then, the first device generates a TCP connection packet requesting the establishment of the first disaster recovery channel, and determines whether the TCP connection packet matches the updated first target whitelist. When the TCP connection packet matches the updated first target whitelist, the first device sends the TCP connection packet to the second device in a preset manner (e.g., CPCAR channel), thereby establishing the first disaster recovery channel. In addition, after the second device receives the TCP connection packet, if the second device still needs to return the acknowledgment packet corresponding to the TCP connection packet to the first device in order to complete the establishment of the first disaster recovery channel (e.g., a three-way handshake), the second device first determines whether the acknowledgment packet matches the second target whitelist. When the acknowledgment packet matches the updated second target whitelist, the second device sends the acknowledgment packet to the first device in a preset manner, thereby establishing the first disaster recovery channel.

[0175] In summary, the disaster recovery channel establishment method provided in this application effectively improves the security of the disaster recovery channel. When an established disaster recovery channel is attacked, this application can re-establish the disaster recovery channel to reduce the loss caused by the interruption of data backup due to the disconnection of the disaster recovery channel; when the disaster recovery channel is attacked before its establishment, this application can continue to complete the establishment of the disaster recovery channel, thus not affecting data backup.

[0176] For simplicity, the above embodiments only describe the establishment process of one disaster recovery channel (i.e., the first disaster recovery channel) between the first device and the second device. It should be understood that there are multiple disaster recovery channels between the first device and the second device, and the establishment process of other disaster recovery channels between the first device and the second device is similar to that of the first disaster recovery channel, and will not be elaborated here. However, it is worth noting that when any disaster recovery channel between the first device and the second device (e.g., the second disaster recovery channel) malfunctions, the other disaster recovery channels between the first device and the second device will be disconnected and re-established. This is because, as mentioned above, when the second disaster recovery channel between the first device and the second device malfunctions, the control device will send the first source IP address and the first destination IP address to the first device, and the second source IP address and the second destination IP address to the second device. At this time, the first device uses the first source IP address as its own IP address, and the second device uses the second source IP address as its own IP address. Therefore, the IP addresses of the other disaster recovery channels between the first device and the second device also need to change accordingly. This will cause the other disaster recovery channels between the first device and the second device to disconnect, and then re-establish the connection based on the first source IP address and the first destination IP address. It should be noted that when the disaster recovery channel between the first device and the second device is disconnected, the batch backup function will be automatically triggered between the first device and the second device, so that user data can be backed up during the period when the disaster recovery channel between the first device and the second device is disconnected; when the disaster recovery channel between the first device and the second device is reconnected, the first device and the second device will automatically perform real-time backup. In other words, the disaster recovery channel establishment method provided in this application can still establish a disaster recovery channel when the first device and / or the second device is attacked, thereby ensuring data backup between the first device and the second device.

[0177] Based on the above method embodiments, the relevant network devices involved in the embodiments of this application are described below. For example... Figure 10 As shown, Figure 10 This is a schematic diagram of the structure of a control device 100 provided in an embodiment of this application. The control device 100 has any of the functions of the control device in the above-described method embodiments. For example... Figure 10 As shown, the control device 100 includes: a sending unit 110 for executing S101 and S203, and a processing unit 120 for executing S201-S202. Optionally, the control device 100 further includes a receiving unit 130 for executing the relevant steps in S201, such as receiving a third message sent by the first device and / or the second device.

[0178] The control device 100 corresponds to the control device in the above method embodiments. Each module in the control device 100 and the other operations and / or functions described above are various steps and methods implemented by the control device in the above method embodiments. For specific details, please refer to the above method embodiments. For the sake of brevity, they will not be repeated here.

[0179] The control device 100 is only illustrated by the above-mentioned division of functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the control device 100 can be divided into different functional modules to complete all or part of the functions described above.

[0180] Figure 11 This is a schematic diagram of the structure of a disaster recovery backup device 200 provided in an embodiment of this application. The disaster recovery backup device 200 has any of the functions of the first device in the above method embodiment. For example... Figure 11 As shown, the disaster recovery backup device 200 includes: a receiving unit 210, used to execute the steps in S102 related to receiving the first message sent by the control device; and a processing unit 220, used to execute the steps in S102 related to establishing a first disaster recovery channel based on the first IP address and the second IP address included in the first message. Optionally, the disaster recovery backup device 200 further includes: a sending unit 230, used to execute the steps in Example 1 related to sending the third message to the control device, and the steps in S102 related to sending TCP connection packets to the second device in a preset manner.

[0181] In a specific implementation, as one embodiment, the processing unit 220 may include an RDS unit 221 and a security unit 222. The RDS unit 221 is used to generate a first target whitelist and distribute the first target whitelist to the security unit 222 before sending a TCP connection packet to the second device. The security unit 222 is used to determine whether the TCP connection packet matches the first target whitelist.

[0182] The disaster recovery backup device 200 corresponds to the first device in the above method embodiment. The modules in the disaster recovery backup device 200 and the other operations and / or functions described above are various steps and methods implemented by the first device in the above method embodiment. For specific details, please refer to the above method embodiment. For the sake of brevity, they will not be repeated here.

[0183] When establishing a disaster recovery channel, the disaster recovery backup device 200 is illustrated using the above-described functional module division as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the disaster recovery backup device 200 can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the disaster recovery backup device 200 provided in the above embodiment and the first device in the above method embodiment belong to the same concept; its specific implementation process is detailed in the above method embodiment and will not be repeated here.

[0184] Corresponding to the method embodiments and virtual device embodiments provided in this application, this application also provides a network device, and the hardware structure of the network device is described below.

[0185] The network device 300 described below corresponds to the control device or the first device in the above method embodiments. The various hardware components, modules, and other operations and / or functions in the network device 300 are respectively for implementing the various steps and methods performed by the control device or the first device in the above method embodiments. Specific details can be found in the above method embodiments, and for brevity, will not be repeated here. The steps in the above method embodiments are completed by the integrated logic circuits of the hardware in the processor of the network device 300 or by instructions in software form. The steps of the methods disclosed in the embodiments of this application can be directly embodied as being executed by the hardware processor, or by a combination of hardware and software modules in the processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are not provided here.

[0186] Network device 300 corresponds to control device 100 or first device 200 in the above virtual device embodiments. Each functional module in control device 100 or first device 200 is implemented using software from network device 300. In other words, the functional modules included in control device 100 or first device 200 are generated by the processor of network device 300 after reading the program code stored in memory.

[0187] See Figure 12 , Figure 12 The diagram illustrates the structure of a network device 300 provided in an exemplary embodiment of this application. The network device 300 can be configured as a control device or a first device. The network device 300 can be implemented using a general bus architecture.

[0188] The network device 300 includes at least one processor 310, a communication bus 320, a memory 330, and at least one communication interface 340.

[0189] The processor 310 can be a general-purpose central processing unit (CPU), a network processor (NP), a microprocessor, or one or more integrated circuits for implementing the solutions of this application, such as an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The aforementioned PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0190] The communication bus 320 is used to transmit information between the aforementioned components. The communication bus 320 can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, it is represented by only one thick line in the figure, but this does not indicate that there is only one bus or one type of bus.

[0191] The memory 330 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions; it may also be a random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions; it may also be an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, or other magnetic storage devices; or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory 330 may exist independently and be connected to the processor 310 via the communication bus 320. The memory 330 may also be integrated with the processor 310.

[0192] Communication interface 340 uses any transceiver-like device for communicating with other devices or communication networks. Communication interface 340 includes a wired communication interface and may also include a wireless communication interface. The wired communication interface may be, for example, an Ethernet interface. The Ethernet interface may be an optical interface, an electrical interface, or a combination thereof. The wireless communication interface may be a wireless local area network (WLAN) interface, a cellular network communication interface, or a combination thereof.

[0193] In a specific implementation, as one example, the processor 310 may include one or more CPUs, such as Figure 12 CPU0 and CPU1 are shown in the diagram.

[0194] In a specific implementation, as one example, network device 300 may include multiple processors, such as... Figure 12 The processors 310 and 350 are shown. Each of these processors can be a single-core processor or a multi-core processor. Here, "processor" can refer to one or more devices, circuits, and / or processing cores used to process data (such as computer program instructions).

[0195] In some embodiments, the memory 330 is used to store program code 360 ​​for executing the scheme of this application, and the processor 310 can execute the program code 360 ​​stored in the memory 330. That is, the network device 300 can implement the method provided in the above method embodiments through the processor 310 and the program code 360 ​​in the memory 330.

[0196] The network device 300 in this application embodiment can correspond to the control device or the first device in the above-described method embodiments. Furthermore, the processor 310, communication interface 340, etc., in the network device 300 can implement the functions and / or various steps and methods implemented by the devices in the above-described method embodiments. For the sake of brevity, further details are omitted here.

[0197] The transmitting unit 110 and receiving unit 130 in the control device 100 can be equivalent to the communication interface 340 in the network device 300; the processing unit 120 in the control device 100 can be equivalent to the processor 310 in the network device 300.

[0198] The receiving unit 210 and sending unit 230 in the disaster recovery backup device 200 can be equivalent to the communication interface 340 in the network device 300; the processing unit 220 in the disaster recovery backup device 200 can be equivalent to the processor 310 in the network device 300.

[0199] See Figure 13This application provides a network system 400, which includes a control device 410, a first device 420, and a second device 430. Optionally, the control device 410 is as follows: Figure 10 The control device 100 shown or Figure 12 The network device 300 shown, the first device 420 is as follows Figure 11 The disaster recovery backup device 200 shown Figure 12 The network device 300 is shown.

[0200] This application provides a computer-readable storage medium storing computer instructions, which, when executed on a computing device (e.g., ...), ... Figure 10 The control device 100 shown Figure 12 When running on the network device 300 shown, the computing device performs some or all of the steps performed by the control device in the above method embodiments.

[0201] This application also provides another computer-readable storage medium storing computer instructions, which, when executed on a computing device (e.g., ...), ... Figure 11 The first device 200 shown Figure 12 When running on the network device 300 shown, the computing device performs some or all of the steps performed by the first device in the above method embodiment.

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

[0203] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be found in the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0204] In the several embodiments provided in this application, the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, or it may be an electrical, mechanical, or other form of connection.

[0205] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of this application, depending on actual needs.

[0206] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0207] If the integrated unit is implemented as a software functional unit 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 all or part 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, server, or network device, etc.) to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0208] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0209] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. This computer program product includes one or more computer program instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD), or a semiconductor medium (e.g., solid-state drive)).

[0210] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0211] The above description is only an optional embodiment of this application and is not intended to limit this application. 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 method for establishing a disaster recovery channel, characterized in that, The method includes: In response to the fulfillment of processing conditions, the control device sends a first message to the first device. The first message includes a first source Internet Protocol (IP) address and a first destination IP address. The first message is used to enable the first device to establish a first disaster recovery channel with the second device based on the first source IP address and the first destination IP address. The processing conditions are related to the status of the second disaster recovery channel between the first device and the second device. The first device and the second device serve as backups for each other.

2. The method according to claim 1, characterized in that, The processing conditions include: The control device receives a second message sent by the first device, the second message indicating that the second disaster recovery channel is abnormal.

3. The method according to claim 1, characterized in that, The preset conditions include: The control device detected an anomaly in the existing second disaster recovery channel between the first device and the second device.

4. The method according to claim 2 or 3, characterized in that, The second disaster recovery channel anomaly includes: failure to establish the second disaster recovery channel, disconnection of the second disaster recovery channel, or abnormal performance of the second disaster recovery channel.

5. The method according to any one of claims 1-3, characterized in that, Before the control device sends the first message to the first device, the method further includes: The control device obtains channel parameters, which include a second source IP address and a second destination IP address, wherein the second source IP address and the second destination IP address are parameters of the second disaster recovery channel; The control device generates the first source IP address and the first destination IP address based on the second source IP address and the second destination IP address.

6. The method according to claim 5, characterized in that, The channel parameters also include a protocol type, which indicates that the channel parameters are parameters of the disaster recovery channel.

7. The method according to any one of claims 1-3, characterized in that, The method is applied to a communication system that includes a control plane (CP) and a user plane (UP) with separation, wherein the first device includes a first CP device and the second device includes a second CP device.

8. A method for establishing a disaster recovery channel, characterized in that, The method includes: The first device receives a first message sent by the control device, the first message including a first source Internet Protocol IP address and a first destination IP address; The first device establishes a first disaster recovery channel with the second device based on the first source IP address and the first destination IP address. The first disaster recovery channel is a channel between the first device and the second device for data backup, and the first device and the second device serve as backups for each other.

9. The method according to claim 8, characterized in that, Before the first device receives the first message sent by the control device, the method further includes: In response to the fulfillment of the processing conditions, the first device sends a second message to the control device, wherein the second message is used to indicate that the second disaster recovery channel is abnormal, thereby triggering the control device to send the first message to the first device; The processing conditions include one or more of the following: the second disaster recovery channel is abnormal, or the packet loss rate of the first device exceeds a preset threshold; the second disaster recovery channel abnormality includes: the second disaster recovery channel fails to be established, the second disaster recovery channel is disconnected, or the performance of the second disaster recovery channel is abnormal.

10. The method according to claim 8 or 9, characterized in that, The first device establishes a first disaster recovery channel with the second device based on the first source IP address and the first destination IP address, including: The first device generates a first Transmission Control Protocol (TCP) connection message based on the first source IP address and the first destination IP address, and sends the first TCP connection message to the second device in a preset manner, thereby establishing the first disaster recovery channel. The preset manner includes one or more of the following: preset bandwidth, preset rate; or... The first device receives a second TCP connection packet sent by the second device. The second TCP connection packet includes a third source IP address and a third destination IP address. The first device establishes a TCP connection with the second device based on the fact that the third source IP address is the same as the first source IP address and the third destination IP address is the same as the first destination IP address, thereby establishing the first disaster recovery channel.

11. The method according to any one of claims 8-9, characterized in that, The first device includes a target whitelist. Before the first device establishes a first disaster recovery channel with the second device based on the first source IP address and the first destination IP address, the method further includes: The first device updates the second source IP address included in the target whitelist to the first source IP address and the second destination IP address included in the target whitelist to the first destination IP address based on the first source IP address and the first destination IP address, wherein the second source IP address corresponds to the second destination IP address.

12. The method according to claim 11, characterized in that, The target whitelist is the disaster recovery channel whitelist.

13. A control device, characterized in that, The control device includes a transmitting unit. The sending unit is used to send a first message to the first device in response to the fulfillment of processing conditions. The first message includes a first source Internet Protocol (IP) address and a first destination IP address. The first message is used to enable the first device to establish a first disaster recovery channel with the second device based on the first source IP address and the first destination IP address. The processing conditions are related to the status of the second disaster recovery channel between the first device and the second device. The first device and the second device are backups for each other.

14. The device according to claim 13, characterized in that, The control device further includes a receiving unit, and the conditions for satisfying the processing include: The receiving unit receives a second message sent by the first device, the second message indicating that the second disaster recovery channel is abnormal.

15. The device according to claim 13, characterized in that, The control device further includes a processing unit, which is used to determine whether processing conditions are met, including: The processing unit is used to determine that the existing second disaster recovery channel between the first device and the second device is abnormal.

16. The device according to any one of claims 13-15, characterized in that, Before the sending unit sends the first message to the first device, The processing unit is also used to obtain channel parameters, which include a second source IP address and a second destination IP address, wherein the second source IP address and the second destination IP address are parameters of the second disaster recovery channel; The processing unit is further configured to generate the first source IP address and the first destination IP address based on the second source IP address and the second destination IP address.

17. A first device, characterized in that, The device includes a receiving unit and a processing unit. The receiving unit is used to receive a first message sent by the control device, the first message including a first source Internet Protocol IP address and a first destination IP address; The processing unit is used to establish a first disaster recovery channel with the second device based on the first source IP address and the first destination IP address. The first disaster recovery channel is a channel between the first device and the second device for data backup, and the first device and the second device are backups of each other.

18. The device according to claim 17, characterized in that, The first device further includes a sending unit, which is used before the receiving unit receives the first message sent by the control device. The sending unit is used to send a second message to the control device in response to the fulfillment of the processing conditions, wherein the second message is used to indicate that the second disaster recovery channel is abnormal, thereby triggering the control device to send the first message to the first device; The processing conditions include one or more of the following: the second disaster recovery channel is abnormal, or the packet loss rate of the first device exceeds a preset threshold; the second disaster recovery channel abnormality includes: the second disaster recovery channel fails to be established, the second disaster recovery channel is disconnected, or the performance of the second disaster recovery channel is abnormal.

19. The device according to claim 17 or 18, characterized in that, The processing unit is specifically configured to generate a first Transmission Control Protocol (TCP) connection message based on the first source IP address and the first destination IP address. The sending unit is further configured to send the first TCP connection message to the second device in a preset manner, thereby establishing the first disaster recovery channel. The preset manner includes one or more of the following: preset bandwidth, preset rate; or... The receiving unit is further configured to receive a second TCP connection message sent by the second device. The second TCP connection message includes a third source IP address and a third destination IP address. The processing unit is specifically configured to establish a TCP connection with the second device based on the fact that the third source IP address is the same as the first source IP address and the third destination IP address is the same as the first destination IP address, thereby establishing the first disaster recovery channel.

20. The device according to any one of claims 17-18, characterized in that, Before the processing unit establishes a first disaster recovery channel with the second device based on the first source IP address and the first destination IP address. The processing unit is further configured to update the second source IP address included in the target whitelist to the first source IP address and the second destination IP address included in the target whitelist to the first destination IP address based on the first source IP address and the first destination IP address, wherein the second source IP address corresponds to the second destination IP address.

Images