A DHCP snooping binding synchronization and restoration method, device, equipment and medium

Abstract

The application discloses a DHCP snooping binding synchronization and restoration method, device, equipment and medium, and relates to the technical field of communication. In the address allocation stage, a DHCP message sent by a client is received, and an option 82 carrying device identification and client access location information is added in the message; the message after the option 82 is added is forwarded to a server, so that the server generates a lease database containing binding information; when a local binding table is lost, a first message carrying device identification is sent to the server, so that all binding information corresponding to the device identification in the extended lease database is requested; the first response message returned by the server is received piece by piece, and each piece of binding information is checked, and the binding information passing the check is temporarily stored in a buffer; when a second response message is received, all the binding information temporarily stored in the buffer is written into the local binding table in batches. The method can accurately restore the binding table containing complete client access location information.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a DHCP Snooping binding synchronization and restoration method, apparatus, device and medium. Background Technology

[0002] In scenarios such as campus networks, enterprise networks, and carrier access networks, user terminals typically obtain IP addresses dynamically via DHCP. Access layer switches, by enabling DHCP Snooping, maintain a local DHCP Snooping binding table, recording information such as the user terminal's MAC address, assigned IP address, VLAN, access port, and lease duration. This binding table forms the data foundation for security features such as IPSG and DAI, and is used to restrict the forwarding of unauthorized packets at the port level.

[0003] Currently, DHCP Snooping binding tables are primarily built by sniffing DHCP ACK packets during the DHCP address allocation process, and binding table entries are then sent to the hardware forwarding table. Some existing solutions utilize the DHCP Server's standard lease database for binding table restoration. Other solutions employ a private UDP protocol to establish a backup channel between the DHCP Snooping device and the DHCP Server. RFC 6926 defines the Bulk Leasequery protocol, which allows the querying party to query lease information in bulk from the DHCP Server via TCP port 647. This protocol primarily retrieves lease database information from DHCP Relay devices, and the returned lease records do not include user access location information.

[0004] However, the existing solutions described above cannot accurately restore the DHCP Snooping binding table. Summary of the Invention

[0005] This application provides a method, apparatus, device, and medium for DHCP Snooping binding synchronization and restoration, which can accurately restore the DHCP Snooping binding table.

[0006] To achieve the above objectives, this application adopts the following technical solution: This application divides the synchronization and restoration of the DHCP Snooping binding table into two interconnected stages: The first stage is table creation and database entry. User terminals obtain IP addresses through standard DHCP interaction. When forwarding DHCP messages (DHCP DISCOVER or DHCP REQUEST messages), the DHCP Snooping device inserts Option 82. When the remote backup extension is enabled, the DHCP Server writes the client MAC address, assigned IP address, lease period, and device identifier, port identifier, and VLAN identifier obtained from Option 82 resolution into the extended lease database. At the same time, the DHCP Snooping device establishes a local binding table by sniffing DHCP ACK messages. The second stage is database restoration and database exit. When the local binding table is lost due to restart, power failure, or other reasons, the DHCP Snooping device, as the Bulk Leasequery requester, sends a Bulk Leasequery message to the DHCP Server through TCP port 647, pulls active leases according to Remote-ID, receives Lease Active messages one by one and verifies and temporarily stores them. After receiving Lease QueryDone messages, it writes them in batches into the local binding table and hardware forwarding table. Both of the above stages are predicated on enabling remote backup extensions on the DHCP Server side.

[0007] In a first aspect, this application provides a DHCP Snooping binding synchronization and restore method, comprising: in the above technical solution, the lease library is an extended lease library; the first message is a Bulk Leasequery message; the first response message is a Lease Active message; and the second response message is a Lease Query Done message.

[0008] Receive Dynamic Host Configuration Protocol (DHCP) messages sent by the client, and add Option82, which carries the DHCP Snooping device identifier and the client access location information, to the DHCP messages; The DHCP message with Option 82 added is forwarded to the server so that the server can generate a lease library containing binding information based on Option 82; Send a first message carrying the DHCP Snooping device identifier to the server to request all binding information corresponding to the DHCP Snooping device identifier in the lease database; The system receives the first response messages returned by the server one by one, verifies the binding information in each first response message, and temporarily stores the binding information that passes the verification in a buffer. When the second response message returned by the server is received, all the binding information temporarily stored in the buffer is written in batches to the local DHCP Snooping binding table.

[0009] Optionally, before sending the first message carrying the DHCP Snooping device identifier to the server, the method further includes: Determine if a local table binding restore is required; If a binding table restoration is required, a connection is established with the server via TCP port 647.

[0010] Optionally, the DHCP Snooping device identifier is the local MAC address of the DHCP Snooping device; the client access location information includes the port identifier and VLAN identifier of the client access.

[0011] Optionally, Option 82 includes a first sub-option and a second sub-option; wherein the value of the first sub-option is the local MAC address of the DHCP Snooping device; and the value of the second sub-option is a combination of the client access port identifier and the VLAN identifier, with the client access port identifier and the VLAN identifier connected by a separator.

[0012] Optionally, the verification of the binding information in each first response message includes: Verify that the client MAC address, assigned IP address, lease time, DHCP Snooping device identifier, client access port identifier, and VLAN identifier in the binding information are complete and valid; If the verification passes, the binding information will be temporarily stored in the buffer. If the verification fails, the binding information is discarded, and the system continues to wait for the next first response message.

[0013] Optionally, the method further includes: If the second response message is not received within the preset time, it is determined whether the number of times the first message has been sent has reached the preset retry threshold. If the preset retry threshold is not reached, the first message is resent to the server. If the preset retry threshold is reached, the buffer is cleared.

[0014] Optionally, determining whether a local table binding restore needs to be performed includes: When the DHCP Snooping device is detected to have restarted and come back online, it is determined that the binding table needs to be restored locally; or when a restoration command is received manually triggered by the administrator, it is determined that the binding table needs to be restored.

[0015] Secondly, this application provides a DHCP Snooping binding synchronization and restore device, comprising: The receiving module is used to receive Dynamic Host Configuration Protocol (DHCP) messages sent by the client, and add Option82, which carries the DHCP Snooping device identifier and the client access location information, to the DHCP message; The sending module is used to forward DHCP messages with Option 82 added to the server, so that the server can generate a lease library containing binding information according to Option 82; and to send a first message carrying the DHCP Snooping device identifier to the server to request all binding information in the lease library corresponding to the DHCP Snooping device identifier. The processing module is used to receive the first response messages returned by the server one by one, and to verify the binding information in each first response message, and temporarily store the binding information that passes the verification in a buffer. The write module is used to write all the binding information temporarily stored in the buffer into the local DHCP Snooping binding table in batches when a second response message is received from the server.

[0016] Thirdly, this application provides a computing device, including a memory and a processor; The memory stores one or more computer programs, the one or more computer programs including instructions; when the instructions are executed by the processor, the computing device performs the method as described in any one of the first aspects.

[0017] Fourthly, this application provides a computer-readable storage medium for storing a computer program for performing the method as described in any one of the first aspects.

[0018] As can be seen from the above technical solution, this application has at least the following beneficial effects: This application adds Option 82, carrying the DHCP Snooping device identifier and client access location information, to DHCP messages and forwards them to the server. The server then generates a lease database containing binding information based on Option 82, thus storing complete binding information, including client access location information, on the server side, enabling centralized and persistent binding information. When the local binding table is lost, a first message carrying the DHCP Snooping device identifier is sent to the server. The server retrieves all corresponding binding information from the lease database based on this device identifier and returns it line by line in a first response message. The device receives the first response message line by line, verifies each binding information, and temporarily stores the verified binding information in a buffer. Upon receiving the second response message from the server, all the temporarily stored binding information in the buffer is written in batches to the local DHCP Snooping binding table. Each record in the restored binding table contains the client MAC address, assigned IP address, lease time, access port identifier, and VLAN identifier, thus accurately restoring the DHCP Snooping binding table containing complete client access location information.

[0019] It should be understood that the descriptions of technical features, technical solutions, beneficial effects, or similar language in this application do not imply that all features and advantages can be achieved in any single embodiment. Rather, it is understood that the description of a feature or beneficial effect means that a specific technical feature, technical solution, or beneficial effect is included in at least one embodiment. Therefore, the descriptions of technical features, technical solutions, or beneficial effects in this specification do not necessarily refer to the same embodiment. Furthermore, the technical features, technical solutions, and beneficial effects described in this embodiment can be combined in any suitable manner. Those skilled in the art will understand that embodiments can be implemented without one or more specific technical features, technical solutions, or beneficial effects of a particular embodiment. In other embodiments, additional technical features and beneficial effects may be identified in specific embodiments that do not embody all embodiments. Attached Figure Description

[0020] Figure 1 A schematic diagram illustrating an application scenario provided in an embodiment of this application; Figure 2 A flowchart illustrating a DHCP Snooping binding synchronization and restore method provided in this application embodiment; Figure 3 A flowchart illustrating the establishment of binding entries in a DHCP Snooping device is provided in an embodiment of this application. Figure 4 A flowchart illustrating the creation of a lease database entry on a server, as provided in this application embodiment; Figure 5 A flowchart illustrating a server restore table entry is provided in this application embodiment; Figure 6 A flowchart illustrating the restoration of binding entries in a DHCP Snooping device is provided as an embodiment of this application. Figure 7 A schematic diagram of a DHCP Snooping binding synchronization and restore device provided in an embodiment of this application; Figure 8 This is a schematic diagram of a computing device provided in an embodiment of this application. Detailed Implementation

[0021] The terms "first," "second," and "third," etc., used in this application specification and accompanying drawings are used to distinguish different objects, not to limit a specific order.

[0022] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0023] The DHCP Snooping binding table is an entry generated locally by the access layer switch by listening to DHCP packets. It records information such as the user terminal's MAC address, assigned IP address, VLAN, access port, and lease time, and is used to restrict the forwarding of illegal packets at the port level. This binding table is only stored in the device's memory. If the device restarts, loses power, or switches from primary to backup, all entries in the table are lost. This causes ports with security features such as IP Source Guard or DAI enabled to be unable to identify legitimate users due to the lack of binding relationships, resulting in the wrongful interception of legitimate packets. To solve the problem of restoring the lost entries, lease information stored on the server side can be used for recovery. However, the standard server lease database only records the client's MAC address and assigned IP address, and does not include location information such as access port identifier and VLAN identifier, so it is impossible to restore the complete DHCP Snooping binding table. Although RFC6926 defines the Bulk Leasequery protocol, which allows the querying party to query the server in batches for lease information, this protocol is mainly designed to obtain lease database information from DHCP Relay devices, and the returned lease records also do not include user access location information. Therefore, how to obtain and accurately restore binding information containing complete access location information from the server side after the DHCP Snooping device binding table is lost is the technical problem to be solved in this application.

[0024] In view of this, embodiments of this application provide a DHCP Snooping binding synchronization and restore method, which can be executed by a DHCP Snooping device.

[0025] In this method, during the DHCP address allocation phase, the DHCP Snooping device adds Option82, which carries the device identifier and the client's access location information, to the client's DHCP message when forwarding it. This allows the server to write the above information, along with the client's MAC address, the allocated IP address, and the lease time, into the lease database while allocating the address. This ensures that all the information required to restore the DHCP Snooping binding table is completely saved on the server side. If the local binding table is lost, the DHCP Snooping device sends a first message carrying the device identifier to the server, requests and receives a first response message containing complete binding information from the server. After verifying each message, the information is temporarily stored in a buffer. Once a second response message confirms that all binding information has arrived, all the temporarily stored binding information in the buffer is written into the local DHCP Snooping binding table in batches, thus achieving accurate restoration of the binding table.

[0026] To make the technical solution of this application clearer and easier to understand, the application scenarios of the technical solution of this application are described below with reference to the accompanying drawings. Figure 1 As shown in the figure, this figure is a schematic diagram of an application scenario provided by an embodiment of this application.

[0027] exist Figure 1 The application scenario shown includes a client, a DHCP Snooping device, and a server. The client sends a DHCP message to the DHCP Snooping device, which contains the client's MAC address. Upon receiving the DHCP message, the DHCP Snooping device obtains its own identification information, the port identifier of the physical port receiving the message, and the VLAN identifier of the VLAN it belongs to. This information is used as the client's access location information and added to Option 82 of the DHCP message along with the DHCP Snooping device identifier. The DHCP message with Option 82 added is then forwarded to the server. Upon receiving the message, the server parses the client's MAC address, assigned IP address, lease duration, and the DHCP Snooping device identifier and client access location information carried in Option 82. This information is then written as a binding record to the lease database, completing the synchronization of binding information.

[0028] When a DHCP Snooping device loses its local DHCP Snooping binding table due to a reboot, it sends a first message carrying its device identifier to the server. Upon receiving this first message, the server retrieves all binding information corresponding to that device identifier from the lease database based on the DHCP Snooping device identifier, and encapsulates each retrieved binding information into a first response message, returning them one by one to the DHCP Snooping device. The DHCP Snooping device receives each first response message, verifies the binding information in each message, and temporarily stores the verified binding information in a buffer. Once all binding information has been returned, the server sends a second response message to the DHCP Snooping device. Upon receiving the second response message, the DHCP Snooping device writes all the temporarily stored binding information in the buffer into its local DHCP Snooping binding table in batches, restoring the binding table.

[0029] To make the technical solution of this application clearer and easier to understand, the following application scenarios will be used to describe a DHCP Snooping binding synchronization and restore method provided by the embodiments of this application. Figure 2 As shown, this figure is a flowchart of a DHCP Snooping binding synchronization and restore method provided in an embodiment of this application. In this embodiment, the method includes: S201 The DHCP Snooping device receives Dynamic Host Configuration Protocol (DHCP) messages sent by the client and adds Option82, which carries the DHCP Snooping device identifier and the client's access location information, to the DHCP message.

[0030] A DHCP Snooping device refers to an access layer switch that has the DHCP Snooping function enabled to listen for and process DHCP messages between clients and servers.

[0031] DHCP messages, or Dynamic Host Configuration Protocol messages, are protocol data units exchanged between clients and servers for requesting and allocating IP addresses.

[0032] The DHCP Snooping device identifier is used to uniquely identify the identity information of the DHCP Snooping device, which in this application is the local MAC address of the DHCP Snooping device.

[0033] Client access location information refers to the physical location of the client accessing the network, which in this application includes the port identifier and VLAN identifier of the client access.

[0034] Option 82, or DHCP Option 82, is a relay agent information option defined in the DHCP protocol, used to carry client location information. Option 82 includes a first sub-option and a second sub-option. The first sub-option is the Remote-ID, whose value is the local MAC address of the DHCP Snooping device, used to identify which DHCP Snooping device forwarded the DHCP message. The second sub-option is the Circuit-ID, whose value is a combination of the client's access port identifier and VLAN identifier, separated by a separator (such as a vertical bar "|"). This identifies which physical port and VLAN of the DHCP Snooping device the client accessed the network from. To ensure data consistency during table creation and restoration, this application makes the following conventions for Option 82 encoding: Remote-ID uses the local MAC address of the DHCP Snooping device; Circuit-ID uses a combination of port identifier and VLAN identifier, separated by a conventional separator. DISCOVER and REQUEST on the same port and in the same VLAN must use the exact same Circuit-ID encoding. DHCPServer database entry and DHCP Snooping local learning also use the same encoding rules for parsing.

[0035] When DHCP Snooping is enabled on a certain access port and Option 82 is enabled, the DHCP Snooping device, upon receiving a DHCP DISCOVER or DHCP REQUEST message from a user terminal, does not directly forward it. Instead, it inserts Option 82 into the message before forwarding it to the server. The Option 82 content inserted in the DISCOVER and REQUEST phases is consistent to ensure that the information entered into the DHCP Server database is consistent with the information learned locally by DHCP Snooping.

[0036] The DHCP Snooping device receives DHCP messages from clients, reads the client's MAC address from the message, obtains the port identifier from the physical port of the device, and obtains the VLAN identifier from the VLAN to which the port belongs. The DHCP Snooping device uses its own MAC address as the DHCP Snooping device identifier, and the port identifier and VLAN identifier as the client's access location information. Following the Option82 encoding format, it fills the Remote-ID sub-option with the own MAC address, and the Circuit-ID sub-option with the port identifier and VLAN identifier concatenated with a separator. This Option82 is then inserted into the DHCP message. The DHCP Snooping device receives a DHCP message carrying the DHCP Snooping device identifier and the client's access location information. This message indicates which DHCP Snooping device, which port, and which VLAN the DHCP request originated from.

[0037] S202, the DHCP Snooping device forwards DHCP messages with Option 82 added to the server, so that the server can generate a lease library containing binding information based on Option 82.

[0038] A server refers to a DHCP server, which is used to receive DHCP requests initiated by clients, allocate IP addresses from the address pool, and maintain a lease database that records information about allocated addresses.

[0039] Binding information refers to the record generated by the server based on the content of the DHCP message, which includes the client's MAC address, assigned IP address, lease time, client access port identifier, and VLAN identifier.

[0040] A lease database refers to a database or data structure on the server side used to store binding information. Each binding record corresponds to a client with an assigned IP address.

[0041] The DHCP Snooping device forwards the DHCP message carrying Option 82 to the server via the uplink. Upon receiving the message, the server extracts the client's MAC address from the header, the assigned IP address from the yiaddr field, the lease time from Option 51, the DHCP Snooping device identifier from the Remote-ID sub-option of Option 82, and the client's access port and VLAN identifier from the Circuit-ID sub-option of Option 82. The server combines all these fields into a single binding entry and writes it to the lease database. Each binding entry in the lease database corresponds to a client that has obtained an IP address, representing the client's MAC address, the IP address it holds, the remaining lease time, and which DHCP Snooping device, port, and VLAN from which the client accessed the network.

[0042] Figure 3 This illustration shows a flowchart of a DHCP Snooping device establishing a binding table entry according to an embodiment of this application. (In conjunction with...) Figure 3 When a DHCP Snooping device receives a DHCP message (such as a DHCP DISCOVER or DHCPREQUEST message) from a client, it first inserts Option 82, which carries the local MAC address (Remote-ID), the client's access port identifier, and the VLAN identifier (Circuit-ID), into the DHCP message. Then, it forwards the DHCP message with Option 82 inserted to the server. After the server completes the address allocation and replies with a DHCP ACK message, the DHCP Snooping device sniffs the DHCP ACK message to extract the client's MAC address, the assigned IP address, the lease time, and the locally recorded access port and VLAN information. If the parsing result is complete and valid, it generates a DHCP Snooping binding entry and sends the binding entry to the hardware forwarding table; if the parsing result is invalid (e.g., missing fields or abnormal lease), it discards the record.

[0043] Figure 4 This illustration shows a flowchart of a server establishing a lease database entry according to an embodiment of this application. (In conjunction with...) Figure 4When the server receives a DHCP message (e.g., a DHCP REQUEST message) forwarded by the DHCP Snooping device, it first determines whether the DHCP message carries Option 82 and whether the DHCP remote backup extension is enabled. If the DHCP message does not carry Option 82 or the remote backup extension is not enabled, it generates an allocation address table according to the standard procedure, sets the extended fields to empty, and replies with a DHCPACK message before ending the process. If the DHCP message carries Option 82 and the remote backup extension is enabled, it parses the Remote-ID and Circuit-ID from Option 82, extracts the DHCP Snooping device's MAC address, access VLAN, and access port, and writes them together with the client's MAC address, allocated IP address, and lease time into the extended lease database. It then marks the binding status as active and finally replies with a DHCP ACK message.

[0044] S203. The DHCP Snooping device sends a first message carrying the DHCP Snooping device identifier to the server to request all binding information corresponding to the DHCP Snooping device identifier from the lease database. The extended lease database is a structured storage added on top of the standard DHCP lease database, used to connect table creation and restoration. Each extended lease record contains standard fields such as the client MAC address, assigned IP address, and lease expiration time, as well as the DHCP Snooping device MAC address, access VLAN, and access port obtained from Option82, and the binding status (active or expired) maintained by the DHCP Server. During a Bulk Leasequery query, the DHCP Server uses the Remote-ID as the primary key and only returns records where the binding_state is active and the lease has not expired. When a user releases an address or the lease expires naturally, the DHCP Server updates the binding_state of the corresponding record to expired, preventing it from participating in restoration queries.

[0045] Before sending the first message carrying the DHCP Snooping device identifier to the server, the method also includes: Determining whether a binding table restoration needs to be performed locally includes: determining whether a binding table restoration needs to be performed locally when the DHCP Snooping device is detected to have restarted and come online; or determining whether a binding table restoration needs to be performed when a restoration command is received manually triggered by the administrator; if a binding table restoration needs to be performed, a connection is established with the server through TCP port 647, and after the connection is established, a first message carrying the DHCP Snooping device identifier is sent to the server.

[0046] The first message refers to the BULKLEASEQUERY message, which is a bulk lease query request message defined in the RFC 6926 standard and is used to request lease information from the server.

[0047] TCP port 647 refers to Transmission Control Protocol port number 647, which is the default port used by the BulkLeasequery protocol as specified in RFC 6926. It is used to establish a reliable connection between DHCP Snooping devices and servers to transmit query request and response messages.

[0048] During startup, the DHCP Snooping device checks if it has restarted or reconnected after a power outage. If so, it determines that its local binding table is lost and needs to be restored. Alternatively, the DHCP Snooping device receives a restoration command from the administrator via command line or network management system and determines that a binding table restoration is necessary. If restoration is required, the DHCP Snooping device initiates a TCP connection request to the server, targeting port 647, establishing a TCP connection to ensure reliable transmission of subsequent query requests and response messages. After the TCP connection is successfully established, the DHCP Snooping device constructs a first message according to RFC 6926, filling its MAC address into the Option159 (Remote-ID) field, and then sends the first message to the server through the established TCP connection. The DHCP Snooping device receives a first message carrying its own identifier, indicating that it is requesting the server to return all binding information belonging to its device.

[0049] Correspondingly, the server-side processing flow is as follows: Figure 5 As shown. Figure 5 A flowchart illustrating a server restore table entry provided in an embodiment of this application is shown. (In conjunction with...) Figure 5Upon receiving the first message (e.g., a BULKLEASEQUERY message) from the DHCP Snooping device on TCP port 647, the server first checks whether the remote backup extension is enabled. If the remote backup extension is not enabled, the server rejects the query and replies to the DHCP Snooping device with a second response message (e.g., a LEASEQUERYDONE message). This second response message carries a status code (a value of 4), indicating that Bulk Leasequery is globally disabled. If the remote backup extension is enabled, the server parses the Remote-ID carried in the first message and uses this Remote-ID as the query key to retrieve all binding records in the extended lease database that match the Remote-ID, have an active binding status, and whose leases have not expired. For each retrieved binding record, the server encapsulates it into a first response message (e.g., a LEASEACTIVE message) and sends it to the DHCP Snooping device one by one. After all matching binding records have been sent with the first response message, the server sends a second response message (e.g., a LEASEQUERYDONE message) to the DHCP Snooping device to notify the querying party that the query has ended.

[0050] S204 The DHCP Snooping device receives the first response message returned by the server one by one, verifies the binding information in each first response message, and temporarily stores the binding information that passes the verification in the buffer.

[0051] In some embodiments, the DHCP Snooping device verifies whether the client MAC address, assigned IP address, lease time, DHCP Snooping device identifier, client access port identifier, and VLAN identifier in the binding information are complete and valid; if the verification passes, the binding information is temporarily stored in a buffer; if the verification fails, the binding information is discarded, and the device continues to wait for the next first response message.

[0052] The first response message refers to the LEASEACTIVE message, which is a lease activity response message defined in the RFC 6926 standard. The server uses this message to return one binding message at a time to the DHCP Snooping device.

[0053] The DHCP Snooping device receives the first response message from the server via a TCP connection. From this message, it parses six fields: client MAC address, assigned IP address, lease time, DHCP Snooping device identifier, client access port identifier, and VLAN identifier. Each of these fields is then checked individually: its existence (i.e., not empty), its format (e.g., MAC address is a valid 48-bit format, IP address is a valid IPv4 address format), and its value (e.g., lease time is greater than 0, port identifier exists). If all six fields pass the check, the DHCP Snooping device stores the binding information in a buffer. If any field fails, the device discards the binding information, does not store it in the buffer, and continues receiving the next first response message. The DHCP Snooping device receives one or more valid binding records temporarily stored in the buffer. These records represent all valid binding records that have passed integrity checks but have not yet been written to the local binding table.

[0054] S205. When the second response message returned by the server is received, the DHCP Snooping device writes all the binding information temporarily stored in the buffer into the local DHCP Snooping binding table in batches.

[0055] The second response message is the LEASEQUERYDONE message, which is the lease query end message defined in the RFC 6926 standard. The server uses this message to notify the DHCP Snooping device that all matching binding information has been returned, and the query is over.

[0056] The local DHCP Snooping binding table is a binding table stored locally on the DHCP Snooping device. It records information such as the user terminal's MAC address, assigned IP address, VLAN, access port, and lease time, and is used to restrict the forwarding of illegal packets at the port level.

[0057] While continuously receiving the first response message, the DHCP Snooping device simultaneously listens for the arrival of a second response message. Upon receiving the second response message, the DHCP Snooping device confirms that the query has ended and all matching binding information has been returned. The DHCP Snooping device reads all the binding information temporarily stored in the buffer, extracting the client MAC address, assigned IP address, lease time, client access port identifier, and VLAN identifier from each binding message. Following the format of the local DHCP Snooping binding table, this information is written in batches into the local DHCP Snooping binding table, with each binding message corresponding to one entry in the table. The DHCP Snooping device obtains the restored local DHCP Snooping binding table, which contains all valid binding records obtained from the server and verified, representing the complete access information of all legitimate clients currently connected to the DHCP Snooping device.

[0058] The method also includes: If a second response message is not received within a preset time, it is determined whether the number of times the first message has been sent has reached a preset retry threshold. If the preset retry threshold has not been reached, the first message is resent to the server. If the preset retry threshold has been reached, the buffer is cleared.

[0059] The preset time refers to the maximum time that the DHCP Snooping device waits for the server to return a second response message after sending the first message. If the second response message is not received after this time, the query is considered to have timed out.

[0060] The preset retry threshold refers to the maximum number of times the DHCP Snooping device is allowed to resend the first packet. When the number of retryes reaches this threshold, no further retries will be made.

[0061] The DHCP Snooping device starts a timer while sending the first message, with a preset duration. Before the timer expires, the DHCP Snooping device waits for the second response message. If no second response message is received by the timer expires, the DHCP Snooping device increments the count of the first message sent and compares this count with a preset retry threshold. If the number of sent messages is less than the preset retry threshold, the DHCP Snooping device reconstructs and sends the first message, re-sending the query request to the server, and simultaneously resets the timer to restart. If the number of sent messages has reached the preset retry threshold, the DHCP Snooping device stops waiting and retrying, deletes all temporarily stored binding information in the buffer, clears the buffer, closes the TCP connection with the server, and terminates the current restore process. After clearing the buffer, it no longer contains any binding information, indicating that the restore process failed due to reaching the timeout retry limit, and the temporarily stored binding information is no longer written to the local DHCP Snooping binding table.

[0062] The specific judgment and processing logic involved in the above timeout retry process is described below in conjunction with... Figure 6 Please provide an explanation. Figure 6 This illustration shows a flowchart of a DHCP Snooping device restoring binding entries according to an embodiment of this application. (In conjunction with...) Figure 6 When a DHCP Snooping device loses its local binding table (typical triggering conditions include device reboot and manual triggering by the administrator), it determines that a binding table restoration is needed. It sends a first message (e.g., a BULKLEASEQUERY message) carrying the device's identifier to the server via TCP port 647 to request all binding information belonging to the device in the lease database. After the server responds, the DHCP Snooping device enters a receiving loop: upon receiving each first response message (e.g., a LEASEACTIVE message), it parses and verifies information such as the client's MAC address, assigned IP address, lease time, client access port identifier, and VLAN identifier. Successfully verified binding information is temporarily stored in a local buffer, and the device continues to wait for the next first response message. Upon receiving a second response message (e.g., a LEASEQUERYDONE message), all temporarily stored binding information in the buffer is written in batches to the DHCP Snooping binding table and then uniformly distributed to the hardware forwarding table. If a second response message is not received within the agreed time, it is determined whether the number of times the first message has been sent has reached the preset retry threshold. If the threshold has not been reached, the first message is resent to the server (e.g., resent BULKLEASEQUERY). If the threshold has been reached, the restoration is terminated and the process ends.

[0063] Based on the above description, this application has the following beneficial effects: This application adds Option 82, carrying the DHCP Snooping device identifier and client access location information, to DHCP messages and forwards them to the server. The server then generates a lease database containing binding information based on Option 82, thus storing complete binding information including client access location information on the server side. When the local binding table is lost, a first message carrying the DHCP Snooping device identifier is sent to the server. The server retrieves all corresponding binding information from the lease database based on this device identifier and returns it line by line in a first response message. The device receives the first response message line by line, verifies each binding information, and temporarily stores the verified binding information in a buffer. Only after receiving a second response message from the server confirming that all binding information has arrived is all the temporarily stored binding information in the buffer written in batches into the local DHCP Snooping binding table. This ensures that each record written to the local binding table completely includes the client MAC address, assigned IP address, lease time, access port identifier, and VLAN identifier, thus restoring the DHCP... The Snooping binding table can control packet forwarding at the port level. At the same time, the check-in process ensures that invalid binding information is not written to the local binding table. The batch writing after temporary storage avoids data incompleteness caused by missing binding information, thus accurately restoring the DHCP Snooping binding table containing complete client access location information.

[0064] The above text combined Figures 1 to 2 The DHCP Snooping binding synchronization and restore method provided in the embodiments of this application has been described in detail. The apparatus and equipment provided in the embodiments of this application will be described below with reference to the accompanying drawings.

[0065] like Figure 7 As shown in the figure, this is a schematic diagram of a DHCP Snooping binding synchronization and restore device provided in an embodiment of this application. The device includes: The receiving module 301 is used to receive the Dynamic Host Configuration Protocol (DHCP) message sent by the client, and add Option82, which carries the DHCP Snooping device identifier and the client access location information, to the DHCP message; The sending module 302 is used to forward the DHCP message with Option 82 added to the server, so that the server generates a lease library containing binding information according to Option 82; and to send a first message carrying the DHCP Snooping device identifier to the server to request all binding information in the lease library corresponding to the DHCP Snooping device identifier. The processing module 303 is used to receive the first response messages returned by the server one by one, and to verify the binding information in each first response message, and temporarily store the binding information that passes the verification in a buffer. The writing module 304 is used to write all the binding information temporarily stored in the buffer into the local DHCP Snooping binding table in batches when it receives the second response message returned by the server.

[0066] Optionally, the processing module 303 is also used to determine whether the binding table needs to be restored locally; If a binding table restoration is required, a connection is established with the server via TCP port 647.

[0067] Optionally, the processing module 303 is specifically used to verify whether the client MAC address, allocated IP address, lease time, DHCP Snooping device identifier, client access port identifier and VLAN identifier in the binding information are complete and valid; If the verification passes, the binding information will be temporarily stored in the buffer. If the verification fails, the binding information is discarded, and the system continues to wait for the next first response message.

[0068] Optionally, the processing module 303 is further configured to determine whether the number of times the first message has been sent has reached a preset retry threshold if the second response message is not received within a preset time. If the preset retry threshold is not reached, the first message is resent to the server. If the preset retry threshold is reached, the buffer is cleared.

[0069] Optionally, the processing module 303 is specifically used to determine that a binding table restoration needs to be performed locally when the DHCP Snooping device is detected to have restarted and come online; or to determine that a binding table restoration needs to be performed when a restoration command is received manually triggered by the administrator.

[0070] The DHCP Snooping binding synchronization and restore apparatus according to the embodiments of this application can correspondingly execute the method described in the embodiments of this application, and the other operations and / or functions of each module / unit of the DHCP Snooping binding synchronization and restore apparatus are respectively for implementing Figure 2 For the sake of brevity, the corresponding processes of each method in the illustrated embodiments will not be described in detail here.

[0071] This application also provides a computing device. For example... Figure 8As shown in the figure, this is a schematic diagram of a computing device provided in an embodiment of this application. The computing device 400 includes a bus 401, a processor 402, a communication interface 403, and a memory 404. The processor 402, the memory 404, and the communication interface 403 communicate with each other via the bus 401.

[0072] Bus 401 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 8 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0073] Processor 402 can be any one or more of the following processors: central processing unit (CPU), graphics processing unit (GPU), microprocessor (MP), or digital signal processor (DSP).

[0074] Communication interface 403 is used for communication with external devices.

[0075] Memory 404 may include volatile memory, such as random access memory (RAM). Memory 404 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0076] The memory 404 stores executable code, which the processor 402 executes to perform the aforementioned DHCPSnooping binding synchronization and restore method.

[0077] Specifically, in achieving Figure 7 In the case of the illustrated embodiment, and Figure 7 When the modules or units of the DHCP Snooping binding synchronization and restore device described in the embodiment are implemented in software, the execution... Figure 7The software or program code required for the functions of each module / unit can be partially or entirely stored in memory 404. Processor 402 executes the program code corresponding to each unit stored in memory 404 to execute the aforementioned DHCP Snooping binding synchronization and restore method.

[0078] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the aforementioned DHCP Snooping binding synchronization and restore method.

[0079] This application also provides a computer program product comprising one or more computer instructions. When the computer instructions are loaded and executed on a computing device, all or part of the processes or functions described in this application are generated.

[0080] The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, or data center to another website, computer, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0081] When the computer program product is executed by a computer, the computer performs any of the aforementioned DHCP Snooping binding synchronization and restore methods. The computer program product can be a software installation package; when any of the aforementioned DHCP Snooping binding synchronization and restore methods is required, the computer program product can be downloaded and executed on the computer.

[0082] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

[0083] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be covered within the scope of protection of this application.

Claims

1. A DHCP Snooping binding synchronization and restore method, characterized in that, The method includes: Receive Dynamic Host Configuration Protocol (DHCP) messages sent by the client, and add Option82, which carries the DHCP snooping device identifier and the client access location information, to the DHCP messages; The DHCP message with Option 82 added is forwarded to the server so that the server can generate a lease library containing binding information based on Option 82; Send a first message carrying the DHCP Snooping device identifier to the server to request all binding information corresponding to the DHCP Snooping device identifier in the lease database; The system receives the first response messages returned by the server one by one, verifies the binding information in each first response message, and temporarily stores the binding information that passes the verification in a buffer. When the second response message returned by the server is received, all the binding information temporarily stored in the buffer is written in batches to the local DHCP Snooping binding table.

2. The method according to claim 1, characterized in that, Before sending a first message carrying the DHCPSnooping device identifier to the server, the method further includes: Determine if a local table binding restore is required; If a binding table restoration is required, a connection is established with the server via TCP port 647.

3. The method according to claim 1, characterized in that, The DHCP Snooping device identifier is the local MAC address of the DHCP Snooping device; the client access location information includes the port identifier and VLAN identifier of the client access.

4. The method according to claim 3, characterized in that, Option 82 includes a first sub-option and a second sub-option; wherein, the value of the first sub-option is the local MAC address of the DHCP Snooping device; and the value of the second sub-option is a combination of the client access port identifier and the VLAN identifier, with the client access port identifier and the VLAN identifier connected by a separator.

5. The method according to claim 1, characterized in that, The verification of the binding information in each first response message includes: Verify that the client MAC address, assigned IP address, lease time, DHCP Snooping device identifier, client access port identifier, and VLAN identifier in the binding information are complete and valid; If the verification passes, the binding information will be temporarily stored in the buffer. If the verification fails, the binding information is discarded, and the system continues to wait for the next first response message.

6. The method according to claim 1, characterized in that, The method further includes: If the second response message is not received within the preset time, it is determined whether the number of times the first message has been sent has reached the preset retry threshold. If the preset retry threshold is not reached, the first message is resent to the server. If the preset retry threshold is reached, the buffer is cleared.

7. The method according to claim 2, characterized in that, The determination of whether the local binding table needs to be restored includes: When the DHCP Snooping device is detected to have restarted and come back online, it is determined that the binding table needs to be restored locally; or when a restoration command is received manually triggered by the administrator, it is determined that the binding table needs to be restored.

8. A DHCP Snooping binding synchronization and restore device, characterized in that, The device includes: The receiving module is used to receive Dynamic Host Configuration Protocol (DHCP) messages sent by the client, and add Option82, which carries the DHCP snooping device identifier and the client's access location information, to the DHCP message. The sending module is used to forward DHCP messages with Option 82 added to the server, so that the server can generate a lease library containing binding information according to Option 82; and to send a first message carrying the DHCP Snooping device identifier to the server to request all binding information in the lease library corresponding to the DHCP Snooping device identifier. The processing module is used to receive the first response messages returned by the server one by one, and to verify the binding information in each first response message, and temporarily store the binding information that passes the verification in a buffer. The write module is used to write all the binding information temporarily stored in the buffer into the local DHCP Snooping binding table in batches when the second response message returned by the server is received.

9. A computing device, characterized in that, Including memory and processor; The memory stores one or more computer programs, the one or more computer programs including instructions; when the instructions are executed by the processor, the computing device performs the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program for performing the method as described in any one of claims 1 to 7.

Images