Method, device, medium and product for implementing primary and backup DHCP servers

Abstract

The embodiment of the application provides a method, device, medium and product for realizing master and backup of a DHCP server, which are applied to a first network device. The method comprises: in the case that the first network device takes over a master dynamic host configuration protocol (DHCP) service due to master and backup switching and does not have lease information of a second network device, performing a target operation, wherein the second network device is a device belonging to the same master and backup redundancy group as the first network device; the target operation comprises: establishing lease information corresponding to a first client according to lease address information in a renewal request message from the first client; and assigning a first target address to a second client according to a lease request message received from the second client, wherein the first target address is a determined address not occupied by any client. The embodiment of the application aims to improve the quality of the DHCP service.

Description

Technical Field

[0001] This application relates to the field of information processing technology, and in particular to a method, device, medium, and product for implementing DHCP server master / standby. Background Technology

[0002] In related technologies, there are generally two methods for achieving high availability of DHCP services: DHCP lease synchronization and separate address pooling. The DHCP lease synchronization method establishes a real-time or near-real-time communication channel between the primary and backup devices. When the primary device allocates or renews an IP address, it immediately synchronizes the lease information to the backup device. However, this method is complex and prone to synchronization failures, creating new points of failure. The separate address pooling method configures completely non-overlapping address pools on the primary and backup devices. After a switchover, clients need to release their old IP addresses and reacquire IP addresses from the new network segment, leading to service interruptions and disrupting business continuity. How to achieve high availability with primary / backup redundancy protection while maintaining business continuity is a pressing issue that needs to be discussed and resolved. Summary of the Invention

[0003] This application provides a method, device, medium, and product for implementing DHCP server primary and backup, aiming to achieve high availability primary and backup redundancy protection while maintaining business continuity.

[0004] In a first aspect, embodiments of this application provide a method for implementing a primary / backup DHCP server, applied to a first network device. The method includes: when the first network device takes over the primary Dynamic Host Configuration Protocol (DHCP) service due to a primary / backup switchover and does not have lease information for a second network device, performing a target operation, wherein the second network device is a device belonging to the same primary / backup redundancy group as the first network device; the target operation includes: establishing lease information corresponding to the first client based on lease address information in a lease renewal request message from a first client; and allocating a first target address to the second client based on a received lease request message from a second client, wherein the first target address is a determined address not occupied by any client.

[0005] In a second aspect, embodiments of this application provide a communication device, comprising: at least one processor; at least one memory for storing at least one program; and, when at least one of the programs is executed by at least one of the processors, implementing the method for implementing a primary / backup DHCP server as described in the first aspect.

[0006] Thirdly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions for performing the method for implementing a DHCP server master / slave as described in the first aspect.

[0007] Fourthly, embodiments of this application provide a computer program product, including a computer program or computer instructions, the computer program or computer instructions being stored in a computer-readable storage medium, a processor of a computer device reading the computer program or computer instructions from the computer-readable storage medium, and the processor executing the computer program or computer instructions to cause the computer device to perform the method for implementing a DHCP server primary / backup as described in the first aspect.

[0008] In this embodiment, after a primary / backup switchover, when the first network device takes over the DHCP service and does not have lease information for the original primary network device in the same primary / backup redundancy group, for the first client initiating a lease renewal request, the first network device establishes lease information based on the leased address information in the renewal request. This eliminates the need for prior synchronization of the lease database of the original primary network device, allowing the original first client to continue using its original address and avoiding service interruption caused by the client re-applying for an address. For the second client initiating the lease request message, a first target address not currently occupied by any client is assigned, thus allocating addresses to the newly added second client without lease synchronization and effectively avoiding the risk of conflicts between addresses assigned to new clients and addresses already occupied by clients with existing leases. Through the mechanism of rebuilding lease information for the first client and allocating addresses not currently occupied by any client for the second client, highly available DHCP primary / backup redundancy protection can be achieved without real-time lease synchronization between the primary and backup devices. This ensures the service continuity of existing clients while guaranteeing address security for new clients, improving the quality of the DHCP service.

[0009] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0010] Figure 1 A system architecture diagram provided for one embodiment of this application; Figure 2 A flowchart illustrating a method for implementing a primary / backup DHCP server according to an embodiment of this application; Figure 3 A schematic diagram of the system module architecture provided as an example of this application; Figure 4 A schematic diagram illustrating a three-segment address pool partitioning as an example of this application; Figure 5A schematic diagram illustrating the process of renewing the lease of the original client IP after a primary / standby switchover, as provided as an example in this application; Figure 6 A schematic diagram illustrating the process of assigning new client IPs after a primary / standby switchover, as provided as an example in this application; Figure 7 A flowchart illustrating the message interaction process for a newly added client to obtain an IP address, as provided in this application as an example; Figure 8 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0012] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0013] In the description of the embodiments of this application, unless otherwise expressly limited, terms such as setting, installing, and connecting should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in the embodiments of this application in combination with the specific content of the technical solution.

[0014] In this application, the terms "furthermore," "exemplarily," or "optionally" are used as examples, illustrations, or descriptions and should not be construed as being more preferred or advantageous than other embodiments or designs. The use of terms such as "furthermore," "exemplarily," or "optionally" is intended to present the relevant concepts in a specific manner.

[0015] Before providing a further detailed description of the embodiments of this application, the nouns and terms used in the embodiments of this application are explained, and the nouns and terms used in the embodiments of this application shall be interpreted as follows: DHCP (Dynamic Host Configuration Protocol) is a protocol used to automatically assign IP addresses and other network parameters to clients. DHCP service is a server program or device function that provides automatic IP address allocation, renewal, and release based on the DHCP protocol.

[0016] OLT (Optical Line Terminal): An access device located at the central office in a fiber optic access network, which aggregates and manages multiple optical network units.

[0017] ONU (Optical Network Unit): An optical network device located on the user side in an optical fiber access network, connecting the optical line terminal and the user terminal.

[0018] FTTR (Fiber to The Room): A broadband access solution that extends fiber optic cables to every room, achieving whole-house fiber optic coverage.

[0019] ICMP (Internet Control Message Protocol): A protocol used to transmit error and control messages in IP networks. The Ping command is based on this protocol to detect host reachability.

[0020] ARP (Address Resolution Protocol): A protocol that resolves IP addresses to their corresponding MAC addresses, used within a local area network to confirm whether an IP address has been used.

[0021] The technical solutions of this application embodiment can be applied to various FTTR (Fiber to the Room) network systems, such as: FTTR systems based on Passive Optical Network (PON) architecture, FTTR systems based on Ethernet protocol, all-optical home networks using Wavelength Division Multiplexing (WDM) technology, FTTR converged networking systems supporting Wi-Fi access, and distributed home networks where the main gateway and multiple slave gateways are cascaded via optical fiber or copper cable, etc.

[0022] The technical solutions of this application can be applied to various network element devices in an FTTR network, such as: FTTR main gateway (Main Optical Line Terminal, main OLT or main gateway), FTTR sub gateway (Sub Gateway, or Optical Network Unit, ONU), management devices in the Optical Distribution Network (ODN), and home routers or access points supporting the DHCP protocol, etc. This application does not limit the specific optical communication technology, transmission medium, or device form used in the FTTR network.

[0023] In related technologies, there are two main technical solutions for implementing DHCP server primary / backup redundancy protection in network devices: The first approach is the DHCP lease synchronization scheme. This scheme requires establishing a real-time or near-real-time communication channel between the primary and backup devices. When the primary device successfully assigns or renews an IP address for a client, it immediately encapsulates the lease information into a synchronization message and sends it to the backup device. Upon receiving the synchronization message, the backup device stores the lease information locally, thus maintaining a lease state nearly identical to that of the primary device. When the primary device fails, the backup device already possesses complete lease data and can take over the DHCP service, eliminating the need for clients to reapply for IP addresses. While the DHCP lease synchronization scheme does not cause service interruption, it requires designing additional synchronization protocols, data serialization, and conflict resolution mechanisms. It also needs to address issues such as inconsistencies in lease information and packet loss retransmission when synchronization fails between the primary and backup devices. Furthermore, in highly dynamic environments where clients frequently log on and off, synchronization operations continuously consume CPU processing power and network bandwidth.

[0024] The second approach is the separate address pool scheme. This scheme doesn't perform any lease synchronization; instead, it divides the total DHCP address pool into two completely non-overlapping parts, assigning them to a primary device and a backup device. During normal operation, only the primary device is assigned IPs from its address pool. When the primary / backup fails, the backup device takes over the DHCP service, but its address pool has a completely different range of IP addresses than the one previously assigned by the primary device. If an existing client attempts to renew its lease, it must release its original IP and re-initiate a lease request from the new device to obtain an IP from the new address pool. This process interrupts existing client connections, affecting service continuity. Furthermore, because the two address pools cannot overlap, the overall IP address resource utilization decreases, resulting in wasted address resources.

[0025] Based on this, embodiments of this application provide a method, device, medium, and product for implementing DHCP server primary / standby. After primary / standby failover, when the first network device takes over the DHCP service and does not have lease information for the original primary second network device in the same primary / standby redundancy group, for the first client initiating a lease renewal request, the first network device establishes lease information based on the leased address information in the renewal request. This eliminates the need to synchronize the lease database of the original primary second network device beforehand, allowing the original first client to continue using its original address and avoiding service interruption caused by the client re-applying for an address. For the second client initiating the lease request message, a first target address that is not currently occupied by any client is assigned to it. This allows for address allocation to the newly added second client without lease synchronization and effectively avoids the risk of conflicts between the address assigned to the new client and the address occupied by a client with an existing lease. By reconstructing lease renewal information for the first client and allocating addresses not occupied by any client for the second client, a highly available DHCP primary-backup redundancy protection mechanism is achieved between the primary and backup devices without real-time lease synchronization. This ensures the service continuity of existing clients while guaranteeing address security for new clients, thus improving the quality of DHCP service. The embodiments of this application will be further described below with reference to the accompanying drawings.

[0026] Figure 1 This is a system architecture diagram of an embodiment of this application. It includes a first network device 110, a second network device 120, a client 130, etc.

[0027] The first network device 110 refers to the network device that switches from standby status to take over the primary function of Dynamic Host Configuration Protocol (DHCP) service after a primary / standby switchover. For example, in FTTR or OLT products, the first network device can be a standby optical line terminal or a standby primary optical modem. The DHCP server on the first network device 110 can take over the DHCP service of each client 130 according to the primary / standby switchover event, and perform operations such as IP address allocation and lease renewal processing for the connected optical network units and terminal devices. Compared with the second network device 120, the DHCP server of the first network device 110 is in standby state during normal operation and does not participate in IP address allocation, but its address pool configuration is ready. The first network device 110 can be a high-performance computer, a cluster of multiple high-performance computers, an optical line terminal device, or a primary optical modem device in the operator's access room. The first network device 110 can also communicate with the second network device 120 and the client 130 via wired or wireless means to exchange data.

[0028] The second network device 120 refers to a network device belonging to the same primary / backup redundancy group as the first network device 110. Under normal circumstances, the DHCP server on the second network device 120 acts as the primary DHCP server. For example, in FTTR or OLT products, the second network device can be a primary optical line terminal or a primary optical modem. The second network device is responsible for daily tasks such as IP address allocation and lease management. The stability, security, and performance requirements of the second network device 120 are comparable to those of the first network device 110, and the two serve as backups for each other. There is no need to establish a lease database synchronization channel between the second network device 120 and the first network device 110; connectivity testing and primary / backup status negotiation are only performed through standard network protocols. The second network device 120 can communicate with the first network device 110 and the client 130 via wired or wireless means to exchange data.

[0029] Client 130 refers to a terminal device that requests or renews an IP address from a DHCP server and accesses the network. Client 130 can include two types: one is an existing client that obtained an IP address from the original primary network device 120 before the switchover and needs to continue using that IP address after the switchover by actively initiating a renewal request; the other is a new client that comes online after the switchover and needs to request a new IP address. Client 130 can take various forms, including desktop computers, laptops, mobile phones, tablets, optical network units, and smart home devices. In an FTTR scenario, client 130 can include an optical network unit connected to an optical line terminal or the main optical modem, as well as various user terminals connected to the optical network unit. Furthermore, client 130 can be a single device or a collection of multiple devices, such as multiple terminals connected through a home LAN sharing a single optical network unit for internet access. Client 130 can communicate with the first network device 110 or the second network device 120 via wired or wireless means to exchange data. For existing clients, after the primary / standby switchover, they rebuild the lease through a renewal interaction with the first network device 110, thereby maintaining business continuity; for new clients, they obtain a new IP address through a lease request interaction with the first network device 110.

[0030] In some examples, the method of implementing DHCP server master / slave in this application can be implemented by deploying a corresponding DHCP server module on the first network device 110, or by deploying a corresponding DHCP server module on the second network device 120 (when the second network device 120 is in the master state and takes over the DHCP service).

[0031] Figure 2This is a flowchart illustrating a method for implementing a primary / backup DHCP server according to an embodiment of this application. This method for implementing a primary / backup DHCP server can be applied, but is not limited to, to network devices that support primary / backup redundancy protection for DHCP services, or as... Figure 1 The first network device shown can be used for execution, or various embedded network devices such as enterprise-level switches, routers, wireless LAN controllers, carrier access equipment (optical line terminals, optical network units, main optical modems), FTTR (fiber to the room) master devices, etc. This method for implementing a primary / backup DHCP server is particularly suitable for scenarios requiring high availability DHCP service and high business continuity requirements, such as enterprise campus networks, carrier broadband access networks, smart home gateways, and industrial Ethernet switches. In this embodiment, the method for implementing a primary / backup DHCP server includes, but is not limited to: Step 210: If the first network device takes over the primary Dynamic Host Configuration Protocol (DHCP) service due to a primary / standby switchover and does not have lease information for the second network device, perform the target operation, wherein the second network device is a device that belongs to the same primary / standby redundancy group as the first network device. The target operations include: Based on the lease address information in the renewal request message from the first client, lease information corresponding to the first client is established; based on the lease request message received from the second client, the first target address is assigned to the second client, wherein the first target address is a determined address that is not occupied by any client.

[0032] In step 210, the first network device refers to the network device that switches from a standby state to take over the DHCP service after a primary / standby switchover. Primary / standby switchover refers to the process where the original primary device, in response to a fault event or switchover command that triggers the switchover, ceases to take over the DHCP service and becomes a standby device, with the standby device taking over its work. The second network device refers to another network device in the primary / standby redundancy group for the DHCP service, which forms a primary / standby redundancy group with the first network device. Before the primary / standby switchover, the second network device was the original primary device for the DHCP service (in this embodiment, all original primary devices refer to the second network device). After the primary / standby switchover, the first network device takes over the DHCP service. The first network device does not obtain the IP address lease database previously allocated by the second network device through the lease synchronization mechanism; that is, when taking over the DHCP service, the first network device's local lease database is empty or only contains its own historical records.

[0033] Target operation refers to the operation performed by the first network device after it takes over the primary DHCP service following a primary switchover, upon receiving different requests from different clients (such as the first client and the second client).

[0034] The first client refers to a client that has already been assigned an IP address and needs to continue using that IP address. The first client has already been assigned an IP address by the original primary device before sending the renewal request message. The renewal request message is a message sent by the client to the DHCP server according to the DHCP protocol when the lease period reaches a certain percentage, requesting an extension of the IP address's usage period. The renewal request message may include, but is not limited to, the leased address information currently used by the client initiating the renewal request. Lease information refers to the information related to the first client's lease created by the first network device in its local storage. Lease information may include, but is not limited to, client identifier, IP address, lease period, etc. For example, by establishing lease information based on the first client's renewal request, the first network device, after receiving renewal requests from all first clients whose addresses have been assigned by the original primary device, can restore all lease information of the original primary device on its own device. In other words, the first network device inherits all lease information of the original primary device in the above manner without needing to synchronize lease information with the original primary device, ensuring the service continuity of each first client.

[0035] The second client refers to a newly online client that has not yet been assigned an IP address after the primary / standby switchover is completed. A lease request message is a request message sent by the client to the DHCP server according to the DHCP protocol to request the allocation of an IP address. The first destination address refers to an IP address that the first network device has confirmed is not occupied by any client in the network. Since each client's IP address is unique, if an IP address is already occupied by an existing client (such as the first client whose IP address was assigned by the second network device before the primary / standby switchover), allocating that IP address to a newly added client will cause service interruption for the existing client. Because the first network device does not have lease information for the second network device, to avoid service interruption for the existing client, it is necessary to confirm whether the address to be allocated is occupied by another client before allocating an IP address. If the IP address is not occupied by any client, it will be allocated as the first destination address to the newly added second client. For example, the first destination address can be an address that is not occupied by a client within the entire IP network segment configured for the first network device; for example, address probing can be used to determine whether a specific IP address is occupied. The first target address can also be an IP address that has not been assigned in the IP network segment exclusively owned by the first network device in its DHCP address pool; or it can be an IP address that has not been assigned by the first network device itself in the IP network segment shared by the first network device and the second network device, or in other IP network segments, and has been determined by address conflict detection and other methods not to be occupied by any client.

[0036] After taking over the DHCP service, the first network device does not actively synchronize the lease database of the original primary network device (the second network device). Instead, it passively waits for a renewal request message initiated by the first client, which already has an assigned IP address. When the first network device receives the renewal request message from the first client, it extracts the lease address information currently used by the first client from the message and establishes the lease information for the first client. This allows the original client to continue communicating using its existing IP address without needing to reapply for one, avoiding service interruptions caused by the loss of lease information during primary / backup switchover, and eliminating the need for real-time synchronization of lease data between the primary and backup devices.

[0037] After taking over the DHCP service, the first network device receives a lease request message from the second client. When allocating an address to the second client, it confirms that an IP address is not currently occupied by any client and then assigns this IP address as the first target address to the second client. Because lease information is not synchronized before and after the switchover, the first network device lacks the lease information of the original primary device. The first network device cannot know which addresses in its DHCP address pool were allocated to other clients by the second network device before the switchover, and these clients may still be using their original IP addresses after the switchover. Directly allocating IP addresses could cause IP address conflicts with still active original clients. By determining IP address occupancy before allocation, the first network device can securely allocate IP addresses to newly connected clients without lease synchronization, avoiding service interruptions due to IP address conflicts with existing clients and ensuring the uniqueness of each client's IP address.

[0038] In the embodiment of step 210 above, after a primary / backup switchover, when the first network device takes over the DHCP service and does not have lease information for the original primary second network device under the same primary / backup redundancy group, for the first client initiating a lease renewal request, the first network device establishes lease information based on the leased address information in the renewal request. This eliminates the need for prior synchronization of the lease database of the original primary second network device, allowing the original first client to continue using its original address and avoiding service interruption caused by the client re-applying for an address. For the second client initiating the lease request message, address allocation is performed only after confirming that the first target address is not occupied by any client. This allows for address allocation to the newly added second client without lease synchronization and effectively avoids the risk of address conflicts between the new client and the address of an existing client with a lease. Through the mechanism of rebuilding lease information for the first client and allocating addresses to the second client that are not occupied by any client, highly available DHCP primary / backup redundancy protection can be achieved without real-time lease synchronization between the primary and backup devices. This ensures the service continuity of existing clients while also guaranteeing the address security of new clients, thus improving the quality of the DHCP service.

[0039] The above is a general description of step 210. The following is a detailed description of the specific implementation process of step 210.

[0040] In some embodiments, establishing lease information corresponding to the first client based on the lease address information in the lease renewal request message from the first client includes: determining whether the first client is a downstream device of the first network device; and if the first client is a downstream device of the first network device, establishing lease information corresponding to the first client based on the lease address information in the lease renewal request message.

[0041] In this context, a downstream device refers to a device that is directly or indirectly connected to the first network device and is located in the downstream network topology of the first network device. In FTTR or OLT products, a downstream device specifically refers to a downstream optical network unit. The first network device can determine whether a client belongs to its downstream network range by checking characteristics such as the receiving port of the lease renewal request message, the virtual LAN identifier in the message, the client's physical address, or the optical network unit identifier.

[0042] In this embodiment, the first network device does not indiscriminately rebuild leases for all received lease renewal request messages. Instead, it first determines whether the first client sending the lease renewal request message is a downstream device of the first network device itself to verify the legitimacy of the first client, thereby preventing lease renewal requests from illegal or non-downstream networks from occupying IP address resources. Only when the first client is confirmed to be a downstream device does the first network device perform lease information reconstruction. By restricting the permission to rebuild leases to downstream devices, it ensures that legitimate downstream clients can restore their leases without interruption after primary / standby switchover, while preventing illegal lease renewal requests from upstream or external networks. This enhances the security of DHCP services while ensuring client service continuity.

[0043] For example, in an FTTR network with multiple optical network units (first clients) connected to a single optical line terminal (first network device), after the primary optical line terminal fails, the backup optical line terminal takes over the DHCP service. When an optical network unit sends a lease renewal request message, the backup optical line terminal checks the port number receiving the message and finds it belongs to a downstream PON port. Therefore, it identifies the optical network unit as a downstream device and allows the lease to be re-established. If another device from the upstream network also sends a lease renewal request, the backup optical line terminal, finding that its receiving port does not belong to a downstream device, directly rejects the request.

[0044] In the above embodiments, after the first client is determined to be a downstream device, the lease information is reconstructed based on the lease address information in the lease renewal request message, so that only clients belonging to the downstream devices of the first network device can restore the lease through the lease renewal request, thereby preventing illegal lease renewal attacks from untrusted networks and improving the security of DHCP redundancy protection without affecting the continuity of the original services.

[0045] In some embodiments, establishing lease information corresponding to the first client based on the lease address information in the lease renewal request message from the first client includes: obtaining a first time difference, the first time difference being the time difference between the sending time of the lease renewal request message and the time of primary / standby switchover; and, if the first time difference is less than or equal to a preset time threshold, establishing lease information corresponding to the first client based on the lease address information in the lease renewal request message, wherein the preset time threshold is less than or equal to the lease period configured by the DHCP service.

[0046] The first time difference measures the time elapsed between the sending of the lease renewal request and the occurrence of the primary / standby switchover event. The sending time of the lease renewal request message can be either the timestamp of the first network device receiving the message or the timestamp of the second client sending the message. The time of primary / standby switchover refers to the system time at which the first network device confirms the switchover is complete and begins taking over the DHCP service. The preset time threshold is a pre-configured setting in the DHCP service used to limit the lease renewal duration for clients; this threshold is configured to be less than or equal to the lease period configured in the DHCP service. The lease period configured in the DHCP service refers to the effective usage time set for the IP address assigned to the client by the first network device during normal operation; the specific lease period value is specified in the DHCP server configuration.

[0047] Since the IP addresses assigned to all clients by the original primary device before the failover have fixed lease periods, the remaining time of any valid lease will not exceed this lease period. Therefore, setting the preset time threshold to be less than or equal to the lease period configured by the DHCP service means that as long as the interval between the sending time of the renewal request message and the completion time of the failover does not exceed one full lease period, the renewal request message of the first client may theoretically correspond to a valid lease assigned by the original primary device that has not yet expired. The first network device can receive the renewal request from the first client and establish lease information.

[0048] The first network device calculates the first time difference between the time the lease renewal request message is sent and the time of primary / standby failover. This first time difference reflects the length of time between the client initiating the lease renewal and the time the first network device begins taking over the DHCP service. If the first time difference exceeds the lease duration configured for the DHCP service under normal circumstances, it indicates that the client's lease may have expired or that the client's address was not assigned by the original primary device. By introducing the calculation of the time difference, the first network device can filter out clients that may indeed have originated from the original primary device and are still within their valid lease period.

[0049] When the first network device receives a lease renewal request message from the first client, it calculates the difference between the message's sending time and the time of primary / standby failover, obtaining a first time difference. Only when this first time difference does not exceed a preset time threshold does the first network device consider the first client's lease renewal request message legitimate. Based on the lease address information in the message, the first network device then establishes the corresponding lease information for the first client, thus ensuring the business continuity of legitimate clients. Simultaneously, this prevents the first network device from establishing leases for clients that are already offline or whose leases should be managed by other servers, thereby maintaining the accuracy of the lease database.

[0050] For example, the first network device records the time of primary / standby switchover completion internally. When a lease renewal request message is received, the first network device calculates the difference between the time the lease renewal request was sent and the time of primary / standby switchover completion, obtaining a first time difference. The first network device compares the first time difference with a preset time threshold. If the first time difference is less than or equal to the preset time threshold, the first network device performs lease information establishment, extracting lease address information from the lease renewal request message sent by the first client to reconstruct the lease information. If the first time difference is greater than the preset time threshold, the first network device refuses to establish lease information.

[0051] In the above embodiments, by introducing a time window verification and setting the threshold to be greater than or equal to the DHCP lease period, a time dimension restriction is added to the legality of lease renewal establishment. The first network device can filter out the original clients that were assigned IP addresses by the original primary device and are still within the valid lease period. This avoids the establishment of incorrect lease information due to accepting renewal requests from expired or illegal clients after the primary / standby switchover. At the same time, it ensures that the renewal requests of the original clients within the valid lease period can be accepted, thereby ensuring the business continuity of legitimate clients and improving the accuracy and security of lease information.

[0052] In some embodiments, the first network device corresponds to a first address partition exclusively for the first network device, and the second network device corresponds to a second address partition exclusively for the second network device. The first address partition and the second address partition do not overlap. Before assigning the first target address to the second client, the above-described method for implementing DHCP server primary and backup further includes: when receiving a lease request message sent by the second client and there is an available address in the first address partition, selecting an available address from the first address partition as the first target address. The available address represents an address that is not occupied by any client.

[0053] The first address partition refers to a range of contiguous or non-contiguous IP addresses allocated from the total IP network segment. This partition is exclusively reserved for the first network device, providing it with a DHCP address pool that can be directly allocated without needing to synchronize lease information with the second network device or perform address conflict detection after a failover. This allows for rapid response to lease requests from new clients. The total IP network segment refers to the complete range of IP addresses managed by the DHCP server. The second address partition is another range of IP addresses allocated from the same total IP network segment as the first partition, exclusively reserved for the second network device (i.e., the primary device before the failover). Available addresses are the unassigned IP addresses in the first address partition that have not yet been allocated to other clients.

[0054] The first and second address partitions do not overlap, meaning there is no intersection between the IP address ranges of the first and second address partitions. In other words, no IP address in the first address partition belongs to the second address partition, and vice versa. The first and second address partitions together constitute two mutually exclusive subsets of the total IP network segment. They can occupy either end of the total network segment or any other location; no specific restrictions are placed here. Address partitioning is a logical division of the total IP network segment, and each address partition is a subset of the total IP network segment.

[0055] The total IP address range for the DHCP service is pre-divided into two non-overlapping address partitions, one for the first network device and one for the second network device. Since the first and second address partitions do not overlap in their IP address ranges, the second network device does not assign IP addresses belonging to the first address partition during normal operation. Therefore, when a failover occurs and the first network device takes over the DHCP service, upon receiving a lease request message from the second client, the first network device checks if there are any unused IP addresses in the first address partition. If so, it selects one as the first target address and assigns it to the second client. Because there may be clients in the second address partition with already assigned IP addresses still within their lease periods, and because the first and second address partitions do not overlap, the first network device will not reallocate IP addresses for existing clients, nor will it assign IP addresses from the second address partition to the second client, thus ensuring that the original client's service connection is not interrupted. Meanwhile, since the first network device can know the IP addresses in the first address partition that may have been previously allocated by itself or recovered through lease renewal, the available addresses selected in the first address partition can be determined to be unoccupied, and no additional address conflict detection is required.

[0056] In the above embodiments, by pre-dividing exclusive address partitions that do not overlap between primary and backup network devices, the first network device does not need to synchronize leases with the second network device. When there are still available addresses in the first address partition exclusively occupied by the first network device, the first network device does not need to perform any address conflict detection and can directly allocate available IP addresses to the newly added second client in the first address partition. This avoids IP address conflicts with the original clients corresponding to other address partitions. Under the premise of ensuring that the service connection of the original clients is not interrupted, the efficiency of IP address allocation after primary and backup switchover is improved.

[0057] In some embodiments, the first network device corresponds to a first address partition exclusively for the first network device, the second network device corresponds to a second address partition exclusively for the second network device, and the first network device also corresponds to a public reserved address partition shared with the second network device. The public reserved address partition, the first address partition, and the second address partition do not overlap. Before allocating the first target address to the second client, the above-described method for implementing DHCP server primary / backup further includes: when a lease request message from the second client is received and there is no available address in the first address partition, selecting an available address from the available addresses in the public reserved address partition as the first target address. The available address represents an address that is not occupied by any client.

[0058] The public reserved address partition refers to a range of IP addresses allocated from the total IP network segment. This partition is configured in the DHCP address pools of both the first and second network devices, meaning both can use IP addresses from the public reserved address partition after taking over DHCP services. The public reserved address partition, the first address partition, and the second address partition do not overlap, meaning each IP address in the public reserved address partition does not belong to either the first or second address partition; they are all independent address sets within the same total IP network segment. "No available addresses in the first address partition" means all IP addresses in the first address partition have been allocated to other clients, leaving no remaining available IP addresses. The public reserved address partition provides the first network device with a spare range of IP addresses, thereby expanding its available IP address capacity.

[0059] When the first network device receives a lease request message from the second client, it prioritizes IP address allocation from the first address partition. If there are no available addresses in the first address partition that are not occupied by any client, it selects an available address that is not occupied by any client from the public reserved address partition as the first target address and allocates the first target address to the second client.

[0060] In the above embodiments, by setting up a public reserved address partition as a shared backup address pool between primary and backup devices, address depletion that might result from the limited IP address capacity of the exclusive address partition is avoided. When the first address partition is not exhausted, the first network device can quickly allocate IP addresses in response to lease requests from new clients. After the first address partition is exhausted, the first network device can still utilize the public reserved address partition to continue providing IP addresses to new clients. While maintaining the advantage of rapid allocation from the exclusive partition, the public reserved address partition provides capacity expansion capabilities for IP address resources.

[0061] In some embodiments, the first network device corresponds to a first address partition exclusively for the first network device, the second network device corresponds to a second address partition exclusively for the second network device, and the first network device also corresponds to a public reserved address partition shared with the second network device. The public reserved address partition, the first address partition, and the second address partition do not overlap. The above method for implementing DHCP server primary and backup further includes: when a lease request message from a second client is received and an address is allocated to the second client in the public reserved address partition, a first target address is allocated to the second client. The first target address is an address in the public reserved address partition that is not occupied by any client after address conflict detection.

[0062] In some embodiments, selecting an available address as the first target address from the available addresses in the public reserved address partition includes: selecting a first candidate address from the public reserved address partition and performing address conflict detection on the first candidate address, wherein the first candidate address is an address that has not been allocated by the first network device; and determining the first candidate address as the first target address if it is determined based on the address conflict detection that the first candidate address is not occupied by any client.

[0063] Here, the first candidate address refers to an IP address in the public reserved address partition that has not been allocated by the first network device. For example, an address not allocated by the first network device is one that has not been allocated by either the first or second network device; an address not allocated by the first network device is one that has not been allocated by the first network device but has been allocated by the second network device. An address allocated by the first network device can also be an address that was determined to have been allocated by the second network device during the allocation process by the first network device.

[0064] Address conflict detection refers to the process of identifying IP addresses in a publicly reserved address partition that are not occupied by any client. For example, before officially allocating a first candidate address, a first network device may proactively send a network probe request based on the first candidate address and wait for a response from the first candidate address to perform address conflict detection, thereby determining whether the first candidate address is occupied by another client.

[0065] Since the public reserved address partition can also be allocated by the second network device, before the primary / standby switchover, the second network device may have already allocated some IP addresses in the public reserved address partition to other clients, and these clients may still be online and using these IP addresses after the switchover. If allocation is done directly without conflict detection, there is a risk that the IP addresses already allocated to the original clients by the second network device will be reassigned to the second client sending the lease request message, causing IP address conflicts and resulting in service interruption for the original clients. Instead of directly allocating the first candidate address from the public reserved address partition to the second client, the first network device first actively checks for address conflicts to determine if the first candidate address is currently occupied by another client. If it is confirmed that the first candidate address is not occupied, the first network device sets the first candidate address as the first target address and allocates it to the second client. By using address conflict detection, the first network device identifies addresses that were not allocated by itself but have been allocated by the second network device (i.e., addresses already occupied by clients), skips these addresses during allocation, avoids address conflicts, and thus achieves synchronization-free primary / standby redundancy.

[0066] In the above embodiments, by performing address conflict detection on each client before allocating the first candidate address that the first network device has not allocated in the public reserved address partition, the actual occupancy status of the first candidate address in the current network can be obtained without relying on lease synchronization. This avoids the IP conflict risk caused by the lack of lease synchronization after the public reserved address partition is switched over from the primary to the backup device. Thus, without the need for lease synchronization between the primary and backup devices, the IP address capacity is expanded while ensuring the service continuity of the original clients.

[0067] In some embodiments, after performing address conflict detection on the first candidate address, the above method for implementing DHCP server primary / backup further includes: if it is determined based on address conflict detection that the first candidate address is occupied, marking the first candidate address as conflicted, wherein the conflicted state is used to indicate that the marked address is an address already occupied by a client; proceeding to the step of selecting a first candidate address from the public reserved address partition and performing address conflict detection on the first candidate address.

[0068] In this context, a conflict state refers to a conflict marker set by the first network device in its local record for an occupied IP address in the public reserved address partition. This marker is used to skip the address during subsequent allocations, avoiding repeated address conflict detection. To adapt to network changes, the conflict marker can have an expiration period, after which it is automatically cleared, allowing for re-detection of address conflicts. For example, the expiration period of the conflict marker can be set to the lease period configured in the DHCP service.

[0069] In some embodiments, selecting a first candidate address from a public reserved address partition includes: selecting a first candidate address from addresses in the public reserved address partition that are not marked as conflicting.

[0070] When the first network device performs address conflict detection on the first candidate address and finds that the first candidate address has already been occupied by another client, the first network device marks it as conflicted. Since this occupied first candidate address has been marked as conflicted, the first network device selects a new IP address from the public reserved address partition that has not been marked as conflicted as a new first candidate address, and reuses the newly selected first candidate address for address conflict detection until an IP address that has not been occupied by another client is found. This IP address that has not been occupied by another client is then used as the first destination address and assigned to the second client.

[0071] If other new clients subsequently request IP address allocation, the first network device can directly skip IP addresses marked as conflicting when selecting candidate IP addresses from the public reserved address partition again. This avoids repeatedly checking IP addresses that have already been confirmed to be occupied by other clients through conflict detection. Simultaneously, conflict marking allows the first network device to gradually accumulate knowledge of IP address occupancy in the public reserved address partition, supplementing any missing lease information caused by the lack of lease synchronization.

[0072] In the above embodiments, by using conflict status marking and address conflict detection, the first network device can avoid already occupied IP addresses and avoid repeatedly probing the same conflicting address, thereby improving the overall efficiency of subsequent IP address allocation. Simultaneously, as IP address conflict status markings accumulate in the address partition, lease information that has not been synchronized is gradually improved, further enhancing the efficiency of IP address allocation.

[0073] In some embodiments, before selecting an available address from the available addresses in the public reserved address partition as the first target address, the above-described method for implementing DHCP server primary / backup further includes: after primary / backup switchover, performing address conflict detection on all addresses in the public reserved address partition one by one to determine the occupancy status of each address in the public reserved address partition; marking addresses whose occupancy status indicates that they are occupied by clients as conflict states, where the conflict state is used to indicate that the marked address is an address that has been occupied by a client.

[0074] In this design, the first network device does not wait until it receives a lease request from the second client to perform address conflict detection on each IP address in the public reserved address partition. Instead, it proactively performs a comprehensive full-scale address conflict detection on all addresses in the public reserved address partition after taking over the DHCP service. By performing a full-scale address conflict detection on all IP addresses in the public reserved address partition after taking over the DHCP service, the first network device can determine which IP addresses in the entire public reserved address partition have already been assigned to clients and mark the assigned IP addresses as conflicted. Through this one-time full-scale address conflict detection, the first network device can know in advance which IP addresses in the entire public reserved partition have been occupied by clients assigned by the original primary device, thus preparing for rapid allocation subsequently.

[0075] In the above embodiments, by actively pre-probing all addresses, the conflict detection of IP addresses in the public reserved address partition is changed from being performed in real time on demand to being completed in advance all at once. This avoids the delay in conflict detection when allocating public reserved IP addresses, making the allocation efficiency of the public reserved address partition close to that of the exclusive address partition, while retaining the capacity expansion capability of the public reserved address partition.

[0076] In some embodiments, selecting an available address as a first target address from available addresses in a public reserved address partition includes: selecting a first candidate address as a first target address from first candidate addresses in a public reserved address partition that are not marked as conflicting, wherein the first candidate address is an address that has not been allocated by the first network device.

[0077] Specifically, when the first network device receives a lease request message from the second client and there is no available IP address in the first address partition, the first network device can directly determine the first candidate address from the public reserved address partition that has not been allocated by the first network device and has not been marked as conflicting, and allocate the first candidate address as the first target address to the second client. There is no need to perform real-time address detection when receiving the lease request message, thereby reducing the client's IP address allocation delay and achieving a fast response almost the same as that of exclusive address partition allocation.

[0078] In the above embodiments, by directly selecting the first target address from the addresses that are not marked as conflicting, the delay in the allocation of the public reserved partition is reduced, so that the allocation efficiency of the public reserved address partition is the same as that of the exclusive partition, while retaining the capacity expansion capability of the public reserved partition.

[0079] In some embodiments, the step of performing address conflict detection includes: sending a target probe message carrying the address to be detected, wherein the address to be detected is an address selected from a public reserved address partition that needs to be detected for address conflict; and determining, in response to receiving a response message corresponding to the target probe message, that the address to be detected is an address occupied by a client.

[0080] The address to be detected refers to an IP address selected from the public reserved address partition that needs to be verified for its availability. A target probe message is a network protocol message used for address conflict detection, such as an ICMP Ping or ARP request message. The purpose of sending a target probe message is to trigger a response from a client using the address to be detected. A response message is a client's reply to the target probe message, such as an ICMP Echo Reply or ARP Reply. Receiving a response message indicates that a device on the network is using the address to be detected.

[0081] When address conflict detection is required for an address to be detected, the first network device constructs and sends a target probe packet to the address to be detected. If the first network device receives a response packet for the target probe packet within the timeout period, it indicates that an active client is indeed using the address to be detected in the network. Therefore, the first network device can determine that the address to be detected is an IP address already occupied by another client, and will not allocate this occupied address in the future, marking this occupied address as conflicted.

[0082] In the above embodiments, by sending a target probe message to the address to be detected and waiting for a response, it is determined whether the address to be detected is occupied by other clients. In this way, it can be determined whether the address to be detected can be directly assigned to a client, so that IP conflicts can still be effectively avoided even when there is no need for lease synchronization between the primary and backup devices.

[0083] The following examples provide a comprehensive and detailed description of the method for implementing a primary and backup DHCP server according to this application. It is understood that the following embodiments are merely illustrative examples to better illustrate the method for implementing a primary and backup DHCP server according to this application, and are not intended to be specific or limiting.

[0084] Example 1: For example, Figure 3 This diagram illustrates the system module architecture for implementing a DHCP server primary / standby method as an example of this application. The system implementing the DHCP server primary / standby method of this application includes a primary device and a standby device. For example... Figure 3As shown, each network device integrates a DHCP server module. The DHCP server module consists of five functional sub-modules that work together to achieve lease renewal information establishment, address allocation, and conflict detection after primary / standby failover: The address pool management submodule is responsible for maintaining the address partition information configured on the DHCP server, which may include, but is not limited to, the first address partition, the second address partition, and the public reserved address partition. Upon receiving a request message from a client, the address pool management submodule manages the IP addresses within the address partitions according to the priority order of address allocation.

[0085] The allocation strategy control submodule is responsible for determining the source of IP addresses for allocation. Upon receiving a lease request message from a new client, the allocation strategy control submodule instructs the address pool management submodule to prioritize selecting an available IP address from the first address partition; if no available IP addresses are available in the first address partition, it instructs the selection of a candidate IP address from the public reserved address partition. After selecting a candidate IP address from the public reserved address partition, the allocation strategy control submodule calls the conflict detection submodule to perform address conflict detection and decides whether to allocate the candidate IP address to the new client based on the result of the address conflict detection.

[0086] The conflict detection submodule is responsible for detecting conflicts in candidate IP addresses to determine whether they are already occupied by other clients under the DHCP server. It supports multiple network probing methods, including sending ICMP (Internet Control Message Protocol) echo request messages or ARP (Address Resolution Protocol) request messages. Based on the response, it determines whether the candidate IP address is occupied. If occupied, it marks the candidate IP address as conflicted and records the timestamp and validity period. For example, the validity period can be set to the lease period configured by the DHCP service. The conflict detection submodule also supports batch pre-probing of public reserved address partitions. This involves actively traversing the entire address partition's IP addresses after system startup or primary / standby failover and pre-marking all occupied IP addresses as conflicted.

[0087] The lease renewal policy control submodule is responsible for processing lease renewal request messages from existing clients and establishing lease information. Upon receiving a lease renewal request message, the submodule extracts the leased address information from the message and reconstructs the existing client's lease information in the lease database. Before establishing the lease information, the submodule can perform optional checks, such as determining whether the first client is a downstream device of the current network device, or calculating whether the difference between the lease renewal request message's sending time and the primary / standby switchover time is less than or equal to a preset time threshold (such as the lease period configured in the DHCP service). Lease establishment is only allowed if the checks pass.

[0088] The standard DHCP protocol processing submodule is responsible for parsing and responding to messages such as DHCPDISCOVER (lease request message) and DHCP REQUEST (lease renewal request message) sent by clients in accordance with the standard DHCP protocol.

[0089] In the example above, each submodule runs together in the DHCP server module. When taking over the DHCP service after a primary / standby switch, there is no need to synchronize the lease database with the original primary network device. The high-availability DHCP service without lease synchronization can be achieved by relying solely on local address partitioning configuration, lease renewal reconstruction, and proactive conflict detection.

[0090] Example 2: For example, the method for implementing a primary / backup DHCP server according to this application can be deployed in a primary / backup redundancy group of the DHCP service, which consists of a first network device and a second network device. The first network device and the second network device act as two gateways in the same broadcast domain, serving all clients under the same IP network segment.

[0091] This example divides the workflow for implementing a lease-free, highly available DHCP service into three phases: address pool planning and configuration, normal operation, and failover and takeover. Specifically, it includes: Phase 1: Address pool planning and configuration.

[0092] The total available IP address range of an IP network segment is logically divided into three address partitions: the first address partition, the second address partition, and the public reserved address partition. The first address partition is an IP address range exclusively reserved for the first network device and configured in its DHCP address pool, but not in the address pool of the second network device. The second address partition is another IP address range within the same IP network segment, exclusively reserved for the second network device and configured in its DHCP address pool, but not in the DHCP address pool of the first network device. The first and second address partitions do not overlap. The public reserved address partition is an IP address range configured in the DHCP address pools of both the first and second network devices, meaning both devices can use IP addresses from the public reserved address partition under specific conditions. The public reserved address partition does not overlap with either the first or second address partition.

[0093] For example, Figure 4 This is a schematic diagram illustrating a three-segment address pool partitioning as an example of this application. For example... Figure 4 As shown, taking the IP network segment 192.168.1.0 / 24 (254 available addresses) as an example, assuming that the total number of IP addresses required by clients connected to the network device where the DHCP server is located is 150, the total available IP network segment is `192.168.1.0 / 24` (excluding network addresses and broadcast addresses, there are actually 254 available addresses). This can be divided into three address partitions, specifically: First address partition (exclusively used by the first network device): 192.168.1.10-192.168.1.59 (50 IPs in total); Second address partition (exclusively used by the second network device): 192.168.1.160-192.168.1.209 (50 IPs in total); Public reserved address partition: 192.168.1.60-192.168.1.159 (100 IPs in total). Both the first and second network devices have DHCP address pools configured with a first address partition, a second address partition, and a public reserved address partition. During normal operation, the first network device is in standby mode and does not participate in address allocation. When the second network device acts as the primary device, it allocates IP addresses from the second address partition and the public reserved address partition. After a switchover, the first network device takes over the DHCP service and allocates IP addresses to new clients from the first address partition and the public reserved address partition.

[0094] Phase Two: Normal Work Phase.

[0095] The second network device acts as the primary DHCP server, allocating IP addresses to clients from the second address partition and the public reserved address partition. The DHCP server process of the first network device is in a standby state, but the first address partition and the public reserved address partition of the first network device are already ready and do not participate in address allocation. In the second phase, the lease information for allocating IP addresses to clients is only stored locally on the second network device; no lease synchronization operation is performed between the first and second network devices.

[0096] Phase Three: The Reshuffle and Takeover Phase.

[0097] When the second network device fails or needs to be switched over, the first network device takes over as the primary DHCP server. After taking over the DHCP service, the first network device can manage the addresses of existing and new clients within the same IP segment, specifically including: a. Existing clients: Existing clients refer to clients that obtained IP addresses from the second network device before the primary / standby switchover (i.e., the first client), and continue to use their original IP addresses for communication.

[0098] For example, Figure 5 This is a schematic diagram illustrating the process of renewing the lease of the original client IP after a primary / standby switchover, as provided as an example in this application. Figure 5 As shown, assuming Figure 5 The primary server corresponds to the second network device, and the standby device corresponds to the first network device. After a primary / standby switchover, when the first client's lease reaches 50% of its validity, the first client first sends a renewal request message (DHCP REQUEST) to the original DHCP server. The destination IP address of this renewal request message points to the DHCP server. In the primary / standby redundancy group, both the primary and standby devices provide one IP address pointing to the DHCP server, and this IP address is used to redirect messages sent by clients to the DHCP server to the current primary device. For example, before the switchover, this IP address pointed to the original primary second network device; after the switchover, this IP address will point back to the primary network device, which has now been converted to the primary state.

[0099] In some cases, such as Figure 5As shown, after the primary / standby switchover, the first network device (standby device) takes over the primary function. Therefore, the DHCP request sent by the first client to the DHCP server will be received by the DHCP server on the first network device. When the DHCP server on the first network device receives the DHCP request, it usually allows the lease renewal by default, replies with a DHCP ACK message to the first client, and extracts the lease address information of the first client from the lease renewal request message (which may include, but is not limited to, IP address, MAC address, lease period, etc.). It then reconstructs the lease information of the first client in the local lease database of the first network device.

[0100] In other cases, such as Figure 5 As shown, if the primary / standby switchover is not complete, or if the first network device has not fully taken over the primary function, the DHCP REQUEST sent by the first client will not receive a corresponding response message, or the client will receive a rejection message. In this case, the first client will broadcast a renewal request message (DHCP REQUEST) when the lease period reaches 87.5% after the server does not respond or rejects the request.

[0101] like Figure 5 As shown, any server can be the first network device after taking over the primary server, or it can be the original server, specifically as in cases one and two below: In scenario one, after the first client broadcasts a renewal request message (DHCP REQUEST), the first network device, which has now taken over the primary function, will perform the aforementioned renewal processing and rebuild the lease information based on the received broadcast DHCP REQUEST, and reply to the first client with a DHCP ACK. The first client successfully renews the lease, and the lease period is reset. Scenario 2: After the first client broadcasts a renewal request message (DHCP REQUEST), while the first client is waiting for the lease period to reach 87.5%, the original server takes over the primary function again. In this case, the original server renews the lease for the first client based on the received broadcast DHCPREQUEST and replies with a DHCP ACK to the first client. The first client successfully renews the lease, and the lease period is reset.

[0102] If the first client still does not receive a response to the broadcast renewal request message, it is determined that the lease has expired and the IP address has been reclaimed. At this time, the first client's address changes to 169.254.xx (i.e., DHCP error), or it resends DHCPDISCOVER.

[0103] For example, to enhance security, a security check on the first client can be performed before allowing a lease renewal request. This check determines whether the first client sending the lease renewal request message is a downstream device of the first network device. If the first client is not a downstream device of the first network device, the lease renewal request can be rejected. For example, for OLT or FTTR devices, it checks whether the lease renewal request message originates from a downstream ONU (Optical Network Unit). If the client sending the lease renewal request is determined to be a non-downstream device, the lease renewal request can be rejected. Alternatively, the difference between the lease renewal request sending time and the primary / standby switchover time (i.e., the first time difference) can be calculated. If the first time difference is less than or equal to a preset time threshold (e.g., the lease period configured in the DHCP service), the lease renewal request is allowed, and the lease information is rebuilt.

[0104] b. Adding a new client: For example, Figure 6 This is a schematic diagram illustrating the process of assigning new client IPs after a primary / standby switchover, as provided in an example of this application. Figure 6 As shown, a new client refers to a new client that comes online after a primary / standby switchover (i.e., the second client). When the second client comes online, it will send a lease request message (i.e., a DHCP DISCOVER message) to the DHCP server.

[0105] like Figure 6 As shown, after a primary / standby switchover occurs, when the first network device receives a lease request message from the second client, it first attempts to allocate an IP address from its exclusive first address partition. It queries the first network device's local records for available IP addresses in the first address partition. Since the first and second address partitions do not overlap, and the second network device will not allocate IP addresses from the first address partition before the primary / standby switchover, the selected available IP address has no conflict risk. The first network device can directly generate a DHCP OFFER message selecting this available IP address, allocate this available IP address to the second client, and complete the REQUEST / ACK four-way handshake with the second client without any detection delay.

[0106] like Figure 6As shown, when all addresses in the spare exclusive address zone (first address partition) are allocated, the first network device selects a candidate IP address from the public reserved address partition and performs conflict detection on this candidate IP address. If the candidate IP address is found to be non-conflicting, it is allocated to the second client. If the candidate IP address is found to be conflicting, it is marked as conflicted, and it is determined whether there are other available IP addresses in the public reserved address partition. If there are other available IP addresses in the public reserved address partition, a new candidate IP address is selected from the public reserved address partition, and conflict detection is performed again; if there are no other available IP addresses in the public reserved address partition, a Nak rejection message is sent to the second client to reject the second client's lease renewal request.

[0107] For example, Figure 7 This application provides a schematic diagram of the message interaction process for a newly added client to obtain an IP address, in conjunction with... Figure 7 The specific process of allocating addresses to new clients from the public reserved address partition is as follows: When a broadcast lease request message is received by the DHCP server on the first network device, if there are no free IP addresses in the first address partition, the DHCP server will select a candidate IP address from the public reserved address partition. Before officially allocating the candidate IP address via DHCP OFFER, a conflict detection process is initiated. In the conflict detection process, the DHCP server sends an ICMP Echo Request (or ARP Request) probe message to the candidate IP address and sets a timeout (e.g., 2 seconds). If an ICMP Echo Reply (or ARP Reply) response message is received, it indicates that another client on the network is already using the candidate IP address (e.g., a client assigned before the second network device switchover is still active), and a conflict is determined. If no response is received within the timeout period, the candidate IP address is determined to be unused. If a conflict is detected, the candidate IP address is marked as conflicted (a validity period, such as the DHCP lease period, can be set), and then a next candidate IP address is selected from the public reserved address partition, repeating the conflict detection process. If no conflict is detected, the candidate IP address is considered safe, and the DHCP protocol engine allocates it to the second client via an OFFER message and records it locally as allocated.

[0108] In some examples, conflict detection can also be based on the ARP protocol. The first network device selects a candidate IP address from the public reserved address partition, constructs an ARP Request message, sets the target protocol address to the candidate IP address, and the target MAC address to the broadcast address (FF:FF:FF:FF:FF:FF), and broadcasts this ARP Request message within the local network. A timeout timer (e.g., 2 seconds) is also set. If another client on the network is already using this candidate IP address, that client, upon receiving the ARP Request message, will return an ARP Reply response message containing its own MAC address. Upon receiving the ARP Reply response message, the first network device determines that the candidate IP address is already in use and marks it as conflicted. If no ARP Reply response message is received within the timeout period, the candidate IP address is determined to be unused and can be allocated.

[0109] To improve address allocation efficiency, the first network device can proactively conduct a comprehensive scan of all IP addresses in the public reserved address partition after taking over the DHCP service (or periodically) to determine the occupancy status of each IP address and pre-mark occupied IP addresses as conflicting. Subsequently, when an address needs to be allocated from the public reserved address partition, an IP address can be directly selected from those not marked as conflicting, eliminating the need for real-time address conflict detection.

[0110] In the example above, by setting up dedicated address partitions and public address partitions between primary and backup devices, using lease renewal and reconstruction mechanisms, and address conflict detection mechanisms, the first network device can provide DHCP services securely and efficiently without lease synchronization, while ensuring the business continuity of existing clients.

[0111] Figure 8 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application. Figure 8 As shown, the communication device 2000 includes a memory and a processor. The number of memories and processors can be one or more. Figure 8 Taking a memory 2101 and a processor 2201 as an example; the memory 2101 and processor 2201 in the network device can be connected via a bus or other means. Figure 8 Taking the example of a connection between China and Israel via a bus.

[0112] The memory 2101, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as program instructions / modules corresponding to the methods provided in any embodiment of this application. The processor 2201 implements the method for implementing DHCP server master / standby provided in any of the above embodiments by running the software programs, instructions, and modules stored in the memory 2101.

[0113] Memory 2101 may primarily include a program storage area and a data storage area, wherein the program storage area may store the operating system and application programs required for at least one function. Furthermore, memory 2101 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, memory 2101 further includes memory remotely located relative to processor 2201, and this remote memory can be connected to the device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0114] One embodiment of this application also provides a computer-readable storage medium storing computer-executable instructions for performing a method for implementing a DHCP server master / standby as provided in any embodiment of this application.

[0115] An embodiment of this application also provides a computer program product, including a computer program or computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer program or computer instructions from the computer-readable storage medium and executes the computer program or computer instructions, causing the computer device to perform the method for implementing a DHCP server master / standby as provided in any embodiment of this application.

[0116] The system architecture and application scenarios described in this application are intended to more clearly illustrate the technical solutions of this application and do not constitute a limitation on the technical solutions provided in this application. Those skilled in the art will understand that as system architectures evolve and new application scenarios emerge, the technical solutions provided in this application are also applicable to similar technical problems.

[0117] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0118] In hardware implementations, the division between functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0119] The terms “component,” “module,” “system,” etc., used in this specification are used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, or a computer. As illustrated, applications running on computing devices and computing devices can both be components. One or more components may reside in a process or execution thread, and components may be located on a single computer or distributed among two or more computers. Furthermore, these components can be executed from various computer-readable media on which various data structures are stored. Components can communicate, for example, via local or remote processes based on signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system, or a network, such as the Internet interacting with other systems via signals).

[0120] The above description, with reference to the accompanying drawings, illustrates some embodiments of this application, but does not limit the scope of this application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and spirit of this application shall be within the scope of this application.

Claims

1. A method for implementing a primary / standby DHCP server, characterized in that, Applied to a first network device, the method includes: When the first network device takes over the primary Dynamic Host Configuration Protocol (DHCP) service due to a primary / standby switchover and does not have lease information for the second network device, the target operation is performed, wherein the second network device is a device belonging to the same primary / standby redundancy group as the first network device. The target operation includes: Based on the leased address information in the renewal request message from the first client, lease information corresponding to the first client is established; based on the received lease request message from the second client, a first target address is assigned to the second client, wherein the first target address is a determined address that is not occupied by any client; The first network device has a first address partition exclusively for the first network device, the second network device has a second address partition exclusively for the second network device, and the first network device also has a public reserved address partition shared with the second network device. The public reserved address partition, the first address partition and the second address partition do not overlap with each other. Before assigning the first target address to the second client, the method further includes: Upon receiving a lease request message from the second client and finding no available address in the first address partition, an available address is selected from the available addresses in the public reserved address partition as the first target address. The available address represents an address that is not occupied by any client.

2. The method for implementing DHCP server master / slave as described in claim 1, characterized in that, The step of establishing lease information corresponding to the first client based on the lease address information in the lease renewal request message from the first client includes: Determine whether the first client is a downstream device of the first network device; If the first client is a downstream device of the first network device, lease information corresponding to the first client is established based on the lease address information in the lease renewal request message.

3. The method for implementing DHCP server master / slave as described in claim 1, characterized in that, The step of establishing lease information corresponding to the first client based on the lease address information in the lease renewal request message from the first client includes: Obtain the first time difference, which is the time difference between the sending time of the lease renewal request message and the time of the primary / standby switchover. If the first time difference is less than or equal to a preset time threshold, lease information corresponding to the first client is established based on the lease address information in the lease renewal request message, wherein the preset time threshold is less than or equal to the lease period configured by the DHCP service.

4. The method for implementing DHCP server master / slave as described in claim 1, characterized in that, The first network device has a first address partition exclusively for the first network device, and the second network device has a second address partition exclusively for the second network device. The first address partition and the second address partition do not overlap. Before assigning the first target address to the second client, the method further includes: Upon receiving a lease request message from a second client and finding an available address in the first address partition, an available address is selected from the first address partition as the first target address. The available address represents an address that is not occupied by any client.

5. The method for implementing DHCP server master / slave as described in claim 1, characterized in that, Selecting an available address from the available addresses in the public reserved address partition as the first target address includes: A first candidate address is selected from the public reserved address partition, and address conflict detection is performed on the first candidate address. The first candidate address is an address that has not been allocated by the first network device. If the address conflict detection determines that the first candidate address is not occupied by any client, the first candidate address is determined as the first target address.

6. The method for implementing DHCP server master / slave as described in claim 5, characterized in that, After performing address conflict detection on the first candidate address, the method further includes: If the address conflict detection determines that the first candidate address is occupied, the first candidate address is marked as conflicted, wherein the conflicted state is used to indicate that the marked address is an address that has been occupied by the client. Proceed to the step of selecting a first candidate address from the public reserved address partition and performing address conflict detection on the first candidate address.

7. The method for implementing DHCP server master / slave as described in claim 6, characterized in that, The step of selecting a first candidate address from the public reserved address partition includes: The first candidate address is selected from the addresses in the public reserved address partition that are not marked with the conflict status.

8. The method for implementing DHCP server master / slave as described in claim 1, characterized in that, Before selecting an available address from the available addresses in the public reserved address partition as the first target address, the method further includes: After the primary / standby switchover, address conflict detection is performed on all addresses in the public reserved address partition to determine the occupancy status of each address in the public reserved address partition. The address indicated by the occupancy status is marked as being occupied by the client and is in a conflict state. The conflict state is used to indicate that the marked address has been occupied by the client.

9. The method for implementing DHCP server master / slave as described in claim 8, characterized in that, Selecting an available address from the available addresses in the public reserved address partition as the first target address includes: From the first candidate addresses in the public reserved address partition that are not marked with the conflict state, select one of the first candidate addresses as the first target address, wherein the first candidate address is one of the addresses that has not been allocated by the first network device.

10. The method for implementing DHCP server master / slave as described in claim 5 or 8, characterized in that, The steps for performing address conflict detection include: Send a target probe message carrying the address to be detected, wherein the address to be detected is an address selected from the public reserved address partition that needs to be detected for address conflict; In response to receiving the response message corresponding to the target detection message, it is determined that the address to be detected is an address occupied by the client.

11. A communication device, characterized in that, include: At least one processor; At least one memory for storing at least one program; When at least one of the programs is executed by at least one of the processors, the method for implementing a primary / backup DHCP server as described in any one of claims 1 to 10 is implemented.

12. A computer-readable storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are used to execute the method for implementing a primary / backup DHCP server as described in any one of claims 1 to 10.

13. A computer program product, comprising a computer program or computer instructions, characterized in that, The computer program or the computer instructions are stored in a computer-readable storage medium. The processor of the electronic device reads the computer program or the computer instructions from the computer-readable storage medium and executes the computer program or the computer instructions, causing the electronic device to perform the method for implementing a DHCP server master / slave as described in any one of claims 1 to 10.

Images