Method and system for keeping ARP / NDP alive between devices in hot restart state

Abstract

The invention discloses an inter-device ARP / NDP keep-alive method and system in a hot restart state. The method comprises the steps that a first device executes a hot restart operation and writes the hot restart operation into a database; the lldq module subscribes and reads the hot restart state, constructs a first user-defined tlv according to the hot restart state, packages the first user-defined tlv to form a first lldq message, and sends the first lldq message to the second device through the direct connection port; after receiving the first custom tlv, the second device dynamically sets kernel parameters corresponding to the direct connection port according to the analyzed custom tlv content; after the first equipment completes hot restart, a second user-defined tlv is constructed by the lldq module, and after a second lldq message is formed through packaging, the second user-defined tlv is sent to neighbor second equipment through the direct connection port; and after the second device extracts the second custom tlv, the kernel parameter corresponding to the direct connection port is recovered to the initial value. According to the embodiment of the invention, through combination of a notification mechanism of an lldq protocol and dynamic adjustment of kernel parameters, the problem of traffic packet loss caused by aging of ARP / NDP during hot restart of equipment is solved.

Description

Technical Field

[0001] The present invention relates to the field of networks, and in particular, to a method, apparatus, and device for implementing a large-scale hybrid strategy. Background Art

[0002] In the management and maintenance of modern network devices, the warm-reboot operation of a device is a common maintenance measure used to maintain network continuity and stability when the network device is updated with configurations or upgraded with systems. When a device performs a warm-reboot, the forwarding table entries in the local chip are not deleted, and traffic forwarding is maintained. However, if the remaining aging time of ARP / NDP of the directly connected device is less than the time required for the local warm-reboot, during the warm-reboot period, when the ARP / NDP of the directly connected device is about to age, the ARP / NDP request packets sent will not be replied by the device performing the warm-reboot, resulting in the aging and deletion of ARP / NDP and causing packet loss during the warm-reboot period. Summary of the Invention

[0003] Aiming at the above problems, the purpose of the embodiments of the present invention is to provide a method and system for ARP / NDP keep-alive between devices in a warm-reboot state to improve the above problems.

[0004] The embodiments of the present invention provide a method for ARP / NDP keep-alive between devices in a warm-reboot state, which includes the following steps:

[0005] A first device performs a warm-reboot operation and writes the warm-reboot state into a database;

[0006] The lldq module of the first device subscribes to and reads the warm-reboot state in the database, constructs a first custom TLV containing warm-reboot start information according to the warm-reboot state, and after encapsulating the first custom TLV to form a first lldq packet, sends the first lldq packet to a second device that is a neighbor through a directly connected port;

[0007] The second device receives the first lldq packet, extracts the first custom TLV in the first lldq packet, and dynamically sets the kernel parameter delay_first_probe_time of the corresponding directly connected port according to the parsed custom TLV content;

[0008] When the first device completes the warm-reboot, the lldq module detects the end of the warm-reboot state, constructs a second custom TLV containing warm-reboot end information, and after encapsulating the second custom TLV to form a second lldq packet, sends the second lldq packet to the second device that is a neighbor through a directly connected port;

[0009] After receiving the second lldq message, the second device extracts the second custom tlv in the second lldq message, and then restores the kernel parameter delay_first_probe_time of the corresponding direct connection port to the initial value according to the content of the second custom tlv.

[0010] Preferably, the hot restart state is implemented by writing a specific identifier into the database. The identifier is generated by a hot restart command trigger and stored in the shared database of the device.

[0011] Preferably, the specific identifier is used to distinguish whether this restart is a hot restart or a normal restart.

[0012] Preferably, the structure of the custom tlv includes the organization code, subtype, length, and value field; the subtype field is used to represent the hot restart state, 1 represents the start of the hot restart, and 0 represents the end of the hot restart; the value field carries the specific delay_first_probe_time parameter value.

[0013] Preferably, the second device dynamically adjusts the kernel parameter delay_first_probe_time of the corresponding direct connection port by calling the operating system kernel interface.

[0014] Preferably, the dynamic adjustment includes reading the current parameter value, modifying the parameter value, and verifying the modification result.

[0015] Preferably, the lldq module periodically sends lldq messages containing hot restart status information at a preset time interval until the hot restart state ends.

[0016] An embodiment of the present invention also provides an ARP / NDP keep-alive system between devices in a hot restart state, which includes a first device and a second device; wherein:

[0017] The first device is used to perform a hot restart operation and write the hot restart state into the database;

[0018] The lldq module of the first device is used to subscribe to and read the hot restart state in the database, construct a first custom tlv containing hot restart start information according to the hot restart state, and after encapsulating the first lldq message according to the first custom tlv, send the first lldq message to the second device of the neighbor through the direct connection port;

[0019] The second device is used to receive the first lldq message, extract the first custom tlv in the first lldq message, and then dynamically set the kernel parameter delay_first_probe_time of the corresponding direct connection port according to the parsed custom tlv content;

[0020] The first device is further configured to, after completing a warm reboot, when its lldq module detects the end of the warm reboot state, construct a second custom tlv containing warm reboot end information, and after encapsulating the second custom tlv to form a second lldq message, send the second lldq message to the second device of the neighbor through a direct connection port;

[0021] The second device is further configured to receive the second lldq message, extract the second custom tlv in the second lldq message, and then restore the kernel parameter delay_first_probe_time of the corresponding direct connection port to its initial value according to the content of the second custom tlv.

[0022] This embodiment combines the notification mechanism of the lldq protocol with the dynamic adjustment of kernel parameters, solving the problem of traffic packet loss caused by ARP / NDP aging during the warm reboot of the device. This embodiment can quickly sense the warm reboot state of the directly connected device and make timely responses on the direct connection port to maintain its kernel state. This embodiment has the characteristics of strong generality and low implementation cost, is applicable to various network devices and scenarios, and provides a reliable guarantee for traffic forwarding during the warm reboot. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the technical solutions of the present invention, the accompanying drawings required for the embodiments will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0024] Figure 1 FIG. is a schematic flow chart of the ARP / NDP keep-alive method between devices in the warm reboot state provided by the first embodiment of the present invention.

[0025] Figure 2 FIG. is a schematic diagram of the working principle of the ARP / NDP keep-alive method between devices in the warm reboot state provided by the second embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0026] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only some of the embodiments of the present invention, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0027] Please refer to Figure 1, the first embodiment of the present invention provides a method for keeping ARP / NDP alive between devices in a hot restart state, which includes the following steps:

[0028] S101, the first device performs a hot restart operation and writes the hot restart state into the database.

[0029] S102, the lldq module of the first device subscribes to and reads the hot restart state in the database, constructs a first custom tlv containing hot restart start information according to the hot restart state, and after encapsulating the first lldq message according to the first custom tlv, sends the first lldq message to the second device of the neighbor through the direct connection port.

[0030] In this embodiment, the first device first executes the hot restart command; then writes warm-rebootflag (identifier) into the database, and this flag is used to enable the process to identify whether this restart is a hot restart or a normal restart before and after the restart.

[0031] In this embodiment, the lldp module of the first device subscribes to the hot restart state in the database and parses the current hot restart state when the hot restart state changes.

[0032] Specifically, when it is recognized that the current device has performed a hot restart, the lldp module constructs a first custom tlv containing hot restart information and encapsulates it into the first lldp message; then traverses the ports directly connected to the current device and sends the first lldp message. Among them, the specific content of the custom tlv includes:

[0033]

[0034] S103, the second device receives the first lldq message, extracts the first custom tlv in the first lldq message, and dynamically sets the kernel parameter delay_first_probe_time of the corresponding direct connection port according to the parsed custom tlv content.

[0035] In this embodiment, after receiving the first lldq message, the second device parses the first custom tlv to extract the warm-reboot state and the corresponding delay_first_probe_Time parameter value. The second device dynamically adjusts the kernel parameter delay_first_probe_time of the corresponding direct connection port according to the extracted parameter value, thereby extending the aging time of ARP / NDP. The adjustment of the kernel parameter is implemented by calling the operating system kernel interface, and the specific operations include reading the current parameter value, modifying the parameter value, and verifying the modification result.

[0036] S104. After the first device completes a warm reboot, when the lldq module detects the end of the warm reboot status, it constructs a second custom tlv containing the warm reboot end information, and after encapsulating it into a second lldq message according to the second custom tlv, it sends the second lldq message to the second device of the neighbor through a direct connection port;

[0037] S105. The second device receives the second lldq message, extracts the second custom tlv in the second lldq message, and then restores the kernel parameter delay_first_probe_time of the corresponding direct connection port to its initial value according to the content of the second custom tlv.

[0038] In this embodiment, after the lldq module of the first device detects the end of the warm reboot status, it constructs a second custom tlv containing the warm reboot end information, encapsulates it into a second lldq message and sends it to the second device through a direct connection port. After receiving the warm reboot end information, the second device restores the kernel parameter delay_first_probe_time of the corresponding direct connection port to its initial value to restore the normal aging mechanism. The restoration operation is also implemented by calling the operating system kernel interface, and the specific operations include reading the current parameter value, restoring the initial parameter value, and verifying the restoration result.

[0039] As can be seen from the above, this embodiment realizes the real-time perception and synchronization of the warm reboot status between devices through the lldq protocol, ensuring that the direct-connected devices can maintain their ARP / NDP status without aging during the warm reboot. As a link layer protocol, the lldq protocol has the characteristics of low overhead and high reliability, and is suitable for status notification and parameter synchronization between devices.

[0040] In particular, this embodiment realizes the precise control of the ARP / NDP aging time by dynamically adjusting the kernel parameter delay_first_probe_time. The adjustment range of the kernel parameter can be configured according to the actual network environment to meet the requirements in different scenarios. For example, in a scenario where the warm reboot time is long, delay_first_probe_time can be set to a larger value to ensure that ARP / NDP will not age during the warm reboot.

[0041] Furthermore, this embodiment realizes the efficient transmission of the warm reboot status information through the design of the custom tlv. The custom tlv has a simple structure and is easy to expand, can be compatible with the existing LLDP protocol stack, and at the same time supports the expansion of future functions.

[0042] In summary, in this embodiment, by combining the notification mechanism of the lldq protocol with the dynamic adjustment of kernel parameters, the problem of traffic packet loss caused by ARP / NDP aging during the hot restart of the device is solved. This embodiment can quickly sense the hot restart state of the directly connected device and make timely responses on the directly connected port to maintain its kernel state. This embodiment has the characteristics of strong versatility and low implementation cost, is applicable to various network devices and scenarios, and provides a reliable guarantee for traffic forwarding during hot restart.

[0043] The second embodiment of the present invention also provides a system for ARP / NDP keep-alive between devices in a hot restart state, which includes a first device and a second device; wherein:

[0044] The first device is used to perform a hot restart operation and write the hot restart state into the database;

[0045] The lldq module of the first device is used to subscribe to and read the hot restart state in the database, construct a first custom tlv containing hot restart start information according to the hot restart state, and after encapsulating the first custom tlv to form a first lldq message, send the first lldq message to the neighboring second device through the directly connected port;

[0046] The second device is used to receive the first lldq message, extract the first custom tlv in the first lldq message, and dynamically set the kernel parameter delay_first_probe_time of the corresponding directly connected port according to the parsed custom tlv content;

[0047] The first device is further used to, after completing the hot restart, when its lldq module detects the end of the hot restart state, construct a second custom tlv containing hot restart end information, and after encapsulating the second custom tlv to form a second lldq message, send the second lldq message to the neighboring second device through the directly connected port;

[0048] The second device is further used to receive the second lldq message, extract the second custom tlv in the second lldq message, and restore the kernel parameter delay_first_probe_time of the corresponding directly connected port to its initial value according to the second tlv content.

[0049] In several embodiments provided by the embodiments of the present invention, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device and method embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architectures, functions, and operations of devices, methods, and computer program products according to multiple embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code, and the module, program segment, or part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than marked in the accompanying drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and the combination of blocks in the block diagram and / or flowchart, can be implemented by a dedicated hardware-based system for performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0050] In addition, each functional module in various embodiments of the present invention may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

[0051] If the described functions are implemented in the form of software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of this 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 for causing a computer device (which may be a personal computer, an electronic device, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of the present invention. The aforementioned storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), magnetic disks, or optical discs that can store program codes. It should be noted that in this article, the term "including", "comprising", or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article, or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article, or device. Without further limitations, an element defined by the statement "including a..." does not exclude the existence of additional identical elements in the process, method, article, or device including the said element.

[0052] The terms used in the embodiments of the present invention are for the purpose of describing specific embodiments only and are not intended to limit the present invention. The singular forms "a", "the", and "said" used in the embodiments of the present invention and the appended claims are also intended to include the plural forms unless the context clearly dictates otherwise.

[0053] It should be understood that the term "and / or" used herein is merely a description of the associated relationship of the associated objects, indicating that three relationships may exist. For example, A and / or B may represent: the sole existence of A, the simultaneous existence of A and B, and the sole existence of B. In addition, the character " / " herein generally represents an "or" relationship between the associated objects before and after.

[0054] Depending on the context, the word "if" as used herein can be interpreted as "when" or "while" or "in response to determining" or "in response to detecting". Similarly, depending on the context, the phrase "if determined" or "if detected (stated condition or event)" can be interpreted as "when determined" or "in response to determining" or "when detected (stated condition or event)" or "in response to detecting (stated condition or event)".

[0055] The "first / second" mentioned in the embodiments is only to distinguish similar objects and does not represent a specific order for the objects. It can be understood that the "first / second" can be interchanged in a specific order or sequence when allowed. It should be understood that the objects distinguished by the "first / second" can be interchanged appropriately so that the embodiments described herein can be implemented in an order other than those illustrated or described herein.

[0056] The above is only the preferred embodiment of the present invention and is not used to limit the present invention. For those skilled in the art, various changes and modifications can be made to the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. A method for ARP / NDP keep-alive between devices in a hot restart state, characterized in that It includes the following steps: The first device performs a warm reboot operation and writes the warm reboot status to the database; The lldq module of the first device subscribes to and reads the warm reboot status in the database, constructs a first custom tlv containing warm reboot start information according to the warm reboot status, and after encapsulating the first custom tlv to form a first lldq message, sends the first lldq message to the second device of the neighbor through a direct connection port; The second device receives the first lldq message, extracts the first custom tlv in the first lldq message, and dynamically sets the kernel parameter delay_first_probe_time of the corresponding direct connection port according to the parsed custom tlv content; When the first device completes the warm reboot, the lldq module detects the end of the warm reboot status, constructs a second custom tlv containing warm reboot end information, and after encapsulating the second custom tlv to form a second lldq message, sends the second lldq message to the second device of the neighbor through a direct connection port; The second device receives the second lldq message, extracts the second custom tlv in the second lldq message, and restores the kernel parameter delay_first_probe_time of the corresponding direct connection port to the initial value according to the second custom tlv content.

2. The method for maintaining ARP / NDP alive between devices in the hot restart state as described in claim 1, wherein, The warm reboot status is realized by writing a specific identifier in the database. This identifier is generated by the warm reboot command trigger and stored in the shared database of the device.

3. The method for maintaining ARP / NDP between devices in the hot restart state according to claim 2, wherein The specific identifier is used to distinguish whether this reboot is a warm reboot or a normal reboot.

4. The method for maintaining ARP / NDP alive between devices in the hot restart state according to claim 1, wherein The structure of the custom tlv includes organization code, subtype, length, and value field; among them, the subtype field is used to represent the warm reboot status, 1 represents the start of the warm reboot, and 0 represents the end of the warm reboot; the value field carries the specific delay_first_probe_time parameter value.

5. The method for maintaining ARP / NDP alive between devices in the hot restart state according to claim 1, wherein The second device dynamically adjusts the kernel parameter delay_first_probe_time of the corresponding direct connection port by calling the operating system kernel interface.

6. The method for maintaining ARP / NDP between devices in the hot restart state according to claim 1, wherein The dynamic adjustment includes reading the current parameter value, modifying the parameter value, and verifying the modification result.

7. The method for maintaining ARP / NDP alive between devices in the hot restart state according to claim 1, wherein The lldq module periodically sends lldq messages containing warm reboot status information at a preset time interval until the warm reboot status ends.

8. An ARP / NDP keep-alive system between devices in a hot restart state, characterized in that, It includes the first device and the second device; where: The first device is used to perform a warm reboot operation and write the warm reboot status to the database; The lldq module of the first device is used to subscribe to and read the warm reboot status in the database, construct a first custom tlv containing warm reboot start information according to the warm reboot status, and after encapsulating the first custom tlv to form a first lldq message, send the first lldq message to the second device of the neighbor through a direct connection port; The second device is used to receive the first lldq message, extract the first custom tlv in the first lldq message, and dynamically set the kernel parameter delay_first_probe_time of the corresponding direct connection port according to the parsed custom tlv content; The first device is further configured to, after completing a warm restart, detect the end of the warm restart state by its lldq module, construct a second custom tlv containing warm restart end information, encapsulate the second custom tlv to form a second lldq message, and then send the second lldq message to the second device of the neighbor through a direct connection port; The second device is further configured to receive the second lldq message, extract the second custom tlv in the second lldq message, and restore the kernel parameter delay_first_probe_time of the corresponding direct connection port to the initial value according to the content of the second custom tlv.

Images