Communication method and device

Abstract

The present application provides a communication method and device, the method comprising: receiving a first message including an IP address of the DHCP client sent by a DHCP client; if there is no first abnormal user entry matching the IP address in a local abnormal user table, sending the first DHCP message to a DHCP server; receiving a second DHCP message sent by the DHCP server after identifying the IP address; if the type of the second DHCP message is the first type, generating a first normal user entry corresponding to the DHCP client according to the value of a parameter option included in the second DHCP message; sending an authentication request message to a 3A server, the authentication request message including an authentication option in the parameter option; receiving an authentication response message sent by the 3A server after identifying the authentication option, the authentication response message including an authentication result; if the authentication result indicates that the authentication option is authenticated, updating the state of the first normal user entry to an online state.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a communication method and device. Background Art

[0002] Dynamic Host Configuration Protocol (DHCP) uses a client / server model, where the server dynamically allocates network configuration parameters such as IP addresses and default gateways to network devices.

[0003] When the DHCP client and the DHCP server are in different physical network segments, the DHCP client can continue to communicate with the DHCP server through the DHCP relay agent to obtain information such as the address, default gateway address, and DNS server address. Figure 1 As shown, Figure 1 The following is a basic networking diagram of the existing DHCP relay. Figure 1 In DHCP, when the DHCP client and the DHCP server are in different physical network segments, the DHCP relay agent obtains the message between the DHCP client and the DHCP server and sends it to the other end.

[0004] The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) is designed for the IPv6 addressing scheme and is used to allocate IPv6 prefixes, IPv6 addresses and other network configuration parameters to hosts.

[0005] Internet Protocol over Ethernet (IPoE) authentication is based on the Internet user's physical location to authenticate and bill users, so that users do not need to enter user names and passwords when surfing the Internet.

[0006] In current applications, DHCP relay is usually implemented by a broadband remote access server (BRAS). The DHCP client and BRAS are interconnected through a layer 2 switch.

[0007] After the DHCP client is triggered to go online through DHCPv4 or DHCPv6, if the BRAS restarts abnormally (for example, due to power outage, failure, etc.), after the BRAS starts, there will be no session of the online DHCP client in the local area. The DHCP client cannot sense the BRAS abnormality, and will not send DHCP / DHCPv6 messages to go online again before the address lease expires. Since there is no user session in the BRAS, the DHCP client can no longer access network resources.

[0008] Currently, the auto save technology can be used to ensure that the DHCP client continues to go online normally after the BRAS restarts abnormally.

[0009] When the DHCP client goes online normally, the BRAS periodically records the session entries of the DHCP client to a local file. After the BRAS restarts, the session entries of the DHCP client are restored from the local file, so that the DHCP client can continue to go online normally.

[0010] However, the existing self-rescue technology also exposes the following problems: 1) In the process of periodically recording the session table entries of the DHCP client to the local file, if the period interval is short, the flash write operation will be frequent, affecting the flash life; if the period interval is long, the session table entries of some DHCP clients will not be written to the flash when the BRAS is restarted; 2) The session table entries of each DHCP client in the BRAS must be written to the local file, affecting the BRAS performance and consuming the BRAS memory; 3) If the BRAS is replaced, the local files in the old BRAS must be transferred to the new BRAS, which is complicated. Summary of the invention

[0011] In view of this, the present application provides a communication method and device to solve the problems exposed by the existing BRAS writing the session table entries of the DHCP client into the local file, such as frequent flash writing operations, affecting the flash life, some session table entries not being written to the flash, affecting the BRAS performance, consuming the BRAS memory, etc.

[0012] In a first aspect, the present application provides a communication method, the method being applied to a BRAS, the BRAS being restarted, the method comprising:

[0013] Receiving a first message sent by a DHCP client, wherein the first message includes an IP address of the DHCP client;

[0014] If there is no first abnormal user entry matching the IP address in the local abnormal user table, sending a first DHCP message to the DHCP server, where the first DHCP message includes the IP address and parameter options;

[0015] receiving a second DHCP message sent by the DHCP server after identifying the IP address;

[0016] If the type of the second DHCP message is the first type, generating a first normal user entry corresponding to the DHCP client according to the value of the parameter option included in the second DHCP message, where the state of the first normal user entry is a pending authentication state;

[0017] Sending an authentication request message to a 3A server, wherein the authentication request message includes the authentication option in the parameter option;

[0018] receiving an authentication response message sent by the 3A server after identifying the authentication option, wherein the authentication response message includes an authentication result;

[0019] If the authentication result indicates that the authentication option is authenticated, the state of the first normal user entry is updated to an online state.

[0020] In a second aspect, the present application provides a communication device, the device is applied to a BRAS, the BRAS has been restarted, and the device includes:

[0021] A receiving unit, configured to receive a first message sent by a DHCP client, wherein the first message includes an IP address of the DHCP client;

[0022] a sending unit, configured to send a first DHCP message to a DHCP server if there is no first abnormal user entry matching the IP address in the local abnormal user table, wherein the first DHCP message includes the IP address and parameter options;

[0023] The receiving unit is further configured to receive a second DHCP message sent by the DHCP server after the DHCP server identifies the IP address;

[0024] a generating unit, configured to generate, if the type of the second DHCP message is the first type, a first normal user entry corresponding to the DHCP client according to the value of the parameter option included in the second DHCP message, wherein the state of the first normal user entry is a pending authentication state;

[0025] The sending unit is further used to send an authentication request message to the 3A server, wherein the authentication request message includes the authentication option in the parameter option;

[0026] The receiving unit is further configured to receive an authentication response message sent by the 3A server after the server identifies the authentication option, wherein the authentication response message includes an authentication result;

[0027] An updating unit is configured to update the state of the first normal user entry to an online state if the authentication result indicates that the authentication option is authenticated.

[0028] In a third aspect, the present application provides a network device, including a processor and a machine-readable storage medium, the machine-readable storage medium storing machine-executable instructions that can be executed by the processor, and the processor is prompted by the machine-executable instructions to execute the method provided in the first aspect of the present application.

[0029] Therefore, by applying the communication method and device provided by the present application, the BRAS receives a first message sent by a DHCP client, the first message including the IP address of the DHCP client; if there is no first abnormal user table entry matching the IP address in the local abnormal user table, the BRAS sends a first DHCP message to the DHCP server, the first DHCP message including the IP address and parameter options; the BRAS receives a second DHCP message sent by the DHCP server after identifying the IP address; if the type of the second DHCP message is the first type, the BRAS generates a first normal user table entry corresponding to the DHCP client according to the value of the parameter option included in the second DHCP message, and the state of the first normal user table entry is a pending authentication state; the BRAS sends an authentication request message to the 3A server, the authentication request message including the authentication option in the parameter option; the BRAS receives an authentication response message sent by the 3A server after identifying the authentication option, the authentication response message including the authentication result; if the authentication result indicates that the authentication option is authenticated, the BRAS updates the state of the first normal user table entry to an online state.

[0030] In this way, the BRAS no longer needs to save the session table entries of the online DHCP clients to local files, which improves the performance of the BRAS and reduces the frequency of flash usage. When the BRAS is replaced, it is also convenient to replace the BRAS. The BRAS uses the existing standard DHCPv4 / DHCPv6 mechanism to obtain the authentication information of the DHCP client from the DHCP server, and uses the authentication information to authenticate, authorize, and bill the DHCP client at the 3A server to restore the session table entries of the local DHCP client. At the same time, if the BRAS does not obtain the address information of the DHCP client from the DHCP server, it records the abnormal user entry to suppress the subsequent message sending by the DHCP client. This solves the problems exposed by the existing BRAS writing the session table entries of the DHCP client to the local file, such as frequent flash write operations, affecting the flash life, some session table entries not being written to the flash, affecting the BRAS performance, and consuming BRAS memory. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 This is a basic networking diagram of the existing DHCP relay;

[0032] Figure 2 A flow chart of a communication method provided in an embodiment of the present application;

[0033] Figure 3 A structural diagram of a communication device provided in an embodiment of the present application;

[0034] Figure 4 The network device hardware structure provided in the embodiment of the present application. DETAILED DESCRIPTION

[0035] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0036] The terms used in this application are only for the purpose of describing specific embodiments and are not intended to limit this application. The singular forms of "a", "said" and "the" used in this application and the appended claims are also intended to include plural forms unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used in this article refers to and includes any or all possible combinations of one or more corresponding listed items.

[0037] It should be understood that although the terms first, second, third, etc. may be used in the present application to describe various information, these information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of the present application, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0038] A communication method provided in an embodiment of the present application is described in detail below. Figure 2 , Figure 2 The flow chart of the communication method provided in the embodiment of the present application. The method is applied to BRAS. The communication method provided in the embodiment of the present application may include the following steps.

[0039] Step 210: Receive a first message sent by a DHCP client, where the first message includes an IP address of the DHCP client;

[0040] Specifically, when the DHCP client and the DHCP server are in different physical network segments, the DHCP relay agent obtains the message between the DHCP client and the DHCP server and sends it to the other end.

[0041] In the embodiment of the present application, the DHCP client includes a DHCPv4 client and a DHCPv6 client; the DHCP server includes a DHCPv4 server and a DHCPv6 server; and the DHCP relay is a BRAS.

[0042] After the DHCP client is triggered to go online through DHCPv4 or DHCPv6, if the BRAS restarts abnormally (for example, due to power failure or failure), after the BRAS starts, there is no normal user entry of the online DHCP client in the local area.

[0043] The DHCP client cannot sense the BRAS abnormality, and the DHCP client still normally sends a first message to the BRAS to access network resources, and the first message includes the IP address of the DHCP client. The above first message varies according to different types of DHCP clients. For example, when the DHCP client is a DHCPv4 client, the first message is specifically an IP message and an ARP message; when the DHCP client is a DHCPv6 client, the first message is specifically an IPv6 message and an ND message.

[0044] Step 220: If there is no first abnormal user entry matching the IP address in the local abnormal user table, a first DHCP message is sent to the DHCP server, where the first DHCP message includes the IP address and parameter options;

[0045] Specifically, according to the description of step 210, after the BRAS obtains the IP address of the DHCP client from the first message, it queries the local abnormal user table according to the IP address to see whether there is a first abnormal user entry matching the IP address.

[0046] The abnormal user entry includes the IP address field of the DHCP client, the MAC address field of the DHCP client, the interface identifier of the interface receiving the message, and the VLAN identifier to which the interface belongs.

[0047] If there is no first abnormal user entry matching the IP address in the local abnormal user table, the BRAS generates and sends a first DHCP message to the DHCP server, where the first DHCP message includes the IP address and parameter options.

[0048] Optionally, before executing step 220, after the BRAS obtains the IP address of the DHCP client from the first message, it first determines, according to the IP address, whether there is a first normal user entry matching the IP address in the local normal user table.

[0049] If there is a first normal user table entry that matches the IP address in the local normal user table, the BRAS processes the first message according to existing regulations; if there is no first normal user table entry that matches the IP address in the local normal user table, the BRAS determines whether there is a first abnormal user table entry that matches the IP address in the local abnormal user table.

[0050] If there is no first abnormal user entry matching the IP address in the local abnormal user table, the BRAS generates and sends a first DHCP message to the DHCP server; if there is a first abnormal user entry matching the IP address in the local abnormal user table, the BRAS discards the first message.

[0051] It should be noted that the local abnormal user table in the BRAS is to prevent the BRAS from frequently sending the first DHCP message to the DHCP server, which causes the DHCP server to be too busy.

[0052] Since DHCP clients include different types, the formats and fields of the first DHCP message generated by the BRAS are also different, which are described below respectively.

[0053] In one implementation, the DHCP client is a DHCPv4 client. The first DHCP message generated by the BRAS is specifically a DHCPLEASEQUERY message, which is a DHCPv4 message defined in the existing RFC4388 and is used by the DHCP relay to obtain address information of a designated DHCP client from the DHCPv4 server.

[0054] When the BRAS obtains the address information of a specified DHCP client from the DHCP server, it can use the IP address, MAC address, or CID of the DHCP client as an index (key). In the embodiment of the present application, the BRAS uses the IP address of the DHCP client as an index. The DHCPLEASEQUERY message includes a ciaddr field, an htype field, an hlen field, and a chaddr field. The ciaddr field is used to carry the IP address of the DHCP client. The htype field, the hlen field, and the chaddr field are all configured to 0 and no longer carry the CID.

[0055] The DHCPLEASEQUERY message also includes a giaddr field, which is used to carry the IP address of the BRAS, so that when the DHCP server responds to the DHCPLEASEQUERY message, it sends it to the corresponding BRAS.

[0056] The DHCPLEASEQUERY message also includes parameter options. The parameter options include but are not limited to the following options: parameter request list option (option 55), option 55 includes option 12 for carrying the DHCP client name, lease time option (option 51), renewal time option (option 58), rebinding time option (option 59), vendor information option (option 60), client identification option (option 61) and relay agent information option (option 82).

[0057] The above parameter options can be configured according to the provisions of the existing RFC4388. For example, option 82 includes two sub-options: sub-option 1 (Circuit ID, circuit ID sub-option) and sub-option 2 (Remote ID, remote ID sub-option). Among them, sub-option 1 can be used to carry the location information of the DHCP client.

[0058] In another implementation, the DHCP client is a DHCPv6 client. The first DHCP message generated by the BRAS is specifically a DHCPLEASEQUERY message, which is a DHCPv6 message defined in the existing RFC5007 and is used by the DHCP relay to obtain address information of a designated DHCP client from the DHCPv6 server.

[0059] When the BRAS obtains the address information of a specified DHCP client from the DHCP server, it can use the IPv6 address of the DHCP client or the DUID of the DHCP client as an index (key). In the embodiment of the present application, the BRAS uses the IPv6 address of the DHCP client as an index. The DHCPLEASEQUERY message includes option 5 (option_iaaddr) for carrying the IPv6 address of the DHCP client, and no longer carries the DUID of the DHCP client.

[0060] The DHCPLEASEQUERY message also includes parameter options. The parameter options include but are not limited to the following options: parameter request list option (option 6), option 6 includes option 1 for carrying the DHCP client identification (DUID) option, attribute information of the DHCP client, manufacturer information (option 16), location information option of the DHCP client (option 18), and remote device information option (option 37).

[0061] The above parameter options may be configured according to the provisions of the existing RFC5007. For example, option 37 may be used to carry the MAC address of the BRAS.

[0062] In summary, after receiving the first message sent by the BRAS, the DHCP server obtains the IP address of the DHCP client from the first message.

[0063] The DHCP server identifies whether it manages the IP address of the DHCP client. The DHCP server can determine whether it manages the IP address of the DHCP client by searching the local user table to see whether the DHCP client has been recorded.

[0064] If the DHCP server finds a user entry that matches the IP address locally, the DHCP server determines that it manages the IP address. The DHCP server searches the user entry to see if the lease of the IP address is stored. If the DHCP server finds a user entry that stores the lease of the IP address, the DHCP server generates and sends a second DHCP message to the BRAS.

[0065] Step 230: Receive a second DHCP message sent by the DHCP server after identifying the IP address;

[0066] Specifically, according to the description of step 220, the BRAS receives the second DHCP message sent by the DHCP server.

[0067] The BRAS identifies the type of the second DHCP message. If the type of the DHCP message is the first type, the BRAS executes step 240.

[0068] Step 240: If the type of the second DHCP message is the first type, a first normal user entry corresponding to the DHCP client is generated according to the value of the parameter option included in the second DHCP message, and the state of the first normal user entry is a pending authentication state;

[0069] Specifically, according to the judgment in step 230, if the type of the second DHCP message is the first type, the BRAS generates a first normal user table item corresponding to the DHCP client according to the value of the parameter option included in the second DHCP message. Since the DHCP client has not been authenticated by the 3A server at this time, the first normal user table item has not been fully restored successfully, and the BRAS configures the state of the first normal user table item to be authenticated.

[0070] Since DHCP clients include different types, the formats and fields of the second DHCP message generated by the DHCP server are also different, which are described below respectively.

[0071] In one implementation, the DHCP client is a DHCPv4 client, and the first type of DHCP message generated by the DHCP server specifically refers to a DHCPLEASEACTIVE message, and the DHCPLEASEACTIVE message includes all parameter options included in the aforementioned first DHCP message.

[0072] The DHCPLEASEACTIVE message includes a ciaddr field, which is used to carry the IP address of the DHCP client. The DHCPLEASEACTIVE message also includes parameter options. The parameter options include but are not limited to the following options: parameter request list option (option 55), option 55 includes option 12 for carrying the DHCP client name, lease time option (option 51), renewal time option (option 58), rebinding time option (option 59), vendor information option (option 60), client identification option (option 61) and relay agent information option (option 82).

[0073] It is understandable that option 12, option 60, option 61, and option 82 are the same as those configured in the DHCPLEASEQUERY message. The DHCP server configures the values ​​of option 51, option 58, and option 59 based on the lease of the DHCP client's IP address recorded locally. The value of option 51 is the remaining lease time of the lease; the value of option 58 is the remaining renewal time of the lease; and the value of option 59 is the remaining rebinding time of the lease.

[0074] Further, if the DHCP server determines that it manages the IP address but fails to find the lease storing the IP address in the user table, the DHCP server generates and sends a second DHCP message to the BRAS. The type of the second DHCP message is the second type. The second type of DHCP message specifically refers to a DHCPLEASEUNASSIGNED message, which includes the IP address of the DHCP client, but no longer includes all the parameter options included in the aforementioned first DHCP message.

[0075] The DHCPLEASEUNASSIGNED message includes a ciaddr field, and the ciaddr field is used to carry the IP address of the DHCP client.

[0076] If the DHCP server determines that it does not manage the IP address, the DHCP server generates and sends a second DHCP message to the BRAS. The type of the second DHCP message is the third type. The third type of DHCP message specifically refers to a DHCPLEASEUNKNOWN message, which does not include any other information.

[0077] Furthermore, after receiving the second DHCP message, the BRAS identifies the type of the second DHCP message. If the type of the DHCP message is the second type or the third type, the BRAS generates a first abnormal user table entry, which includes an IP address, a MAC address of the DHCP client, an interface identifier of the interface receiving the first message, and a VLAN identifier to which the interface belongs. The BRAS discards the first message.

[0078] In another implementation, the DHCP client is a DHCPv6 client, and the first type of DHCP message generated by the DHCP server is specifically a LEASEQUERY-REPLY message, and the parameter option in the LEASEQUERY-REPLY message is specifically option 45 (option_client_data), and the value of option 45 is the lease of the IP address.

[0079] Further, if the DHCP server determines that it manages the IP address but fails to find the lease storing the IP address in the user table, the DHCP server generates and sends a second DHCP message to the BRAS. The type of the second DHCP message is the second type. The second type of DHCP message specifically refers to a LEASEQUERY-REPLY message, and option 45 is not included in the LEASEQUERY-REPLY message.

[0080] Furthermore, after receiving the second DHCP message, the BRAS identifies the type of the second DHCP message. If the type of the DHCP message is the second type, the BRAS generates a first abnormal user entry, which includes an IP address, a MAC address of the DHCP client, an interface identifier of the interface receiving the first message, and a VLAN identifier to which the interface belongs. The BRAS discards the first message.

[0081] Step 250: Send an authentication request message to the 3A server, wherein the authentication request message includes the authentication option in the parameter option;

[0082] Specifically, according to the description of step 240, after the BRAS generates the first normal user entry, the BRAS obtains the authentication option from the parameter option included in the second DHCP message. The BRAS generates and sends an authentication request message to the 3A server, and the authentication request message includes the authentication option.

[0083] Since DHCP clients include different types, the formats and fields of the authentication request message generated by the BRAS are also different, which are described below respectively.

[0084] In one implementation manner, the DHCP client is a DHCPv4 client, and the authentication options included in the authentication request message generated by the BRAS are specifically: option 60, option 61, and option 82.

[0085] In another implementation manner, the DHCP client is a DHCPv6 client, and the authentication options included in the authentication request message generated by the BRAS are specifically: option 1, option 16, option 18, and option 37.

[0086] After receiving the authentication request message sent by the BRAS, the 3A server obtains the authentication option from it. The 3A server authenticates the authentication option. The 3A server can search locally for a record that matches the value of the authentication option. If a matching record exists locally, the 3A server determines that the authentication is successful; otherwise, the 3A server determines that the authentication has failed.

[0087] According to the authentication result, the 3A server generates and sends an authentication response message to the BRAS.

[0088] Step 260: receiving an authentication response message sent by the 3A server after identifying the authentication option, wherein the authentication response message includes an authentication result;

[0089] Specifically, according to the description of step 250, the BRAS server receives the authentication response message and obtains the authentication result of the 3A server therefrom.

[0090] Step 270: If the authentication result indicates that the authentication option is authenticated, the state of the first normal user entry is updated to an online state.

[0091] Specifically, according to the description of step 260, the BRAS identifies the authentication result. If the authentication result indicates that the authentication option is authenticated, the BRAS updates the pending authentication state of the first normal table item to the online state. In this way, after the BRAS subsequently receives the IP message / ARP message, or IP message / ND message sent by the DHCP client again, it can process the above message according to the first normal table item. The specific processing process can refer to the existing processing process, which will not be repeated here.

[0092] Optionally, if the authentication result indicates that the authentication option authentication fails, the BRAS deletes the first normal user entry. The BRAS generates a first abnormal user entry, which includes the IP address of the DHCP client, the MAC address of the DHCP client, the interface identifier of the interface receiving the first message, and the VLAN identifier to which the interface belongs. The BRAS discards the first message.

[0093] When the BRAS subsequently receives an IP message / ARP message, or an IPv6 message / ND message sent by the DHCP client, since the BRAS can query the matching abnormal user table entry through the local abnormal user table, at this time, the BRAS does not need to send a DHCPLEASEQUERY message to the DHCP server, and it can directly discard the message sent by the DHCP client.

[0094] Therefore, by applying the communication method provided by the present application, the BRAS receives a first message sent by a DHCP client, the first message including the IP address of the DHCP client; if there is no first abnormal user table entry matching the IP address in the local abnormal user table, the BRAS sends a first DHCP message to the DHCP server, the first DHCP message including the IP address and parameter options; the BRAS receives a second DHCP message sent by the DHCP server after identifying the IP address; if the type of the second DHCP message is the first type, the BRAS generates a first normal user table entry corresponding to the DHCP client according to the value of the parameter option included in the second DHCP message, and the state of the first normal user table entry is a pending authentication state; the BRAS sends an authentication request message to the 3A server, the authentication request message including the authentication option in the parameter option; the BRAS receives an authentication response message sent by the 3A server after identifying the authentication option, the authentication response message including the authentication result; if the authentication result indicates that the authentication option is authenticated, the BRAS updates the state of the first normal user table entry to an online state.

[0095] In this way, the BRAS no longer needs to save the session table entries of the online DHCP clients to local files, which improves the performance of the BRAS and reduces the frequency of flash usage. When replacing the BRAS, it also facilitates the replacement of the BRAS. The BRAS uses the existing standard DHCPv4 / DHCPv6 mechanism to obtain the authentication information of the DHCP client from the DHCP server, and uses the authentication information to authenticate, authorize, and bill the DHCP client at the 3A server to restore the session table entries of the local DHCP client. At the same time, if the BRAS does not obtain the address information of the DHCP client from the DHCP server, it records the abnormal user entry to suppress subsequent messages sent by the DHCP client. This solves the problems exposed by the existing BRAS writing the session table entries of the DHCP client to local files, such as frequent flash write operations, affecting the flash life, some session table entries not being written to the flash, affecting BRAS performance, and consuming BRAS memory.

[0096] Optionally, the embodiment of the present application also includes: a process of deleting local abnormal user entries.

[0097] Specifically, according to the above-mentioned embodiment, the DHCP client initially does not perceive the BRAS abnormality. After the normal user table in the BRAS is not fully restored and the IP address lease of the DHCP client expires, the DHCP client releases the IP address and obtains the IP address from the DHCP server again (the process of obtaining the IP address is the same as the existing process of obtaining the IP address, which will not be repeated here).

[0098] If the BRAS determines that the DHCP client has successfully obtained the IP address from the DHCP server and there is a first abnormal user entry matching the IP address in the local abnormal user table, the BRAS deletes the first abnormal user entry.

[0099] Optionally, the embodiment of the present application also includes: a process in which the BRAS identifies whether the DHCP client is an illegal DHCP client.

[0100] Specifically, in the aforementioned embodiment, the first message also includes the first location information of the DHCP client; the parameter option also includes the location information option (option 82 or option 18) of the DHCP client.

[0101] The above-mentioned location information specifically includes the interface identifier of the received message, the VLAN identifier to which the interface belongs, and the like.

[0102] The BRAS obtains the second location information of the DHCP client from the location information option of the DHCP client included in the second DHCP message. The BRAS compares whether the first location information is the same as the second location information; if the location information is different, the BRAS determines that the DHCP client is an illegal client and discards the first message.

[0103] Based on the same inventive concept, the embodiment of the present application also provides a communication device corresponding to the communication method. Figure 3 , Figure 3 A communication device provided in an embodiment of the present application is applied to a BRAS, the BRAS has been restarted, and the device includes:

[0104] The receiving unit 310 is configured to receive a first message sent by a DHCP client, where the first message includes an IP address of the DHCP client;

[0105] The sending unit 320 is configured to send a first DHCP message to the DHCP server if there is no first abnormal user entry matching the IP address in the local abnormal user table, where the first DHCP message includes the IP address and parameter options;

[0106] The receiving unit 310 is further configured to receive a second DHCP message sent by the DHCP server after the DHCP server identifies the IP address;

[0107] The generating unit 330 is configured to generate a first normal user entry corresponding to the DHCP client according to the value of the parameter option included in the second DHCP message if the type of the second DHCP message is the first type, wherein the state of the first normal user entry is a pending authentication state;

[0108] The sending unit 320 is further configured to send an authentication request message to the 3A server, wherein the authentication request message includes the authentication option in the parameter option;

[0109] The receiving unit 310 is further configured to receive an authentication response message sent by the 3A server after the server identifies the authentication option, wherein the authentication response message includes an authentication result;

[0110] The updating unit 340 is configured to update the state of the first normal user entry to an online state if the authentication result indicates that the authentication option is authenticated.

[0111] Optionally, the device further includes: a first judgment unit (not shown in the figure), configured to judge whether there is the first normal user entry matching the IP address in the local normal user table;

[0112] a second judgment unit (not shown in the figure), configured to judge whether there is the first abnormal user entry matching the IP address in the abnormal user table, if not;

[0113] A discarding unit (not shown in the figure) is used to discard the first message if the first abnormal user entry matching the IP address exists in the abnormal user table.

[0114] Optionally, the generating unit 330 is further configured to, if the type of the second DHCP message is the second type or the third type, generate the first abnormal user entry, wherein the first abnormal user entry includes the IP address, the MAC address of the DHCP client, the interface identifier of the interface receiving the first message, and the VLAN identifier to which the interface belongs;

[0115] The discarding unit (not shown in the figure) is further configured to discard the first message.

[0116] Optionally, the device further includes: a deleting unit (not shown in the figure), configured to delete the first abnormal user entry if the DHCP client has successfully obtained the IP address from the DHCP server and the first abnormal user entry matching the IP address exists in the local abnormal user table.

[0117] Optionally, the first message further includes first location information of the DHCP client; the parameter option further includes a location information option of the DHCP client;

[0118] The device further includes: an acquisition unit (not shown in the figure), configured to acquire the second location information of the DHCP client from the location information option of the DHCP client included in the second DHCP message;

[0119] a comparing unit (not shown in the figure), configured to compare whether the first location information is the same as the second location information;

[0120] The discarding unit (not shown in the figure) is further configured to discard the first message if they are different.

[0121] Optionally, the deleting unit (not shown in the figure) is further configured to delete the first normal user entry if the authentication result indicates that the authentication option authentication fails;

[0122] The generating unit 330 is further configured to generate the first abnormal user entry, wherein the first abnormal user entry includes the IP address, the MAC address of the DHCP client, the interface identifier of the interface receiving the first message, and the VLAN identifier to which the interface belongs;

[0123] The discarding unit (not shown in the figure) is further configured to discard the first message.

[0124] Therefore, by applying the communication device provided by the present application, the BRAS receives a first message sent by a DHCP client, the first message including the IP address of the DHCP client; if there is no first abnormal user table entry matching the IP address in the local abnormal user table, the BRAS sends a first DHCP message to the DHCP server, the first DHCP message including the IP address and parameter options; the BRAS receives a second DHCP message sent by the DHCP server after identifying the IP address; if the type of the second DHCP message is the first type, then according to the value of the parameter option included in the second DHCP message, the BRAS generates a first normal user table entry corresponding to the DHCP client, the state of the first normal user table entry is a pending authentication state; the BRAS sends an authentication request message to the 3A server, the authentication request message including the authentication option in the parameter option; the BRAS receives an authentication response message sent by the 3A server after identifying the authentication option, the authentication response message including the authentication result; if the authentication result indicates that the authentication option is authenticated, the BRAS updates the state of the first normal user table entry to an online state.

[0125] In this way, the BRAS no longer needs to save the session table entries of the online DHCP clients to local files, which improves the performance of the BRAS and reduces the frequency of flash usage. When replacing the BRAS, it also facilitates the replacement of the BRAS. The BRAS uses the existing standard DHCPv4 / DHCPv6 mechanism to obtain the authentication information of the DHCP client from the DHCP server, and uses the authentication information to authenticate, authorize, and bill the DHCP client at the 3A server to restore the session table entries of the local DHCP client. At the same time, if the BRAS does not obtain the address information of the DHCP client from the DHCP server, it records the abnormal user entry to suppress subsequent messages sent by the DHCP client. This solves the problems exposed by the existing BRAS writing the session table entries of the DHCP client to local files, such as frequent flash write operations, affecting the flash life, some session table entries not being written to the flash, affecting BRAS performance, and consuming BRAS memory.

[0126] Based on the same inventive concept, the embodiment of the present application also provides a network device, such as Figure 4 As shown, it includes a processor 410, a transceiver 420 and a machine-readable storage medium 430, the machine-readable storage medium 430 stores machine-executable instructions that can be executed by the processor 410, and the processor 410 is prompted by the machine-executable instructions to execute the communication method provided in the embodiment of the present application. Figure 3 The communication device shown can be used as Figure 4 The network device hardware structure shown is implemented.

[0127] The computer-readable storage medium 430 may include a random access memory (RAM) or a non-volatile memory (NVM), such as at least one disk storage. Optionally, the computer-readable storage medium 430 may also be at least one storage device located away from the processor 410.

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

[0129] In the embodiment of the present application, the processor 410 reads the machine executable instructions stored in the machine readable storage medium 430, and the machine executable instructions enable the processor 410 itself and the transceiver 420 to execute the communication method described in the aforementioned embodiment of the present application.

[0130] In addition, an embodiment of the present application provides a machine-readable storage medium 430, which stores machine-executable instructions. When called and executed by the processor 410, the machine-executable instructions prompt the processor 410 itself and the calling transceiver 420 to execute the address allocation method described in the aforementioned embodiment of the present application.

[0131] The implementation process of the functions and effects of each unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0132] For the device embodiment, since it basically corresponds to the method embodiment, the relevant parts can refer to the partial description of the method embodiment. The device embodiment described above is only schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present application scheme. A person of ordinary skill in the art can understand and implement it without paying any creative work.

[0133] As for the communication device and machine-readable storage medium embodiments, since the method contents involved are basically similar to the aforementioned method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.

[0134] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A communication method, characterized in that: The method is applied to a BRAS, the BRAS has been restarted, and the method includes: Receiving a first message sent by a DHCP client, wherein the first message includes an IP address of the DHCP client; If there is no first abnormal user entry matching the IP address in the local abnormal user table, sending a first DHCP message to the DHCP server, where the first DHCP message includes the IP address and parameter options; receiving a second DHCP message sent by the DHCP server after identifying the IP address; If the type of the second DHCP message is the first type, generating a first normal user entry corresponding to the DHCP client according to the value of the parameter option included in the second DHCP message, where the state of the first normal user entry is a pending authentication state; Sending an authentication request message to a 3A server, wherein the authentication request message includes the authentication option in the parameter option; receiving an authentication response message sent by the 3A server after identifying the authentication option, wherein the authentication response message includes an authentication result; If the authentication result indicates that the authentication option is authenticated, updating the state of the first normal user entry to an online state; Wherein, when the DHCP client is a DHCPv4 client, if the DHCP server determines to manage the IP address and finds the lease of the IP address, the first type indicates that the second DHCP message is specifically a DHCPLEASEACTIVE message; When the DHCP client is a DHCPv6 client, if the DHCP server determines to manage the IP address and finds the lease of the IP address, the first type indicates that the second DHCP message is specifically a LEASEQUERY-REPLY message.

2. The method according to claim 1, characterized in that After receiving the first message sent by the DHCP client, the method further includes: Determine whether there is a first normal user entry matching the IP address in the local normal user table; If not, determining whether there is the first abnormal user entry matching the IP address in the abnormal user table; If the first abnormal user entry matching the IP address exists in the abnormal user table, the first message is discarded.

3. The method according to claim 1, characterized in that The method further comprises: If the type of the second DHCP message is the second type or the third type, generating the first abnormal user entry, the first abnormal user entry including the IP address, the MAC address of the DHCP client, the interface identifier of the interface receiving the first message, and the VLAN identifier to which the interface belongs; discarding the first message; Wherein, when the DHCP client is a DHCPv4 client, if the DHCP server determines that it manages the IP address and does not find a lease for the IP address, the second type indicates that the second DHCP message is specifically a DHCPLEASEUNASSIGNED message; if the DHCP server determines that it does not manage the IP address, the third type indicates that the second DHCP message is specifically a DHCPLEASEUNKNOWN message; When the DHCP client is a DHCPv6 client, if the DHCP server determines to manage the IP address and fails to find a lease for the IP address, the second type indicates that the second DHCP message is specifically a LEASEQUERY-REPLY message.

4. The method according to claim 1, characterized in that: The method further comprises: If the DHCP client has successfully obtained the IP address from the DHCP server and the first abnormal user entry matching the IP address exists in the local abnormal user table, the first abnormal user entry is deleted.

5. The method according to claim 1, characterized in that The first message also includes the first location information of the DHCP client; the parameter option also includes the location information option of the DHCP client; Acquire the second location information of the DHCP client from the location information option of the DHCP client included in the second DHCP message; comparing whether the first location information is the same as the second location information; If they are different, the first message is discarded.

6. The method according to claim 1, characterized in that The method further comprises: If the authentication result indicates that the authentication option authentication fails, deleting the first normal user table entry; Generate the first abnormal user table entry, where the first abnormal user table entry includes the IP address, the MAC address of the DHCP client, the interface identifier of the interface receiving the first message, and the VLAN identifier to which the interface belongs; The first message is discarded.

7. A communication device, characterized in that: The device is applied to a BRAS, the BRAS has been restarted, and the device includes: A receiving unit, configured to receive a first message sent by a DHCP client, wherein the first message includes an IP address of the DHCP client; a sending unit, configured to send a first DHCP message to a DHCP server if there is no first abnormal user entry matching the IP address in the local abnormal user table, wherein the first DHCP message includes the IP address and parameter options; The receiving unit is further configured to receive a second DHCP message sent by the DHCP server after the DHCP server identifies the IP address; a generating unit, configured to generate, if the type of the second DHCP message is the first type, a first normal user entry corresponding to the DHCP client according to the value of the parameter option included in the second DHCP message, wherein the state of the first normal user entry is a pending authentication state; The sending unit is further used to send an authentication request message to the 3A server, wherein the authentication request message includes the authentication option in the parameter option; The receiving unit is further configured to receive an authentication response message sent by the 3A server after the server identifies the authentication option, wherein the authentication response message includes an authentication result; an updating unit, configured to update the state of the first normal user entry to an online state if the authentication result indicates that the authentication option is authenticated; Wherein, when the DHCP client is a DHCPv4 client, if the DHCP server determines to manage the IP address and finds the lease of the IP address, the first type indicates that the second DHCP message is specifically a DHCPLEASEACTIVE message; When the DHCP client is a DHCPv6 client, if the DHCP server determines to manage the IP address and finds the lease of the IP address, the first type indicates that the second DHCP message is specifically a LEASEQUERY-REPLY message.

8. The device according to claim 7, characterized in that The device also includes: A first judging unit, configured to judge whether there is a first normal user entry matching the IP address in a local normal user table; a second judgment unit, configured to judge whether there is a first abnormal user entry matching the IP address in the abnormal user table if the first abnormal user entry does not exist; A discarding unit is used to discard the first message if the first abnormal user entry matching the IP address exists in the abnormal user table.

9. The device according to claim 8, characterized in that The generating unit is further configured to generate the first abnormal user entry if the type of the second DHCP message is the second type or the third type, wherein the first abnormal user entry includes the IP address, the MAC address of the DHCP client, the interface identifier of the interface receiving the first message, and the VLAN identifier to which the interface belongs; The discarding unit is further used to discard the first message; Wherein, when the DHCP client is a DHCPv4 client, if the DHCP server determines that it manages the IP address and does not find a lease for the IP address, the second type indicates that the second DHCP message is specifically a DHCPLEASEUNASSIGNED message; if the DHCP server determines that it does not manage the IP address, the third type indicates that the second DHCP message is specifically a DHCPLEASEUNKNOWN message; When the DHCP client is a DHCPv6 client, if the DHCP server determines to manage the IP address and fails to find a lease for the IP address, the second type indicates that the second DHCP message is specifically a LEASEQUERY-REPLY message.

10. The device according to claim 8, characterized in that The device also includes: The deleting unit is configured to delete the first abnormal user entry if the DHCP client has successfully obtained the IP address from the DHCP server and the first abnormal user entry matching the IP address exists in the local abnormal user table.

11. The device according to claim 8, characterized in that The first message also includes the first location information of the DHCP client; the parameter option also includes the location information option of the DHCP client; The device further includes: an acquiring unit, configured to acquire second location information of the DHCP client from a location information option of the DHCP client included in the second DHCP message; a comparing unit, configured to compare whether the first location information is the same as the second location information; The discarding unit is further configured to discard the first message if they are different.

12. The device according to claim 10, characterized in that The deleting unit is further configured to, if the authentication result indicates that the authentication option authentication fails, delete the first normal user entry; The generating unit is further used to generate the first abnormal user entry, wherein the first abnormal user entry includes the IP address, the MAC address of the DHCP client, the interface identifier of the interface receiving the first message, and the VLAN identifier to which the interface belongs; The discarding unit is further configured to discard the first message.

Images