A BGP Down fault locating method and device

Abstract

The application discloses a BGP Down fault positioning method and device, wherein the method comprises the following steps: S01, network data loading, detecting BGP state; S02, logging in local equipment, detecting local equipment state; S03, logging in opposite equipment, detecting opposite equipment state. The application discloses a BGP Down fault positioning method and device, which is attached with expert ability, automatically performs BGP Down fault diagnosis in combination with alarm information, network protocol and test command, performs real-time analysis and processing on inspection result data, guarantees timeliness, performs flow processing and analysis on BGP Down fault, helps network operation and maintenance personnel to quickly locate the position of service fault, reduces work pressure, standardizes and automates the fault positioning process, reduces the possibility of artificial mischeck and oversight, improves the accuracy of fault diagnosis, and improves the efficiency of fault positioning.

Description

Technical Field

[0001] This invention relates to the field of communications, and in particular to a BGP Down fault location method and apparatus. Background Technology

[0002] BGP (Border Gateway Protocol) is a widely used routing protocol in IP networks, responsible for transmitting routing information between different autonomous systems. A BGP down failure can cause network interruption, affecting data transmission and user experience. Because it's a protocol-level failure, troubleshooting is complex. Maintenance personnel need to spend considerable time manually determining the fault location, leading to prolonged system downtime and negatively impacting customers.

[0003] Maintenance personnel need to use their professional knowledge and various protocols and commands to analyze faults, spending a lot of time manually determining the cause of BGP down faults. This is time-consuming, labor-intensive, and results in a low timeliness of fault handling, placing a heavy burden on maintenance personnel. Summary of the Invention

[0004] To address the problems existing in the prior art, this invention provides a BGP Down fault location method and apparatus. By collecting and analyzing alarms and protocol status of network elements experiencing BGP Down faults, and initiating tests on the faulty network elements, the cause of the BGP Down fault can be located, reducing the workload of network operation and maintenance personnel and improving operation and maintenance efficiency.

[0005] To achieve the above objectives, the present invention adopts the following technical solution:

[0006] In one embodiment of the present invention, a BGP Down fault location method is proposed, the method comprising:

[0007] S01. Load network data and check BGP status;

[0008] S011. Load network alarm data. Alarms include: device port down alarm, BGP down alarm. When a device network element has a port down alarm, and BGP down alarms occur 3 or more times, determine whether the BGP protocol down is caused by the device port down.

[0009] S012. Check if the BGP status has been restored;

[0010] S013. Check if the BGP status is idle. If the BGP status is idle, locate the cause of the fault and the process ends; if the BGP status is not idle, proceed to S014.

[0011] S014. Check if the BGP route exceeds the limit. If the BGP route exceeds the limit, check the BGP route settings. This will not directly affect BGPDOWN or interrupt the diagnostic process. Proceed to S015.

[0012] S015. Check if an error message is received. If an error message is received, the BGP error message does not directly affect BGPDOWN. Receiving an error message does not interrupt the diagnostic process. Complete the reception of the BGP error message and proceed to S016.

[0013] S016. Check if BGP configuration is causing neighbor disconnection;

[0014] S017. Check if the BGP direct connection is disconnected. If both the Current state and Line protocol of the port are UP, then pass; otherwise, fail.

[0015] Current state refers to the current state of the BGP neighbor, and Line protocol state refers to the line protocol state of the interface.

[0016] S018. Check if a Notification message, Hold timer expiration, or remote peer unreachable message has been received. If not received, proceed to manual processing. If the above information is received, proceed to S02.

[0017] S02. Log in to the local device and check the status of the local device;

[0018] S021. Check if the interconnection interface status is normal, and whether the CRC, symbol, and error counts are increasing; if the port status is UP, it is normal, otherwise it is abnormal; if the CRC, symbol, and error counts increase, it indicates that the interconnection port is abnormal.

[0019] If an error occurs, the message "An error occurred on the local interconnect port, causing BGP interruption. The cause of the fault has been located and the process ends" will be displayed.

[0020] If everything is normal, proceed to S022;

[0021] S022. Execute the command to check if the VPN BFD status is normal. If the state is UP, it means normal; otherwise, it is abnormal.

[0022] An error message will appear: BGP interrupted, local VPN BFD status is abnormal, the cause of the fault has been located, and the process ends.

[0023] If everything is normal, proceed to S023;

[0024] S023. Ping the interconnected IP address to check if it is reachable. If the ping to the port interconnected address is successful, the test is passed and proceed to S024; if the ping test fails, the message "This end pings the other end's interconnected address and cannot reach it" will be displayed, the cause of the fault will be located, and the process will end.

[0025] S024. Ping the neighbor's IP address to check if it is reachable. If the ping to the neighbor's address is successful, the test is passed and proceed to S025; otherwise, the message "The local end cannot reach the peer's neighbor address by ping" is displayed, the cause of the fault is located, and the process ends.

[0026] S025. Check if the CPU utilization is normal. Execute the command: display cpu-usage. If the CPU utilization is lower than the threshold, the test passes; if the CPU utilization exceeds the threshold, it is abnormal. The prompt is: Local CPU utilization is abnormal / too high. The CPU utilization test results do not interrupt the diagnostic process. Proceed to S026.

[0027] S026. Check if ACL 179 is restricting access. If BGP is configured to allow access, the check passes and proceeds to S027. If the check fails, the message "Local ACL 179 is restricted" will be displayed. The cause of the fault will be located and the process will end.

[0028] S027. Trace neighbor addresses to determine if the bidirectional trace paths at both ends are consistent. If they are inconsistent, prompt: "The round-trip paths of this end and the other end are inconsistent." Consistency judgment results do not interrupt the diagnostic process; proceed to S028.

[0029] S028. Check if there is a port interruption alarm. Check if the interconnected port has an interruption alarm within the range of BGP Down alarm occurrence time -10 minutes to the last alarm occurrence time +10 minutes. If no interruption alarm occurs, the check passes and proceeds to S03; if an interruption alarm occurs, the check fails and the message "Interconnected port on this end has an interruption alarm, the cause of the fault has been located, and the process ends" is displayed.

[0030] S03. Log in to the peer device and check the status of the peer device;

[0031] S031. Check if the Peer IP configuration is correct. Execute the command display bgp peer to view the status and configuration information of the BGP neighbor. If the configuration is correct, the check passes and proceeds to S032. If the configuration is abnormal, the check fails and the message "No problem on this end, but the BGP peer IP configuration is incorrect" is displayed. Locate the cause of the fault and the process ends.

[0032] S032. Check if the BGP status is idle. If the BGP status is idle, the message "TCP 179 unreachable" will be displayed. Manually close the connection, locate the cause of the fault, and the process ends. If the BGP status is not idle, proceed to S033.

[0033] S033. Check if the VPN BFD status is normal. The checking method is the same as S022. If the VPN BFD status is abnormal, the prompt will be: BGP interrupted, the peer VPN BFD status is abnormal. Locate the cause of the fault and the process ends. If the VPN BFD status is normal, proceed to S034.

[0034] S034. Ping the interconnected IP to check if it is reachable. The method of checking is the same as S023. If it fails, the message "BGP interrupted, the peer's interconnected address cannot be reached by ping" will be displayed. The cause of the fault will be located and the process will end. If the check passes, proceed to S035.

[0035] S035. Ping the neighbor's IP address to check if it is reachable. The method of checking is the same as S024. If it fails, the message "BGP interrupted, ping test of the peer neighbor address is unreachable" will be displayed. The cause of the fault will be located and the process will end. If the check passes, proceed to S036.

[0036] S036. Check if the CPU utilization is normal. The checking method is the same as S025. If the CPU utilization is abnormal, prompt: The CPU utilization of the other end is abnormal / too high. Regardless of whether it is normal or abnormal, the diagnostic process will not be interrupted and will proceed to S037.

[0037] S037. Check if ACL 179 is restrictive. The checking method is the same as S026. If BGP is configured to allow access, the check will pass and proceed to S038. If it fails, the message "BGP interrupted, peer ACL 179 restrictive" will be displayed. The cause of the fault will be located and the process will end.

[0038] S038. Trace neighbor addresses to determine if the bidirectional trace paths at both ends are consistent. The checking method is the same as in S027. If they are inconsistent, the message "Bidirectional paths are inconsistent" will be displayed. If they are consistent, the diagnostic process will not be interrupted and will proceed to S039.

[0039] S039. Check if there is a port interruption alarm. If an interruption alarm occurs, the check fails and the message "BGP interruption, peer port interruption alarm" is displayed. The cause of the fault is located and the process ends. If no interruption alarm occurs, the process is transferred to manual handling.

[0040] Further, S012 includes:

[0041] S0121. Check if the normal BGP status has been restored. If the BGP status is ESTABLISHED, the BGP connection has self-healed and the fault has been recovered during the test, and the process ends. If the BGP status has not been restored, proceed to S013.

[0042] S0122. Check if the VPN BGP status has recovered. If the BGP status is ESTABLISHED, the BGP connection has self-healed and the fault has been recovered during the check, and the process ends. If the BGP status has not recovered, proceed to S013.

[0043] Further, S016 includes:

[0044] S0161. Execute the command: show running-config bgp | inc [neighbor's IP];

[0045] S0162. If result information is returned and the neighbor connection is not broken, proceed to S017.

[0046] S0163. No results returned, indicating that the neighbor is disconnected. The neighbor is disconnected, prompting: BGP configuration error. Check the BGP peer settings, locate the cause of the fault, and the process ends.

[0047] Further, S017 includes:

[0048] S0171. If the port is a physical port, then query the physical port twice to check if the CRC and Symbol values ​​have increased.

[0049] S0172. If the port is a bundled Eth-Trunk port, then query the corresponding physical port, and then query the physical port twice to check if the CRC and Symbol have increased.

[0050] S0173 If the test fails, the message "BGP direct connection port disconnected" will be displayed. The interconnect interface will be tested, and the test information will be loaded to locate the cause of the fault. The process will then end.

[0051] S0174, Test passed, proceed to S018.

[0052] Furthermore, the status and configuration information of the BGP neighbor in S031 includes: IP address, AS number, status, and whether a BGP session has been established.

[0053] In one embodiment of the present invention, a BGP Down fault location device is also provided, the device comprising:

[0054] The network data loading module detects BGP status, including:

[0055] Load network alarm data, including: device port down alarm, BGP down alarm. When a device network element has a port down alarm, and BGP down alarms occur 3 or more times, determine whether the BGP protocol down is caused by the device port down.

[0056] Check if the BGP status has been restored;

[0057] Check if the BGP status is idle. If the BGP status is idle, locate the cause of the fault and the process ends; if the BGP status is not idle, proceed to the next step.

[0058] Check if the BGP route exceeds the limit. If the BGP route exceeds the limit, check the BGP route settings. This will not directly affect BGP DOWN, will not interrupt the diagnostic process, and will proceed to the next step.

[0059] Check if an error message has been received. If an error message is received, the BGP error message does not directly affect BGPDOWN. Receiving an error message does not interrupt the diagnostic process. Complete the reception of the BGP error message and proceed to the next step.

[0060] Check if BGP configuration is causing neighbor disconnections;

[0061] The system checks whether the BGP direct connection is disconnected. If both the Current state and Line protocol of the port are UP, the test passes; otherwise, it fails.

[0062] Current state refers to the current state of the BGP neighbor, and Line protocol state refers to the line protocol state of the interface.

[0063] Check if a Notification message, Hold timer expiration, or remote peer unreachable message has been received. If not, proceed to manual handling. If the above information is received, proceed to the local device login module.

[0064] Log in to the local device module to check the status of the local device, including:

[0065] Check if the interconnection interface status is normal, and whether the CRC, symbol, and error counts are increasing; if the port status is UP, it is normal, otherwise it is abnormal; if the CRC, symbol, and error counts are increasing, it indicates that the interconnection port is abnormal;

[0066] If an error occurs, the message "An error occurred on the local interconnect port, causing BGP interruption. The cause of the fault has been located and the process ends" will be displayed.

[0067] If everything is normal, proceed to the next step;

[0068] The command is executed to check if the VPN BFD status is normal. If the state is UP, it means it is normal; otherwise, it is abnormal.

[0069] An error message will appear: BGP interrupted, local VPN BFD status is abnormal, the cause of the fault has been located, and the process ends.

[0070] If everything is normal, proceed to the next step;

[0071] Ping the interconnected IP address to check if it is reachable. If the ping to the interconnected address on the port is successful, the test is passed and you can proceed to the next step. If the ping test fails, the message "This end cannot reach the interconnected address of the other end by ping" will be displayed, the cause of the fault will be located, and the process will end.

[0072] Ping the neighbor's IP address to check if it is reachable. If the ping to the neighbor's address is successful, the test is complete and proceed to the next step; otherwise, the message "This end cannot reach the neighbor's address when pinged" is displayed, the cause of the fault is located, and the process ends.

[0073] To check if CPU utilization is normal, execute the command: display cpu-usage. If CPU utilization is below the threshold, the test passes; if CPU utilization exceeds the threshold, it is abnormal, and the message "Local CPU utilization is abnormal / too high" will be displayed. The results of the CPU utilization test will not interrupt the diagnostic process; proceed to the next step.

[0074] Check if ACL 179 is restricting access. If BGP is configured to allow access, the check passes and proceeds to the next step. If the check fails, the message "Local ACL 179 is restricted" will be displayed. Once the cause of the fault is identified, the process ends.

[0075] Trace neighbor addresses to determine if the bidirectional trace paths at both ends are consistent. If they are inconsistent, an error message is displayed: "The round-trip paths of this end and the other end are inconsistent." Consistency determination results do not interrupt the diagnostic process; proceed to the next step.

[0076] Check for port interruption alarms. Check if the interconnected port experienced an interruption alarm within the range of BGP Down alarm occurrence time -10 minutes to the last alarm occurrence time +10 minutes. If no interruption alarm occurred, the check passes and proceeds to the peer device login module. If an interruption alarm occurred, the check fails and the message "Interconnected port experienced interruption alarm" is displayed. The cause of the fault has been located and the process ends.

[0077] Log in to the peer device module and check the peer device status, including:

[0078] Check if the Peer IP configuration is correct. Execute the command `display bgp peer` to view the status and configuration information of the BGP neighbor. If the configuration is correct, the check passes and you can proceed to the next step. If the configuration is abnormal, the check fails and the message "No problem on this end, but the BGP peer IP configuration is incorrect" is displayed. Locate the cause of the fault and the process ends.

[0079] Check if the BGP status is idle. If the BGP status is idle, the message "TCP 179 unreachable" will appear. Manually close the connection, locate the cause of the fault, and the process ends. If the BGP status is not idle, proceed to the next step.

[0080] Check if the VPN BFD status is normal. The checking method is the same as the process for logging into the local device module. If the VPN BFD status is abnormal, the prompt will be: BGP interrupted, peer VPN BFD status is abnormal. Locate the cause of the fault and the process ends. If the VPN BFD status is normal, proceed to the next step.

[0081] Ping the interconnected IP address to check its reachability. The method for checking this is the same as the process for logging into the local device module. If it fails, the message "BGP interrupted, ping test of the peer's interconnected address is unreachable" will be displayed. Once the cause of the fault is located, the process ends. If the check passes, proceed to the next step.

[0082] Ping the neighbor's IP address to check if it is reachable. The method for checking is the same as the process of logging into the local device module. If it fails, the message "BGP interrupted, ping test of the peer neighbor address is unreachable" will be displayed. After locating the cause of the fault, the process ends. If the check passes, proceed to the next step.

[0083] Check if the CPU utilization is normal. The checking method is the same as the process of logging into the local device module. If the CPU utilization is abnormal, the message "Peer CPU utilization is abnormal / too high" will be displayed. Regardless of whether it is normal or abnormal, the diagnostic process will not be interrupted and will proceed to the next step.

[0084] Check if ACL 179 is restricted. The checking method is the same as the login process for the local device module. If BGP is configured to allow access, the check will pass and proceed to the next step; otherwise, the message "BGP interrupted, peer ACL 179 restricted" will be displayed. After locating the cause of the fault, the process ends.

[0085] Trace neighbor addresses to determine if the bidirectional trace paths at both ends are consistent. The checking method is the same as the process for logging into the local device module. If they are inconsistent, the message "Bidirectional paths are inconsistent" will be displayed. If they are consistent, the diagnostic process will not be interrupted and will proceed to the next step.

[0086] Check for port interruption alarms. If an interruption alarm occurs, the check fails and the message "BGP interruption, peer port interruption alarm" is displayed. Once the cause of the fault is located, the process ends. If no interruption alarm occurs, the process is transferred to manual handling.

[0087] In one embodiment of the present invention, a computer device is also proposed, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the aforementioned BGP Down fault location method.

[0088] In one embodiment of the present invention, a computer-readable storage medium is also provided, which stores a computer program for performing the BGP Down fault location method.

[0089] Beneficial effects:

[0090] This invention provides a BGP Down fault location method and apparatus. It incorporates expert capabilities and automatically diagnoses BGP Down faults by combining alarm information, network protocols, and test commands. The method performs real-time analysis and processing of the inspection results to ensure timeliness. It provides a streamlined process for analyzing BGP Down faults, helping network maintenance personnel quickly locate service faults, reducing their workload. The standardized and automated fault location process reduces the possibility of human error and omissions, improving the accuracy of fault diagnosis and enhancing the efficiency of fault location. Attached Figure Description

[0091] Figure 1 This is a schematic diagram of the BGP Down fault location method of the present invention;

[0092] Figure 2 This is a schematic diagram of the BGP Down fault location device of the present invention;

[0093] Figure 3 This is a schematic diagram of a computer device structure according to an embodiment of the present invention. Detailed Implementation

[0094] The principles and spirit of the present invention will now be described with reference to several exemplary embodiments. It should be understood that these embodiments are provided merely to enable those skilled in the art to better understand and implement the present invention, and are not intended to limit the scope of the present invention in any way. Rather, these embodiments are provided to make this disclosure more thorough and complete, and to fully convey the scope of this disclosure to those skilled in the art.

[0095] Those skilled in the art will recognize that embodiments of the present invention can be implemented as a system, apparatus, device, method, or computer program product. Therefore, this disclosure can be specifically implemented in the following forms: entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.

[0096] According to an embodiment of the present invention, a BGP Down fault location method and apparatus are proposed. By collecting and analyzing alarms and protocol status of network elements experiencing BGP Down faults, and initiating tests on the faulty network elements, the cause of BGP Down faults can be located, thereby reducing the workload of network operation and maintenance personnel and improving operation and maintenance efficiency.

[0097] The principles and spirit of the present invention will be explained in detail below with reference to several representative embodiments.

[0098] like Figure 1 As shown, the present invention relates to a BGP Down fault location method, the method comprising:

[0099] S01. Load network data and check BGP status;

[0100] S01 includes:

[0101] S011. Load network alarm data. Alarms include: device port down alarm, BGP down alarm. When a device network element has a port down alarm, and BGP down alarms occur 3 or more times, determine whether the BGP protocol down is caused by the device port down.

[0102] S012. Check if the BGP status has been restored;

[0103] S012 includes:

[0104] S0121. Check if the normal BGP status has been restored. If the BGP status is ESTABLISHED, the BGP connection has self-healed and the fault has been recovered during the test, and the process ends. If the BGP status has not been restored, proceed to S013.

[0105] S0122. Check if the VPN BGP status has recovered. If the BGP status is ESTABLISHED, the BGP connection has self-healed and the fault has been recovered during the check, and the process ends. If the BGP status has not recovered, proceed to S013.

[0106] S013. Check if the BGP status is idle (admin). If the BGP status is idle (admin), locate the cause of the fault and the process ends; if the BGP status is not idle (admin), proceed to S014.

[0107] S014. Check if the BGP route exceeds the limit. If the BGP route exceeds the limit, check the BGP route settings. This will not directly affect BGPDOWN or interrupt the diagnostic process. Proceed to S015.

[0108] S015. Check if an error message is received. If an error message is received, the BGP error message does not directly affect BGPDOWN. Receiving an error message does not interrupt the diagnostic process. Complete the reception of the BGP error message and proceed to S016.

[0109] S016. Check if BGP configuration is causing neighbor disconnection;

[0110] S016 includes:

[0111] S0161. Execute the command: show running-config bgp | inc [neighbor's IP];

[0112] S0162. If result information is returned and the neighbor connection is not broken, proceed to S017.

[0113] S0163. No results returned, indicating that the neighbor is disconnected. The neighbor is disconnected, prompting: BGP configuration error. Check the BGP peer settings, locate the cause of the fault, and the process ends.

[0114] S017. Check if the BGP direct connection is disconnected. If both the Current state and Line protocol of the port are UP, then pass; otherwise, fail.

[0115] Current state refers to the current state of the BGP neighbor, while Line protocol state refers to the line protocol state of the interface.

[0116] S017 includes:

[0117] S0171. If the port is a physical port, then query the physical port twice to check if the CRC and Symbol values ​​have increased.

[0118] S0172. If the port is a bundled Eth-Trunk port, then query the corresponding physical port, and then query the physical port twice to check if the CRC and Symbol have increased.

[0119] A rapid increase in CRC can cause physical ports to go down, leading to the downing of all protocols.

[0120] S0173 If the test fails, the message "BGP direct connection port disconnected" will be displayed. The interconnect interface will be tested, and the test information will be loaded to locate the cause of the fault. The process will then end.

[0121] S0174, Test passed, proceed to S018.

[0122] S018. Check if a Notification message, Hold timer expiration, or remote peer unreachable message has been received. If not received, proceed to manual processing. If the above information is received, proceed to S02.

[0123] S02. Log in to the local device and check the status of the local device;

[0124] S02 includes:

[0125] S021. Check if the interconnection interface status is normal, and whether the error counts such as CRC, symbol, and error are increasing; if the port status is UP, it is normal, otherwise it is abnormal; if the error counts such as CRC, symbol, and error are increasing, it indicates that the interconnection port is abnormal;

[0126] If an error occurs, the message "An error occurred on the local interconnect port, causing BGP interruption. The cause of the fault has been located and the process ends" will be displayed.

[0127] If everything is normal, proceed to S022;

[0128] S022. Execute the command to check if the VPN BFD status is normal. If the state is UP, it means normal; otherwise, it is abnormal.

[0129] An error message will appear: BGP interrupted, local VPN BFD status is abnormal, the cause of the fault has been located, and the process ends.

[0130] If everything is normal, proceed to S023;

[0131] S023. Ping the interconnected IP address to check if it is reachable. If the ping to the port interconnected address is successful, the test is passed and proceed to S024. If the ping test fails, the message "This end pings the other end's interconnected address and cannot reach it" will be displayed. The cause of the fault has been located and the process ends.

[0132] S024. Ping the neighbor's IP address to check if it is reachable. If the ping to the neighbor's address is successful, the test is passed and proceed to S025; otherwise, the message "Ping the neighbor's address on this end is unreachable" is displayed, the cause of the fault is located, and the process ends.

[0133] S025. Check if the CPU utilization is normal. Execute the command: display cpu-usage. If the CPU utilization is lower than the threshold (initialized to 75%), the test passes. If the CPU utilization exceeds the threshold, it is abnormal. The prompt is: Local CPU utilization is abnormal (too high). The CPU utilization test results do not interrupt the diagnostic process. Proceed to S026.

[0134] S026. Check if ACL 179 is restricted. If BGP (179) is configured to allow access, the check passes and proceeds to S027. If the check fails, the message "Local ACL 179 is restricted" will be displayed. The cause of the fault will be located and the process will end.

[0135] S027. Trace neighbor addresses to determine if the bidirectional trace paths at both ends are consistent. If they are inconsistent, prompt: "The round-trip paths of this end and the other end are inconsistent." Consistency judgment results do not interrupt the diagnostic process; proceed to S028.

[0136] S028. Check if there is a port interruption alarm. Check if the interconnected port has an interruption alarm within the range of BGP Down alarm occurrence time -10 minutes to the last alarm occurrence time +10 minutes. If no interruption alarm occurs, the check passes and proceeds to S03; if an interruption alarm occurs, the check fails and the message "Interconnected port on this end has an interruption alarm, the cause of the fault has been located, and the process ends" is displayed.

[0137] S03. Log in to the peer device and check the status of the peer device.

[0138] S03 includes:

[0139] S031. Check if the Peer IP configuration is correct. Execute the command display bgp peer to view the status and configuration information of the BGP neighbor. If the configuration is correct, the check passes and proceeds to S032. If the configuration is abnormal, the check fails and the message "No problem on this end, but the BGP peer IP configuration is incorrect" is displayed. Locate the cause of the fault and the process ends.

[0140] The status and configuration information of the BGP neighbor in S031 includes: IP address, AS number, status, and whether a BGP session has been established.

[0141] S032. Check if the BGP status is idle(admin). If the BGP status is idle(admin), the message "TCP 179 unreachable" will be displayed. Manually close the connection, locate the cause of the fault, and the process will end. If the BGP status is not idle(admin), proceed to S033.

[0142] S033. Check if the VPN BFD status is normal. The checking method is the same as S022. If the VPN BFD status is abnormal, the prompt will be: BGP interrupted, the peer VPN BFD status is abnormal. Locate the cause of the fault and the process ends. If the VPN BFD status is normal, proceed to S034.

[0143] S034. Ping the interconnected IP to check if it is reachable. The method of checking is the same as S023. If it fails, the message "BGP interrupted, the peer's interconnected address cannot be reached by ping" will be displayed. The cause of the fault will be located and the process will end. If the check passes, proceed to S035.

[0144] S035. Ping the neighbor's IP address to check if it is reachable. The method of checking is the same as S024. If it fails, the message "BGP interrupted, ping test of the peer neighbor address is unreachable" will be displayed. The cause of the fault will be located and the process will end. If the check passes, proceed to S036.

[0145] S036. Check if the CPU utilization is normal. The checking method is the same as S025. If the CPU utilization is abnormal, the prompt will be: The CPU utilization of the other end is abnormal (too high). Regardless of whether it is normal or abnormal, the diagnostic process will not be interrupted. Proceed to S037.

[0146] S037. Check if ACL 179 is restricted. The checking method is the same as S026. If BGP (179) is configured to allow passage, the check will pass and proceed to S038. If it fails, the message will be: BGP interrupted, peer ACL 179 restricted. The cause of the fault will be located and the process will end.

[0147] S038. Trace neighbor addresses to determine if the bidirectional trace paths at both ends are consistent. The checking method is the same as in S027. If they are inconsistent, the message "Bidirectional paths are inconsistent" will be displayed. If they are consistent, the diagnostic process will not be interrupted and will proceed to S039.

[0148] S039. Check if there is a port interruption alarm. If an interruption alarm occurs, the check fails and the message "BGP interruption, peer port interruption alarm" is displayed. The cause of the fault is located and the process ends. If no interruption alarm occurs, the process is transferred to manual handling.

[0149] It should be noted that although the operation of the method of the present invention has been described in a specific order in the above embodiments and figures, this does not require or imply that the operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0150] To provide a clearer explanation of the above-mentioned BGP Down fault location method, specific embodiments are described below. However, it is worth noting that these embodiments are only for better illustrating the present invention and do not constitute an improper limitation of the present invention.

[0151] S01. Load network data and check BGP status;

[0152] S01 includes:

[0153] S011. Load network alarm data. Alarms include: device port down alarm, BGP down alarm. When a device network element has a port down alarm, and BGP down alarms occur 3 or more times, determine whether the BGP protocol down is caused by the device port down.

[0154] S012. Check if the BGP status has been restored;

[0155] S012 includes:

[0156] S0121. Check if the normal BGP status has been restored. If the BGP status is ESTABLISHED, the BGP connection has self-healed and the fault has been recovered during the test, and the process ends. If the BGP status has not been restored, proceed to S013.

[0157] The "ESTABLISHED" state in the BGP state machine indicates that the BGP neighbor relationship has been successfully established and that BGP peers can exchange routing information.

[0158] ipv4: dis bgp peer 36.133.59.254 verbose;

[0159] ipv6: dis bgp ipv6 peer 2409:8000::1:1 verbose;

[0160] S0122. Check if the VPN BGP status has recovered. If the BGP status is ESTABLISHED, the BGP connection has self-healed and the fault has been recovered during the check, and the process ends. If the BGP status has not recovered, proceed to S013.

[0161] ipv4: display bgp vpnv4 all peer;

[0162] display bgp vpnv4 vpn-instance ChinaMobile_CBOSS peer 10.5.90.214verbose;

[0163] ipv6: display bgp vpnv6 all peer;

[0164] display bgp vpnv6 vpn-instance ChinaMobile_CBOSS peer 2409:8000:4820:B401::1 verbose

[0165] S013. Check if the BGP status is idle (admin). If the BGP status is idle (admin), locate the cause of the fault and the process ends; if the BGP status is not idle (admin), proceed to S014.

[0166] The idle (admin) state is a state in BGP (Border Gateway Protocol). "idle" represents the initial state of BGP, while "admin" indicates a state resulting from administrator intervention (such as manually closing the BGP session). In the "idle" state, the BGP process will not attempt to establish TCP connections with neighbors, nor will it send or receive BGP messages.

[0167] S014. Check if the BGP route exceeds the limit. If the BGP route exceeds the limit, check the BGP route settings. This will not directly affect BGPDOWN or interrupt the diagnostic process. Proceed to S015.

[0168] For regular BGP, execute:

[0169] display bgp peer 36.133.59.254 verbose;

[0170] display bgp routing-table peer 36.133.59.254 received-routes;

[0171] VPN BGP, execute:

[0172] display ip vpn-instance verbose vpn-instance-name

[0173] The results show:

[0174] For address family :IPv4 Unicast

[0175] Med attribute sent to th1s neighbor

[0176] Weight is O

[0177] Community attribute sent to this neighbor

[0178] Advertised prefixes limit 4294967295

[0179] Maximum limit 4294967295

[0180] Threshold for warning message 75%

[0181] Maximum limit: 4294967295; Threshold for warning message: 75%.

[0182] S015. Check if an error message is received. If an error message is received, the BGP error message does not directly affect BGPDOWN. Receiving an error message does not interrupt the diagnostic process. Complete the reception of the BGP error message and proceed to S016.

[0183] S016. Check if BGP configuration is causing neighbor disconnection;

[0184] S016 includes:

[0185] S0161. Execute the command: show running-config bgp | inc [neighbor's IP];

[0186] S0162. If result information is returned and the neighbor connection is not broken, proceed to S017.

[0187] S0163. No results returned, indicating that the neighbor is disconnected. The neighbor is disconnected, prompting: BGP configuration error. Check the BGP peer settings, locate the cause of the fault, and the process ends.

[0188] Execute the command "show running-config bgp | inc 221.130.169.252[neighbor's IP]",

[0189] Example of execution result:

[0190] show running-config bgp | include 221.130.169.252

[0191] neighbor 221.130.169.252 remote-as 64810

[0192] neighbor 221.130.169.252 peer-group MAN_CORE_RR

[0193] neighbor 221.130.169.252 description XXX

[0194] S017. Check if the BGP direct connection is disconnected. If both the Current state and Line protocol of the port are UP, then pass; otherwise, fail.

[0195] Current state refers to the current state of the BGP neighbor, while Line protocol state refers to the line protocol state of the interface.

[0196] S017 includes:

[0197] S0171. If the port is a physical port, then query the physical port twice to check if the CRC and Symbol values ​​have increased.

[0198] S0172. If the port is a bundled Eth-Trunk port, then query the corresponding physical port, and then query the physical port twice to check if the CRC and Symbol have increased.

[0199] A rapid increase in CRC can cause physical ports to go down, leading to the downing of all protocols.

[0200] S0173 If the test fails, the message "BGP direct connection port disconnected" will be displayed. The interconnect interface will be tested, and the test information will be loaded to locate the cause of the fault. The process will then end.

[0201] S0174, Test passed, proceed to S018.

[0202] Detection method:

[0203] Standard BGP:

[0204] IPv4:

[0205] display ip routing-table 36.133.59.254;

[0206] dis curr | in route-static | in 36.133.59.254;

[0207] disp inte Eth-Trunk44;

[0208] IPv6:

[0209] display ip routing-table 2409:8000::1:1;

[0210] dis curr | in route-static | in 2409:8000::1:1;

[0211] disp ipv6 inte Eth-Trunk27;

[0212] VPN BGP:

[0213] IPv4:

[0214] display ip routing-table vpn-instance ChinaMobile_CBOSS 10.5.90.214;

[0215] disp inte Eth-Trunk6.419;

[0216] IPv6:

[0217] display ipv6 routing-table vpn-instance ChinaMobile_CBOSS 2409:8000:4820:B401::1;

[0218] disp ipv6 inte Eth-Trunk6.419;

[0219] S018. Check if a Notification message, Hold timer expiration, or remote peer unreachable message has been received. If not received, proceed to manual processing. If the above information is received, proceed to S02.

[0220] S02. Log in to the local device and check the status of the local device;

[0221] S02 includes:

[0222] S021. Check if the interconnection interface status is normal, and whether the error counts such as CRC, symbol, and error are increasing; if the port status is UP, it is normal, otherwise it is abnormal; if the error counts such as CRC, symbol, and error are increasing, it indicates that the interconnection port is abnormal;

[0223] If an error occurs, the message "An error occurred on the local interconnect port, causing BGP interruption. The cause of the fault has been located and the process ends" will be displayed.

[0224] If everything is normal, proceed to S022;

[0225] S022. Execute the command to check if the VPN BFD status is normal. If the state is UP, it means normal; otherwise, it is abnormal.

[0226] An error message will appear: BGP interrupted, local VPN BFD status is abnormal, the cause of the fault has been located, and the process ends.

[0227] If everything is normal, proceed to S023;

[0228] Detection method:

[0229] Execute command:

[0230] V6:

[0231] display bgp ipv6 bfd session peer ipv6-address;

[0232] V4:

[0233] display bgp bfd session peer ipv4-address

[0234] Execution result:

[0235] display bgp bfd session peer ipv4-address 10.10.1.1

[0236] Local|Remote|PeerIpAddr|State|Type|InterfaceName

[0237] 1 / 1|1 / 1|10.10.1.1|UP|S_IP_IF|GigabitEthernet / 0 / 0 / 0

[0238] Total UP / DOWN Session Number:1 / 0

[0239] S023. Ping the interconnected IP address to check if it is reachable. If the ping to the port interconnected address is successful, the test is passed and proceed to S024. If the ping test fails, the message "This end pings the other end's interconnected address and cannot reach it" will be displayed. The cause of the fault has been located and the process ends.

[0240] Ping testing methods:

[0241] V6:

[0242] ping ipv6 2409:8080::2D3

[0243] V4:

[0244] ping 221.183.20.82

[0245] S024. Ping the neighbor's IP address to check if it is reachable. If the ping to the neighbor's address is successful, the test is passed and proceed to S025; otherwise, the message "Ping the neighbor's address on this end is unreachable" is displayed, the cause of the fault is located, and the process ends.

[0246] Ping testing methods:

[0247] V6:

[0248] ping ipv6 2409:8080::2D3

[0249] V4:

[0250] ping 221.183.20.82

[0251] S025. Check if the CPU utilization is normal. Execute the command: display cpu-usage. If the CPU utilization is lower than the threshold (initialized to 75%), the test passes. If the CPU utilization exceeds the threshold, it is abnormal. The prompt is: Local CPU utilization is abnormal (too high). The CPU utilization test results do not interrupt the diagnostic process. Proceed to S026.

[0252] S026. Check if ACL 179 is restricted. If BGP (179) is configured to allow access, the check passes and proceeds to S027. If the check fails, the message "Local ACL 179 is restricted" will be displayed. The cause of the fault will be located and the process will end.

[0253] Inspection method:

[0254] IPv4:

[0255] display acl all | i 36.133.59.254

[0256] IPv6:

[0257] display acl ipv6 all | i 2409:8000::1:1

[0258] S027. Trace neighbor addresses to determine if the bidirectional trace paths at both ends are consistent. If they are inconsistent, prompt: "The round-trip paths of this end and the other end are inconsistent." Consistency judgment results do not interrupt the diagnostic process; proceed to S028.

[0259] Inspection method:

[0260] IPv4:

[0261] tracert 192.168.3.9

[0262] IPv6:

[0263] tracert ipv6 2409:8080::2D3

[0264] S028. Check if there is a port interruption alarm. Check if the interconnected port has an interruption alarm within the range of BGP Down alarm occurrence time -10 minutes to the last alarm occurrence time +10 minutes. If no interruption alarm occurs, the check passes and proceeds to S03; if an interruption alarm occurs, the check fails and the message "Interconnected port on this end has an interruption alarm, the cause of the fault has been located, and the process ends" is displayed.

[0265] S03. Log in to the peer device and check the status of the peer device.

[0266] S03 includes:

[0267] S031. Check if the Peer IP configuration is correct. Execute the command display bgp peer to view the status and configuration information of the BGP neighbor. If the configuration is correct, the check passes and proceeds to S032. If the configuration is abnormal, the check fails and the message "No problem on this end, but the BGP peer IP configuration is incorrect" is displayed. Locate the cause of the fault and the process ends.

[0268] The status and configuration information of the BGP neighbor in S031 includes: IP address, AS number, status, and whether a BGP session has been established.

[0269] S032. Check if the BGP status is idle(admin). If the BGP status is idle(admin), the message "TCP 179 unreachable" will be displayed. Manually close the connection, locate the cause of the fault, and the process will end. If the BGP status is not idle(admin), proceed to S033.

[0270] S033. Check if the VPN BFD status is normal. The checking method is the same as S022. If the VPN BFD status is abnormal, the prompt will be: BGP interrupted, the peer VPN BFD status is abnormal. Locate the cause of the fault and the process ends. If the VPN BFD status is normal, proceed to S034.

[0271] S034. Ping the interconnected IP to check if it is reachable. The method of checking is the same as S023. If it fails, the message "BGP interrupted, the peer's interconnected address cannot be reached by ping" will be displayed. The cause of the fault will be located and the process will end. If the check passes, proceed to S035.

[0272] S035. Ping the neighbor's IP address to check if it is reachable. The method of checking is the same as S024. If it fails, the message "BGP interrupted, ping test of the peer neighbor address is unreachable" will be displayed. The cause of the fault will be located and the process will end. If the check passes, proceed to S036.

[0273] S036. Check if the CPU utilization is normal. The checking method is the same as S025. If the CPU utilization is abnormal, the prompt will be: The CPU utilization of the other end is abnormal (too high). Regardless of whether it is normal or abnormal, the diagnostic process will not be interrupted. Proceed to S037.

[0274] S037. Check if ACL 179 is restricted. The checking method is the same as S026. If BGP (179) is configured to allow passage, the check will pass and proceed to S038. If it fails, the message will be: BGP interrupted, peer ACL 179 restricted. The cause of the fault will be located and the process will end.

[0275] S038. Trace neighbor addresses to determine if the bidirectional trace paths at both ends are consistent. The checking method is the same as in S027. If they are inconsistent, the message "Bidirectional paths are inconsistent" will be displayed. If they are consistent, the diagnostic process will not be interrupted and will proceed to S039.

[0276] S039. Check if there is a port interruption alarm. If an interruption alarm occurs, the check fails and the message "BGP interruption, peer port interruption alarm" is displayed. The cause of the fault is located and the process ends. If no interruption alarm occurs, the process is transferred to manual handling.

[0277] Based on the same inventive concept, this invention also proposes a BGP Down fault location device. The implementation of this device can refer to the implementation of the method described above, and repeated details will not be repeated. The term "module" used below can refer to a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0278] Figure 2 This is a schematic diagram of the BGP Down fault location device of the present invention. Figure 2 As shown, the device includes:

[0279] Network data loading module 110 detects BGP status including:

[0280] Load network alarm data, including: device port down alarm, BGP down alarm. When a device network element has a port down alarm, and BGP down alarms occur 3 or more times, determine whether the BGP protocol down is caused by the device port down.

[0281] Check if the BGP status has been restored;

[0282] Check if the BGP status is idle. If the BGP status is idle, locate the cause of the fault and the process ends; if the BGP status is not idle, proceed to the next step.

[0283] Check if the BGP route exceeds the limit. If the BGP route exceeds the limit, check the BGP route settings. This will not directly affect BGP DOWN, will not interrupt the diagnostic process, and will proceed to the next step.

[0284] Check if an error message has been received. If an error message is received, the BGP error message does not directly affect BGPDOWN. Receiving an error message does not interrupt the diagnostic process. Complete the reception of the BGP error message and proceed to the next step.

[0285] Check if BGP configuration is causing neighbor disconnections;

[0286] The system checks whether the BGP direct connection is disconnected. If both the Current state and Line protocol of the port are UP, the test passes; otherwise, it fails.

[0287] Current state refers to the current state of the BGP neighbor, and Line protocol state refers to the line protocol state of the interface.

[0288] Check if a Notification message, Hold timer expiration, or remote peer unreachable message has been received. If not, proceed to manual processing. If the above information is received, proceed to the login module 120 on the local device.

[0289] Log in to the local device module 120 to check the status of the local device, including:

[0290] Check if the interconnection interface status is normal, and whether the CRC, symbol, and error counts are increasing; if the port status is UP, it is normal, otherwise it is abnormal; if the CRC, symbol, and error counts are increasing, it indicates that the interconnection port is abnormal;

[0291] If an error occurs, the message "An error occurred on the local interconnect port, causing BGP interruption. The cause of the fault has been located and the process ends" will be displayed.

[0292] If everything is normal, proceed to the next step;

[0293] The command is executed to check if the VPN BFD status is normal. If the state is UP, it means it is normal; otherwise, it is abnormal.

[0294] An error message will appear: BGP interrupted, local VPN BFD status is abnormal, the cause of the fault has been located, and the process ends.

[0295] If everything is normal, proceed to the next step;

[0296] Ping the interconnected IP address to check if it is reachable. If the ping to the interconnected address on the port is successful, the test is passed and you can proceed to the next step. If the ping test fails, the message "This end cannot reach the interconnected address of the other end by ping" will be displayed, the cause of the fault will be located, and the process will end.

[0297] Ping the neighbor's IP address to check if it is reachable. If the ping to the neighbor's address is successful, the test is complete and proceed to the next step; otherwise, the message "This end cannot reach the neighbor's address when pinged" is displayed, the cause of the fault is located, and the process ends.

[0298] To check if CPU utilization is normal, execute the command: display cpu-usage. If CPU utilization is below the threshold, the test passes; if CPU utilization exceeds the threshold, it is abnormal, and the message "Local CPU utilization is abnormal / too high" will be displayed. The results of the CPU utilization test will not interrupt the diagnostic process; proceed to the next step.

[0299] Check if ACL 179 is restricting access. If BGP is configured to allow access, the check passes and proceeds to the next step. If the check fails, the message "Local ACL 179 is restricted" will be displayed. Once the cause of the fault is identified, the process ends.

[0300] Trace neighbor addresses to determine if the bidirectional trace paths at both ends are consistent. If they are inconsistent, an error message is displayed: "The round-trip paths of this end and the other end are inconsistent." Consistency determination results do not interrupt the diagnostic process; proceed to the next step.

[0301] Check for port interruption alarms. Check if the interconnected port experienced an interruption alarm within the range of BGP Down alarm occurrence time -10 minutes to the last alarm occurrence time +10 minutes. If no interruption alarm occurred, the check passes and proceeds to the login module 130 for the peer device. If an interruption alarm occurred, the check fails and the message "Interconnected port experienced interruption alarm" is displayed. The cause of the fault has been located and the process ends.

[0302] Log in to the peer device module 130 and check the peer device status, including:

[0303] Check if the Peer IP configuration is correct. Execute the command `display bgp peer` to view the status and configuration information of the BGP neighbor. If the configuration is correct, the check passes and you can proceed to the next step. If the configuration is abnormal, the check fails and the message "No problem on this end, but the BGP peer IP configuration is incorrect" is displayed. Locate the cause of the fault and the process ends.

[0304] Check if the BGP status is idle. If the BGP status is idle, the message "TCP 179 unreachable" will appear. Manually close the connection, locate the cause of the fault, and the process ends. If the BGP status is not idle, proceed to the next step.

[0305] Check if the VPN BFD status is normal. The checking method is the same as the process for logging into the local device module. If the VPN BFD status is abnormal, the prompt will be: BGP interrupted, peer VPN BFD status is abnormal. Locate the cause of the fault and the process ends. If the VPN BFD status is normal, proceed to the next step.

[0306] Ping the interconnected IP address to check its reachability. The method for checking this is the same as the process for logging into the local device module. If it fails, the message "BGP interrupted, ping test of the peer's interconnected address is unreachable" will be displayed. Once the cause of the fault is located, the process ends. If the check passes, proceed to the next step.

[0307] Ping the neighbor's IP address to check if it is reachable. The method for checking is the same as the process of logging into the local device module. If it fails, the message "BGP interrupted, ping test of the peer neighbor address is unreachable" will be displayed. After locating the cause of the fault, the process ends. If the check passes, proceed to the next step.

[0308] Check if the CPU utilization is normal. The checking method is the same as the process of logging into the local device module. If the CPU utilization is abnormal, the message "Peer CPU utilization is abnormal / too high" will be displayed. Regardless of whether it is normal or abnormal, the diagnostic process will not be interrupted and will proceed to the next step.

[0309] Check if ACL 179 is restricted. The checking method is the same as the login process for the local device module. If BGP is configured to allow access, the check will pass and proceed to the next step; otherwise, the message "BGP interrupted, peer ACL 179 restricted" will be displayed. After locating the cause of the fault, the process ends.

[0310] Trace neighbor addresses to determine if the bidirectional trace paths at both ends are consistent. The checking method is the same as the process for logging into the local device module. If they are inconsistent, the message "Bidirectional paths are inconsistent" will be displayed. If they are consistent, the diagnostic process will not be interrupted and will proceed to the next step.

[0311] Check for port interruption alarms. If an interruption alarm occurs, the check fails and the message "BGP interruption, peer port interruption alarm" is displayed. Once the cause of the fault is located, the process ends. If no interruption alarm occurs, the process is transferred to manual handling.

[0312] It should be noted that although several modules of the BGP Down fault location device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of the present invention, the features and functions of two or more modules described above can be embodied in a single module. Conversely, the features and functions of a single module described above can be further divided and embodied by multiple modules.

[0313] Based on the aforementioned inventive concept, such as Figure 3As shown, the present invention also proposes a computer device 200, including a memory 210, a processor 220, and a computer program 230 stored in the memory 210 and executable on the processor 220. When the processor 220 executes the computer program 230, it implements the aforementioned BGP Down fault location method.

[0314] Based on the aforementioned inventive concept, the present invention also proposes a computer-readable storage medium storing a computer program that executes the aforementioned BGP Down fault location method.

[0315] This invention provides a BGP Down fault location method and apparatus. It incorporates expert capabilities and automatically diagnoses BGP Down faults by combining alarm information, network protocols, and test commands. The method performs real-time analysis and processing of the inspection results to ensure timeliness. It provides a streamlined process for analyzing BGP Down faults, helping network maintenance personnel quickly locate service faults, reducing their workload. The standardized and automated fault location process reduces the possibility of human error and omissions, improving the accuracy of fault diagnosis and enhancing the efficiency of fault location.

[0316] While the spirit and principles of the invention have been described with reference to several specific embodiments, it should be understood that the invention is not limited to the disclosed specific embodiments, and the division of aspects does not imply that features in these aspects cannot be combined for benefit; such division is merely for ease of description. The invention is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

[0317] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0318] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0319] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0320] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0321] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0322] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0323] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0324] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

[0325] Regarding the limitation of the scope of protection of this invention, those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solution of this invention are still within the scope of protection of this invention.

Claims

1. A BGP Down fault location method, characterized in that, The method includes: S01. Load network data and check BGP status; S011. Load network alarm data. Alarms include: device port down alarm, BGP down alarm. When a device network element has a port down alarm, and BGP down alarms occur 3 or more times, determine whether the BGP protocol down is caused by the device port down. S012. Check if the BGP status has been restored; S013. Check if the BGP status is idle. If the BGP status is idle, locate the cause of the fault and the process ends; if the BGP status is not idle, proceed to S014. S014. Check if the BGP route exceeds the limit. If the BGP route exceeds the limit, check the BGP route settings. This will not directly affect BGPDOWN or interrupt the diagnostic process. Proceed to S015. S015. Check if an error message is received. If an error message is received, the BGP error message does not directly affect BGPDOWN. Receiving an error message does not interrupt the diagnostic process. Complete the reception of the BGP error message and proceed to S016. S016. Check if BGP configuration is causing neighbor disconnection; S017. Check if the BGP direct connection is disconnected. If both the Current state and Line protocol of the port are UP, then pass; otherwise, fail. Current state refers to the current state of the BGP neighbor, and Line protocol state refers to the line protocol state of the interface. S018. Check if a Notification message, Hold timer expiration, or remote peer unreachable message has been received. If not received, proceed to manual processing. If the above information is received, proceed to S02. S02. Log in to the local device and check the status of the local device; S021. Check if the interconnection interface status is normal, and whether the CRC, symbol, and error counts are increasing; if the port status is UP, it is normal, otherwise it is abnormal; if the CRC, symbol, and error counts increase, it indicates that the interconnection port is abnormal. If an error occurs, the message "An error occurred on the local interconnect port, causing BGP interruption. The cause of the fault has been located and the process ends" will be displayed. If everything is normal, proceed to S022; S022. Execute the command to check if the VPN BFD status is normal. If the state is UP, it means normal; otherwise, it is abnormal. An error message will appear: BGP interrupted, local VPN BFD status is abnormal, the cause of the fault has been located, and the process ends. If everything is normal, proceed to S023; S023. Ping the interconnected IP address to check if it is reachable. If the ping to the port interconnected address is successful, the test is passed and proceed to S024; if the ping test fails, the message "This end pings the other end's interconnected address and cannot reach it" will be displayed, the cause of the fault will be located, and the process will end. S024. Ping the neighbor's IP address to check if it is reachable. If the ping to the neighbor's address is successful, the test is passed and proceed to S025; otherwise, the message "The local end cannot reach the peer's neighbor address by ping" is displayed, the cause of the fault is located, and the process ends. S025. Check if the CPU utilization is normal. Execute the command: display cpu-usage. If the CPU utilization is lower than the threshold, the test passes; if the CPU utilization exceeds the threshold, it is abnormal. The prompt is: Local CPU utilization is abnormal / too high. The CPU utilization test results do not interrupt the diagnostic process. Proceed to S026. S026. Check if ACL 179 is restricting access. If BGP is configured to allow access, the check passes and proceeds to S027. If the check fails, the message "Local ACL 179 is restricted" will be displayed. The cause of the fault will be located and the process will end. S027. Trace neighbor addresses to determine if the bidirectional trace paths at both ends are consistent. If they are inconsistent, prompt: "The round-trip paths of this end and the other end are inconsistent." If the consistency judgment results do not interrupt the diagnostic process, proceed to S028. S028. Check if there is a port interruption alarm. Check if the interconnected port has an interruption alarm within the range of BGP Down alarm occurrence time -10 minutes to the last alarm occurrence time +10 minutes. If no interruption alarm occurs, the check passes and proceeds to S03; if an interruption alarm occurs, the check fails and the message "Interconnected port on this end has an interruption alarm, the cause of the fault has been located, and the process ends" is displayed. S03. Log in to the peer device and check the status of the peer device; S031. Check if the Peer IP configuration is correct. Execute the command display bgp peer to view the status and configuration information of the BGP neighbor. If the configuration is correct, the check passes and proceeds to S032. If the configuration is abnormal, the check fails and the message "No problem on this end, but the BGP peer IP configuration is incorrect" is displayed. Locate the cause of the fault and the process ends. S032. Check if the BGP status is idle. If the BGP status is idle, the message "TCP 179 unreachable" will be displayed. Manually close the connection, locate the cause of the fault, and the process ends. If the BGP status is not idle, proceed to S033. S033. Check if the VPN BFD status is normal. The checking method is the same as S022. If the VPN BFD status is abnormal, the prompt will be: BGP interrupted, the peer VPN BFD status is abnormal. Locate the cause of the fault and the process ends. If the VPN BFD status is normal, proceed to S034. S034. Ping the interconnected IP to check if it is reachable. The method of checking is the same as S023. If it fails, the message "BGP interrupted, the peer's interconnected address cannot be reached by ping" will be displayed. The cause of the fault will be located and the process will end. If the check passes, proceed to S035. S035. Ping the neighbor's IP address to check if it is reachable. The method of checking is the same as S024. If it fails, the message "BGP interrupted, ping test of the peer neighbor address is unreachable" will be displayed. The cause of the fault will be located and the process will end. If the check passes, proceed to S036. S036. Check if the CPU utilization is normal. The checking method is the same as S025. If the CPU utilization is abnormal, prompt: The CPU utilization of the other end is abnormal / too high. Regardless of whether it is normal or abnormal, the diagnostic process will not be interrupted and will proceed to S037. S037. Check if ACL 179 is restrictive. The checking method is the same as S026. If BGP is configured to allow access, the check will pass and proceed to S038. If it fails, the message "BGP interrupted, peer ACL 179 restrictive" will be displayed. The cause of the fault will be located and the process will end. S038. Trace neighbor addresses to determine if the bidirectional trace paths at both ends are consistent. The checking method is the same as in S027. If they are inconsistent, the message "Bidirectional paths are inconsistent" will be displayed. If they are consistent, the diagnostic process will not be interrupted and will proceed to S039. S039. Check if there is a port interruption alarm. If an interruption alarm occurs, the check fails and the message "BGP interruption, peer port interruption alarm" is displayed. The cause of the fault is located and the process ends. If no interruption alarm occurs, the process is transferred to manual handling.

2. The BGP Down fault location method according to claim 1, characterized in that, S012 includes: S0121. Check if the normal BGP status has been restored. If the BGP status is ESTABLISHED, the BGP connection has self-healed and the fault has been recovered during the test, and the process ends. If the BGP status has not been restored, proceed to S013. S0122. Check if the VPN BGP status has recovered. If the BGP status is ESTABLISHED, the BGP connection has self-healed and the fault has been recovered during the check, and the process ends. If the BGP status has not recovered, proceed to S013.

3. The BGP Down fault location method according to claim 1, characterized in that, S016 includes: S0161. Execute the command: show running-config bgp | inc [neighbor's IP]; S0162. If result information is returned and the neighbor connection is not broken, proceed to S017. S0163. No results returned, indicating that the neighbor is disconnected. The neighbor is disconnected, prompting: BGP configuration error. Check the BGPpeer settings, locate the cause of the fault, and the process ends.

4. The BGP Down fault location method according to claim 1, characterized in that, S017 includes: S0171. If the port is a physical port, then query the physical port twice to check if the CRC and Symbol values ​​have increased. S0172. If the port is a bundled Eth-Trunk port, then query the corresponding physical port, and then query the physical port twice to check if the CRC and Symbol have increased. S0173 If the test fails, the message "BGP direct connection port disconnected" will be displayed. The interconnect interface will be tested, and the test information will be loaded to locate the cause of the fault. The process will then end. S0174, Test passed, proceed to S018.

5. The BGP Down fault location method according to claim 1, characterized in that, The status and configuration information of the BGP neighbor in S031 includes: IP address, AS number, status, and whether a BGP session has been established.

6. A BGP Down fault location device, characterized in that, The device includes: The network data loading module detects BGP status, including: Load network alarm data, including: device port down alarm, BGP down alarm. When a device network element has a port down alarm, and BGP down alarms occur 3 or more times, determine whether the BGP protocol down is caused by the device port down. Check if the BGP status has been restored; Check if the BGP status is idle. If the BGP status is idle, locate the cause of the fault and the process ends; if the BGP status is not idle, proceed to the next step. Check if the BGP route exceeds the limit. If the BGP route exceeds the limit, check the BGP route settings. This will not directly affect BGP DOWN, will not interrupt the diagnostic process, and will proceed to the next step. Check if an error message has been received. If an error message is received, the BGP error message does not directly affect BGP DOWN. Receiving an error message does not interrupt the diagnostic process. Complete the reception of the BGP error message and proceed to the next step. Check if BGP configuration is causing neighbor disconnections; The system checks whether the BGP direct connection is disconnected. If both the Current state and Line protocol of the port are UP, the test passes; otherwise, it fails. Current state refers to the current state of the BGP neighbor, and Line protocol state refers to the line protocol state of the interface. Check if a Notification message, Hold timer expiration, or remote peer unreachable message has been received. If not, proceed to manual handling. If the above information is received, proceed to the local device login module. Log in to the local device module to check the status of the local device, including: Check if the interconnection interface status is normal, and whether the CRC, symbol, and error counts are increasing; if the port status is UP, it is normal, otherwise it is abnormal; if the CRC, symbol, and error counts are increasing, it indicates that the interconnection port is abnormal; If an error occurs, the message "An error occurred on the local interconnect port, causing BGP interruption. The cause of the fault has been located and the process ends" will be displayed. If everything is normal, proceed to the next step; The command is executed to check if the VPN BFD status is normal. If the state is UP, it means it is normal; otherwise, it is abnormal. An error message will appear: BGP interrupted, local VPN BFD status is abnormal, the cause of the fault has been located, and the process ends. If everything is normal, proceed to the next step; Ping the interconnected IP address to check if it is reachable. If the ping to the interconnected address on the port is successful, the test is passed and you can proceed to the next step. If the ping test fails, the message "This end cannot reach the interconnected address of the other end by ping" will be displayed, the cause of the fault will be located, and the process will end. Ping the neighbor's IP address to check if it is reachable. If the ping to the neighbor's address is successful, the test is complete and proceed to the next step; otherwise, the message "This end cannot reach the neighbor's address when pinged" is displayed, the cause of the fault is located, and the process ends. To check if CPU utilization is normal, execute the command: display cpu-usage. If CPU utilization is below the threshold, the test passes; if CPU utilization exceeds the threshold, it is abnormal, and the message "Local CPU utilization is abnormal / too high" will be displayed. The results of the CPU utilization test will not interrupt the diagnostic process; proceed to the next step. Check if ACL 179 is restricting access. If BGP is configured to allow access, the check passes and proceeds to the next step. If the check fails, the message "Local ACL 179 is restricted" will be displayed. Once the cause of the fault is identified, the process ends. Trace neighbor addresses to determine if the bidirectional trace paths at both ends are consistent. If they are inconsistent, prompt: "The round-trip paths of this end and the other end are inconsistent." If the consistency judgment results are not interrupted, proceed to the next step. Check for port interruption alarms. Check if the interconnected port experienced an interruption alarm within the range of BGP Down alarm occurrence time -10 minutes to the last alarm occurrence time +10 minutes. If no interruption alarm occurred, the check passes and proceeds to the peer device login module. If an interruption alarm occurred, the check fails and the message "Interconnected port experienced interruption alarm" is displayed. The cause of the fault has been located and the process ends. Log in to the peer device module and check the peer device status, including: Check if the Peer IP configuration is correct. Execute the command `display bgp peer` to view the status and configuration information of the BGP neighbor. If the configuration is correct, the check passes and you can proceed to the next step. If the configuration is abnormal, the check fails and the message "No problem on this end, but the BGP peer IP configuration is incorrect" is displayed. Locate the cause of the fault and the process ends. Check if the BGP status is idle. If the BGP status is idle, the message "TCP 179 unreachable" will appear. Manually close the connection, locate the cause of the fault, and the process ends. If the BGP status is not idle, proceed to the next step. Check if the VPN BFD status is normal. The checking method is the same as the process for logging into the local device module. If the VPN BFD status is abnormal, the prompt will be: BGP interrupted, peer VPN BFD status is abnormal. Locate the cause of the fault and the process ends. If the VPN BFD status is normal, proceed to the next step. Ping the interconnected IP address to check its reachability. The method for checking this is the same as the process for logging into the local device module. If it fails, the message "BGP interrupted, ping test of the peer's interconnected address is unreachable" will be displayed. Once the cause of the fault is located, the process ends. If the check passes, proceed to the next step. Ping the neighbor's IP address to check if it is reachable. The method for checking is the same as the process of logging into the local device module. If it fails, the message "BGP interrupted, ping test of the peer neighbor address is unreachable" will be displayed. After locating the cause of the fault, the process ends. If the check passes, proceed to the next step. Check if the CPU utilization is normal. The checking method is the same as the process of logging into the local device module. If the CPU utilization is abnormal, the message "Peer CPU utilization is abnormal / too high" will be displayed. Regardless of whether it is normal or abnormal, the diagnostic process will not be interrupted and will proceed to the next step. Check if ACL 179 is restricted. The checking method is the same as the login process for the local device module. If BGP is configured to allow access, the check will pass and proceed to the next step; otherwise, the message "BGP interrupted, peer ACL 179 restricted" will be displayed. After locating the cause of the fault, the process ends. Trace neighbor addresses to determine if the bidirectional trace paths at both ends are consistent. The checking method is the same as the process for logging into the local device module. If they are inconsistent, the message "Bidirectional paths are inconsistent" will be displayed. If they are consistent, the diagnostic process will not be interrupted and will proceed to the next step. Check for port interruption alarms. If an interruption alarm occurs, the check fails and the message "BGP interruption, peer port interruption alarm" is displayed. Once the cause of the fault is located, the process ends. If no interruption alarm occurs, the process is transferred to manual handling.

7. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that performs the method according to any one of claims 1-5.

Images