CN113438112A - Fault detection method, device, equipment and medium - Google Patents
Fault detection method, device, equipment and medium Download PDFInfo
- Publication number
- CN113438112A CN113438112A CN202110708917.7A CN202110708917A CN113438112A CN 113438112 A CN113438112 A CN 113438112A CN 202110708917 A CN202110708917 A CN 202110708917A CN 113438112 A CN113438112 A CN 113438112A
- Authority
- CN
- China
- Prior art keywords
- packet sending
- timeout
- sending interval
- compensation
- hardware layer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/26—Special purpose or proprietary protocols or architectures
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- Environmental & Geological Engineering (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention provides a method, a device, equipment and a medium for fault detection, wherein the method comprises the following steps: determining whether timeout compensation is needed or not according to a time requirement parameter of fault detection, wherein the time requirement parameter comprises a first packet sending interval and/or first timeout; when overtime compensation is needed, configuring a second packet sending interval supported by a hardware layer according to the first packet sending interval; sending a Continuity Check Message (CCM) message according to a configured second packet sending interval through a hardware layer, wherein an extension field in the CCM message carries an overtime compensation indication and first overtime; when a CCM message from a remote MEP device is received, determining that an extension field in the CCM message carries an overtime compensation indication and first overtime, and performing fault detection according to the first overtime. The invention realizes that a timeout compensation scheme is provided to meet the requirements of relevant scenes for the uncovered time regions of the CC packet sending interval and the timeout time defined by the CFM standard protocol.
Description
Technical Field
The present invention relates to the field of ethernet technologies, and in particular, to a method, an apparatus, a device, and a medium for fault detection.
Background
CFM (Connectivity Fault Management) is a network-level ethernet OAM (Operation Administration and Maintenance) technology, and implements end-to-end Connectivity Fault detection, Fault notification, Fault determination, and Fault location functions for a network. The fault diagnosis method is used for actively diagnosing faults of the EVC (Ethernet Virtual Connection), effectively reducing network maintenance cost through a fault management function and improving maintainability of the Ethernet.
The CFM detects connectivity of an ethernet virtual connection using a CC (Continuity Check) protocol, and determines a connection state between MPs (Maintenance nodes). The function is realized by periodically sending a CCM (Continuity Check Message) through an MEP (Maintenance association interior node), and other MEPs in the same service instance receive the Message, thereby determining the state of an RMEP (Remote Maintenance association End node). If equipment fails or link intermediate configuration is wrong, the MEP cannot normally receive and process CCMs sent by the RMEP. If the MEP does not receive the CCM message of the remote end in 3.5 CCM interval periods, the link is considered to have a fault, and fault alarm is sent according to alarm priority configuration.
The current CFM standard protocol defines a CFM CC packet transmission interval, a maximum timeout time, a minimum timeout time, and a CC packet transmission interval threshold in a message, and fault detection is performed according to the current CFM standard protocol, and a large number of uncovered CC packet transmission intervals and CC timeout times exist, which results in that the CC packet transmission intervals and the CC timeout times cannot meet the requirements of some applications, so that a solution for making up the deficiencies of the definition of the CFM standard protocol CC packet transmission intervals and the CC timeout times is required to cover the requirements of more application scenarios.
Disclosure of Invention
The application aims to provide a fault detection method, a fault detection device, fault detection equipment and a fault detection medium.
The method is used for solving the problems of a large number of uncovered CC packet sending intervals and CC overtime time when the existing CFM standard protocol is used for fault detection.
In a first aspect, an embodiment of the present application provides a method for fault detection, which is applied to MEP equipment, and includes:
determining whether timeout compensation is needed or not according to a time requirement parameter of fault detection, wherein the time requirement parameter comprises a first packet sending interval and/or first timeout;
when overtime compensation is needed, configuring a second packet sending interval supported by a hardware layer according to the first packet sending interval;
sending a Continuity Check Message (CCM) message through a hardware layer according to a configured second packet sending interval, wherein an extension field in the CCM message carries an overtime compensation indication and the first overtime;
and when a CCM message from a remote MEP device is received, determining that an extension field in the CCM message carries an overtime compensation indication and the first overtime, and performing fault detection according to the first overtime.
In some possible embodiments, the configuring, when timeout compensation is required, a second packet sending interval supported by a hardware layer according to the first packet sending interval includes:
when the hardware layer supports the first packet sending interval, configuring a second packet sending interval of the hardware layer as the first packet sending interval;
when the hardware layer does not support the first packet sending interval, configuring a second packet sending interval of the hardware layer as a packet sending interval which is supported by the hardware layer and is smaller than and closest to the first packet sending interval.
In some possible embodiments, the performing the fault detection according to the first timeout time includes:
when the hardware layer supports the first packet sending interval, calculating timeout time according to the configured second packet sending interval;
and when the calculated overtime time does not receive the CCM message of the remote MEP equipment, the hardware layer detects that fault alarm is carried out.
In some possible embodiments, the performing the fault detection according to the first timeout time includes:
when the hardware layer does not support the first packet sending interval, calculating second timeout time according to the configured second packet sending interval, and determining third timeout time needing software compensation according to the second timeout time and the first timeout time in the CCM;
when the CCM message from the far-end MEP equipment is received, detecting that the CCM message of the far-end MEP equipment is not received after the second timeout is exceeded through a hardware layer, and starting overtime detection through software layer detection;
and when the software layer detects that the CCM message of the remote equipment is not received after the third overtime time, performing fault alarm.
In some possible embodiments, the time required parameter for fault detection to determine whether timeout compensation is required comprises:
if the first packet sending interval and/or the first timeout time of the MEP equipment accord with the CFM standard protocol, determining that timeout compensation is not needed, otherwise, determining that timeout compensation is needed.
In some possible embodiments, the method further comprises:
when the overtime compensation is not needed, configuring a second packet sending interval of the hardware layer as the first packet sending interval;
sending a Continuity Check Message (CCM) message according to a configured second packet sending interval through a hardware layer, wherein the CCM message carries a packet sending interval threshold value indicating the first packet sending interval;
when a CCM message from the remote MEP equipment is received, calculating the timeout time according to the configured second packet sending interval;
and when detecting that the CCM message of the remote MEP equipment is not received after the calculated timeout period is exceeded through a hardware layer, carrying out fault alarm.
In some possible embodiments, according to the time-out compensation requirement, the CCM message further carries a packet transmission interval threshold value indicating that a packet transmission interval defined by any standard protocol corresponds to the CCM message.
In some possible embodiments, according to that an extension field in the CCM message is an extension field TLV, the extension field includes a TYPE field and a value VLAUE field, the TYPE field is filled with a timeout compensation indication, and the VLAUE field is filled with the first timeout time.
In some possible embodiments, according to the CCM message received from the remote MEP device, the method includes:
when the hardware layer supports the first packet sending interval, receiving a packet sending interval corresponding to the first timeout time in a CCM message from a remote MEP device, and starting timeout timing when the packet sending interval is consistent with the first packet sending interval configured by the hardware layer;
and when the hardware layer does not support the first packet sending interval, receiving the first timeout time in the CCM message from the remote MEP equipment once, and starting second timeout time timing when the first timeout time in the time requirement parameter is consistent with the first timeout time in the time requirement parameter.
In a second aspect, an embodiment of the present application provides an apparatus for fault detection, including:
the system comprises a timeout compensation determining module, a timeout compensation determining module and a fault detection module, wherein the timeout compensation determining module is used for determining whether timeout compensation is needed according to a time requirement parameter of fault detection, and the time requirement parameter comprises a first packet sending interval and/or first timeout time;
the hardware configuration module is used for configuring a second packet sending interval supported by a hardware layer according to the first packet sending interval when overtime compensation is needed;
the message sending module is used for sending a Continuity Check Message (CCM) through a hardware layer according to a configured second packet sending interval, wherein an extension field in the CCM carries an overtime compensation indication and the first overtime;
and the fault detection module is used for determining that an extension field in the CCM message carries an overtime compensation indication and the first overtime when the CCM message from the remote MEP equipment is received, and carrying out fault detection according to the first overtime.
In a third aspect, an embodiment of the present application provides a fault detection apparatus, including at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform a method of fault detection as provided in the first aspect above.
In a fourth aspect, an embodiment of the present application provides a computer storage medium, where a computer program is stored, where the computer program is used to enable a computer to execute a method for fault detection provided in the first aspect.
Drawings
FIG. 1 is a diagram illustrating a network of different levels of MD networks in the related art;
FIG. 2 is a schematic diagram of a network structure of MEPs and MIPs in the related art;
FIG. 3 is a schematic diagram of an application environment according to an embodiment of the present application;
fig. 4 is a flowchart of a fault detection method provided in an embodiment of the present application;
fig. 5 is a detailed flowchart of a fault detection method according to an embodiment of the present disclosure;
FIG. 6 is a flowchart illustrating timeout compensation timing performed by software according to an embodiment of the present disclosure;
fig. 7 is a structural diagram of a fault detection apparatus according to an embodiment of the present application;
fig. 8 is a schematic structural diagram of a fault detection device according to an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be described in detail and clearly with reference to the accompanying drawings. In the description of the embodiments of the present application, "/" means "or" unless otherwise specified, for example, a/B may mean a or B; "and/or" in the text is only an association relationship describing an associated object, and means that three relationships may exist, for example, a and/or B may mean: three cases of a alone, a and B both, and B alone exist, and in addition, "a plurality" means two or more than two in the description of the embodiments of the present application.
In the description of the embodiments of the present application, the term "plurality" means two or more unless otherwise specified, and other terms and the like should be understood similarly, and the preferred embodiments described herein are only for the purpose of illustrating and explaining the present application, and are not intended to limit the present application, and features in the embodiments and examples of the present application may be combined with each other without conflict.
To further illustrate the technical solutions provided by the embodiments of the present application, the following detailed description is made with reference to the accompanying drawings and the detailed description. Although the embodiments of the present application provide method steps as shown in the following embodiments or figures, more or fewer steps may be included in the method based on conventional or non-inventive efforts. In steps where no necessary causal relationship exists logically, the order of execution of the steps is not limited to that provided by the embodiments of the present application. The method can be executed in the order of the embodiments or the method shown in the drawings or in parallel in the actual process or the control device.
In view of the fact that the related art utilizes the current CFM standard protocol for fault detection, there are a lot of uncovered CC packet sending intervals and CC timeout time, which cannot meet the requirements of some application scenarios.
In view of the above, the inventive concept of the present application is: for the uncovered time region of the CC packet sending interval and the overtime time defined by the CFM standard protocol, an overtime compensation scheme is provided for fault detection to meet the application requirements of relevant scenes.
Additional features and advantages of the application will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the application. The objectives and other advantages of the application may be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.
The following describes the method for compensating fault detection in the embodiments of the present application in detail with reference to the accompanying drawings.
CFM is a network level ethernet OAM technology, and the CFM components of CFM and the functions of CFM are summarized below.
The CFM component mainly relates to MD (Maintenance Domain), Service Instance (Service Instance), MEP (Maintenance association End Point), MIP (Maintenance association Intermediate Point), and MP (Maintenance node). The method comprises the following specific steps:
1)MD
an MD called MEG (Maintenance Entity Group) is a network that runs a CFM function, and determines a network range for performing OAM management. The maintenance domain has a level attribute, the level attribute is divided into 8 levels (0-7), the higher the number is, the higher the level of the maintenance domain is, and the range of the corresponding maintenance domain is larger. Protocol messages of the low-level MD are discarded after entering the high-level MD, but if no MEP exists in the high-level MD and only MIP exists, the messages can pass through. Protocol messages of a high-level MD may traverse a low-level MD. Different maintenance domains can be adjacent and nested but can not be crossed within the same VLAN.
As shown in fig. 1, MD2 is included in MD1, and a protocol packet of MD1 needs to traverse MD 2. Therefore, the level of the MD1 is configured to be 6, and the level of the MD2 is configured to be 3, so that the protocol messages in the MD1 can traverse the MD2 to realize the connectivity fault management of the whole MD1, and the protocol messages in the MD2 cannot be diffused into the MD 1. MD2 is the server tier and MD1 is the client tier.
2) Service instance
A service instance, also called MA (Maintenance Association), is part of an MD, which may be divided into one or more service instances. The service instance corresponds to a service and can be mapped to a group of VLANs, and the VLANs mapped by different service instances cannot be crossed. Although a service instance may be mapped to multiple VLANs, a service instance may only use one VLAN for transceiving OAM messages, which is referred to as the primary VLAN of the service instance.
3)MEP
As shown in fig. 2, MEPs are edge nodes of a service instance. The MEP can send and process the CFM message, and the service instance and MD where the MEP is located determine the VLAN and level of the MEP for sending and receiving the message.
For any device in the network running CFM, the MEP on the device is called local MEP, and the MEPs on other devices in the same service instance are called RMEP (Remote Maintenance association End Point) for the device.
A plurality of MEPs can be configured in one service instance, messages sent by MEPs in the same service instance have the same S-VLAN TAG, the same priority and the same C-VLAN TAG, the MEPs can receive OAM messages sent by other MEPs in the same service instance, terminate messages with the same level or lower than the level of the MEPs, and forward messages with higher level than the level of the MEPs.
4)MIP
As shown in fig. 2, MIP is an internal node of a service instance and is automatically created by a device according to rules. MIP cannot actively send CFM messages but can process and respond to LTM (link trace Message) and LBM (LoopBack Message) messages.
5)MP
MEPs and MIPs are collectively referred to as maintenance nodes MP.
The improved OAM functions of the CFM mainly include a fault detection function, a fault confirmation function, and a fault location function, as follows:
1) and (3) a fault detection function:
the fault detection function is to detect the connectivity of an ethernet virtual connection by using a CC (Continuity Check) protocol, and determine the connection state between MPs. This function is implemented by the MEP periodically sending a CCM (Continuity Check Message) Message, which is received by other MEPs within the same service instance, thereby determining the state of the RMEP. If equipment fails or link intermediate configuration is wrong, the MEP cannot normally receive and process CCMs sent by the RMEP. If the MEP does not receive the CCM message of the remote end in 3.5 CCM interval periods, the link is considered to have a fault, and fault alarm is sent according to alarm priority configuration.
2) A failure confirmation function:
the fault confirmation function sends the LBM and the destination MP reply LBR through the source MEP using LB (LoopBack, LoopBack function) to determine connectivity between the two MPs. The source MEP sends LBM to the MP which needs to be confirmed by the fault, after the MP receives the LBM message, the MP sends an LBR to the source MEP, if the source MEP receives the LBR, the confirmation path is connected, if the source MEP does not receive the LBR, the connection fault exists.
3) The fault positioning function is as follows:
the fault location function uses LT (LinkTrace ) to send LTMs to destination MPs via source MEPs, and each MP device in the LTM transmission path responds to LTRs to the source MEPs to locate fault points by recording valid LTRs and LTMs.
The embodiment of the application mainly relates to a fault detection function of CFM, and the specific application environment is used for carrying out fault detection on CCM messages sent by a plurality of MEPs in a service instance. As shown in FIG. 3, in the application environment of the present example, there are two links between SW-A and SW-C, Link 1 and RPL respectively, and two links between SW-B and SW-C, Link 2 and RPL respectively.
For Ring-1(Ring-2 is similar), the RPL Link between SW-A and SW-C is normally in a blocking state and the other Link (Link 1) is in a forwarding state. When the CFM CC detects that the Link 1 Link has connectivity failure, the RPL Link between the SW-A and the SW-C is switched into a forwarding state, and the Link (Link 1) is switched into a blocking state.
When the CFM CC is used for detecting the connectivity between the SW-A and the SW-C of the switch equipment, the timeout time is between 60ms and 75ms, and the phenomenon is considered to be normal. When the TIMEOUT exceeds 80ms, a CC TIMEOUT fault is deemed to have occurred. In this case, the CFM CC triggers 8032 to complete the link switch.
For the fault detection function, the current CFM standard protocol (IEEE 802.1AG and ITU-T y.1731) defines the CFM CC packet transmission interval, the maximum timeout time, the minimum timeout time, and the CC packet transmission interval threshold in the packet, which is specifically referred to table 1:
TABLE 1
According to the definition of the current IEEE 802.1AG and ITU-T Y.1731 standard protocols, a large number of uncovered CC packet sending intervals and CC timeout time exist in the middle. For example, the packet transmission interval is 4ms to 9ms, 11ms to 99ms, 101ms to 999ms, and the like, and the CC timeout time is approximately 13ms to 31.5ms, 35.75ms to 346.5ms, 353.5ms to 3496.5ms, and the like.
In the embodiment, the CFM CC hardware is used for detecting the link connectivity, and a corresponding overtime compensation mode is provided, so that the defects of a CFM standard protocol CC packet sending interval and CC overtime definition are overcome, and the requirements of more application scenes are met.
Example 1
The embodiment of the present application provides a method for fault detection, which can solve the problem that fault detection is performed by using the current CFM standard protocol, where a large number of uncovered CC packet sending intervals and CC timeout time exist, and the requirement of some application scenarios cannot be met, and the method for fault detection provided in the embodiment of the present application can implement timeout compensation of CC packet sending intervals undefined in the standard protocol, and meet the application requirement of more scenarios, as shown in fig. 4, the method includes:
the time requirement parameter comprises a first packet sending interval and/or a first overtime;
and searching the time requirement parameters of the MEP equipment in the CFM standard protocol, if the searching is successful, the time-out compensation is not needed, and if the searching is failed, the time-out compensation is needed.
As an optional implementation, determining whether timeout compensation is required according to the time requirement parameter of the fault detection includes:
if the first packet sending interval and/or the first timeout time of the MEP equipment accord with the CFM standard protocol, determining that timeout compensation is not needed, otherwise, determining that timeout compensation is needed.
As shown in table 1, the CC packet transmission interval threshold value corresponding to 7 CC packet transmission intervals defined by the standard protocol is 1 to 7. Searching whether a first packet sending interval which is equal to the requirement of the equipment exists in 7 CC packet sending intervals defined by a CFM standard protocol; if the search is successful, determining that timeout compensation is not needed; if the lookup fails, it is determined that timeout compensation is needed. Of course, the first timeout time may also be looked up from table 1, where the first timeout time includes a maximum timeout time and/or a minimum timeout time, and if the look-up is successful, it is determined that timeout compensation is not needed; if the lookup fails, it is determined that timeout compensation is needed. Wherein the maximum/minimum timeout time is equal to the corresponding n times the first transmission interval.
when the hardware layer performs packet transmission interval configuration, the packet transmission interval needs to be configured as a second packet transmission interval supported by the hardware layer. The second layer of packet sending intervals supported by the hardware layer may or may not include the first packet sending interval. In implementation, when the second packet sending interval supported by the hardware layer is configured according to the first packet sending interval, the packet sending interval of the hardware layer may be configured to be supported by the hardware layer and not greater than the first packet sending interval, that is, the second packet sending interval is not greater than the first packet sending interval.
As an optional implementation manner, when the hardware layer supports the first packet sending interval, the second packet sending interval may be directly configured as the first packet sending interval, otherwise, the second packet sending interval may be configured as the packet sending interval defined in the protocol and smaller than the first packet sending interval.
when determining that the timeout compensation is needed, the embodiment of the present invention adds the timeout compensation indication and the first timeout period to the extended field to support the remote MEP device receiving the message to perform fault detection according to the first timeout period.
In the embodiment of the invention, when the timeout compensation is determined to be needed, the packet sending interval is configured according to the first packet sending interval on the hardware layer, the timeout compensation indication is carried in the CCM message to indicate that the remote MEP does not carry out fault detection according to the timeout time defined by the protocol any more, and the first timeout time is carried in the CCM message, so that the remote MEP is supported to carry out fault detection according to the first timeout time, and when the CCM message is received and the timeout compensation indication is determined to be carried in the CCM message, the timeout compensation is determined to be needed, so that the fault detection is carried out according to the first timeout time in the CCM message, and therefore, the defects of the CFM standard protocol CC packet sending interval and the CC timeout time definition can be overcome, and the requirements of more application scenes can be met.
When the above scheme is implemented, the MEP device performs timeout compensation to perform fault detection according to the first timeout time in the CCM message, and may determine to perform timeout compensation in one of the following manners according to whether the hardware layer supports the first packet sending interval required by the MEP device:
1) hardware timeout compensation mode
If the hardware layer supports a first packet sending interval required by the MEP equipment, configuring a second packet sending interval supported by the hardware layer according to the first packet sending interval, wherein the second packet sending interval comprises the following steps:
and configuring a second packet sending interval of the hardware layer as the first packet sending interval.
Thus, the hardware layer configures the packet sending interval which is the packet sending interval required by the device, and is not the 7 CC packet sending intervals defined by the standard protocol, but is a custom packet sending interval outside the 7 CC packet sending intervals.
Because the hardware layer sends the CCM message according to the first packet sending interval required by the device, the fault detection is carried out according to the first overtime in the received CCM message, and the fault detection comprises the following steps:
when the hardware layer supports the first packet sending interval, calculating timeout time according to the configured second packet sending interval;
and when the calculated overtime time does not receive the CCM message of the remote MEP equipment, the hardware layer detects that fault alarm is carried out.
The overtime time required by the equipment can be directly obtained from the configuration parameters of the hardware layer, and the hardware overtime compensation is realized.
2) Software timeout compensation mode
If the hardware layer does not support the first packet sending interval required by the MEP device, when timeout compensation is needed, configuring a second packet sending interval supported by the hardware layer according to the first packet sending interval, including:
configuring the second packet sending interval of the hardware layer to be a packet sending interval supported by the hardware layer, wherein the second packet sending interval is smaller than and closest to the first packet sending interval.
The packet sending interval supported by the hardware layer, which is smaller than and closest to the first packet sending interval, is a packet sending interval defined by a standard protocol. Thus, the hardware layer configures a packetization interval that is one of the 7 CC packetization intervals defined by the standard protocol.
Because the hardware layer does not send the CCM message according to the first packet sending interval required by the device, software is required to assist in performing timeout compensation, and fault detection is performed according to the first timeout time, which includes:
when the hardware layer does not support the first packet sending interval, calculating second timeout time according to the configured second packet sending interval, and determining third timeout time needing software compensation according to the second timeout time and the first timeout time in the CCM;
when the CCM message from the far-end MEP equipment is received, detecting that the CCM message of the far-end MEP equipment is not received after the second timeout is exceeded through a hardware layer, and starting overtime detection through software layer detection;
and when the software layer detects that the CCM message of the remote equipment is not received after the third overtime time, performing fault alarm.
The third timeout period is the first timeout period minus the second timeout period.
As described above, the second packet sending interval configured by the hardware layer is smaller than the first packet sending interval, so that the timeout compensation time calculated according to the second packet sending interval is smaller than the first timeout time, when the second timeout time of the hardware layer reaches, the software is started to continue timing, and when the third timeout time is exceeded and the CCM message of the remote MEP is not received, it is indicated that the CCM message of the remote device is not received within the first timeout time, a fault alarm is performed.
As an optional implementation manner, when the timeout compensation is not needed, configuring the second packet sending interval of the hardware layer as the first packet sending interval;
sending a Continuity Check Message (CCM) message according to a configured second packet sending interval through a hardware layer, wherein the CCM message carries a packet sending interval threshold value indicating the first packet sending interval;
when a CCM message from the remote MEP equipment is received, calculating the timeout time according to the configured second packet sending interval;
and when detecting that the CCM message of the remote MEP equipment is not received after the calculated timeout period is exceeded through a hardware layer, carrying out fault alarm.
The technical scheme provided by the embodiment of the invention can be suitable for a network with a CFM function, and can be specifically executed by any MEP equipment in the network, wherein each MEP equipment is initialized to realize the CC function in the CFM on a hardware layer. Typically, the network may be the internet of things, and the MEP devices may be switches, routers, and the like.
A detailed embodiment of the method of fault detection of the present invention is given below, and as shown in fig. 5, the method includes:
the time requirement parameters include a required packetization interval and/or a timeout period.
wherein, the timeout time is n CC sending interval, n is larger than or equal to 3.25 and smaller than or equal to 3.5. The minimum timeout time is 3.25 CC packet intervals and the maximum timeout time is 3.5 CC packet intervals.
In specific implementation, whether a packet sending interval equal to the requirement of the equipment exists in 7 CC packet sending intervals defined by a standard protocol is searched; if the search is successful, determining that timeout compensation is not needed; if the lookup fails, it is determined that timeout compensation is needed. Of course, other parameters such as minimum timeout time or maximum timeout time may be queried.
When the embodiment of the invention is applied to a link switching scene, the requirements of the equipment on the CC packet sending interval and the timeout time under the scene are as follows: tsw { [ Tcc ] { [ Delta ] min, [ Delta ] max } + T [ Delta ]
Tsw represents the maximum time of link switching; tcc represents CC packet sending interval, and the value range follows standard protocol definition;
Δ min and Δ max follow the protocol standard definition and are 3.25 and 3.5 respectively;
t delta represents other software processing time, is an empirical value and has a relation with CPU performance and the number of LOCAL-MEPs and REMOTE-MEPs. In the case of a certain number of CPUs, LOCAL-MEPs and REMOTE-MEPs, T Delta is not changed much and T Delta is negligible.
specifically, the process of determining whether the hardware layer supports the CC packet sending interval required by the device may include: identifying whether the model of a switching chip on a hardware layer of the MEP equipment is a preset model or not; if so, determining that the hardware layer of the equipment supports the self-defined CC packet sending interval and the overtime time, and supporting the CC packet sending interval required by the equipment; otherwise, determining that the hardware layer of the equipment does not support the customized CC packet sending interval and the overtime time, and determining to adopt a software overtime compensation mode needing software assistance to carry out overtime compensation.
in the prior art, the packet transmission interval field value of the packet transmission interval field in the CCM message corresponding to 7 CC packet transmission intervals defined by the standard protocol is 1-7. In the step 504-505, hardware timeout compensation is adopted, and the CC packet sending interval of the hardware layer is not 7 CC packet sending intervals defined by the standard protocol any more, but is a self-defined packet sending interval located outside the 7 CC packet sending intervals, so as to prevent the sent CCM from being recognized as an illegal message, the value of the packet sending interval field carried in the sent CCM is still the value in 1-7, and which value in 1-7 can be selected arbitrarily.
As an optional implementation, the selected values are: and in 7 CC packet sending intervals defined by the standard protocol, a CC packet sending interval threshold value which is smaller than the CC packet sending interval required by the equipment and is closest to the CC packet sending interval required by the equipment is selected.
It should be noted that, in the case of requiring timeout compensation, the packet transmission interval field value in CCM has no practical physical meaning, and cannot correctly identify the packet transmission interval required by the device, and for this purpose, the required timeout time may be filled in the extension field in the CCM message.
As an optional implementation manner, the extension field in the CCM packet is an extension field TLV, the extension field includes a TYPE field and a value VLAUE field, the TYPE field fills a timeout compensation indication, and the VLAUE field fills a timeout time required by the device.
The CCM message further includes an MEG ID field, when the protocol used by the CFM is IEEE 802.1AG, the MA NAME in the MEG ID field is not null, the TYPE field VALUE in the extension field is set to a VALUE (for example, 10) in the range of 9 to 30 as a timeout compensation indication, and the corresponding VALUE field fills the timeout time corresponding to the CC packet sending interval required by the device. When the protocol used by the CFM is y.1731, MANAME in the MEG ID field is empty, the TYPE field VALUE in the extension field is set to a VALUE (for example, 32) in the range of 32 to 63 as a timeout compensation indication, and the corresponding VALUE field fills the timeout time corresponding to the CC packet transmission interval required by the device.
After a hardware layer of the equipment receives a CCM message sent to the equipment by a remote equipment in a network, extracting the overtime time corresponding to the CC packet sending interval required by the remote equipment carried in the CCM message, and when the CC packet sending interval corresponding to the overtime time is extracted to be consistent with the CC packet sending interval configured by the hardware layer of the equipment, determining that the CCM message from the remote equipment is correctly received once, and starting the timing of the overtime of the CCM message; if the CCM message from the remote equipment is not correctly received again until the CCM message TIMEOUT time reaches (n x the CC packet sending interval configured by the hardware layer), the remote equipment is determined to have a CC TIMEOUT fault, and the CC TIMEOUT alarm of the remote equipment needs to be carried out.
The extracting of the timeout time corresponding to the CC packet sending interval required by the remote device carried in the CCM message includes:
reading a MEGID field in CCM;
if the MANAME in the MEGID field is empty, reading a VALUE VALUE corresponding to a set TYPE (for example, 32) in the extension field, wherein the set TYPE belongs to the range of 32-63, and the VALUE is the timeout time corresponding to the CC packet sending interval required by the remote equipment carried in the CCM; when the VALUE corresponding to the TYPE set in the range of 32-63 does not exist in the extension field, directly taking the CC packet sending interval of the packet sending interval domain VALUE identifier in the CCM as the CC packet sending interval required by the remote equipment carried in the CCM;
if the MA NAME in the MEGID field is not empty, reading a VALUE VALUE corresponding to a set TYPE (for example, 10) in the extension field, wherein the set TYPE belongs to the range of 9-30, and the VALUE is the timeout time corresponding to the CC packet sending interval required by the remote equipment carried in the CCM message; and when the VALUE corresponding to the set TYPE within the range of 9-30 does not exist in the extension field, directly taking the CC packet sending interval of the packet sending interval domain VALUE identifier in the CCM message as the CC packet sending interval required by the remote equipment carried in the CCM.
And 507, performing CC TIMEOUT alarm of the remote equipment in a hardware interrupt mode.
And step 508, selecting a CC packet sending interval supported by a hardware layer, which is less than and closest to the CC packet sending interval required by the device, from the 7 CC packet sending intervals defined by the standard protocol, and calculating the timeout time required for software compensation.
And when the hardware layer does not support the CC packet sending interval required by the equipment, calculating the corresponding timeout according to the configured CC packet sending interval, and determining the third timeout needing software compensation according to the timeout required by the equipment and the calculated timeout.
In practice, the following calculation can be adopted: the timeout time that needs software compensation is n (the requirement of CC packet interval required by the device-the CC packet interval configured by the hardware layer). For example, when n is 3.5, and the CC packet transmission interval required by the device is 55ms, the CC packet transmission interval Tcc supported by the hardware layer is 10ms, and the timeout time for software compensation is 157.5 (3.5) × (55-10) ms.
In the prior art, 7 CC packet intervals defined by the standard protocol correspond to packet intervals in the CCM of 1 to 7. In the above step 509-. As an optional implementation manner, the values of the packet transmission interval field in the CCM message are: the CC packet sending interval threshold value configured in the hardware layer, that is, the CC packet sending interval threshold value that is smaller than the CC packet sending interval required by the present apparatus and is closest to the CC packet sending interval required by the present apparatus among 7 CC packet sending intervals defined by the standard protocol.
The same as in step 505, in step 510, in order to correctly identify the timeout time corresponding to the CC packet sending interval required by the device, the extension field in the CCM message is an extension field TLV, the extension field includes a TYPE field and a value VLAUE field, the TYPE field fills the timeout compensation indication, and the VLAUE field fills the timeout time required by the device.
The CCM message further includes an MEG ID field, when the protocol used by the CFM is IEEE 802.1AG, MANAME in the MEG ID field is not empty, a TYPE field VALUE in the extension field is set to a VALUE (for example, 10) within a range of 9 to 30 as a timeout compensation indication, and the corresponding VALUE field fills the timeout time corresponding to the CC packet sending interval required by the device. When the protocol used by the CFM is y.1731, the MA NAME in the MEG ID field is null, the TYPE field VALUE in the extension field is set to a VALUE (for example, 32) in the range of 32 to 63 as a timeout compensation indication, and the corresponding VALUE field fills the timeout time corresponding to the CC packet sending interval required by the device.
In step 511, when detecting that the TIMEOUT time reaches a point where the CCM message of the remote MEP device is not received, the hardware layer of the device determines that a CC TIMEOUT fault occurs, where the TIMEOUT time is (n × CC packet sending interval configured by the hardware layer).
The detection process of this step 511 is the same as the above step 506.
And step 512, the hardware layer triggers and adopts a software mode to perform overtime compensation timing in an interruption mode, wherein the time duration is the calculated overtime time compensated by the software, and when the CCM of the remote equipment is not received after the timing is finished, the CC TIMEOUT alarm of the remote equipment is performed through the software.
In this step 512, performing timeout compensation timing in a software manner includes the following steps, as shown in fig. 6:
substep 5122: the time delay Tth, the count is incremented and substep 5121 is entered.
Where the threshold Δ th is rounded (the calculated software compensated timeout/Tth). Tth corresponds to at least one beat of the device timer, which may be as accurate as 1ms, at a minimum. If the compensation time is in the ms level, Tth can be 1 ms; if the compensation time is in the order of min, Tth may take 10ms or 100 ms. When the ratio is not an integer, rounding methods such as rounding up, rounding down, rounding up, and the like may be employed, and rounding up is preferable.
And step 514, the hardware layer periodically sends a CCM message in the network according to the configured CC packet sending interval, wherein the CCM message carries a packet sending interval threshold value, and the extension field is empty.
Unlike the above steps 505 and 510, in this step 514, the packet transmission interval field value in the CCM message is the configured CC packet transmission interval, and the extension field does not carry any CC packet transmission interval information.
This step 515 is the same as step 506 described above.
And 516, performing CC TIMEOUT alarm of the remote equipment in a hardware interrupt mode.
This step 516 is the same as step 507 described above and will not be described in detail here.
Taking the protocol IEEE 802.1AG as an example, the following 3 tables respectively give the relevant parameters of the scheme in the CCM message under 3 different conditions. Table 2 shows the packet transmission interval threshold and TLV field filling manner in the CCM message corresponding to the time-out compensation is not required, table 3 shows the packet transmission interval threshold and TLV field filling manner in the CCM message corresponding to the time-out compensation is required, and table 4 shows the packet transmission interval threshold and TLV field filling manner in the CCM message corresponding to the time-out compensation is required, where the time-out time may be, but is not limited to, 60 ms.
TABLE 2
TABLE 3
TABLE 4
Example 2
An embodiment of the present application provides a fault detection apparatus, as shown in fig. 7, including:
a timeout compensation determining module 701, configured to determine whether timeout compensation is needed according to a time requirement parameter for fault detection, where the time requirement parameter includes a first packet sending interval and/or a first timeout;
a hardware configuration module 702, configured to configure, when timeout compensation is required, a second packet sending interval supported by a hardware layer according to the first packet sending interval;
a message sending module 703, configured to send, by a hardware layer, a continuity check message CCM message according to a configured second packet sending interval, where an extension field in the CCM message carries an timeout compensation indication and the first timeout time;
and the fault detection module 704 is configured to, when a CCM message from a remote MEP device is received, determine that an extension field in the CCM message carries an overtime compensation indication and the first overtime, and perform fault detection according to the first overtime.
In some possible embodiments, when timeout compensation is required, configuring, according to the first packet sending interval hardware configuration module, a second packet sending interval supported by a hardware layer, including:
when the hardware layer supports the first packet sending interval, a hardware configuration module configures a second packet sending interval of the hardware layer as the first packet sending interval;
when the hardware layer does not support the first packet sending interval, the hardware configuration module configures a second packet sending interval of the hardware layer to be a packet sending interval which is supported by the hardware layer and is smaller than and closest to the first packet sending interval.
In some possible embodiments, the performing, by the message sending module, the fault detection according to the first timeout time includes:
when the hardware layer supports the first packet sending interval, and a message sending module receives a CCM message from a remote MEP device, calculating timeout time according to the configured second packet sending interval;
and when the calculated overtime time does not receive the CCM message of the remote MEP equipment, the hardware layer detects that fault alarm is carried out.
In some possible embodiments, the performing, by the message sending module, the fault detection according to the first timeout time includes:
when the hardware layer does not support the first packet sending interval, calculating second timeout time according to the configured second packet sending interval, and determining third timeout time needing software compensation according to the second timeout time and the first timeout time in the CCM;
when the CCM message from the far-end MEP equipment is received, detecting that the CCM message of the far-end MEP equipment is not received after the second timeout is exceeded through a hardware layer, and starting overtime detection through software layer detection;
and when the software layer detects that the CCM message of the remote equipment is not received after the third overtime time, performing fault alarm.
In some possible embodiments, the timeout compensation determining module determines whether timeout compensation is required based on a time requirement parameter of the fault detection, including:
if the first packet sending interval and/or the first timeout time of the MEP equipment accord with the CFM standard protocol, determining that timeout compensation is not needed, otherwise, determining that timeout compensation is needed.
In some possible embodiments, the apparatus for fault detection further includes:
when the timeout compensation is not needed, an adjusting module (not shown in the figure) configures a second packet sending interval of the hardware layer as the first packet sending interval;
sending a Continuity Check Message (CCM) message according to a configured second packet sending interval through a hardware layer, wherein the CCM message carries a packet sending interval threshold value indicating the first packet sending interval;
when a CCM message from the remote MEP equipment is received, calculating the timeout time according to the configured second packet sending interval;
and when detecting that the CCM message of the remote MEP equipment is not received after the calculated timeout period is exceeded through a hardware layer, carrying out fault alarm.
In some possible embodiments, according to the time-out compensation requirement, the CCM message in the hardware configuration module further carries a packet sending interval threshold value corresponding to a packet sending interval defined by any standard protocol.
In some possible embodiments, an extension field in a CCM message of the message sending module is an extension field TLV, the extension field includes a TYPE field and a value-VLAUE field, the TYPE field is filled with a timeout compensation indication, and the VLAUE field is filled with the first timeout time.
In some possible embodiments, the receiving, by the fault detection module, a CCM message from a remote MEP device includes:
when the hardware layer supports the first packet sending interval, receiving a packet sending interval corresponding to the first timeout time in a CCM message from a remote MEP device, and starting timeout timing when the packet sending interval is consistent with the first packet sending interval configured by the hardware layer;
and when the hardware layer does not support the first packet sending interval, receiving the first timeout time in a CCM message from the remote MEP equipment once, and starting second timeout time timing when the first timeout time in the time requirement parameter is consistent with the first timeout time.
The apparatus 130 for fault detection according to this embodiment of the present application is described below with reference to the drawings. The failure detection apparatus 130 shown in fig. 7 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.
As shown in fig. 8, the failure detection device 130 is in the form of a general-purpose electronic device. The components of the fault detection device 130 may include, but are not limited to: the at least one processor 131, the at least one memory 132, and a bus 133 that connects the various system components (including the memory 132 and the processor 131).
The memory 132 may include readable media in the form of volatile memory, such as Random Access Memory (RAM)1321 and/or cache memory 1322, and may further include Read Only Memory (ROM) 1323.
The fault detection device 130 may also communicate with one or more external devices 134 (e.g., keyboard, pointing device, etc.), may also communicate with one or more devices that enable a user to interact with the fault detection device 130, and/or may communicate with any devices (e.g., router, modem, etc.) that enable the fault detection device 130 to communicate with one or more other electronic devices. Such communication may occur via input/output (I/O) interfaces 135. Also, the failure detection device 130 may also communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the Internet) via a network adapter 136. As shown, network adapter 136 communicates with other modules of device 130 for fault detection over bus 133. It should be understood that although not shown in the figures, other hardware and/or software modules may be used in conjunction with the fault detection device 130, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.
In a possible embodiment, the various aspects of the method for fault detection provided herein may also be implemented in the form of a program product comprising program code for causing a computer device to perform the method steps of fault detection according to various exemplary embodiments of the present application described above in this specification, when the program product is run on the computer device.
The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
The program product for monitoring of the embodiments of the present application may employ a portable compact disc read only memory (CD-ROM) and include program code, and may be run on an electronic device. However, the program product of the present application is not limited thereto, and in this document, a readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
While the preferred embodiments of the present application have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all alterations and modifications as fall within the scope of the application.
It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.
Claims (12)
1. A fault detection method is applied to MEP equipment and is characterized by comprising the following steps:
determining whether timeout compensation is needed or not according to a time requirement parameter of fault detection, wherein the time requirement parameter comprises a first packet sending interval and/or first timeout;
when overtime compensation is needed, configuring a second packet sending interval supported by a hardware layer according to the first packet sending interval;
sending a Continuity Check Message (CCM) message through a hardware layer according to a configured second packet sending interval, wherein an extension field in the CCM message carries an overtime compensation indication and the first overtime;
and when a CCM message from a remote MEP device is received, determining that an extension field in the CCM message carries an overtime compensation indication and the first overtime, and performing fault detection according to the first overtime.
2. The method of claim 1, wherein configuring a second packetization interval supported by a hardware layer according to the first packetization interval when timeout compensation is required comprises:
when the hardware layer supports the first packet sending interval, configuring a second packet sending interval of the hardware layer as the first packet sending interval;
when the hardware layer does not support the first packet sending interval, configuring a second packet sending interval of the hardware layer as a packet sending interval which is supported by the hardware layer and is smaller than and closest to the first packet sending interval.
3. The method of claim 2, wherein performing fault detection in accordance with the first timeout period comprises:
when the hardware layer supports the first packet sending interval, calculating timeout time according to the configured second packet sending interval;
and when the calculated overtime time does not receive the CCM message of the remote MEP equipment, the hardware layer detects that fault alarm is carried out.
4. The method of claim 2, wherein performing fault detection in accordance with the first timeout period comprises:
when the hardware layer does not support the first packet sending interval, calculating second timeout time according to the configured second packet sending interval, and determining third timeout time needing software compensation according to the second timeout time and the first timeout time in the CCM;
when the CCM message from the far-end MEP equipment is received, detecting that the CCM message of the far-end MEP equipment is not received after the second timeout is exceeded through a hardware layer, and starting overtime detection through software layer detection;
and when the software layer detects that the CCM message of the remote equipment is not received after the third overtime time, performing fault alarm.
5. The method of claim 1, wherein determining whether timeout compensation is needed based on a time required parameter for fault detection comprises:
if the first packet sending interval and/or the first timeout time of the MEP equipment accord with the CFM standard protocol, determining that timeout compensation is not needed, otherwise, determining that timeout compensation is needed.
6. The method of claim 1, further comprising:
when the overtime compensation is not needed, configuring a second packet sending interval of the hardware layer as the first packet sending interval;
sending a Continuity Check Message (CCM) message according to a configured second packet sending interval through a hardware layer, wherein the CCM message carries a packet sending interval threshold value indicating the first packet sending interval;
when a CCM message from the remote MEP equipment is received, calculating the timeout time according to the configured second packet sending interval;
and when detecting that the CCM message of the remote MEP equipment is not received after the calculated timeout period is exceeded through a hardware layer, carrying out fault alarm.
7. The method of claim 1, wherein when the timeout compensation is required, the CCM message further carries a packet transmission interval threshold value indicating a corresponding packet transmission interval defined by any standard protocol.
8. The method of claim 1, wherein an extension field in the CCM message is an extension field TLV, wherein the extension field comprises a TYPE field and a value VLAUE field, wherein the TYPE field fills a timeout compensation indication, and wherein the VLAUE field fills the first timeout time.
9. The method according to claim 1, wherein the receiving a CCM message from a remote MEP device comprises:
when the hardware layer supports the first packet sending interval, receiving a packet sending interval corresponding to the first timeout time in a CCM message from a remote MEP device, and starting timeout timing when the packet sending interval is consistent with the first packet sending interval configured by the hardware layer;
and when the hardware layer does not support the first packet sending interval, receiving the first timeout time in the CCM message from the remote MEP equipment once, and starting second timeout time timing when the first timeout time in the time requirement parameter is consistent with the first timeout time in the time requirement parameter.
10. An apparatus for fault detection, comprising:
the system comprises a timeout compensation determining module, a timeout compensation determining module and a fault detection module, wherein the timeout compensation determining module is used for determining whether timeout compensation is needed according to a time requirement parameter of fault detection, and the time requirement parameter comprises a first packet sending interval and/or first timeout time;
the hardware configuration module is used for configuring a second packet sending interval supported by a hardware layer according to the first packet sending interval when overtime compensation is needed;
the message sending module is used for sending a Continuity Check Message (CCM) through a hardware layer according to a configured second packet sending interval, wherein an extension field in the CCM carries an overtime compensation indication and the first overtime;
and the fault detection module is used for determining that an extension field in the CCM message carries an overtime compensation indication and the first overtime when the CCM message from the remote MEP equipment is received, and carrying out fault detection according to the first overtime.
11. An apparatus for fault detection, comprising at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-9.
12. A computer storage medium, characterized in that the computer storage medium stores a computer program for causing a computer to perform the method according to any one of claims 1-9.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110708917.7A CN113438112B (en) | 2021-06-25 | 2021-06-25 | Fault detection method, device, equipment and medium |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110708917.7A CN113438112B (en) | 2021-06-25 | 2021-06-25 | Fault detection method, device, equipment and medium |
Publications (2)
Publication Number | Publication Date |
---|---|
CN113438112A true CN113438112A (en) | 2021-09-24 |
CN113438112B CN113438112B (en) | 2022-12-20 |
Family
ID=77754327
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110708917.7A Active CN113438112B (en) | 2021-06-25 | 2021-06-25 | Fault detection method, device, equipment and medium |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN113438112B (en) |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1953400A (en) * | 2005-10-17 | 2007-04-25 | 华为技术有限公司 | A method to control the continuity detection of Ethernet link |
US20110026397A1 (en) * | 2008-04-16 | 2011-02-03 | Panagiotis Saltsidis | Connectivity fault management traffic indication extension |
CN102714607A (en) * | 2009-12-10 | 2012-10-03 | 阿尔卡特朗讯公司 | Connectivity fault management timeout period control |
US20130114394A1 (en) * | 2011-11-07 | 2013-05-09 | Ciena Corporation | Systems and methods for dynamic operations, administration, and management |
CN103731322A (en) * | 2014-01-16 | 2014-04-16 | 杭州华三通信技术有限公司 | Method and device for detecting self-adapting link among devices with different capabilities |
CN108282383A (en) * | 2017-12-18 | 2018-07-13 | 瑞斯康达科技发展股份有限公司 | A kind of method and apparatus for realizing troubleshooting |
-
2021
- 2021-06-25 CN CN202110708917.7A patent/CN113438112B/en active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1953400A (en) * | 2005-10-17 | 2007-04-25 | 华为技术有限公司 | A method to control the continuity detection of Ethernet link |
US20110026397A1 (en) * | 2008-04-16 | 2011-02-03 | Panagiotis Saltsidis | Connectivity fault management traffic indication extension |
CN102714607A (en) * | 2009-12-10 | 2012-10-03 | 阿尔卡特朗讯公司 | Connectivity fault management timeout period control |
US20130114394A1 (en) * | 2011-11-07 | 2013-05-09 | Ciena Corporation | Systems and methods for dynamic operations, administration, and management |
CN103731322A (en) * | 2014-01-16 | 2014-04-16 | 杭州华三通信技术有限公司 | Method and device for detecting self-adapting link among devices with different capabilities |
CN108282383A (en) * | 2017-12-18 | 2018-07-13 | 瑞斯康达科技发展股份有限公司 | A kind of method and apparatus for realizing troubleshooting |
Also Published As
Publication number | Publication date |
---|---|
CN113438112B (en) | 2022-12-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
USRE42253E1 (en) | Optimizations and enhancements to the IEEE RSTP 802.1W implementation | |
US7969896B2 (en) | Method and system for providing connectivity outage detection for MPLS core networks based on service level agreement | |
US11463341B2 (en) | Network health monitoring | |
US10277454B2 (en) | Handling failure of stacking system | |
CN102710457B (en) | A kind of N+1 backup method of cross-network segment and device | |
CN113726556B (en) | Edge internet of things proxy node operation and maintenance method, system, storage medium and computing equipment | |
EP3806392A1 (en) | Fault management method and related device | |
CN102263651A (en) | Method for detecting connection state of local end equipment in SNMP (simple network management protocol) network management system (NMS) | |
EP3866393A1 (en) | Data center traffic exchange method and apparatus, device and storage medium | |
CN101729426A (en) | Method and system for quickly switching between master device and standby device of virtual router redundancy protocol (VRRP) | |
US10567195B2 (en) | Network nodes in a ring network | |
CN109639488B (en) | Multi-extranet shunt acceleration method and system | |
CN101938369B (en) | Comprehensive network management access management system, management method and network management system applying same | |
EP4264901A1 (en) | Mitigation of physical network misconfigurations for clustered nodes | |
US20050083855A1 (en) | Method and system for identifying the health of virtual routers | |
CN113438112B (en) | Fault detection method, device, equipment and medium | |
US10374941B2 (en) | Determining aggregation information | |
US20230106077A1 (en) | Distributed Storage System, Exception Handling Method Thereof, and Related Apparatus | |
Lee et al. | Fault localization in NFV framework | |
US20120230207A1 (en) | Early detection of loss of continuity in a maintenance association | |
Cisco | show rmsautostate through show timezone | |
KR20120074528A (en) | Cluster node control method and internet protocol private branch exchange | |
CN113760459A (en) | Virtual machine failure detection method, storage medium and virtualized cluster | |
CN101043357A (en) | Automatic discovery method for equipment | |
US20250030775A1 (en) | Enhanced systems and methods for persistent network paths |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |