Method and device for determining out-of-management of network element, and related equipment

Abstract

The embodiment of the invention discloses a method and device for determining out-of-management of a network element and related equipment, and belongs to the technical field of communication. The method comprises the following steps: when a network element receives a first SNMP handshake request message from a first network management unit, a first handshake period set for the first SNMP handshake request message is obtained, so that a subsequent network element can perform handshake according to whether a second SNMP handshake request message from the first network management unit is received in the first handshake period after the current time; and judging whether the managed state of the network element is a network element off-management state or not. Therefore, the embodiment of the invention provides a method for actively detecting whether the network element is out of control or not by the network element, so that the initiative of self-out-of-control detection of the network element is improved, the network element can accurately sense whether the network element is out of control or not, and the flexibility of determining the out-of-control of the network element is improved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of communication technology, and in particular to a method, an apparatus and related equipment for determining whether a network element is out of management. Background Art

[0002] As the number of network elements in the network increases, one or more network managers can be configured in the network to manage the network elements in the network, such as monitoring the performance of the network elements or alarming the abnormalities of the network elements. Network element out-of-management means that the network manager cannot communicate with the network element normally, resulting in the network manager being unable to manage the network element. Based on this, it is necessary to regularly determine whether the network element is in the network element out-of-management state.

[0003] In the related art, the network manager periodically sends a query message to the network element, and the query message is used to query the device information of the network element. If the network manager does not receive a response message to the query message within three consecutive cycles, the network manager can determine that the network element is in a network element unmanaged state. This method has low flexibility. Summary of the invention

[0004] The embodiment of the present application provides a method, device and related equipment for determining whether a network element is out of control, which can be used by the network element to actively detect whether it is out of control, thereby improving the initiative of the network element's own out of control detection. The technical solution is as follows:

[0005] In a first aspect, a method for determining whether a network element is out of management is provided, in which the network element receives a first Simple Network Management Protocol (SNMP) handshake request message from a first network manager; the network element obtains a first handshake cycle corresponding to the first SNMP handshake request message; if the network element fails to receive a second SNMP handshake request message from the first network manager within the first handshake cycle after the current time, the managed state of the network element is determined to be a network element out of management state.

[0006] In an embodiment of the present application, when a network element receives a first SNMP handshake request message from a first network manager, it can obtain a first handshake cycle set for the first SNMP handshake request message, so that subsequent network elements can determine whether the managed state of the network element is in a network element unmanaged state based on whether a second SNMP handshake request message is received from the first network manager within the first handshake cycle after the current time. Therefore, an embodiment of the present application provides a method by which a network element can actively detect whether it is unmanaged, thereby improving the initiative of the network element's own unmanaged detection, enabling the network element to accurately sense whether it is unmanaged, thereby improving the flexibility of determining whether the network element is unmanaged.

[0007] Based on the method provided in the first aspect, in some implementations, the first SNMP handshake request message carries a first object identifier OID and a parameter value corresponding to the first OID, the first OID indicates a first MIB node in a management information base MIB, and the first MIB node indicates a handshake cycle. In this scenario, the implementation process of obtaining the first handshake cycle corresponding to the first SNMP handshake request message may be: determining the first handshake cycle corresponding to the first SNMP handshake request message based on the parameter value corresponding to the first OID.

[0008] In the embodiment of the present application, the MIB node in the MIB may be extended to indicate the handshake cycle, so that the first handshake cycle can be carried in the first SNMP handshake request message.

[0009] Based on the method provided in the first aspect, in some implementations, if the network element fails to receive the second SNMP handshake request message from the first network manager within the first handshake cycle after the current time, the implementation process of determining the managed state of the network element as the network element unmanaged state is as follows: if the network element fails to receive the second SNMP handshake request message within the first handshake cycle after the current time, the handshake state of the first network manager is determined as a handshake timeout state; from the mapping relationship between the handshake state and the network manager identifier, the handshake state of each second network manager in at least one second network manager is obtained, and the first network manager and at least one second network manager are both used to manage the network element; if the handshake state of each second network manager in at least one second network manager is a normal handshake state, the managed state of the network element is determined as an unmanaged state.

[0010] Based on the method provided in the first aspect, in some implementations, if the network element receives a handshake request message from a second SNMP handshake request message within the first handshake cycle after the current time, the handshake status of the first network manager is determined to be a normal handshake status; if the handshake status of the first network manager before receiving the first SNMP handshake request message is an abnormal handshake status, and the handshake status of each second network manager in at least one second network manager is a normal handshake status, the managed status of the network element is updated from the network element unmanaged status to the normal managed status.

[0011] When a network element is managed by multiple network managers at the same time, it is not rigorous to judge whether the network element is out of management based only on the handshake status with a certain network manager. Therefore, when a network element is managed by multiple network managers at the same time, only when the handshake between the network element and all network managers is normal, can it be determined that the network element is in a normal managed state. When a handshake timeout occurs between any network manager and the network element, it is directly determined that the network element is in an out of management state.

[0012] Based on the method provided in the first aspect, in some implementations, the first SNMP handshake request message carries a second OID and a parameter value corresponding to the second OID, the second OID indicates a second MIB node in the management information base MIB, and the second MIB node indicates a network manager identifier. In this scenario, after determining the handshake state of the first network manager as a handshake timeout state, the network element can also determine the network manager identifier of the first network manager based on the parameter value corresponding to the second OID; based on the network manager identifier of the first network manager and the handshake state with the first network manager, update the mapping relationship between the handshake state and the network manager identifier.

[0013] In the embodiment of the present application, the MIB node in the MIB can be extended to indicate the network manager identifier, so that the network manager identifier of the first network manager can be carried in the first SNMP handshake request message, so that the network element can record information such as the handshake status of different network managers.

[0014] Based on the method provided in the first aspect, in some implementations, the first SNMP handshake request message carries a third OID and a parameter value corresponding to the third OID, the third OID indicates a third MIB node in the management information base MIB, and the third MIB node indicates a serial number. In this scenario, before the network element obtains the first handshake cycle corresponding to the first SNMP handshake request message, the network element can also determine the first serial number corresponding to the first SNMP handshake request message based on the parameter value corresponding to the third OID; if the first serial number is greater than or equal to the sum of the target serial number and 1, the operation of obtaining the first handshake cycle corresponding to the first SNMP handshake request message is performed, and the target serial number indicates the maximum value of the serial numbers in the SNMP handshake request messages received before the current time.

[0015] Correspondingly, if the first serial number is smaller than the sum of the target serial number and 1, the first SNMP handshake request message is discarded.

[0016] When the first serial number is greater than or equal to the sum of the target serial number and 1, it indicates that the first SNMP handshake request message is a new SNMP handshake request message, so that the subsequent network element can more accurately judge whether to disconnect the management based on the first handshake cycle corresponding to the first SNMP handshake request message. Correspondingly, when the first serial number is less than the sum of the target serial number and 1, it indicates that the first SNMP message is no longer a new SNMP handshake request message. At this time, it is meaningless to judge whether to disconnect the management based on the first handshake cycle corresponding to the first SNMP handshake request message, so the first SNMP handshake request message is discarded.

[0017] Based on the method provided in the first aspect, in some implementations, after the managed state of the network element is determined to be the network element unmanaged state, the network element can also start collecting logs of each business module in at least one business module; when the managed state of the network element is updated from the network element unmanaged state to the normal managed state, stop collecting logs of each business module in at least one business module.

[0018] In the embodiment of the present application, the network element collects logs of each service module from the beginning to the end of the de-management (i.e., the de-management period). The subsequent operation and maintenance personnel can locate and analyze the cause of the de-management based on the logs during the de-management period.

[0019] Based on the method provided in the first aspect, in some implementations, the first SNMP handshake request message carries a fourth OID and a parameter value corresponding to the fourth OID, the fourth OID indicates a fourth MIB node in the management information base MIB, and the fourth MIB node indicates the network management time. In this scenario, the network element determines the first network management time corresponding to the first network management based on the parameter value corresponding to the fourth OID; the network element determines the time of receiving the first SNMP handshake request message to obtain the first reception time; and the network element stores the corresponding relationship between the first network management time and the first reception time.

[0020] In the embodiment of the present application, the MIB node in the MIB can be extended to indicate the network management time, so that the network management time can be carried in the first SNMP handshake request message. The network element can then reconcile the account based on the corresponding relationship between the first network management time and the first reception time to avoid the problem of mismatch due to the asynchrony between the network management side time and the network element side time.

[0021] On the second aspect, a method for determining whether a network element is off-management is provided, in which a first network manager sends a first Simple Network Management Protocol (SNMP) handshake request message to the network element; wherein the first SNMP handshake request message corresponds to a first handshake cycle, so that if the network element fails to receive a second SNMP handshake request message from the first network manager within the first handshake cycle after receiving the first SNMP handshake request message, the managed state is determined to be the network element off-management state.

[0022] In an embodiment of the present application, when a network element receives a first SNMP handshake request message from a first network manager, it can obtain a first handshake cycle set for the first SNMP handshake request message, so that subsequent network elements can determine whether the managed state of the network element is in a network element unmanaged state based on whether a second SNMP handshake request message is received from the first network manager within the first handshake cycle after the current time. Therefore, an embodiment of the present application provides a method by which a network element can actively detect whether it is unmanaged, thereby improving the initiative of the network element's own unmanaged detection, enabling the network element to accurately sense whether it is unmanaged, thereby improving the flexibility of determining whether the network element is unmanaged.

[0023] Based on the method provided in the second aspect, in some implementations, the first SNMP handshake request message carries a first object identifier OID and a parameter value corresponding to the first OID, the first OID indicates a first MIB node in a management information base MIB, and the first MIB node indicates a handshake period; and / or the first SNMP handshake request message carries a second OID and a parameter value corresponding to the second OID, the second OID indicates a second MIB node in the MIB, and the second MIB node indicates a network management identifier; and / or the first SNMP handshake request message carries a third OID and a parameter value corresponding to the third OID, the third OID indicates a third MIB node in the MIB, and the third MIB node indicates a serial number; and / or the first SNMP handshake request message carries a fourth OID and a parameter value corresponding to the fourth OID, the fourth OID indicates a fourth MIB node in the MIB, and the fourth MIB node indicates the network management time.

[0024] In an embodiment of the present application, some MIB nodes can be extended in the MIB so that some parameters such as the handshake period can be carried in the first SNMP handshake request message. Subsequently, the network element can determine whether it is in an unmanaged state based on these parameters carried in the SNMP handshake request message.

[0025] In a third aspect, a device for determining whether a network element is out of management is provided, the device being deployed in a network element, and the device for determining whether a network element is out of management has the function of implementing the method behavior of determining whether a network element is out of management in the first aspect. The device for determining whether a network element is out of management includes at least one module, and the at least one module is used to implement the method for determining whether a network element is out of management provided in the first aspect.

[0026] In a fourth aspect, a device for determining whether a network element is out of management is provided, the device being deployed in a first network management, and the device for determining whether a network element is out of management has the function of implementing the method behavior of determining whether a network element is out of management in the second aspect. The device for determining whether a network element is out of management includes at least one module, and the at least one module is used to implement the method for determining whether a network element is out of management provided in the second aspect.

[0027] In a fifth aspect, a device for determining that a network element is disconnected is provided, wherein the structure of the device for determining that a network element is disconnected includes a processor and a memory, wherein the memory is used to store a program that supports the device for determining that a network element is disconnected to execute the method for determining that a network element is disconnected provided in the first aspect, and to store data involved in implementing the method for determining that a network element is disconnected provided in the first aspect. The processor is configured to execute the program stored in the memory. The operating device of the storage device may also include a communication bus, which is used to establish a connection between the processor and the memory.

[0028] In a sixth aspect, a device for determining that a network element is disconnected is provided, wherein the structure of the device for determining that a network element is disconnected includes a processor and a memory, wherein the memory is used to store a program that supports the device for determining that a network element is disconnected to execute the method for determining that a network element is disconnected provided in the second aspect, and to store data involved in implementing the method for determining that a network element is disconnected provided in the second aspect. The processor is configured to execute the program stored in the memory. The operating device of the storage device may also include a communication bus, which is used to establish a connection between the processor and the memory.

[0029] In a seventh aspect, a computer-readable storage medium is provided, wherein instructions are stored in the computer-readable storage medium, and when the computer-readable storage medium is executed on a computer, the computer executes the method for determining whether a network element is disconnected from management as described in the first aspect or the second aspect.

[0030] In an eighth aspect, a computer program product comprising instructions is provided, which, when executed on a computer, enables the computer to execute the method for determining whether a network element is disconnected from management as described in the first aspect or the second aspect.

[0031] The technical effects obtained in the above-mentioned third to eighth aspects are similar to the technical effects obtained by the corresponding technical means in the first or second aspect, and will not be repeated here.

[0032] The beneficial effects brought by the technical solution provided by the embodiment of the present application include at least:

[0033] In an embodiment of the present application, when a network element receives a first SNMP handshake request message from a first network manager, it can obtain a first handshake cycle set for the first SNMP handshake request message, so that subsequent network elements can determine whether the managed state of the network element is in a network element unmanaged state based on whether a second SNMP handshake request message is received from the first network manager within the first handshake cycle after the current time. Therefore, an embodiment of the present application provides a method by which a network element can actively detect whether it is unmanaged, thereby improving the initiative of the network element's own unmanaged detection, enabling the network element to accurately sense whether it is unmanaged, thereby improving the flexibility of determining whether the network element is unmanaged. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 It is a flowchart provided by SNMP for determining the managed status of network elements;

[0035] Figure 2 It is a schematic diagram of an implementation environment provided by an embodiment of the present application;

[0036] Figure 3 It is a schematic diagram of an implementation environment based on an access network provided in an embodiment of the present application;

[0037] Figure 4 This is a flow chart of a method for determining that a network element is out of management provided by an embodiment of the present application;

[0038] Figure 5 is a flow chart of another method for determining that a network element is out of management provided by an embodiment of the present application;

[0039] Figure 6 is a flow chart of another method for determining that a network element is out of management provided by an embodiment of the present application;

[0040] Figure 7 It is a schematic diagram of a processing flow for determining the start of disconnection provided by an embodiment of the present application;

[0041] Figure 8 It is a schematic diagram of a processing flow for determining the end of disconnection provided by an embodiment of the present application;

[0042] Fig. 9 This is another schematic diagram of a process for determining that a network element is out of management provided by an embodiment of the present application;

[0043] Fig.10 It is a structural schematic diagram of a device for determining whether a network element is out of management provided by an embodiment of the present application;

[0044] Fig.11 It is a structural schematic diagram of a device for determining whether a network element is out of management provided by an embodiment of the present application;

[0045] Fig.12 This is a schematic diagram of a system for determining network element disconnection provided by an embodiment of the present application;

[0046] Fig.13 It is a structural diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0047] In order to make the purpose, technical solutions and advantages of the present application more clear, the implementation mode of the present application will be further described in detail below with reference to the accompanying drawings.

[0048] For the massive network elements in the existing network, such as access network elements, the network management system (NMS) can centrally monitor the network element performance of these network elements or issue abnormal alarms, so that operation and maintenance personnel can discover network element abnormalities in real time and take necessary recovery measures in time, thereby ensuring the continuous stability of services on the network elements.

[0049] The problem of network element outage often occurs in the existing network. Network element outage means that the network management cannot monitor the network element in real time. For example, if the network element is an optical line terminal (OLT), if a fiber break occurs on the user side during the OLT outage, the OLT cannot report an alarm to the network management, and the operation and maintenance personnel cannot know and handle the fault in the first time, which affects the timely recovery of the service. Therefore, major operators have taken OLT outage as an important assessment indicator and put forward higher requirements for the network element's anti-outage, rapid recovery from outage, and demarcation and positioning capabilities.

[0050] Currently, NMS manages network elements through the simple network management protocol (SNMP), that is, the network manager and the network element communicate through the SNMP protocol to achieve the management of the network element. After a network element is successfully added to the NMS, the network manager in the NMS will periodically send a Get message based on the SNMP protocol to the network element, referred to as an SNMP Get message. Among them, the SNMP Get message carries the object identifier (sysObjectID) of the management information base (MIB) node to be queried. The MIB node is a node defined in the MIB. Each node in the MIB indicates an object. The MIB node to be queried can indicate the device model and / or the manufacturer corresponding to the device model, etc., so as to query the device information of the network element through the SNMP Get message. After receiving the SNMP Get message, the network element returns an SNMP Get response message to the network manager, and the SNMP Get response message carries its own device information.

[0051] In the current SNMP, the network manager determines the managed status of the network element based on whether the SNMP response message returned by the network element is received in time. Figure 1 This is a flowchart provided by SNMP for determining the managed status of network elements. Figure 1 As shown in the figure, the network manager periodically sends SNMP get messages. If the network manager receives the SNMP get response message from the network element side normally, the network manager determines that the managed state of the network element is "normally managed". If the network manager does not receive the SNMP get response message from the network element side within three consecutive cycles, the network manager determines that the managed state of the network element is "network element out of management".

[0052] The method for determining whether a network element is out of management provided in the embodiment of the present application is applied to the above-mentioned SNMP-based NMS. In the embodiment of the present application, when a network element receives a first SNMP handshake request message from a first network manager, it can obtain a first handshake period set for the first SNMP handshake request message, so that subsequent network elements can determine whether the managed state of the network element is in a network element out of management state based on whether a second SNMP handshake request message is received from the first network manager within the first handshake period after the current time. Therefore, the embodiment of the present application provides a method by which a network element can actively detect whether it is out of management, thereby improving the initiative of the network element's own out of management detection, enabling the network element to accurately sense whether it is out of management, thereby improving the flexibility of determining whether the network element is out of management.

[0053] The implementation environment of the embodiments of the present application is explained below.

[0054] Figure 2 This is a schematic diagram of an implementation environment provided by the embodiment of the present application. Figure 2 As shown, the implementation environment includes at least one network manager 201 and multiple network elements 202. Each network manager 201 communicates with part or all of the multiple network elements 202 to monitor the operation status of these network elements 202.

[0055] In the embodiment of the present application, any pair of network management 201 and network element 202 communicates based on SNMP to manage the network element through SNMP.

[0056] in, Figure 2 The implementation environment shown can be applied in any network, and can be an access network by way of example. Figure 3 FIG. 1 is a schematic diagram of an implementation environment based on an access network provided by an embodiment of the present application. Figure 3 As shown, the implementation environment includes an access network element 301 , a forwarding node 302 and an access network management 303 . Figure 3 An access network element 301 and an access network management 303 are used as an example for description. Optionally, Figure 3 The implementation environment shown may include a greater number of access network elements 301 and a greater number of access network managers 303 .

[0057] The access network element 301 may include, for example, a multiple dwelling unit (MDU), an OLT, a digital subscriber line access multiplexer (DSLAM), and a multi-service access network (MSAN). The access network element 301 is monitored by the access network management 303. It mainly provides services such as internet protocol television (IPTV), voice, Internet access, and dedicated lines.

[0058] The forwarding node 302 illustratively includes a router and a switch, etc. The forwarding node 302 is used to connect the access network element 301 to the network and reach the access network management 303 .

[0059] The access network management 303 may include, for example, a network cloud engine (NCE), etc. The access network management 303 is responsible for the operation, management, and maintenance of the access network element 301, etc.

[0060] It should be noted that Figure 3 This is an example implementation environment of the embodiment of the present application. Other types of network elements in the network and corresponding network management can also apply the method provided by the embodiment of the present application, and will not be illustrated one by one here.

[0061] The following is an explanation of the method for determining network element disconnection provided in an embodiment of the present application.

[0062] Figure 4 1 is a flow chart of a method for determining a network element out of management provided by an embodiment of the present application. Figure 4 As shown, the method includes the following steps.

[0063] Step 401: A network element receives a first SNMP handshake request message from a first network manager.

[0064] Step 402: The network element obtains a first handshake cycle corresponding to the first SNMP handshake request message.

[0065] Step 403: If the network element fails to receive the second SNMP handshake request message from the first network manager within the first handshake cycle after the current time, the managed state of the network element is determined as the network element unmanaged state.

[0066] In an embodiment of the present application, when a network element receives a first SNMP handshake request message from a first network manager, it can obtain a first handshake cycle set for the first SNMP handshake request message, so that subsequent network elements can determine whether the managed state of the network element is in a network element unmanaged state based on whether a second SNMP handshake request message is received from the first network manager within the first handshake cycle after the current time. Therefore, an embodiment of the present application provides a method by which a network element can actively detect whether it is unmanaged, thereby improving the initiative of the network element's own unmanaged detection, enabling the network element to accurately sense whether it is unmanaged, thereby improving the flexibility of determining whether the network element is unmanaged.

[0067] Figure 5 is a flow chart of another method for determining that a network element is disconnected from management provided by an embodiment of the present application. Figure 5 As shown, the method includes the following steps.

[0068] Step 501: The first network manager sends a first SNMP handshake request message to the network element; wherein the first SNMP handshake request message corresponds to a first handshake cycle, so that if the network element fails to receive a second SNMP handshake request message from the first network manager within the first handshake cycle after receiving the first SNMP handshake request message, the managed state is determined as the network element unmanaged state.

[0069] In an embodiment of the present application, when a network element receives a first SNMP handshake request message from a first network manager, it can obtain a first handshake cycle set for the first SNMP handshake request message, so that subsequent network elements can determine whether the managed state of the network element is in a network element unmanaged state based on whether a second SNMP handshake request message is received from the first network manager within the first handshake cycle after the current time. Therefore, an embodiment of the present application provides a method by which a network element can actively detect whether it is unmanaged, thereby improving the initiative of the network element's own unmanaged detection, enabling the network element to accurately sense whether it is unmanaged, thereby improving the flexibility of determining whether the network element is unmanaged.

[0070] Figure 6 is a flow chart of another method for determining that a network element is disconnected from management provided by an embodiment of the present application. Figure 6 As shown, the method includes the following steps.

[0071] Step 601: A first network manager sends a first SNMP handshake request message to a network element.

[0072] The first network manager may be any network manager for managing network elements. The first SNMP handshake request message corresponds to a first handshake cycle. The first handshake cycle may be understood as the maximum handshake cycle allowed by the network manager, so that subsequent network elements can actively detect whether they are out of management based on the first handshake cycle.

[0073] In the embodiment of the present application, the first SNMP handshake request message may be an SNMP set message. In this scenario, each time the first network manager sends an SNMP set message to the network element, it is called the first network manager performing a handshake on the network element. Optionally, the first SNMP handshake request message may also be implemented by other forms of SNMP messages, which will not be described one by one here.

[0074] In some embodiments, the first handshake period may be carried in the first SNMP handshake request message, so that when the network element receives the first SNMP handshake request message, it can directly parse the first SNMP handshake request message to obtain the first handshake period.

[0075] For example, the first SNMP handshake request message carries a first object identifier OID and a parameter value corresponding to the first OID, the first OID indicates a first MIB node in the management information base MIB, and the first MIB node indicates a handshake cycle. At this time, the parameter value corresponding to the first OID can indicate the first handshake cycle.

[0076] In the embodiment of the present application, the MIB node in the MIB may be extended to indicate the handshake cycle, so that the first handshake cycle can be carried in the first SNMP handshake request message.

[0077] In addition, the same network element can usually be managed by multiple network managers. In this scenario, the network manager identifier of the first network manager can also be carried in the first SNMP handshake request message, so that the network element can record some information related to the first network manager, such as the aforementioned first handshake cycle, etc. The network manager identifier can be, for example, the Internet protocol (IP) address of the network manager.

[0078] For example, the first SNMP handshake request message carries the second OID and a parameter value corresponding to the second OID, the second OID indicates a second MIB node in the MIB, and the second MIB node indicates a network management identifier. At this time, the parameter value corresponding to the second OID can indicate the network management identifier of the first network management.

[0079] In the embodiment of the present application, the MIB node in the MIB may be extended to indicate the network manager identifier, so that the network manager identifier of the first network manager can be carried in the first SNMP handshake request message.

[0080] In addition, in some embodiments, the serial number of the first SNMP handshake request message can also be carried in the first SNMP handshake request message, and the serial number is used to indicate the sequence of the SNMP handshake request messages exchanged between the first network management and the network element, so that the subsequent network element can judge whether the currently received SNMP handshake request message is the latest handshake request message based on the serial number to determine whether the handshake request message needs to be further processed. The detailed implementation method is described in the subsequent embodiments and will not be described in detail here.

[0081] For example, the first SNMP handshake request message carries a third OID and a parameter value corresponding to the third OID, the third OID indicates a third MIB node in the MIB, and the third MIB node indicates a serial number. At this time, the parameter value corresponding to the third OID can indicate the serial number of the first SNMP handshake request message.

[0082] In the embodiment of the present application, the MIB node in the MIB may be extended to indicate the serial number so that the serial number can be carried in the first SNMP handshake request message.

[0083] In addition, in some embodiments, the first SNMP handshake request message may also carry time information on the network management side, such as the time when the network manager sends the first SNMP handshake request message. This time may be called the network management time, so that subsequent network elements can reconcile based on the network management time carried in the first SNMP handshake request message and their own time.

[0084] For example, the first SNMP handshake request message carries a fourth OID and a parameter value corresponding to the fourth OID, the fourth OID indicates a fourth MIB node in the MIB, and the fourth MIB node indicates the network management time;

[0085] In the embodiment of the present application, the MIB node in the MIB may be extended to indicate the network management time, so that the network management time can be carried in the first SNMP handshake request message.

[0086] In summary, in an embodiment of the present application, some MIB nodes can be extended in the MIB so that the first SNMP handshake request message carries some parameters such as the handshake period. Subsequently, the network element can determine whether it is in an unmanaged state based on these parameters carried in the SNMP handshake request message.

[0087] Table 1 is a schematic table of an extended MIB node provided in an embodiment of the present application. As shown in Table 1, four MIB nodes are extended in the MIB to indicate the network management IP, handshake cycle, serial number and network management time respectively. The functions of these four MIBs can refer to the above content and will not be repeated here.

[0088] Table 1

[0089]

[0090]

[0091] It should be noted that Table 1 is described by taking the expansion of four MIB nodes as an example. Optionally, in the embodiment of the present application, more or fewer MIB nodes may be expanded to carry the required parameters, which will not be described one by one here.

[0092] In addition, referring to the MIB nodes in the existing MIB, the MIB nodes expanded this time can be put under the MIBhwDevSnmpProbeMonitor MIB node, that is, the expanded MIB nodes are subnodes of the MIB node. The definition of the expanded MIB nodes can be put in files such as HUAWEI-DEVICE-AN-MIB.mib.

[0093] Step 602: The network element obtains a first handshake cycle corresponding to the first SNMP handshake request message.

[0094] Based on step 601, it can be known that in a scenario where the first SNMP handshake request message carries a first object identifier OID and a parameter value corresponding to the first OID, the implementation method for obtaining the first handshake cycle corresponding to the first SNMP handshake request message can be: based on the parameter value corresponding to the first OID, determine the first handshake cycle corresponding to the first SNMP handshake request message.

[0095] For example, the parameter value corresponding to the first OID may be directly used as the first handshake cycle. Alternatively, the parameter value corresponding to the first OID may be processed according to a certain rule and used as the first handshake cycle.

[0096] Optionally, when the first SNMP handshake request message does not carry the first handshake period, in this scenario, the first handshake period can be pre-configured on the network element, and the network element can directly obtain the first handshake period from local storage. For example, when the network is initialized, the handshake period for all SNMP handshake request messages is pre-configured on the network element, so that the subsequent network element can directly determine whether it is in a disconnected state based on the configured handshake period.

[0097] In addition, in the scenario where the first SNMP handshake request message carries a third OID and a parameter value corresponding to the third OID, the third OID indicates a third MIB node in the MIB, and the third MIB node indicates a serial number, before the network element obtains the first handshake cycle corresponding to the first SNMP handshake request message, it can also determine the first serial number corresponding to the first SNMP handshake request message based on the parameter value corresponding to the third OID; if the first serial number is greater than or equal to the sum of the target serial number and 1, the operation of obtaining the first handshake cycle corresponding to the first SNMP handshake request message is performed, and the target serial number indicates the maximum value of the serial numbers in the SNMP handshake request messages received before the current time. Accordingly, if the first serial number is less than the sum of the target serial number and 1, the first SNMP handshake request message is discarded.

[0098] When the first serial number is greater than or equal to the sum of the target serial number and 1, it indicates that the first SNMP handshake request message is a new SNMP handshake request message, so that the subsequent network element can more accurately judge whether to disconnect the management based on the first handshake cycle corresponding to the first SNMP handshake request message. Correspondingly, when the first serial number is less than the sum of the target serial number and 1, it indicates that the first SNMP message is no longer a new SNMP handshake request message. At this time, it is meaningless to judge whether to disconnect the management based on the first handshake cycle corresponding to the first SNMP handshake request message, so the first SNMP handshake request message is discarded.

[0099] Step 603: If the network element fails to receive the second SNMP handshake request message from the first network manager within the first handshake cycle after the current time, the managed state of the network element is determined as the unmanaged state of the network element.

[0100] Since the first SNMP handshake request message corresponds to the first handshake cycle, when the network element receives the first SNMP handshake request message from the first network manager, it can determine whether the managed state of the network element is in the unmanaged state based on whether the second SNMP handshake request message from the first network manager is received within the first handshake cycle after the current time.

[0101] Correspondingly, if the network element receives the second SNMP handshake request message within the allowed handshake waiting time after the current time, the managed state is determined to be a normal managed state.

[0102] In addition, in an embodiment of the present application, after the network element detects that it is out of management, it can also start collecting logs of each business module in at least one business module; when the managed state of the network element is updated from the network element out of management state to the normal managed state, it stops collecting logs of each business module in at least one business module.

[0103] Among them, at least one service module is a service module configured on a network element, and each service module is used to implement a service on the network element.

[0104] The event when the network element detects that the disconnected state is updated from the normal managed state to the network element disconnected state is called the start of disconnection, and the event when the network element detects that the disconnected state is updated from the network element disconnected state to the normal managed state is called the end of disconnection. In an embodiment of the present application, the network element collects logs of each business module during the period from the start of disconnection to the end of disconnection (i.e., the disconnection period). Subsequent operation and maintenance personnel can locate and analyze the cause of disconnection based on the logs during the disconnection period.

[0105] When a network element is managed by only one network manager, the above operation can quickly determine whether the network element is in the network element out-of-management state. When a network element is managed by multiple network managers at the same time, it is not rigorous to determine whether the network element is in the out-of-management state only based on the handshake status with a certain network manager. Therefore, when a network element is managed by multiple network managers at the same time, the managed state is defined as shown in the following Table 2.

[0106] Table 2

[0107]

[0108] That is, when a network element is managed by multiple network managers at the same time, only when the handshake between the network element and all network managers is normal, the network element is determined to be in a normal managed state. When the handshake between any network manager and the network element times out, the network element is directly determined to be in a network element unmanaged state.

[0109] In addition, when a network element is managed by multiple network managers at the same time, in order to facilitate the query of information such as the handshake status of each network manager, the embodiment of the present application provides a network manager record table for the network element. The network manager record table is used to record information of each network manager in at least one network manager that manages the network element, such as the handshake status of each network manager, the network manager identification of each network manager, and the handshake cycle of each network manager.

[0110] The handshake status includes a normal handshake and a handshake timeout. The explanations of the normal handshake and the handshake timeout can refer to the explanations shown in the following Table 3.

[0111] Table 3

[0112]

[0113] Table 4 is a schematic illustration of the definition of the beginning and end of de-management when a network element is managed by multiple network managers, provided by an embodiment of the present application. As shown in Table 4, among all network managers that shake hands with the network element, once a network manager handshake times out, it is considered that de-management has begun. Among all network managers that shake hands with the network element, if all network managers that have handshake timeouts return to normal handshakes, it is considered that de-management has ended.

[0114] In addition, as shown in Table 4, when the network element detects the beginning of the out-of-management, it can also send a "network element out-of-management" alarm message to other devices, so that the operation and maintenance personnel can maintain the network element in time. Correspondingly, when the network element detects the end of the out-of-management, it can also send a "normal management" recovery alarm message to other devices to notify the operation and maintenance personnel that the current network element has returned to the normal management state.

[0115] Table 4

[0116]

[0117] Based on this, the implementation method of step 603 can be: if the network element fails to receive the second SNMP handshake request message within the first handshake cycle after the current time, the handshake status of the first network manager is determined to be a handshake timeout state; from the mapping relationship between the handshake status and the network manager identifier, the handshake status of each second network manager in at least one second network manager is obtained, and the first network manager and at least one second network manager are both used to manage the network element; if the handshake status of each second network manager in at least one second network manager is a normal handshake state, the managed state of the network element is determined to be a network element unmanaged state.

[0118] Among them, determining the managed state of the network element as the unmanaged state can include two understandings. One understanding is to update the managed state of the network element from the normal managed state to the unmanaged state of the network element. In this scenario, before the current time, the handshake between the network element and all network managers (including the first network manager) is normal. Another understanding is to keep the managed state of the network element as the unmanaged state of the network element. In this scenario, before the current time, the handshake between the network element and the first network manager has already experienced a handshake timeout problem.

[0119] That is, as long as the handshake between one of all network managers and the network element times out, it is determined that the managed state of the network element is the network element unmanaged state.

[0120] Optionally, if the network element fails to receive a second SNMP handshake request message within the first handshake cycle after the current time, the handshake status of the first network manager is determined to be a handshake timeout state; the handshake status of each second network manager in at least one second network manager is obtained from the mapping relationship between the handshake status and the network manager identifier, and the first network manager and at least one second network manager are both used to manage the network element; if the handshake status of one or more second network managers in at least one second network manager is a handshake timeout state, it indicates that the managed state of the network element before the current time was already a network element unmanaged state, and therefore the managed state of the network element is maintained in the network element unmanaged state.

[0121] Optionally, if the network element receives a handshake request message from a second SNMP handshake request message within the first handshake cycle after the current time, the handshake status of the first network manager is determined to be a normal handshake status; if the handshake status of the first network manager before receiving the first SNMP handshake request message is an abnormal handshake status, and the handshake status of each second network manager in at least one second network manager is a normal handshake status, the managed status of the network element is updated from the network element unmanaged status to the normal managed status.

[0122] That is, only when the handshakes between all network managers and network elements are normal, the managed state of the network element will be determined as the normal managed state.

[0123] Optionally, if the network element receives a handshake request message from a second SNMP handshake request message within the first handshake cycle after the current time, the handshake status of the first network manager is determined to be a normal handshake status; in this case, if the handshake status of one or more second network managers in at least one second network manager is a handshake timeout status, it indicates that the managed state of the network element before the current time is already a network element unmanaged state, and therefore the managed state of the network element is maintained in the network element unmanaged state.

[0124] In addition, in order to facilitate the subsequent rapid determination of whether the network element is in an unmanaged state when receiving an SNMP handshake request message sent by other network managers, the handshake state of the first network manager can also be updated to the mapping relationship between the handshake state and the network manager identifier. Among them, the network manager identifier and handshake state in each table item in the aforementioned network manager record table can be regarded as a type of mapping relationship between the handshake state and the network manager identifier.

[0125] In some embodiments, in a scenario where the first SNMP handshake request message carries a second OID and a parameter value corresponding to the second OID, the second OID indicates a second MIB node in the MIB, and the second MIB node indicates a network manager identifier, after the network element determines the handshake status of the first network manager as a handshake timeout status, it also determines the network manager identifier of the first network manager based on the parameter value corresponding to the second OID; and based on the network manager identifier of the first network manager and the handshake status of the first network manager, updates the mapping relationship between the handshake status and the network manager identifier.

[0126] Among them, determining the network manager identifier of the first network manager based on the parameter value corresponding to the second OID can be understood as directly using the parameter value corresponding to the second OID as the network manager identifier of the first network manager, or processing the parameter value corresponding to the second OID according to certain rules as the network manager identifier of the first network manager.

[0127] In addition, based on the network manager identifier of the first network manager and the handshake status of the first network manager, the implementation method for updating the mapping relationship between the handshake status and the network manager identifier can be: when the network manager identifier of the first network manager already exists in the mapping relationship, it indicates that the first SNMP message is not the SNMP message of the first network manager that the network element receives for the first time, and at this time, the handshake status corresponding to the network manager identifier of the first network manager in the mapping relationship can be directly updated. When the network manager identifier of the first network manager does not exist in the mapping relationship, it indicates that the first SNMP message is the SNMP message of the first network manager that the network element receives for the first time, and at this time, the network manager identifier of the first network manager and the handshake status of the first network manager are added to the mapping relationship between the handshake status and the network manager identifier.

[0128] Figure 7 1 is a schematic diagram of a process flow for determining the start of disconnection provided by an embodiment of the present application. Figure 7 As shown, the network element configures a handshake timer for each network manager in the network manager record table, and the timing duration of the handshake timer is the handshake cycle corresponding to the last SNMP message received from the corresponding network manager. If a new SNMP handshake request message from a network manager has not been received after the handshake timer of a certain network manager times out, check the handshake status of the network manager in the network manager record table. If the handshake status of the network manager in the network manager record table is already a handshake timeout state, it indicates that before the current time, the network element has entered the network element unmanaged state due to the handshake timeout of the network manager. Therefore, there is no need to update the managed state of the network element, and the handshake timer is directly restarted. The timing duration is still the handshake cycle corresponding to the last SNMP message received from the network manager.

[0129] If the handshake status of the network manager in the network manager record table is a normal handshake status, then update the handshake status of the network manager in the network manager record table. Then, determine whether the network manager is the first network manager whose handshake times out based on the handshake status of other network managers in the network manager record table. If the network manager is the first network manager whose handshake times out, it indicates that the network element is currently entering the network element out-of-management state, so a network element out-of-management alarm message can be sent and logs on each business module can be collected. If the network manager is not the first network manager whose handshake times out, it indicates that the network element has entered the network element out-of-management state due to handshake timeouts of other network managers before the current time, so there is no need to update the managed state of the network element, and the handshake timer for the network manager can be directly restarted.

[0130] Figure 8 1 is a schematic diagram of a processing flow for determining the end of disconnection provided by an embodiment of the present application. Figure 8As shown, when the network element receives an SNMP handshake request message from a certain network manager, it first replies to the network manager with an SNMP handshake response message. At the same time, the data in the SNMP handshake request message, such as the network manager IP, handshake cycle, and serial number, are extracted. According to the network manager record table, it is determined whether the network manager is a new network manager, that is, whether the network manager IP is in the network manager record table. If not, it is determined that the network manager is a new network manager. At this time, a new table entry is added to the network manager record table, and the table entry index is the network manager IP, and the handshake cycle and serial number and other information are filled in the table entry.

[0131] If the network manager is not a new network manager and the SNMP handshake request message is received within the handshake period, the network manager continues to determine the currently extracted serial number ( Figure 8 The current serial number is marked in the figure) is greater than or equal to the sum of the target serial number and 1. If this condition is met, then continue to determine whether the handshake status of the network manager in the network manager record table is a handshake timeout state. If it is a handshake timeout state, it indicates that the network manager has recovered from a handshake timeout to a normal handshake. Therefore, the normal handshake event of the network manager can be recorded, and it can be determined whether the network manager is the last network manager to recover from a handshake timeout among the network managers that have had a handshake timeout. If the network manager is the last network manager to recover from a handshake timeout among the network managers that have had a handshake timeout, it indicates that the management is over. At this time, the network element stops collecting logs of each business module, sends a normal management recovery alarm message, and updates the handshake status of the network manager in the network manager record table. And restart the handshake timer for the network manager, and the timing duration is the handshake period in the SNMP handshake request message, which serves as the basis for subsequent judgment of whether the network manager handshake has timed out.

[0132] Correspondingly, if the currently extracted serial number is smaller than the sum of the target serial number and 1, it indicates that the SNMP handshake request message is not a new SNMP handshake request message, and the SNMP handshake request message can be discarded at this time.

[0133] like Figure 8 As shown, if the handshake status of the network manager in the network manager record table is a normal handshake status, the handshake timer for the network manager can be directly restarted. The timing duration is the handshake period in the SNMP handshake request message, which is used as a basis for subsequent judgment on whether the network manager handshake has timed out.

[0134] like Figure 8 As shown, if the network manager is not the last network manager among the network managers whose handshake has timed out to recover to the handshake timeout, in other words, there are other network managers whose handshake status is the handshake timeout status in the network manager record table, this indicates that the disconnection has not yet ended. Therefore, you can directly restart the handshake timer for the network manager. The timing duration is the handshake period in the SNMP handshake request message, which will serve as the basis for subsequent judgment on whether the network manager handshake has timed out.

[0135] In addition, in an embodiment of the present application, in a scenario where the first SNMP handshake request message carries a fourth OID and a parameter value corresponding to the fourth OID, the fourth OID indicates a fourth MIB node in the MIB, and the fourth MIB node indicates the network management time, the network element can determine the first network management time corresponding to the first network management based on the parameter value corresponding to the fourth OID; the network element determines the time of receiving the first SNMP handshake request message to obtain the first reception time; and the network element stores the correspondence between the first network management time and the first reception time.

[0136] The network element can then perform reconciliation based on the correspondence between the first network management time and the first receiving time to avoid the problem of mismatching due to the asynchrony between the network management side time and the network element side time.

[0137] Among them, based on the parameter value corresponding to the fourth OID, determining the first network management time corresponding to the first network management can be understood as directly using the parameter value corresponding to the fourth OID as the first network management time, or processing the parameter value corresponding to the fourth OID according to certain rules as the first network management time.

[0138] Below Fig. 9 Take the example to illustrate the method for determining network element disconnection provided in the embodiment of the present application. Fig. 9 FIG. 1 is another flow chart of determining that a network element is disconnected from management provided by an embodiment of the present application. Fig. 9 As shown, the process includes the following steps.

[0139] 1. The network element receives the first SNMP handshake request message R1 sent by the first network manager. R1 includes: network manager IP, handshake cycle, network manager time, serial number and other information. Fig. 9 As shown, the SNMP handshake request message is an SNMP setting message.

[0140] 2. The network element immediately replies with the SNMP handshake response message P1. Fig. 9 As shown, the SNMP handshake request response message is an SNMP setting response message.

[0141] The network element queries the network manager record table based on the network manager IP in R1. Because this is the first handshake request message from the network manager, there is no entry for the network manager in the network manager record table. The network element allocates an entry in the network manager record table to the network manager. The entry index is the network manager IP, and the handshake cycle, network manager time, serial number (the serial number corresponding to the first handshake request message is 1) in R1 are recorded in the entry. In addition, the network manager also sets the handshake status of the network manager in the entry to "handshake normal". The handshake timer for the network manager is started, and the timing duration is the handshake cycle T1 in R1, which is the handshake cycle for the network manager in the network manager record table.

[0142] At this time, the managed state of the network element is still the initial state, which is the "normal management" state.

[0143] 3. Before the handshake timer times out, the network element receives the second SNMP handshake request message R2 from the network manager, with serial number 2.

[0144] 4. The network element immediately replies with an SNMP handshake response message P2.

[0145] The network element queries the network management record table based on the network management IP in R2. The serial number recorded in the network management record table is 1, and the serial number of R2 received this time is 2, indicating that R2 is a new handshake request message, so continue to process R2 (if it is not a new handshake request message, ignore the handshake request message and stop subsequent processing). The handshake status of the network management in the network management record table is "handshake normal". Since this handshake is normal, there is no need to trigger the handshake status migration of the network management.

[0146] For ease of description, it is assumed that at this time the network element still only receives the SNMP handshake request message from one network manager, and the system has no "other" network manager shaking hands with the network element. The handshake status of the system's only network manager is "normal handshake", so the managed status of the network element remains "normally managed".

[0147] Start the handshake timer of the network management, with the duration being the handshake period T2 in R2.

[0148] 5. The handshake timer times out, but the network element does not receive the third SNMP handshake request message from the network manager.

[0149] The handshake status of the network manager in the network management record table is "Normal handshake". This handshake waiting timeout event triggers the handshake status of the network manager to change to "Handshake timeout" and records the network manager "Handshake timeout" event log. Since there is only one network manager at present, the network manager handshake timeout event triggers the managed state of the network element to change to "Network element out of management".

[0150] Restart the handshake timer of the network management, the duration is the handshake period T3, T3 can be equal to T2.

[0151] Send a "network element out of management" alarm message.

[0152] Each business module starts network management link monitoring and begins collecting real-time logs.

[0153] 6. Before the handshake timer times out, the network element receives the fourth SNMP handshake request message R4 from the network manager, with serial number 4.

[0154] 7. The network element immediately replies with an SNMP handshake response message P4.

[0155] The network element queries the network management record table based on the network management IP in R4.

[0156] The serial number recorded in the network management record table is 2, and the serial number of this SNMP handshake request message R4 is 4. 4>2, so it is a new handshake request message, and the message continues to be processed.

[0157] The handshake status of the network manager in the network manager record table is "handshake timeout". This handshake is normal, so it triggers the handshake status of the network manager to migrate to "handshake normal", and records the "handshake normal" event log of the network manager.

[0158] Start the handshake timer of the network management, the duration of which is the handshake period T4 in R4.

[0159] The managed state of the network element is "network element unmanaged". Assuming that the network element still only receives a handshake request message from a network manager at this time, the "normal handshake" state of the network manager is used as the "unmanaged end" event, triggering the managed state of the network element to change to "normal management".

[0160] Send a "normal management" recovery alarm message.

[0161] Stop each service module from starting network management link monitoring and stop real-time log collection.

[0162] In summary, the embodiment of the present application provides a new heartbeat keep-alive mechanism. In this mechanism, when the network element receives the first SNMP handshake request message from the first network manager, the first handshake cycle set for the first SNMP handshake request message can be obtained, so that the subsequent network element can determine whether the managed state of the network element is in the network element disconnected state according to whether the second SNMP handshake request message from the first network manager is received within the first handshake cycle after the current time. Therefore, the embodiment of the present application provides a method by which the network element can actively detect whether it is disconnected, improve the initiative of the network element's own disconnection detection, and enable the network element to accurately sense whether it is disconnected, thereby improving the flexibility of determining whether the network element is disconnected. And timely collect logs during the disconnection period, providing a basis for the rapid discovery and location of such faults.

[0163] Fig.10 is a schematic diagram of a structure of a device for determining whether a network element is out of management provided by an embodiment of the present application. The device is deployed in a network element, such as Fig.10 As shown, the device 1000 includes the following modules.

[0164] The receiving module 1001 is used to receive a first simple network management protocol SNMP handshake request message from a first network manager; the specific implementation method can refer to Figure 6 Step 601 in the embodiment.

[0165] The acquisition module 1002 is used to acquire the first handshake cycle corresponding to the first SNMP handshake request message; the specific implementation method can refer to Figure 6 Step 602 in an embodiment.

[0166] The first determination module 1003 is used to determine the managed state of the network element as the unmanaged state of the network element if the second SNMP handshake request message from the first network manager is not received within the first handshake cycle after the current time. Figure 6 Step 603 in the embodiment.

[0167] Optionally, the first SNMP handshake request message carries a first object identifier OID and a parameter value corresponding to the first OID, the first OID indicates a first MIB node in a management information base MIB, and the first MIB node indicates a handshake cycle;

[0168] The acquisition module is used to:

[0169] Based on the parameter value corresponding to the first OID, a first handshake cycle corresponding to the first SNMP handshake request message is determined.

[0170] Optionally, the first determining module is used to:

[0171] If the second SNMP handshake request message is not received within the first handshake cycle after the current time, the handshake state of the first network management is determined as a handshake timeout state;

[0172] Acquire the handshake state of each second network manager in at least one second network manager from the mapping relationship between the handshake state and the network manager identifier, wherein the first network manager and the at least one second network manager are both used to manage network elements;

[0173] If the handshake state of each second network manager in the at least one second network manager is a normal handshake state, the managed state of the network element is determined to be a disconnected state.

[0174] Optionally, the first determining module is further used for:

[0175] If the network element receives a second SNMP handshake request message within a first handshake cycle after the current time, the handshake state of the first network management is determined as a normal handshake state;

[0176] If the handshake status of the first network manager before receiving the first SNMP handshake request message is an abnormal handshake status, and the handshake status of each second network manager in at least one second network manager is a normal handshake status, the managed status of the network element is updated from the network element unmanaged status to the normal managed status.

[0177] Optionally, the first SNMP handshake request message carries a second OID and a parameter value corresponding to the second OID, the second OID indicates a second MIB node in the management information base MIB, and the second MIB node indicates a network management identifier;

[0178] The device also includes:

[0179] A second determining module, configured to determine a network management identifier of the first network management based on a parameter value corresponding to the second OID;

[0180] The updating module is used to update the mapping relationship between the handshake status and the network manager identifier based on the network manager identifier of the first network manager and the handshake status with the first network manager.

[0181] Optionally, the first SNMP handshake request message carries a third OID and a parameter value corresponding to the third OID, the third OID indicates a third MIB node in the management information base MIB, and the third MIB node indicates a serial number;

[0182] The device also includes:

[0183] A third determining module, configured to determine a first serial number corresponding to the first SNMP handshake request message based on a parameter value corresponding to the third OID;

[0184] The acquisition module is used to execute the operation of acquiring the first handshake cycle corresponding to the first SNMP handshake request message if the first serial number is greater than or equal to the sum of the target serial number and 1, and the target serial number indicates the maximum value of the serial numbers in the SNMP handshake request messages received before the current time.

[0185] Optionally, the device further comprises:

[0186] The discarding module is used to discard the first SNMP handshake request message if the first serial number is smaller than the sum of the target serial number and 1.

[0187] Optionally, the device further comprises:

[0188] The collection module is used to start collecting the logs of each business module in at least one business module after the managed state of the network element is determined to be the network element unmanaged state; when the managed state of the network element is updated from the network element unmanaged state to the normal managed state, stop collecting the logs of each business module in at least one business module.

[0189] Optionally, the first SNMP handshake request message carries a fourth OID and a parameter value corresponding to the fourth OID, the fourth OID indicates a fourth MIB node in the management information base MIB, and the fourth MIB node indicates network management time;

[0190] The device also includes:

[0191] A fourth determining module, configured to determine a first network management time corresponding to the first network management based on a parameter value corresponding to the fourth OID;

[0192] A fifth determining module, used to determine the time of receiving the first SNMP handshake request message to obtain a first receiving time;

[0193] The storage module is used to store the corresponding relationship between the first network management time and the first receiving time.

[0194] In summary, the embodiment of the present application provides a new heartbeat keep-alive mechanism. In this mechanism, when the network element receives the first SNMP handshake request message from the first network manager, the first handshake cycle set for the first SNMP handshake request message can be obtained, so that the subsequent network element can determine whether the managed state of the network element is in the network element disconnected state according to whether the second SNMP handshake request message from the first network manager is received within the first handshake cycle after the current time. Therefore, the embodiment of the present application provides a method by which the network element can actively detect whether it is disconnected, improve the initiative of the network element's own disconnection detection, and enable the network element to accurately sense whether it is disconnected, thereby improving the flexibility of determining whether the network element is disconnected. And timely collect logs during the disconnection period, providing a basis for the rapid discovery and location of such faults.

[0195] It should be noted that: the device for determining whether a network element is disconnected provided in the above embodiment only uses the division of the above functional modules as an example when determining whether a network element is disconnected. In actual applications, the above functional distribution can be completed by different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the device for determining whether a network element is disconnected provided in the above embodiment and the method embodiment for determining whether a network element is disconnected belong to the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0196] Fig.11 is a schematic diagram of a structure of a device for determining that a network element is out of management provided by an embodiment of the present application, the device is deployed in a first network management, such as Fig.11 As shown, the device includes the following modules.

[0197] The sending module 1101 is used to send a first simple network management protocol SNMP handshake request message to the network element. Figure 6 Step 601 in the embodiment.

[0198] The first SNMP handshake request message corresponds to the first handshake cycle, so that if the network element fails to receive the second SNMP handshake request message from the first network manager within the first handshake cycle after receiving the first SNMP handshake request message, the managed state is determined as the network element unmanaged state.

[0199] Optionally, the first SNMP handshake request message carries a first object identifier OID and a parameter value corresponding to the first OID, the first OID indicates a first MIB node in a management information base MIB, and the first MIB node indicates a handshake cycle; and / or

[0200] The first SNMP handshake request message carries a second OID and a parameter value corresponding to the second OID, the second OID indicates a second MIB node in the MIB, and the second MIB node indicates a network management identifier; and / or

[0201] The first SNMP handshake request message carries a third OID and a parameter value corresponding to the third OID, the third OID indicates a third MIB node in the MIB, and the third MIB node indicates a serial number; and / or

[0202] The first SNMP handshake request message carries a fourth OID and a parameter value corresponding to the fourth OID, the fourth OID indicates a fourth MIB node in the MIB, and the fourth MIB node indicates network management time.

[0203] In summary, the embodiment of the present application provides a new heartbeat keep-alive mechanism. In this mechanism, when the network element receives the first SNMP handshake request message from the first network manager, the first handshake cycle set for the first SNMP handshake request message can be obtained, so that the subsequent network element can determine whether the managed state of the network element is in the network element disconnected state according to whether the second SNMP handshake request message from the first network manager is received within the first handshake cycle after the current time. Therefore, the embodiment of the present application provides a method by which the network element can actively detect whether it is disconnected, improve the initiative of the network element's own disconnection detection, and enable the network element to accurately sense whether it is disconnected, thereby improving the flexibility of determining whether the network element is disconnected. And timely collect logs during the disconnection period, providing a basis for the rapid discovery and location of such faults.

[0204] It should be noted that: the device for determining whether a network element is disconnected provided in the above embodiment only uses the division of the above functional modules as an example when determining whether a network element is disconnected. In actual applications, the above functional distribution can be completed by different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the device for determining whether a network element is disconnected provided in the above embodiment and the method embodiment for determining whether a network element is disconnected belong to the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0205] Fig.12 Schematic diagram of a system for determining network element disconnection provided by an embodiment of the present application. Fig.12 As shown, the system 1200 includes a network element 1201 and a first network manager 1202 .

[0206] The first network manager 1202 is used to send a first simple network management protocol SNMP handshake request message to the network element 1201.

[0207] The network element 1201 is configured to receive a first simple network management protocol (SNMP) handshake request message from a first network manager.

[0208] The network element 1201 is further configured to obtain a first handshake cycle corresponding to the first SNMP handshake request message.

[0209] The network element 1201 is further configured to determine the managed state of the network element as the unmanaged state of the network element if the network element fails to receive the second SNMP handshake request message from the first network manager within the first handshake cycle after the current time.

[0210] The functions of the network element 1201 and the first network management 1202 can be referred to as Fig.10 and Fig.11 The device shown will not be described in detail here.

[0211] Fig.13 Schematic diagram of the structure of a computer device provided in an embodiment of the present application. The network element or network management in the above embodiments can be Fig.13 The computer device shown is implemented. Fig.13 The computer device includes at least one processor 1301 , a communication bus 1302 , a memory 1303 and at least one communication interface 1304 .

[0212] The processor 1301 may be a general-purpose central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the program of the present application.

[0213] The communication bus 1302 may include a pathway for transmitting information between the above-mentioned components.

[0214] The memory 1303 may be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 1303 may exist independently and be connected to the processor 1301 via the communication bus 1302. The memory 1303 may also be integrated with the processor 1301.

[0215] The memory 1303 is used to store the program code for executing the solution of the present application, and the execution is controlled by the processor 1301. The processor 1301 is used to execute the program code stored in the memory 1303. The program code may include one or more software modules. The network element or network management in the aforementioned embodiment can determine the data for developing the application through the processor 1301 and one or more software modules in the program code in the memory 1303.

[0216] The communication interface 1304 uses any transceiver or other device for communicating with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area networks (WLAN), etc.

[0217] In a specific implementation, as an embodiment, a computer device may include multiple processors, such as Fig.13 1301 and processor 1305 shown in FIG. Each of these processors may be a single-CPU processor or a multi-CPU processor. A processor herein may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0218] In a specific implementation, as an embodiment, the computer device may further include an output device 1306 and an input device 1307. The output device 1306 communicates with the processor 1301 and may display information in a variety of ways. For example, the output device 1306 may be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector. The input device 1307 communicates with the processor 1301 and may receive user input in a variety of ways. For example, the input device 1307 may be a mouse, a keyboard, a touch screen device, or a sensor device.

[0219] The above-mentioned computer device can be a general-purpose computer device or a special-purpose computer device. In a specific implementation, the computer device can be a desktop computer, a portable computer, a network server, a personal digital assistant (PDA), a mobile phone, a tablet computer, a wireless terminal device, a communication device or an embedded device. The embodiment of the present application does not limit the type of computer device.

[0220] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital versatile disc (DVD)), or a semiconductor medium (eg, a solid state disk (SSD)).

[0221] A person skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware or by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a disk or an optical disk, etc.

[0222] The above content is not intended to limit the embodiments of the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the embodiments of the present application should be included in the protection scope of the embodiments of the present application.

Claims

1. A method for determining whether a network element is out of management, characterized in that: The method comprises: The network element receives a first simple network management protocol SNMP handshake request message from the first network manager; The network element obtains a first handshake cycle corresponding to the first SNMP handshake request message; If the network element fails to receive the second SNMP handshake request message from the first network manager within the first handshake cycle after the current time, the managed state of the network element is determined as the network element unmanaged state.

2. The method according to claim 1, characterized in that The first SNMP handshake request message carries a first object identifier OID and a parameter value corresponding to the first OID, the first OID indicates a first MIB node in a management information base MIB, and the first MIB node indicates a handshake period; The network element obtains a first handshake cycle corresponding to the first SNMP handshake request message, including: Based on the parameter value corresponding to the first OID, a first handshake period corresponding to the first SNMP handshake request message is determined.

3. The method according to claim 1 or 2, characterized in that If the network element fails to receive the second SNMP handshake request message from the first network manager within the first handshake cycle after the current time, determining the managed state of the network element as the network element unmanaged state includes: If the network element fails to receive the second SNMP handshake request message within the first handshake period after the current time, determining the handshake state of the first network management as a handshake timeout state; Acquire the handshake status of each second network manager in at least one second network manager from a mapping relationship between the handshake status and the network manager identifier, wherein the first network manager and the at least one second network manager are both used to manage the network element; If the handshake state of each of the at least one second network manager is a normal handshake state, the managed state of the network element is determined to be a disconnected state.

4. The method according to claim 3, characterized in that The method further comprises: If the network element receives the second SNMP handshake request message from the second SNMP within the first handshake period after the current time, the handshake state of the first network management is determined as a normal handshake state; If the handshake status of the first network manager before receiving the first SNMP handshake request message is an abnormal handshake status, and the handshake status of each second network manager in the at least one second network manager is a normal handshake status, the managed status of the network element is updated from the network element unmanaged status to the normal managed status.

5. The method according to claim 3 or 4, characterized in that The first SNMP handshake request message carries a second OID and a parameter value corresponding to the second OID, the second OID indicates a second MIB node in the management information base MIB, and the second MIB node indicates a network management identifier; After determining the handshake state of the first network manager as a handshake timeout state, the method further includes: Determining a network management identifier of the first network management based on a parameter value corresponding to the second OID; Based on the network manager identifier of the first network manager and the handshake status with the first network manager, a mapping relationship between the handshake status and the network manager identifier is updated.

6. The method according to any one of claims 1 to 5, characterized in that: The first SNMP handshake request message carries a third OID and a parameter value corresponding to the third OID, the third OID indicates a third MIB node in the management information base MIB, and the third MIB node indicates a serial number; Before the network element obtains the first handshake cycle corresponding to the first SNMP handshake request message, the method further includes: Determine a first serial number corresponding to the first SNMP handshake request message based on a parameter value corresponding to the third OID; If the first serial number is greater than or equal to the sum of the target serial number and 1, an operation of obtaining the first handshake cycle corresponding to the first SNMP handshake request message is performed, and the target serial number indicates the maximum value of the serial numbers in the SNMP handshake request messages received before the current time.

7. The method according to claim 6, characterized in that The method further comprises: If the first serial number is smaller than the sum of the target serial number and 1, the first SNMP handshake request message is discarded.

8. The method according to any one of claims 1 to 7, characterized in that: After determining that the managed state of the network element is a network element unmanaged state, the method further includes: The network element starts collecting logs of each service module in at least one service module; When the managed state of the network element is updated from the network element unmanaged state to the normal managed state, the collection of logs of each service module in the at least one service module is stopped.

9. The method according to any one of claims 1 to 8, characterized in that: The first SNMP handshake request message carries a fourth OID and a parameter value corresponding to the fourth OID, the fourth OID indicates a fourth MIB node in the management information base MIB, and the fourth MIB node indicates network management time; The method further comprises: The network element determines, based on the parameter value corresponding to the fourth OID, a first network management time corresponding to the first network management; The network element determines the time of receiving the first SNMP handshake request message to obtain a first receiving time; The network element stores the corresponding relationship between the first network management time and the first receiving time.

10. A method for determining whether a network element is out of management, characterized in that: The method comprises: The first network manager sends a first simple network management protocol SNMP handshake request message to the network element; Among them, the first SNMP handshake request message corresponds to the first handshake cycle, so that if the network element fails to receive the second SNMP handshake request message from the first network manager within the first handshake cycle after receiving the first SNMP handshake request message, the managed state is determined as the network element unmanaged state.

11. The method according to claim 10, characterized in that The first SNMP handshake request message carries a first object identifier OID and a parameter value corresponding to the first OID, the first OID indicates a first MIB node in a management information base MIB, and the first MIB node indicates a handshake period; and / or The first SNMP handshake request message carries a second OID and a parameter value corresponding to the second OID, the second OID indicates a second MIB node in the MIB, and the second MIB node indicates a network management identifier; and / or The first SNMP handshake request message carries a third OID and a parameter value corresponding to the third OID, the third OID indicates a third MIB node in the MIB, and the third MIB node indicates a serial number; and / or The first SNMP handshake request message carries a fourth OID and a parameter value corresponding to the fourth OID, the fourth OID indicates a fourth MIB node in the MIB, and the fourth MIB node indicates network management time.

12. A device for determining whether a network element is out of management, characterized in that: The device is deployed in a network element, and the device includes: A receiving module, used for receiving a first simple network management protocol SNMP handshake request message from a first network manager; An acquisition module, used to acquire a first handshake cycle corresponding to the first SNMP handshake request message; The first determining module is configured to determine the managed state of the network element as the unmanaged state of the network element if the second SNMP handshake request message from the first network manager is not received within the first handshake cycle after the current time.

13. The device according to claim 12, characterized in that The first SNMP handshake request message carries a first object identifier OID and a parameter value corresponding to the first OID, the first OID indicates a first MIB node in a management information base MIB, and the first MIB node indicates a handshake period; The acquisition module is used for: Based on the parameter value corresponding to the first OID, a first handshake period corresponding to the first SNMP handshake request message is determined.

14. The device according to claim 12 or 13, characterized in that The first determining module is used for: If the second SNMP handshake request message is not received within the first handshake period after the current time, the handshake state of the first network management is determined as a handshake timeout state; Acquire the handshake status of each second network manager in at least one second network manager from a mapping relationship between the handshake status and the network manager identifier, wherein the first network manager and the at least one second network manager are both used to manage the network element; If the handshake state of each of the at least one second network manager is a normal handshake state, the managed state of the network element is determined to be a disconnected state.

15. The device according to claim 14, characterized in that The first determining module is further used for: If the network element receives the second SNMP handshake request message from the second SNMP within the first handshake period after the current time, the handshake state of the first network management is determined as a normal handshake state; If the handshake status of the first network manager before receiving the first SNMP handshake request message is an abnormal handshake status, and the handshake status of each second network manager in the at least one second network manager is a normal handshake status, the managed status of the network element is updated from the network element unmanaged status to the normal managed status.

16. The device according to claim 14 or 15, characterized in that The first SNMP handshake request message carries a second OID and a parameter value corresponding to the second OID, the second OID indicates a second MIB node in the management information base MIB, and the second MIB node indicates a network management identifier; The device also includes: A second determining module, configured to determine a network management identifier of the first network management based on a parameter value corresponding to the second OID; An updating module is used to update the mapping relationship between the handshake status and the network manager identifier based on the network manager identifier of the first network manager and the handshake status with the first network manager.

17. The device according to any one of claims 12 to 16, characterized in that: The first SNMP handshake request message carries a third OID and a parameter value corresponding to the third OID, the third OID indicates a third MIB node in the management information base MIB, and the third MIB node indicates a serial number; The device also includes: A third determining module, configured to determine a first serial number corresponding to the first SNMP handshake request message based on a parameter value corresponding to the third OID; The acquisition module is used to execute the operation of acquiring the first handshake cycle corresponding to the first SNMP handshake request message if the first serial number is greater than or equal to the sum of the target serial number and 1, and the target serial number indicates the maximum value of the serial numbers in the SNMP handshake request messages received before the current time.

18. The device according to claim 17, characterized in that The device also includes: A discarding module is used to discard the first SNMP handshake request message if the first serial number is less than the sum of the target serial number and 1.

19. The device according to any one of claims 12 to 18, characterized in that: The device also includes: A collection module is used to start collecting logs of each service module in at least one service module after the managed state of the network element is determined to be a network element unmanaged state; when the managed state of the network element is updated from the network element unmanaged state to the normal managed state, stop collecting logs of each service module in the at least one service module.

20. The device according to any one of claims 12 to 19, characterized in that: The first SNMP handshake request message carries a fourth OID and a parameter value corresponding to the fourth OID, the fourth OID indicates a fourth MIB node in the management information base MIB, and the fourth MIB node indicates network management time; The device also includes: a fourth determining module, configured to determine a first network management time corresponding to the first network management based on a parameter value corresponding to the fourth OID; A fifth determining module, used to determine the time of receiving the first SNMP handshake request message to obtain a first receiving time; A storage module is used to store the corresponding relationship between the first network management time and the first receiving time.

21. A device for determining whether a network element is out of management, characterized in that: The device is deployed on a first network management system, and includes: A sending module, used for sending a first simple network management protocol SNMP handshake request message to the network element; Among them, the first SNMP handshake request message corresponds to the first handshake cycle, so that if the network element fails to receive the second SNMP handshake request message from the first network manager within the first handshake cycle after receiving the first SNMP handshake request message, the managed state is determined as the network element unmanaged state.

22. A device for determining whether a network element is out of management, characterized in that: The device includes a memory and a processor; The memory is used to store a program that supports the device to execute the method according to any one of claims 1 to 9, and to store data involved in implementing the method according to any one of claims 1 to 9; The processor is configured to execute the program stored in the memory.

23. A device for determining whether a network element is out of management, characterized in that: The device includes a memory and a processor; The memory is used to store a program that supports the device to execute the method described in any one of claims 10-11, and to store data involved in implementing the method described in any one of claims 10-11; The processor is configured to execute the program stored in the memory.

24. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, which, when executed on a computer, enable the computer to execute the method described in any one of claims 1 to 9, or enable the computer to execute the method described in any one of claims 10 to 11.

Images