Method and apparatus for determining device status

Abstract

The present disclosure provides a method and device for determining device status, which are applied to a first distributed elastic device. The method comprises: sending a first distributed resource control protocol (DRCP) message to a second distributed elastic device at a predetermined sending period through an internal control link; and determining that the status of the second distributed elastic device is reachable according to status information in a first DRCP response if the first DRCP response sent by the second distributed elastic device is received within a first predetermined time.

Description

Technical Field

[0001] This disclosure relates to the field of communication technology, and in particular to a method and apparatus for determining the status of a device. Background Technology

[0002] DRNI (Distributed Resilient Network Interconnect) is a cross-device link aggregation technology that virtualizes two physical devices into one device at the aggregation level to achieve cross-device link aggregation, thereby providing device-level redundancy protection and traffic load balancing.

[0003] In a DR (Distributed Resilient) system, two devices can be configured as master and slave devices to share the load and forward traffic together. When the master device fails, traffic can be quickly switched to the slave device, ensuring the normal operation of services.

[0004] Once the master-slave roles are set up, the two devices can periodically send Keepalive messages through the Keepalive link to perform peer status checks. The frequent sending of Keepalive messages results in significant communication overhead for the devices. Summary of the Invention

[0005] In view of this, the present disclosure provides a method and apparatus for determining the status of a device, which can reduce the transmission of liveness detection messages and reduce communication consumption.

[0006] In a first aspect, this disclosure provides a method for determining the status of a device, applied to a first distributed elastic device, wherein an internal control link is established between the first distributed elastic device and a second distributed elastic device. The method includes: sending a first Distributed Aggregation Control Protocol (DRCP) message to the second distributed elastic device at a predetermined sending period through the internal control link, so that the second distributed elastic device sends a first DRCP response to the first distributed elastic device based on the first DRCP message, wherein the first DRCP message includes status information of the first distributed elastic device, and the first DRCP response includes status information of the second distributed elastic device; if the first DRCP response sent by the second distributed elastic device is received within a first predetermined time, then the status of the second distributed elastic device is determined to be reachable based on the status information in the first DRCP response.

[0007] Secondly, this disclosure provides an apparatus for determining device status, applied to a first distributed elastic device, wherein an internal control link is established between the first distributed elastic device and a second distributed elastic device. The apparatus includes: a first sending module, configured to send a first Distributed Aggregation Control Protocol (DRCP) message to the second distributed elastic device at a predetermined sending period via the internal control link, so that the second distributed elastic device sends a first DRCP response to the first distributed elastic device based on the first DRCP message, wherein the first DRCP message includes status information of the first distributed elastic device, and the first DRCP response includes status information of the second distributed elastic device; and a first determining module, configured to determine that the status of the second distributed elastic device is reachable based on the status information in the first DRCP response if the first DRCP response sent by the second distributed elastic device is received within a first predetermined time.

[0008] Thirdly, this disclosure provides a network device including a processor and a machine-readable storage medium storing machine-executable instructions that can be executed by the processor, the processor being prompted by the machine-executable instructions to perform the method provided in the first aspect of this disclosure.

[0009] Therefore, by applying the method and apparatus for determining device status provided in this disclosure, the status detection of the peer device can be achieved by periodically sending DRCP messages through the internal control link. This reduces the number of liveness detection messages sent and lowers communication overhead. Attached Figure Description

[0010] Figure 1 A schematic diagram of the system architecture provided for embodiments of this disclosure;

[0011] Figure 2 A flowchart illustrating a method for determining device status provided in an embodiment of this disclosure;

[0012] Figure 3 A schematic diagram illustrating a method for determining device status according to an embodiment of this disclosure;

[0013] Figure 4 A schematic diagram illustrating a method for determining device status according to an embodiment of this disclosure;

[0014] Figure 5 A structural diagram of a device for determining the state of a device provided in an embodiment of this disclosure;

[0015] Figure 6 The network device hardware structure provided in the embodiments of this disclosure. Detailed Implementation

[0016] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0017] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the corresponding listed items.

[0018] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0019] The following combination Figure 1 The system architecture of the methods and apparatus for determining device status that can be applied to embodiments of this specification will be described. It should be noted that... Figure 1 The examples shown are merely examples of system architectures that can be applied to the embodiments of this disclosure, in order to help those skilled in the art understand the technical content of this disclosure, but do not mean that the embodiments of this disclosure cannot be used in other devices, systems, environments or scenarios.

[0020] Figure 1 This is a schematic diagram of a system architecture illustrated in this specification according to an exemplary embodiment.

[0021] like Figure 1As shown, the system architecture can be a DR system, which may include, for example, DR devices Device A (DR1) and Device B (DR2). Device A and Device B are neighbors. Exemplarily, in this embodiment, Device A can be the primary device, and Device B can be the secondary device. Each DR device can have a DR interface (Distributed Relay interface) and an IPP (Intra-Portal Port).

[0022] The DR interface is a Layer 2 aggregation interface (BAGG) that connects to external devices. DR interfaces connected to the same aggregation group on an external device belong to the same DR group (Distributed-Relay group). For example, BAGG 1 on Device A and BAGG 2 on Device B belong to the same DR group. DR interfaces in a DR group can consist of multiple aggregated links and have the same DR group number.

[0023] An IPP (Internal Portal Link) is an interface used for internal control when connecting to neighboring DR (Direct Controller) devices. Each DR device can have only one IPP port. The link between IPPs is called an IPL (Intra-Portal Link), through which DR devices exchange protocol messages and transmit data traffic. A DR system can have only one IPL.

[0024] Device A and Device B can be connected to an IP network, and also to the BAGG of Device C. Device C can be a device connected to a server.

[0025] DRNI exchanges distributed aggregation information by running DRCP (Distributed Relay Control Protocol) on IPL to determine whether two devices can form a DR system. Devices running this protocol can exchange distributed aggregation information by sending DRCPDU (Distributed Relay Control Protocol Data Unit) to each other.

[0026] The two DR devices can periodically exchange DRCP messages via the IPL link. When the local DR device receives a DRCP negotiation message from the remote DR device, it will determine whether the DRNI system configuration in the DRCP negotiation message is the same as its own. If the DRNI system configurations of both ends are the same, then these two devices can form a DR system.

[0027] DR devices can detect the status of the peer device through the Keepalive link, that is, to perform dual master detection in case of IPL failure by exchanging Keepalive messages (i.e., liveness detection messages).

[0028] If the local DR device receives a Keepalive message from the remote DR device within the specified time:

[0029] If the IPL link status is down, the local and remote DR devices will elect a master and slave device based on the received Keepalive messages to ensure that only one DR device forwards traffic in the DR system and avoid both DR devices from being promoted to master devices.

[0030] If the IPL link status is up, the DR system is working normally.

[0031] If the local DR device does not receive a Keepalive message from the remote DR device within the specified time:

[0032] If the IPL link status is down, then the peer DR device is considered to be down.

[0033] When the local device is the master device, if there is a DR port in the up state on the local device, the local device remains the master device; otherwise, the local device role changes to None. When the device is in the None role, the device cannot send or receive Keepalive messages, and the Keepalive link is in the down state.

[0034] When the local device is a slave device, it is promoted to master device. Afterward, as long as there is an up DR port on the local device, it remains the master device; otherwise, the local device role changes to None. If the IPL link status is up, the Keepalive link status is considered down. At this time, both the master and slave devices operate normally, and the devices print log information to remind the user to check the Keepalive link.

[0035] The method for determining device status provided in the embodiments of this disclosure will now be described in detail. See also... Figure 2 , Figure 2This is a flowchart illustrating a method for determining device status according to an embodiment of this disclosure. The method is applied to distributed resilient devices, and the method for determining device status provided in this disclosure may include the following steps.

[0036] Step 210: Send the first Distributed Aggregation Control Protocol (DRCP) message to the second distributed elastic device through the internal control link at a predetermined sending period.

[0037] According to embodiments of this disclosure, the first distributed elastic device can be a local device, and the second distributed elastic device can be a corresponding peer device. The first and second distributed elastic devices can be neighbors. An internal control link can be established between the first and second distributed elastic devices.

[0038] According to embodiments of this disclosure, after receiving a first DRCP message, the second distributed resilient device can send a first DRCP response to the first distributed resilient device via an internal control link based on the first DRCP message. The first DRCP message may include status information of the first distributed resilient device, and the first DRCP response can be a response to the first DRCP message, for example, it may include status information of the second distributed resilient device. The status information can be used to indicate the device's status, and may include, for example, system MAC address, system number, device role, liveness detection message transmission period, role priority, and bridge MAC address.

[0039] According to embodiments of this disclosure, the predetermined transmission cycle can be set according to actual needs.

[0040] Step 220: Determine whether a first DRCP response sent by the second distributed elastic device is received within a first predetermined time. If a first DRCP response sent by the second distributed elastic device is received within the first predetermined time, proceed to step 230. If a first DRCP response sent by the second distributed elastic device is not received within the first predetermined time, proceed to step 240.

[0041] According to embodiments of this disclosure, the first predetermined time can be set according to actual needs.

[0042] Step 230: Based on the status information in the first DRCP response, determine that the status of the second distributed elastic device is reachable.

[0043] Step 240: Send a liveness detection message to the second distributed elastic device through the liveness detection link.

[0044] According to embodiments of this disclosure, a liveness detection link can be established between the first distributed resilient device and the second distributed resilient device for sending and receiving liveness detection messages.

[0045] According to embodiments of this disclosure, after receiving a liveness detection message, the second distributed elastic device can send a liveness response to the first distributed elastic device via a liveness detection link. The liveness detection message may, for example, include a keepalive message. The liveness response can be a response to the liveness detection message and may include the status information of the second distributed elastic device.

[0046] Step 250: Determine whether a liveness response from the second distributed elastic device is received within the second predetermined time. If a first DRCP response from the second distributed elastic device is received within the first predetermined time, proceed to step 260. If no liveness response from the second distributed elastic device is received within the second predetermined time, proceed to step 270.

[0047] According to embodiments of this disclosure, the second predetermined time can be set according to actual needs.

[0048] Step 260: Based on the status information in the survival response, determine that the status of the second distributed elastic device is reachable.

[0049] Step 270: Determine the status of the second distributed elastic device as unreachable.

[0050] In related technologies, two devices periodically send Keepalive messages through a Keepalive link to detect the status of the other end. The frequency of sending Keepalive messages results in a large communication overhead for the devices.

[0051] According to embodiments of this disclosure, the two distributed resilient devices can periodically send DRCP messages via an IPL link. The status of the peer device is detected through these periodically exchanged DRCP messages, and the status information transmitted by the Keepalive message can be obtained from the DRCP messages. If no DRCP message is received within a timeout period, a Keepalive message is sent to check the status of the peer device. This reduces the number of Keepalive message transmissions and lowers communication overhead.

[0052] Optionally, the status information may include at least one of the following: system MAC address, system number, device role, liveness detection message transmission period, role priority, and bridge MAC address. Based on this, for example, the DR device may also obtain at least one of its local system MAC address, system number, device role, liveness detection message transmission period, role priority, and bridge MAC address. The first DRCP message is determined based on at least one of the following: system MAC address, system number, device role, message transmission interval, role priority, and bridge MAC address.

[0053] For example, the status information can be shown in Table 1.

[0054]

[0055] Table 1

[0056] Optionally, when configuring the distributed elastic device, the sending period for liveness detection messages can be configured, i.e., the original sending period. Based on this, the distributed elastic device can obtain the original sending period for liveness detection messages and then set the scheduled sending period for DRCP messages to be consistent with the original sending period. Thus, periodically sending DRCP messages can replace periodically sending liveness detection messages. This reduces the sending of Keepalive messages and alleviates the communication overhead of the distributed elastic device.

[0057] Optionally, the second distributed elastic device may also send a DRCP message to the first distributed elastic device, wherein the second DRCP message includes the status information of the second distributed elastic device. Based on this, the first distributed elastic device can receive the second DRCP message sent by the second distributed elastic device. Then, based on the status information in the second DRCP message, it determines that the status of the second distributed elastic device is reachable, and sends a second DRCP response to the second distributed elastic device based on the second DRCP message, wherein the second DRCP response includes the status information of the first distributed elastic device.

[0058] The following is for reference. Figure 3 and Figure 4 The method for determining the device status shown above will be explained in conjunction with specific embodiments.

[0059] Figure 3 and Figure 4 This is a schematic diagram of a method for determining the state of a device according to an embodiment of this disclosure.

[0060] like Figure 3 and Figure 4 As shown, after Device A and Device B complete their DR system parameter configuration, the two devices periodically send DRCP messages through the IPL link. When the local device receives a DRCP message from the other end, it checks whether the DR system configuration in the DRCP message is the same as its own. If the DR system configurations of both ends are the same, then these two devices constitute a DR system.

[0061] After successful pairing, the two devices will determine their master-slave status. They will sequentially compare the initial roles, DRNIMAD DOWN status, device health values, role priorities, and bridge MAC addresses of the two DR devices, and the one with the better comparison result will become the master device. After master-slave negotiation, the DR devices will perform a configuration consistency check.

[0062] Once the master and slave roles are determined, both devices periodically send DRCP messages via the IPL link. These DRCP messages contain status information. If the local device receives a DRCP message from the peer device within a first predetermined time, it can determine that the peer device is reachable based on the status information in the DRCP message. If the DR device does not receive a DRCP message from the peer device within the first predetermined time, it can send a Keepalive message via the Keepalive link to check the peer device's status. If it receives a Keepalive message from the peer device within a second predetermined time, it can determine that the peer device is reachable. If it does not receive a Keepalive message from the peer device within the second predetermined time, it can determine that the peer device is unreachable.

[0063] In addition, the two devices will synchronize information from the other end in real time, such as MAC address entries and ARP entries. This way, the failure of any one device will not affect the forwarding of traffic and ensure that normal business is not interrupted.

[0064] According to embodiments of this disclosure, the status of the peer device is detected by periodically sending DRCP messages through the IPL link, which reduces the number of Keepalive messages sent and alleviates the communication overhead of the DR device.

[0065] Based on the same inventive concept, embodiments of this disclosure also provide an apparatus for determining the state of a device, corresponding to the method for determining the state of a device. See also Figure 5 , Figure 5 This is a structural diagram of a device for determining device status provided in an embodiment of this disclosure. The device is applied to a first distributed resilient device, and the device for determining device status may include:

[0066] The first sending module 510 is used to send a first distributed aggregation control protocol (DRCP) message to the second distributed elastic device through an internal control link at a predetermined sending period.

[0067] The first determining module 520 is configured to determine the status of the second distributed elastic device as reachable based on the status information in the first DRCP response if a first DRCP response sent by the second distributed elastic device is received within a first predetermined time.

[0068] Optionally, the means for determining the status of the equipment may further include:

[0069] The second sending module is used to send a liveness detection message to the second distributed elastic device through the liveness detection link if it does not receive the first DRCP response sent by the second distributed elastic device within a first predetermined time.

[0070] The second determining module is used to determine the status of the second distributed elastic device as reachable based on the status information in the survival response if a survival response sent by the second distributed elastic device is received within a second predetermined time.

[0071] The third determining module is used to determine that the state of the second distributed elastic device is unreachable if no liveness response is received from the second distributed elastic device within a second predetermined time.

[0072] Optionally, the status information of the first distributed resilient device includes at least one of the following: system MAC address, system number, device role, message transmission interval, role priority, and bridge MAC address. The means for determining the device status may further include:

[0073] The information acquisition module is used to acquire at least one of the following: system MAC, system number, device role, message transmission interval, role priority, and bridge MAC.

[0074] The message determination module is used to determine the first DRCP message based on at least one of the following: system MAC, system number, device role, message transmission interval, role priority, and bridge MAC.

[0075] Optionally, the means for determining the status of the equipment may further include:

[0076] The period acquisition module is used to acquire the original transmission period of the liveness detection message;

[0077] The period setting module is used to set the predetermined sending period to be consistent with the original sending period.

[0078] Optionally, the means for determining the status of the equipment may further include:

[0079] The receiving module is used to receive a second DRCP message sent by the second distributed elastic device, wherein the second DRCP message includes the status information of the second distributed elastic device;

[0080] The fourth determining module is used to determine the status of the second distributed elastic device as reachable based on the status information in the second DRCP message, and to send a second DRCP response to the second distributed elastic device based on the second DRCP message. The second DRCP response includes the status information of the first distributed elastic device.

[0081] By applying the device status determination apparatus provided in this disclosure, the status detection of the peer device can be achieved by periodically sending DRCP messages through the internal control link. This reduces the number of liveness detection messages sent and lowers communication overhead.

[0082] Based on the same inventive concept, this disclosure also provides a network device, such as... Figure 6As shown, the device includes a processor 610, a transceiver 620, and a machine-readable storage medium 630. The machine-readable storage medium 630 stores machine-executable instructions that can be executed by the processor 610. The processor 610 is prompted by the machine-executable instructions to execute the method for determining device state provided in the embodiments of this disclosure. (The foregoing...) Figure 4 , Figure 5 The device for determining the status of equipment shown can be employed as follows: Figure 6 The hardware structure of the network device shown is implemented.

[0083] The aforementioned computer-readable storage medium 630 may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the computer-readable storage medium 630 may also be at least one storage device located remotely from the aforementioned processor 610.

[0084] The processor 610 mentioned above can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0085] In this embodiment of the present disclosure, the processor 610 reads machine-executable instructions stored in the machine-readable storage medium 630, and is prompted by the machine-executable instructions to enable the processor 610 itself and the transceiver 620 to execute the method for determining the device state described in the foregoing embodiments of the present disclosure.

[0086] In addition, this disclosure provides a machine-readable storage medium 630 that stores machine-executable instructions. When called and executed by a processor 610, the machine-executable instructions cause the processor 610 itself and the transceiver 620 to execute the method for determining the device state described in the foregoing embodiments of this disclosure.

[0087] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0088] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and 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 modules can be selected to achieve the purpose of this disclosure according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0089] For the embodiments of the apparatus for determining the state of a device and the machine-readable storage medium, since the methods involved are basically similar to those in the aforementioned method embodiments, the description is relatively simple, and relevant details can be found in the descriptions of the method embodiments.

[0090] The above description is merely a preferred embodiment of this disclosure and is not intended to limit this disclosure. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for determining the status of equipment, characterized in that, The method is applied to a first distributed elastic device, wherein an internal control link and a liveness detection link are established between the first distributed elastic device and a second distributed elastic device, and the method includes: The first Distributed Aggregation Control Protocol (DRCP) message is sent to the second distributed elastic device through the internal control link at a predetermined sending period. If a first DRCP response is received from the second distributed elastic device within a first predetermined time, the status of the second distributed elastic device is determined to be reachable based on the status information in the first DRCP response. If the first DRCP response sent by the second distributed elastic device is not received within the first predetermined time, a liveness detection message is sent to the second distributed elastic device through the liveness detection link; If a liveness response is received from the second distributed elastic device within a second predetermined time, the status of the second distributed elastic device is determined to be reachable based on the status information in the liveness response. If no liveness response is received from the second distributed elastic device within the second predetermined time, the state of the second distributed elastic device is determined to be unreachable.

2. The method according to claim 1, characterized in that, The status information of the first distributed resilient device includes at least one of system MAC, system number, device role, message transmission interval, role priority, and bridge MAC; the method further includes: Obtain at least one of the following: system MAC, system number, device role, message transmission interval, role priority, and bridge MAC. The first DRCP message is determined based on at least one of the system MAC, the system number, the device role, the message transmission interval, the role priority, and the bridge MAC.

3. The method according to claim 1, characterized in that, The method further includes: Obtain the original transmission cycle of the liveness detection message; Set the predetermined sending period to be consistent with the original sending period.

4. The method according to claim 1, characterized in that, The method further includes: Receive a second DRCP message sent by the second distributed elastic device, wherein the second DRCP message includes the status information of the second distributed elastic device; Based on the status information in the second DRCP message, the status of the second distributed elastic device is determined to be reachable, and a second DRCP response is sent to the second distributed elastic device based on the second DRCP message. The second DRCP response includes the status information of the first distributed elastic device.

5. A device for determining the state of equipment, characterized in that, The device is applied to a first distributed elastic device, and an internal control link and a liveness detection link are established between the first distributed elastic device and a second distributed elastic device. The device includes: The first sending module is used to send a first distributed aggregation control protocol (DRCP) message to the second distributed elastic device at a predetermined sending period via an internal control link. The first determining module is configured to determine that the state of the second distributed elastic device is reachable based on the state information in the first DRCP response if a first DRCP response sent by the second distributed elastic device is received within a first predetermined time. The second sending module is configured to send a liveness detection message to the second distributed elastic device via a liveness detection link if it does not receive a first DRCP response from the second distributed elastic device within a first predetermined time, so that the second distributed elastic device can send a liveness response to the first distributed elastic device based on the liveness detection message, wherein the liveness response includes the status information of the second distributed elastic device. The second determining module is configured to determine that the state of the second distributed elastic device is reachable based on the state information in the survival response if a survival response sent by the second distributed elastic device is received within a second predetermined time. The third determining module is used to determine that the state of the second distributed elastic device is unreachable if no liveness response is received from the second distributed elastic device within a second predetermined time.

6. The apparatus according to claim 5, characterized in that, The status information of the first distributed resilient device includes at least one of system MAC, system number, device role, message transmission interval, role priority, and bridge MAC; the device further includes: The information acquisition module is used to acquire at least one of the following: system MAC, system number, device role, message transmission interval, role priority, and bridge MAC. The message determination module is used to determine the first DRCP message based on at least one of the system MAC, the system number, the device role, the message transmission interval, the role priority, and the bridge MAC.

7. The apparatus according to claim 5, characterized in that, The device further includes: The period acquisition module is used to acquire the original transmission period of the liveness detection message; The period setting module is used to set the predetermined transmission period to be consistent with the original transmission period.

8. The apparatus according to claim 5, characterized in that, The device further includes: The receiving module is configured to receive a second DRCP message sent by the second distributed elastic device, wherein the second DRCP message includes the status information of the second distributed elastic device; The fourth determining module is used to determine that the status of the second distributed elastic device is reachable based on the status information in the second DRCP message, and to send a second DRCP response to the second distributed elastic device based on the second DRCP message, wherein the second DRCP response includes the status information of the first distributed elastic device.

Images