CN111064819B - Address backup method and device - Google Patents
Address backup method and device Download PDFInfo
- Publication number
- CN111064819B CN111064819B CN201911308426.2A CN201911308426A CN111064819B CN 111064819 B CN111064819 B CN 111064819B CN 201911308426 A CN201911308426 A CN 201911308426A CN 111064819 B CN111064819 B CN 111064819B
- Authority
- CN
- China
- Prior art keywords
- address information
- lease
- dhcp client
- state
- dhcp
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
- H04L61/5007—Internet protocol [IP] addresses
- H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
Abstract
The application provides an address backup method and device, which can enable a first DHCP client configured in a standby state to obtain address information in a response message when receiving the response message fed back by a DHCP server aiming at an address request message sent by a second DHCP client configured in a main state corresponding to the first DHCP client; and locally recording the address information, so that the locally recorded address information is the same as the address information recorded by the second DHCP client. The method and the device can enable the DHCP client side in the standby state to directly acquire the same address information recorded by the DHCP server in the main state from the response message fed back by the DHCP server, thereby avoiding the DHCP client side in the main state from transmitting the address information through the channel, further reducing the occupation of the channel bandwidth, and improving the synchronization efficiency.
Description
Technical Field
The present application relates to the field of communications technologies, and in particular, to an address backup method and apparatus.
Background
With the increasing requirements of customers on the safety performance of network equipment, a dual-computer hot-standby environment is inevitably used for networking deployment in many occasions. Since most DHCP clients access the network by dynamically allocating IP addresses through DHCP (dynamic host configuration protocol), in order to implement dual-server hot-standby for the DHCP clients, not only the static configuration in the DHCP clients needs to be backed up, but also the dynamic configuration of the DHCP clients needs to be synchronized, for example, address information dynamically allocated to the DHCP clients by the DHCP server also needs to be played synchronously. However, for the synchronization of the address information, at present, transmission can only be performed by means of a channel between the main and standby hosts, which results in occupying channel resources and affecting synchronization efficiency.
Disclosure of Invention
In view of this, the present application provides an address backup method and apparatus to solve the problem of address synchronization of a DHCP client.
Specifically, the method is realized through the following technical scheme:
in a first aspect, the present application provides an address backup method, which is applied to a first DHCP client configured in a standby state, and includes:
when a response message fed back by a DHCP server aiming at an address request message sent by a second DHCP client side which is configured to be in a main state and corresponds to the first DHCP client side is received, address information in the response message is obtained;
locally recording the address information so that the locally recorded address information is the same as the address information recorded by the second DHCP client.
As an embodiment, the method further comprises:
receiving a first message sent by a second DHCP client when obtaining a lease renewal result, wherein the first message carries address information and a lease status, and updating the lease status corresponding to the address information recorded locally according to the lease status in the first message.
As an embodiment, the method further comprises:
if the first message sent by a second DHCP client side is not received within the preset time, sending a second message to the second DHCP client side, wherein the second message carries the address information and is used for inquiring whether the continuous lease is successful or not;
Judging whether lease renewal is successful according to the lease state corresponding to the address information fed back by the second DHCP client, and if yes, updating the local lease state; if not, deleting the corresponding relation of the address information.
As an embodiment, the determining whether lease renewal is successful according to the lease status corresponding to the address information fed back by the second DHCP client includes:
and receiving a lease state corresponding to the address information fed back by the second DHCP client, judging whether the lease state is consistent with a locally recorded lease state, if so, determining that lease renewal fails, and if not, determining that lease renewal succeeds.
As an embodiment, the method further comprises:
and updating a local state machine according to the response message fed back by the DHCP server and/or the state machine synchronization message sent by the second DHCP client.
In a second aspect, the present application provides an address backup apparatus, which is applied to a first DHCP client configured in a standby state, and includes:
an obtaining unit, configured to obtain address information in a response message when receiving the response message fed back by a DHCP server for an address request message sent by a second DHCP client configured in a master state corresponding to the first DHCP client;
A recording unit, configured to locally record the address information, so that the locally recorded address information is the same as the address information recorded by the second DHCP client.
As an embodiment, the apparatus further comprises:
the first updating unit is used for receiving a first message sent by a second DHCP client when obtaining a lease renewal result, wherein the first message carries address information and a lease status, and updating the lease status corresponding to the address information recorded locally according to the lease status in the first message.
As an embodiment, the first updating unit is specifically configured to send a second message to a second DHCP client if the first message sent by the second DHCP client is not received within a preset time, where the second message carries the address information and is used to inquire whether lease renewal is successful; judging whether lease renewal is successful according to the lease state corresponding to the address information fed back by the second DHCP client, and if yes, updating the local lease state; if not, deleting the corresponding relation of the address information.
As an embodiment, the first updating unit, which executes to determine whether lease renewal is successful according to the lease status corresponding to the address information fed back by the second DHCP client, specifically includes:
And receiving a lease state corresponding to the address information fed back by the second DHCP client, judging whether the lease state is consistent with a locally recorded lease state, if so, determining that lease renewal fails, and if not, determining that lease renewal succeeds.
As an embodiment, the apparatus further comprises:
and the second updating unit is used for updating the local state machine according to the response message fed back by the DHCP server and/or the state machine synchronization message sent by the second DHCP client.
In a third aspect, the present application further provides a computer-readable storage medium, in which a computer program is stored, and the computer program, when executed by a processor, implements any one of the steps of the address backup method.
In a fourth aspect, the present application further provides a network device, which includes a memory, a processor, a communication interface, and a communication bus; the memory, the processor and the communication interface are communicated with each other through the communication bus;
the memory is used for storing a computer program;
the processor is used for executing the computer program stored in the memory, and any step of the address backup method is realized when the processor executes the computer program.
Therefore, the method and the device can enable a first DHCP client configured in a standby state to acquire address information in a response message when receiving the response message fed back by a DHCP server aiming at the address request message sent by a second DHCP client configured in a main state corresponding to the first DHCP client; and locally recording the address information, so that the locally recorded address information is the same as the address information recorded by the second DHCP client. The method and the device can enable the DHCP client side in the standby state to directly acquire the same address information recorded by the DHCP server in the main state from the response message fed back by the DHCP server, thereby avoiding the DHCP client side in the main state from transmitting the address information through the channel, further reducing the occupation of the channel bandwidth, and improving the synchronization efficiency.
Drawings
Fig. 1 is a diagram illustrating a DHCP networking structure in an exemplary embodiment in the related art;
FIG. 2 is a process flow diagram of an address backup method in an exemplary embodiment of the present application;
FIG. 3 is a flow diagram of address backup interaction in an exemplary embodiment of the present application;
fig. 4 is a logical structure diagram of an address backup apparatus according to an exemplary embodiment of the present application;
Fig. 5 is a hardware block diagram of a network device in an exemplary embodiment of the present application.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present application. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
Referring to fig. 1, a DHCP networking structure in an exemplary embodiment in the related art includes a DHCP server and two DHCP clients that enable dual-computer hot standby, where a device a is a DHCP client in an active state and a device B is a DHCP client in a standby state.
When a DHCP client side is required to send a broadcast request message to request address information such as an IP address from a DHCP server, the DHCP client side (such as equipment A) in a main state can broadcast the address request message carrying user information; when the DHCP server receives the broadcast packet of the address request message, it replies a response message carrying the corresponding address information in a broadcast form, at this time, both the device a and the DHCP client (e.g., device B) in the standby state can receive the same response message, the device a will send the received response message to the CPU for processing, and the device B, as the DHCP client in the standby state, will not process the response message, and after the device a obtains the address information, it will send the address information from the channel between the device a and the device B to the device B, thereby completing the backup of the address information.
Because the device B does not perform any processing after receiving the response message, the device B can only wait for the completion of the processing of the device a, and then synchronously backup the address information to the device B through the channel, if the DHCP client is more and the lease time is short, the channel is occupied for updating the address information on the DHCP client each time, which may cause channel congestion, and the critical address information may not be synchronously backed up in time, even cause inconsistency between the address information of the device B and the device a, and if the dual-computer switching occurs at this time, a risk of service interruption may be generated due to the asynchronization of the address information.
Referring to fig. 2, a processing flow diagram of an address backup method in an exemplary embodiment of the present application is shown, where the method is applied to a first DHCP client configured in a standby state, and the method includes:
in this embodiment, when a DHCP client needs to request address information, a second DHCP client in an active state may actively broadcast an address request packet in a VLAN to which the DHCP client belongs, so that a DHCP server in the VLAN receives the broadcast of the address request packet, and allocates address information to a user based on user information (for example, user authentication information, which may include a user name and a password) carried in the address request packet, where the address information includes information such as an IP address, a mask, a gateway, and a DNS. The DHCP server may add the address information to the response message, and broadcast the response message in the VLAN to which the response message belongs, so that both the first DHCP client and the second DHCP client in the VLAN network may receive the response message.
When receiving a response message fed back by a DHCP server for an address request message sent by a second DHCP client configured as an active state corresponding to the first DHCP client, a first DHCP client in a standby state may obtain address information allocated to the user information by the DHCP server in the response message. When the first DHCP client is in the standby state, the first DHCP client cannot actively send an address request message or other protocol messages to the DHCP server, and only receives and processes a response message replied by the DHCP server.
It should be noted that, because the communication between the second DHCP client in the active state and the DHCP server is broadcast messages, the first DHCP client in the standby state may receive an address request message sent by the second DHCP client in the active state and also receive a response message sent by the DHCP server. In order to further screen the response message fed back by the DHCP server, after receiving the broadcast message, the first DHCP client may determine whether the broadcast message is from the DHCP server or the second DHCP client according to the port number of the received broadcast message, and if the broadcast message is from the second DHCP client, no processing is required; if the broadcast message is from the DHCP server, the broadcast message needs to be sent to a DHCP client process in the CPU for processing, so that the address information in the response message is analyzed.
In this embodiment, after the first DHCP client acquires the address information allocated by the DHCP server in the response message, the address information may be locally recorded, so that the locally recorded address information is the same as the address information recorded by the second DHCP client.
The address information acquired by the DHCP client side in the main state is also analyzed according to the response message of the DHCP server, and the response message is simultaneously sent to the DHCP client side in the standby state, so that when the DHCP client side in the standby state receives the response message sent by the DHCP server, the address information in the response message can be acquired and stored, and the DHCP client side in the main state does not need to synchronize the address information to the DHCP client side in the standby state through a channel, thereby reducing the channel occupation, improving the synchronous backup efficiency of the address information, avoiding the problem of service interruption caused by untimely synchronization, and improving the reliability of the dual-computer hot backup.
As an embodiment, after both the second DHCP client in the active state and the first DHCP client in the standby state acquire the address information fed back by the DHCP server, the user may access the network based on the address information through the second DHCP client in the active state. However, since the address information of the DHCP server is provided with a lease, the second DHCP client in the active state needs to renew the lease at a certain time interval, so as to ensure that the user can access the network by using the address information continuously. For example, the second DHCP client in the active state may send a unicast lease renewal message to the DHCP server at 1/2 or 3/4 of the lease time, and update the lease state of the address information according to the lease renewal result fed back by the DHCP server. In addition, after the second DHCP client obtains the lease renewal result, the first DHCP client may further receive a first message sent by the second DHCP client when obtaining the lease renewal result, where the first message carries address information and a new lease status, and update the lease status corresponding to the address information recorded locally according to the new lease status, for example, judge whether lease renewal is successful according to the lease status, if yes, update the local lease status, and use the lease status in the first message as the local lease status; if not, deleting the address information to release the address resource.
If the first message sent by the second DHCP client is not received within the preset time, the first DHCP client can further send a second message to the second DHCP client, and the second message carries the address information and is used for inquiring whether the continuous lease is successful or not; the preset time is greater than or equal to the time for which the second DHCP client inquires for renewal, for example, the second DHCP client renews the lease at 1/2 lease time, and then the preset time for which the first DHCP client inquires for renewal should be greater than 1/2 lease time, so as to ensure that the second DHCP client can obtain the renewal result. The first DHCP can judge whether lease renewal is successful according to the lease state corresponding to the address information fed back by the second DHCP client for the second message, and if yes, the local lease state is updated; if not, deleting the address information.
In an example, the first DHCP client determines whether lease renewal is successful according to the lease state corresponding to the address information fed back by the second DHCP client, specifically, determines whether the lease state is consistent with a locally recorded lease state by receiving the lease state corresponding to the address information fed back by the second DHCP client, if so, determines that lease renewal is failed, and if not, determines that lease renewal is successful.
As an embodiment, the first DHCP client and the second DHCP client need to synchronize the process state machine in addition to synchronizing the address information. The first DHCP client in the standby state may update a local state machine, that is, a local process state machine of the first DHCP client, according to the response message fed back by the DHCP server and/or the state machine synchronization message sent by the second DHCP client, so as to ensure synchronization of the process state machines of the first DHCP client and the second DHCP client. By means of synchronous backup of the process state machines by the main device and the standby device, when the service needs to be migrated, the process states of the dual-machine DHCP client can be kept consistent.
In order to make the objects, technical solutions and advantages of the present application more apparent, the solution of the present application is further described in detail below with reference to fig. 3.
When a user needs to obtain address information such as an IP address through a DHCP client for network access, the device a and the device B in fig. 1 may enter an INIT state after starting a DHCP client function, and then determine whether the current device is in a primary state or a standby state, where a specific determination method may be generated through static configuration or dynamic election, for example, which device is initialized first and then used as the primary state, and another device is used as the standby state, and a specific election rule may be specified by the user, which is not limited herein. If it is determined that the device a is a DHCP client in the active state and the device B is a DHCP client in the standby state, an interaction flow of the device a and the device B when performing address information synchronization backup is shown in fig. 3, which includes:
Step 301, a device a broadcasts an address request message (e.g., a discovery message), where the address request message carries user information, and updates a state machine to a discovery state;
step 302, after receiving the address request message, the device B determines that the address request message is not a response message fed back by the DHCP server, discards the address request message, and updates the state machine to the discovery state;
step 303, when receiving the address request message, the DHCP server allocates address information according to the user information, and broadcasts a response message (for example, an offer message) carrying the address information;
step 304, when receiving the response message, the device a acquires the address information in the response message, records the address information in the response message locally, and updates the current state machine to the offer state;
step 305, when receiving the response message, the device B acquires the address information in the response message, records the address information in the response message locally, and updates the current state machine to the offer state;
step 306, the device a broadcasts a reply message (e.g. a request message), and updates the current state machine to the request state;
step 307, when the device B receives the reply message, discarding the reply message, and updating the current state machine to be in a request state;
Step 308, when the DHCP server receives the reply message, it confirms that the address allocation is successful, and broadcasts a confirmation message (e.g., ack message);
step 309, after receiving the confirmation message, the device a accesses the network through the address information and updates the state machine to the ack state;
step 310, after receiving the acknowledgement message, the device B updates the state machine to the ack state;
step 311, after t1 time, device a sends a renewal request to the DHCP server;
step 312, after receiving the lease renewal request, the DHCP server determines whether to renew the lease according to a preset policy, and replies a lease renewal result;
step 313, after receiving the lease renewal result, the device a updates the lease state and the state machine of the local address information, for example, when the lease renewal fails, deletes the local address information and deletes the state machine;
step 314, device a sends a renewal result to device B;
step 315, after receiving the lease renewal result, the device B updates the lease status and the state machine of the local address information, for example, when the lease renewal fails, deletes the local address information and deletes the state machine.
If device B does not receive the renewal result sent by device a at time t2(t2 > t1), it will actively send a message to device a requesting the renewal result, and then update the lease status and state machine of the local address information according to the renewal result returned by device a.
Corresponding to the embodiment of the address backup method, the application also provides an embodiment of an address backup device.
Referring to fig. 4, a schematic structural diagram of an address backup apparatus in an exemplary embodiment of the present application, where the apparatus is applied to a first DHCP client configured in a standby state, and the apparatus 40 includes:
an obtaining unit 401, configured to obtain address information in a response message when receiving the response message fed back by a DHCP server for an address request message sent by a second DHCP client configured in an active state and corresponding to the first DHCP client;
a recording unit 402, configured to locally record the address information, so that the locally recorded address information is the same as the address information recorded by the second DHCP client.
As an embodiment, the apparatus further comprises:
a first updating unit 403, configured to receive a first message sent by a second DHCP client when obtaining a lease renewal result, where the first message carries address information and a lease status, and update a lease status corresponding to the address information recorded locally according to the lease status in the first message.
As an embodiment, the first updating unit 403 is specifically configured to send a second message to a second DHCP client if the first message sent by the second DHCP client is not received within a preset time, where the second message carries the address information, and is used to inquire whether lease renewal is successful; judging whether lease renewal is successful according to the lease state corresponding to the address information fed back by the second DHCP client, and if yes, updating the local lease state; if not, deleting the address information.
As an embodiment, the first updating unit 403 executes, according to the lease status corresponding to the address information fed back by the second DHCP client, to determine whether lease renewal is successful, which specifically includes:
and receiving a lease state corresponding to the address information fed back by the second DHCP client, judging whether the lease state is consistent with a locally recorded lease state, if so, determining that lease renewal fails, and if not, determining that lease renewal succeeds.
The apparatus as an embodiment further comprises:
a second updating unit 404, configured to update a local state machine according to the response packet fed back by the DHCP server and/or the state machine synchronization message sent by the second DHCP client.
The implementation process of the functions and actions of each unit in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.
For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the application. One of ordinary skill in the art can understand and implement it without inventive effort.
Corresponding to the embodiment of the address backup method, the application also provides an embodiment of the network device for implementing the address backup method.
As shown in fig. 5, the network device includes a memory 51, a processor 82, a communication interface 53, and a communication bus 54; wherein, the memory 51, the processor 52 and the communication interface 53 communicate with each other through the communication bus 54;
the memory 51 is used for storing computer programs;
the processor 52 is configured to execute the computer program stored in the memory 51, and when the processor 52 executes the computer program, any step of the address backup method provided in the embodiment of the present application is implemented.
The present application further provides a computer-readable storage medium, in which a computer program is stored, and when the computer program is executed by a processor, the computer program implements any step of the address backup method provided in the embodiments of the present application.
All the embodiments in the present specification are described in a related manner, and the same and similar parts among the embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for embodiments of the network device and the computer-readable storage medium, since they are substantially similar to the method embodiments, the description is relatively simple, and in relation to the description, reference may be made to some portions of the description of the method embodiments.
In summary, according to the present application, when receiving a response message fed back by a DHCP server with respect to an address request message sent by a second DHCP client configured as an active state and corresponding to the first DHCP client, a first DHCP client configured as a standby state may obtain address information in the response message; and locally recording the address information, so that the locally recorded address information is the same as the address information recorded by the second DHCP client. The method and the device have the advantages that the DHCP client side in the standby state can directly acquire the same address information recorded by the DHCP server in the main state from the response message fed back by the DHCP server, so that the DHCP client side in the main state can be prevented from transmitting the address information through the channel, the occupation of the channel bandwidth is reduced, and the synchronization efficiency is improved.
The above description is only a preferred embodiment of the present application and should not be taken as limiting the present application, and any modifications, equivalents, improvements and the like made within the spirit and principle of the present application should be included in the protection scope of the present application.
Claims (10)
1. An address backup method applied to a first DHCP client configured in a standby state, the method comprising:
When a response message broadcast by a DHCP server is received, acquiring address information in the response message; the response message is a response message fed back by an address request message sent by a second DHCP client configured as a master state corresponding to the first DHCP client;
locally recording the address information so that the locally recorded address information is the same as the address information recorded by the second DHCP client.
2. The method of claim 1, further comprising:
receiving a first message sent by a second DHCP client when obtaining a lease renewal result, wherein the first message carries address information and a lease status, and updating the lease status corresponding to the address information recorded locally according to the lease status in the first message.
3. The method of claim 2, further comprising:
if the first message sent by a second DHCP client side is not received within the preset time, sending a second message to the second DHCP client side, wherein the second message carries the address information and is used for inquiring whether the continuous lease is successful or not;
judging whether lease renewal is successful according to the lease state corresponding to the address information fed back by the second DHCP client, and if yes, updating the local lease state; if not, deleting the address information.
4. The method of claim 3, wherein determining whether lease renewal is successful according to a lease status corresponding to the address information fed back by the second DHCP client comprises:
and receiving a lease state corresponding to the address information fed back by the second DHCP client, judging whether the lease state is consistent with a locally recorded lease state, if so, determining that lease renewal fails, and if not, determining that lease renewal succeeds.
5. The method of claim 1, further comprising:
and updating a local state machine according to the response message fed back by the DHCP server and/or the state machine synchronization message sent by the second DHCP client.
6. An address backup apparatus, applied to a first DHCP client configured in a standby state, comprising:
the device comprises an acquisition unit, a processing unit and a processing unit, wherein the acquisition unit is used for acquiring address information in a response message when receiving the response message broadcast and sent by a DHCP server; the response message is a response message fed back by an address request message sent by a second DHCP client configured as a master state corresponding to the first DHCP client;
A recording unit, configured to locally record the address information, so that the locally recorded address information is the same as the address information recorded by the second DHCP client.
7. The apparatus of claim 6, further comprising:
the first updating unit is used for receiving a first message sent by a second DHCP client when obtaining a lease renewal result, wherein the first message carries address information and a lease status, and updating the lease status corresponding to the address information recorded locally according to the lease status in the first message.
8. The apparatus of claim 7,
the first updating unit is specifically configured to send a second message to a second DHCP client if the first message sent by the second DHCP client is not received within a preset time, and the second message carries the address information and is used to inquire whether lease renewal is successful; judging whether lease renewal is successful according to the lease state corresponding to the address information fed back by the second DHCP client, and if yes, updating the local lease state; if not, deleting the address information.
9. The apparatus according to claim 8, wherein the first updating unit performs, according to the lease status corresponding to the address information fed back by the second DHCP client, determination of whether lease renewal is successful, specifically including:
And receiving a lease state corresponding to the address information fed back by the second DHCP client, judging whether the lease state is consistent with a locally recorded lease state, if so, determining that lease renewal fails, and if not, determining that lease renewal succeeds.
10. The apparatus of claim 6, further comprising:
and the second updating unit is used for updating the local state machine according to the response message fed back by the DHCP server and/or the state machine synchronization message sent by the second DHCP client.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911308426.2A CN111064819B (en) | 2019-12-18 | 2019-12-18 | Address backup method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911308426.2A CN111064819B (en) | 2019-12-18 | 2019-12-18 | Address backup method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111064819A CN111064819A (en) | 2020-04-24 |
| CN111064819B true CN111064819B (en) | 2022-07-29 |
Family
ID=70302208
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911308426.2A Active CN111064819B (en) | 2019-12-18 | 2019-12-18 | Address backup method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111064819B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116781494B (en) * | 2023-08-17 | 2024-03-26 | 天津南大通用数据技术股份有限公司 | Main-standby switching judgment method based on existing network equipment |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101141233A (en) * | 2006-09-07 | 2008-03-12 | 中兴通讯股份有限公司 | Method for implementing node B master-slave redundancy |
| CN101534257B (en) * | 2009-04-16 | 2012-05-23 | 华为技术有限公司 | Method, system and equipment for processing message |
| CN106936940A (en) * | 2017-02-10 | 2017-07-07 | 福建三元达网络技术有限公司 | Lease information backup method and system in a kind of Dynamic Host Configuration Protocol server |
| CN107769979A (en) * | 2017-11-01 | 2018-03-06 | 凌云天博光电科技股份有限公司 | A kind of method synchronously configured between router |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102025475A (en) * | 2009-09-23 | 2011-04-20 | 中兴通讯股份有限公司 | Address allocation method, apparatus and system in hot backup scene |
| US8630165B2 (en) * | 2010-05-10 | 2014-01-14 | Robert Robinson | Scalable reliable failover in a network |
| GB2558163A (en) * | 2014-11-12 | 2018-07-11 | Ibm | Dynamically assigning network addresses |
| CN108242982A (en) * | 2016-12-26 | 2018-07-03 | 天津六友科技有限公司 | A kind of server dual-locomotive heat switching processing system |
| CN107426021A (en) * | 2017-07-19 | 2017-12-01 | 北京锐安科技有限公司 | Construction method, device and the redundant system of redundant system |
| CN107919994B (en) * | 2017-12-13 | 2021-06-08 | 南京熊猫电子股份有限公司 | Method and server for realizing hot standby of network service dual-computer |
-
2019
- 2019-12-18 CN CN201911308426.2A patent/CN111064819B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101141233A (en) * | 2006-09-07 | 2008-03-12 | 中兴通讯股份有限公司 | Method for implementing node B master-slave redundancy |
| CN101534257B (en) * | 2009-04-16 | 2012-05-23 | 华为技术有限公司 | Method, system and equipment for processing message |
| CN106936940A (en) * | 2017-02-10 | 2017-07-07 | 福建三元达网络技术有限公司 | Lease information backup method and system in a kind of Dynamic Host Configuration Protocol server |
| CN107769979A (en) * | 2017-11-01 | 2018-03-06 | 凌云天博光电科技股份有限公司 | A kind of method synchronously configured between router |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111064819A (en) | 2020-04-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10187459B2 (en) | Distributed load balancing system, health check method, and service node | |
| US9847967B2 (en) | DHCP proxy in a subscriber environment | |
| US10122679B2 (en) | Method, relay agent, and system for acquiring internet protocol address in network | |
| US7577146B2 (en) | Network element modifying the DHCP lease timer | |
| US10419531B2 (en) | Method for setting gateway device identity, and management gateway device | |
| CN113891430A (en) | Communication method, device and system | |
| WO2015101260A1 (en) | Method and system for processing instant communication service | |
| US20080028071A1 (en) | Communication load reducing method and computer system | |
| CN107733808B (en) | Flow transmission method and device | |
| KR101526289B1 (en) | Method for obtaining ip address of dynamic host configuration protocol version 6 server, dynamic host configuration protocol version 6 server and dynamic host configuration protocol version 6 communicatioin system | |
| US10069941B2 (en) | Scalable event-based notifications | |
| CN107547665B (en) | Method, equipment and system for allocating DHCP (dynamic host configuration protocol) address | |
| CN111327668B (en) | Network management method, device, equipment and storage medium | |
| WO2021008591A1 (en) | Data transmission method, device, and system | |
| CN109120741B (en) | Duplicate address detection method and device and computer readable storage medium | |
| CN111064819B (en) | Address backup method and device | |
| CN109743357B (en) | Method and device for realizing service access continuity | |
| CN103795581A (en) | Address processing method and address processing device | |
| CN108667957B (en) | IP address allocation method, first electronic device and first server | |
| CN106899456B (en) | Method for realizing link detection and repair | |
| CN106375489B (en) | Method and device for processing Media Access Control (MAC) address | |
| CN109120738B (en) | DHCP server and method for managing network internal equipment | |
| CN111385324A (en) | Data communication method, device, equipment and storage medium | |
| CN115499414A (en) | Address allocation method and device | |
| JP4170649B2 (en) | Messenger server system, method of providing messenger service, connection destination determination server in messenger service |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |