Network anomaly alarm monitoring method, device and storage medium

Abstract

The application relates to a network exception alarm monitoring method, equipment and a storage medium, wherein the monitoring object is a DHCP server, and the monitoring types include service exception, address pool exception, lease exception, request exception and high-availability exception.The network exception alarm monitoring method can realize real-time monitoring and notification processing of the service exception, the address pool exception, the lease exception, the request exception and the high-availability exception of DHCPv4 and DHCPv6, can predict risks in advance, helps users to quickly locate problems, and minimizes the influence of faults.

Description

Technical Field

[0001] This invention relates to the field of network monitoring technology, specifically to network anomaly alarm monitoring methods, devices, and storage media. Background Technology

[0002] DHCP servers are widely used in carrier networks, data centers, and enterprise campuses. Their core function is to dynamically allocate IP addresses and network configuration parameters. As network scales up (e.g., with the surge in IoT devices and the elastic expansion of cloud environments), the stability of DHCP services directly impacts the availability of the entire network.

[0003] To proactively monitor, quickly locate, and promptly respond to DHCP anomalies, ensuring stable, secure, and high-performance network operation, it is necessary to monitor and handle DHCP anomalies, including service anomalies, address pool anomalies, lease anomalies, request anomalies, and high availability anomalies. By proactively identifying risks and promptly addressing them, downtime can be shortened, the impact of failures reduced, and security improved.

[0004] The existing kea-dhcp does not support DHCPv6 authentication or abnormal request identification, does not support lease exception handling, and lacks real-time monitoring capabilities, especially monitoring of the overall deployment architecture. This results in the inability to detect kea-dhcp service anomalies, high availability issues, and abnormal requests in a timely manner.

[0005] Chinese invention patent "A DHCP Security Protection Method and Device Combining Access Location and Third-Party Authentication" (application number CN202411762048.6) provides a DHCP security protection method and device combining access location and third-party authentication. The method includes: acquiring device fingerprint data of an access terminal; comparing the device fingerprint data with a third-party authentication server; uniquely binding the terminal's MAC address to its access location after successful authentication; real-time monitoring of the access location of the access terminal, triggering an alarm if a change in access location is detected; and issuing a blocking command using a network switch or router to cut off the network connection of the unauthorized terminal when a change in access location or authentication failure is detected. However, this method has a limited scope of monitoring, failing to monitor high-frequency requests, lease conflicts, service anomalies, or other abnormal events. It cannot be observed in real-time through an interface, nor can it differentiate alarm levels and processing statuses or push alarm information. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention provides a network anomaly alarm monitoring method. The monitoring object is a DHCP server, and the monitoring types include service anomalies, address pool anomalies, lease anomalies, request anomalies, and high availability anomalies.

[0007] Service exceptions include Agent exceptions, Kea exceptions, and database exceptions;

[0008] Address pool anomalies are caused by abnormal DHCPv4 or DHCPv6 address pool utilization.

[0009] Lease exception refers to lease conflict exception;

[0010] Request exceptions include high-frequency request exceptions and illegal device exceptions;

[0011] High availability anomalies include heartbeat anomalies, service failover, and backup node anomalies;

[0012] Monitoring for service anomalies, address pool anomalies, lease anomalies, request anomalies, and high availability anomalies is controlled by specific switches.

[0013] In service anomaly monitoring, the monitoring method for Agent anomalies and Kea anomalies is as follows: detect the process of Agent or Kea-dhcp service. If the Agent or Kea-dhcp service stops after two consecutive detections, record and report the anomaly.

[0014] The method for monitoring database anomalies is as follows: determine the service status of the primary and backup database nodes by checking the database connection status. If both primary and backup database nodes stop, record and report the anomaly.

[0015] The monitoring method for lease irregularities is as follows:

[0016] Step S11: Configure the abnormal request detection switch KY_LCONFLICY_OPEN=yes to enable the lease conflict detection switch;

[0017] Step S12: Configure the dhcp4 or dhcp6 configuration file, add the conflict detection plugin libdhcp_ping_check.so and related parameter configurations;

[0018] Step S13: Monitor whether the same IP is bound repeatedly. If it is bound repeatedly, there is a lease conflict.

[0019] Step S13 includes:

[0020] Step S131: The client sends an ICMP ping request for a specific IP address;

[0021] Step S132: The server prepares to allocate an IP address by sending an ICMP ping request to the target IP.

[0022] Step S133: Listen for ping replies. If a ping reply is received within the specified time, it indicates a lease conflict. Add the conflict information to the lease conflict list. If no ping reply is received within the specified time, it indicates that there is no lease conflict.

[0023] In step S12, the relevant parameter configuration includes enable-ping-check, enabling or disabling ping checks.

[0024] Among request exceptions, the monitoring method for high-frequency request exceptions is as follows:

[0025] Step S21: Configure the abnormal request detection switch KY_ILLREQ_OPEN=yes to enable the high-frequency request abnormal detection switch;

[0026] Step S22: Configure the dhcp4 or dhcp6 configuration file, load the security enhancement plugin libdhcp_guard_alert.so and the configuration related to high-frequency request detection;

[0027] Step S23: The client sends a DHCP request. After the server receives the message, it calls pkt4 / 6_receive to determine whether it is a DISCOVER / SOLICIT message. If it is not, the message is ignored. If it is, the alarm plugin is called to process the message, update the high-frequency request count and write it to the high-frequency request counter. The total number of client requests is obtained by reading the high-frequency counter.

[0028] Step S24: If the request count is greater than or equal to the threshold, a high-frequency request alarm is triggered.

[0029] Among the request exceptions, the monitoring method for illegal device exceptions is as follows:

[0030] Step S31: Configure the abnormal request detection switch KY_ILLREQ_OPEN=yes to enable the illegal device abnormal detection switch;

[0031] Step S32: Configure the dhcp4 or dhcp6 configuration file, load the security enhancement plugin libdhcp_guard_alert.so and the path to the illegal device blacklist file;

[0032] Step S33: After the client sends the request, the server obtains the configuration file option 60, option 61, option 1 or option 16 from the request message; it performs regular expression matching with the device values ​​in the blacklist one by one according to the matching rules, and if a match is successful, it is considered an illegal device.

[0033] Among these, the monitoring method for address pool anomalies in request exceptions is as follows:

[0034] Step S41: Configure the subnet utilization detection switch KY_SUBNETS_OPEN=yes to enable subnet utilization anomaly monitoring, and configure the subnet utilization threshold KY_SUBNET_ADDRUTIL;

[0035] Step S42: Trigger the subnet information acquisition operation, extract subnet information, obtain detailed data of subnets, calculate the utilization rate of each subnet, and extract the subnet name or identifier for subsequent identification;

[0036] Step S43: Traverse each subnet and compare the current utilization rate of the subnet with the preset threshold in real time;

[0037] Step S44: When the current utilization rate of the subnet is greater than or equal to the threshold, record the alarm information;

[0038] Step S45: Continue with the detection of the next subnet.

[0039] Step S44 includes: distinguishing between initial detection and continuous detection using the subnetMap table.

[0040] If there is no corresponding subnet record in the subnetMap table, it is the first detection. If the current utilization rate of the subnet is greater than or equal to the threshold, an alarm is recorded and a record is added to the subnetMap table as follows: Status = Over threshold, last utilization rate = current subnet utilization rate, consecutive count = 1. If the current utilization rate of the subnet is less than the threshold, a record is added to the subnetMap table as follows: Status = Normal, last utilization rate = current subnet utilization rate.

[0041] If a corresponding subnet record exists in the subnetMap table, continuous monitoring continues: If the current subnet utilization is less than the threshold, the consecutive count in the subnetMap table is reset to 0, the status to normal, and the previous utilization rate equal to the current subnet utilization rate; if the current subnet utilization is greater than or equal to the threshold, the difference is further assessed:

[0042] If the difference is ≥1%: record 1 "post-change abnormal alarm" and update the previous utilization rate of the subnetMap table to equal the current subnet utilization rate; if the difference is <1%: only update the "most recent record time" of the subnetMap table and do not trigger a new alarm.

[0043] The present invention further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, characterized in that the processor executes the computer program to implement the steps of any of the methods described above.

[0044] The present invention further provides a computer-readable storage medium having a computer program stored thereon, characterized in that the computer program, when executed by a processor, implements the steps of the method described in any of the preceding claims.

[0045] The network anomaly alarm monitoring method of the present invention enables real-time monitoring and notification processing of service anomalies, address pool anomalies, lease anomalies, request anomalies, and high availability anomalies in DHCPv4 and DHCPv6. It can predict risks in advance, help users quickly locate problems, and minimize the impact of failures. Attached Figure Description

[0046] Figure 1 : Flowchart of the implementation of address pool anomaly monitoring in this invention.

[0047] Figure 2 : Flowchart of the implementation of high-frequency request alarm monitoring in this invention.

[0048] Figure 3 : Flowchart of the implementation of illegal device alarm monitoring in this invention.

[0049] Figure 4 : Flowchart of the implementation of lease conflict monitoring in this invention. Detailed Implementation

[0050] To gain a better understanding of the technical solution and beneficial effects of the present invention, the technical solution of the present invention and its beneficial effects are described in detail below with reference to the accompanying drawings.

[0051] The anomaly alarm monitoring method based on the Kylin system network described in this invention mainly focuses on real-time monitoring and notification processing of DHCPv4 and DHCPv6 through a visual interface. It promptly displays anomaly alarm information, including alarm time, alarm level, abnormal object, anomaly type, anomaly details, anomaly duration, processing status, and push status. Alarm levels are categorized as: Emergency, Important, and Warning. Monitored abnormal objects include: service anomalies, address pool anomalies, lease anomalies, request anomalies, and high availability anomalies, with different anomaly types distinguished for different anomaly objects. Processing status is categorized as: Processed, Unprocessed, and Alarm Only. Push status is categorized as: Push Successful, Not Pushed, and Push Failed.

[0052] Service anomaly types: Agent anomaly, Kea anomaly, and database anomaly. Alarm monitoring is enabled via the KY_MACHINES_OPEN switch to monitor Agent, Kea-dhcp, and database service anomalies in real time. For Agent or Kea anomaly monitoring, the process of the Agent or Kea-dhcp service is monitored. If two consecutive monitoring checks show that the Agent or Kea-dhcp service has stopped, the anomaly is recorded and reported. The database connection status is used to determine the service status of the primary and backup database nodes. If both primary and backup database nodes are stopped, an anomaly is recorded and reported.

[0053] Address pool anomaly type: High utilization. Alarm monitoring is enabled via the KY_SUBNETS_OPEN switch, and alarm thresholds are set via the KY_SUBNET_ADDRUTIL switch. The utilization of the dhcpv4 and dhcpv6 address pools is continuously monitored. If the address pool utilization exceeds the threshold, the anomaly is recorded and reported. An alarm is recorded for every 1% increase in utilization.

[0054] Lease anomaly type: Lease conflict. Alarm monitoring is enabled via the KY_LCONFLICY_OPEN switch. The lease conflict detection function depends on the libdhcp_ping_check.so plugin. It monitors whether the same IP address is bound repeatedly, and prompts an error message when trying to bind to an already assigned IP. Lease anomaly monitoring ensures the uniqueness and reliability of IP address allocation, preventing network communication interruptions due to address conflicts.

[0055] Request anomaly types: High-frequency requests and unauthorized devices. Alarm monitoring is enabled via the KY_ILLREQ_OPEN switch, and the security alarm plugin libdhcp_guard_alert.so is configured. High-frequency request monitoring tracks the cumulative number of requests sent from the same MAC or DUID within a specific time period; an alarm is triggered when a threshold is reached. High-frequency request anomaly monitoring is primarily used to identify and mitigate abnormal traffic attacks targeting the DHCP service, and to detect resource exhaustion risks caused by network scanning or configuration errors. Unauthorized device monitoring tracks device information carried in DHCP option packets, verifying the legitimacy of information in option 60, option 61, option 1, and option 16. Matching is performed according to the matching rules in the blacklist; a successful match indicates an unauthorized device. Unauthorized device monitoring is used in terminal access control scenarios to prevent unauthorized devices from interfering with normal services or posing security threats. It identifies and blocks access from unauthorized devices by verifying the device's MAC address, DUID address, and vendor information.

[0056] High availability anomaly types: heartbeat anomaly, service failover, and standby node anomaly. Alarm monitoring is enabled via the KY_MACHINES_OPEN switch. Heartbeat anomaly monitoring tracks heartbeat status; packet loss and service interruption are considered heartbeat anomalies. Service failover monitoring tracks primary / standby service failover events; alarms are triggered when such events are detected, such as primary server failure, standby server takeover, or primary service recovery. Standby node anomaly monitoring tracks standby node service status; alarms are triggered when standby node service stops.

[0057] Alerts are issued based on different anomaly levels and processing statuses, providing three levels: Urgent, Important, and Warning, to express the urgency of the alert and help operations and maintenance personnel quickly identify the importance of the alert. Urgent indicates that the alert has already affected the normal operation of system services, causing core business interruption, and must be handled immediately. Important indicates that it has not yet caused business interruption, but has led to a decline in business performance; if not handled, it may develop into a serious issue and requires attention and handling. Warning indicates that it has not yet affected the normal operation of system services, but indicates potential risks and requires regular monitoring.

[0058] The processing status is flexible, including: processed, unprocessed, and alarm only. For service anomalies, address pool anomalies, and high availability anomalies, for the same anomaly record, if the anomaly end time is detected, it is marked as "processed"; otherwise, it is marked as "unprocessed". For lease anomalies and request anomalies, only alarms are generated.

[0059] Alarm statuses are categorized as: Not Pushed, Push Successful, and Push Failed. If the system does not perform a push, the status is marked as Not Pushed; if the API is called to push and a successful reception status is returned, the status is marked as Push Successful; if the system fails to push or returns a reception failure status, the status is marked as Push Failed.

[0060] Example 1: Address Pool Anomaly Monitoring

[0061] like Figure 1 As shown, the address pool anomaly monitoring system monitors the utilization thresholds for each address pool in each subnet. Due to potential statistical delays during data synchronization, it is based on three data collections. If the threshold is exceeded for three consecutive monitoring checks, an anomaly is reported. After exceeding the threshold, a record is made every time the utilization rate changes. For example, if the threshold is set to 90%, an alarm is recorded when the address pool utilization of a subnet reaches 90%, another alarm is recorded when it reaches 91%, and no repeated records are made between 90% and 91%.

[0062] S1: Configure the subnet utilization detection switch KY_SUBNETS_OPEN=yes to enable subnet utilization anomaly monitoring. Configure the subnet utilization threshold KY_SUBNET_ADDRUTIL.

[0063] S2: KylinGetSubnets triggers the subnet information retrieval operation. The RestAPI extracts the subnet information, obtains detailed data of the subnet (such as the total number of addresses, the number of allocated addresses, etc.), calculates the utilization rate of each subnet (allocated / total number of addresses), and extracts the subnet name / identifier for subsequent identification.

[0064] S3: Preliminary assessment of subnet utilization, traversing each subnet, and comparing the collected data with the preset threshold in real time.

[0065] S4: Differentiate between "initial detection" and "continuous detection" using the subnetMap table (a database table that stores the historical status of subnet utilization):

[0066] S41: Initial detection (no record for this subnet in the subnetMap table):

[0067] If the current utilization rate is greater than or equal to the threshold: add a record to the subnetMap table (status = exceeding threshold, last utilization rate = current value, consecutive count = 1), and simultaneously record an alarm (the visual interface displays the subnet utilization exceeding the limit alarm log, with the status "unprocessed"). Figure 1 The "Record alarmNoticeSql (first exception report)" is in the middle.

[0068] If the current utilization rate is less than the threshold: add a record to the subnetMap table (status = normal, last utilization rate = current value), only record the status, and do not trigger an alarm.

[0069] S42: Continuous detection (the subnet has a record in the subnetMap table):

[0070] S421: If the current utilization rate is greater than or equal to the threshold: Read the "last utilization rate" of the subnet in the subnetMap table and calculate the difference (current utilization rate - last utilization rate).

[0071] If the difference is ≥1%: Record 1 "Post-Change Anomaly Alarm" (this record is added to the visual interface, i.e.) Figure 1 Record the alarmNoticeSql (utilization overrun alarm) and update the "last utilization" in the subnetMap table to the current value.

[0072] If the difference is less than 1%, only update the "most recent record time" in the subnetMap table, and do not trigger new alarms.

[0073] S422: If the current utilization rate is less than the threshold: reset the consecutive count in the subnetMap table to 0, the status to normal, the previous utilization rate to the current value, and update the status of the corresponding alarm in the visualization interface to "processed". Figure 1The middle part is "Record alarmNoticeSql (alarm clear)".

[0074] After completing the processing of the current subnet, proceed to the detection of the next subnet.

[0075] Example 2: High-frequency request alarm monitoring

[0076] like Figure 2 As shown, high-frequency request monitoring is used to identify clients that initiate a large number of DHCP requests within a short period of time. If the cumulative number of requests sent by the same MAC address or duid exceeds a set threshold within a certain period, it is considered a high-frequency request, and the device information will be recorded in the alarm list. By obtaining the alarm list through high-frequency-monitor, users can clearly see key information such as the device's MAC address or duid, the number of requests, and the time of the most recent request, providing strong support for subsequent defense and resolution.

[0077] First, configure the abnormal request detection switch KY_ILLREQ_OPEN=yes to enable the high-frequency request abnormal detection switch.

[0078] Next, configure the DHCP4 or DHCP6 configuration file, load the security enhancement plugin libdhcp_guard_alert.so and the high-frequency request detection related configurations (corresponding to...). Figure 2 In the “High-Frequency Request Parameter Configuration” section, parameters such as algorithm configure the high-frequency detection algorithm, alert_threshold configure the alarm threshold, and window_size configure the time window are used.

[0079] When a client sends a DHCP request, the server receives the message and calls `pkt4 / 6_receive` to determine if it's a DISCOVER / SOLICIT message. If not, the message is ignored; otherwise, the alarm plugin is invoked to process the message, update the high-frequency request count, and write it to the high-frequency request counter. The total client request count can be obtained by reading the high-frequency counter.

[0080] When the client sends a request, the output message is as follows:

[0081] [root@client ~]# dhclient -4 -v ens9 -s 10.44.60.145

[0082] Internet Systems Consortium DHCP Client 4.4.2

[0083] Copyright 2004-2020 Internet Systems Consortium.

[0084] All rights reserved.

[0085] For info, please visit https: / / www.isc.org / software / dhcp /

[0086] Listening on LPF / ens9 / 52:54:00:e8:48:a9

[0087] Sending on LPF / ens9 / 52:54:00:e8:48:a9

[0088] Sending on Socket / fallback

[0089] DHCPDISCOVER on ens9 to 10.44.60.145 port 67 interval 5 (xid=0x57c53b61)

[0090] DHCPDISCOVER on ens9 to 10.44.60.145 port 67 interval 11 (xid=0x57c53b61)

[0091] The cumulative number of requests sent from the same MAC or DUID address can be determined by the number of DISCOVER / SOLICIT messages sent by the same client (MAC / DUID) to the same DHCP server address within a short period. If multiple different clients send requests, each request is counted within the window_size, triggering an independent alarm.

[0092] DHCPv4 high-frequency requests only parse DISCOVER messages, while DHCPv6 high-frequency requests only parse SOLICIT messages. This is used to count high-frequency requests when applying for IP addresses. When the cumulative number of IP address requests from clients within a time window is greater than or equal to a set threshold, an alarm is triggered, and the client's information (ID, total count, time, etc.) is added to the alarm record list. This can be viewed using the high-frequency-monitor command or in a visual interface.

[0093] Example 3: Monitoring of Illegal Device Alarms

[0094] like Figure 3 As shown, first, configure the abnormal request detection switch KY_ILLREQ_OPEN=yes to enable the illegal device abnormality detection switch.

[0095] Next, configure the dhcp4 or dhcp6 configuration file, load the security enhancement plugin libdhcp_guard_alert.so, the path to the illegal device blacklist file (blacklist_v4_path or blacklist_v6_path), and the file configuration.

[0096] DHCPv4 verifies the validity of information in option 60 (Vendor Class ID: identifies the device manufacturer and model) and option 61 (client ID: uniquely identifies the client device, such as a MAC address). DHCPv6 verifies the validity of information in option 1 (Client Identifier: unique device identifier, i.e., the client's DUID) and option 16 (Vendor Class: identifies the manufacturer information). After the client sends a request, the request message carries the configuration files created by the client, options 60, 61, 1, and 16. After receiving the request, the server retrieves the configuration files from the message and performs regular expression matching against the device values ​​in the blacklist. If a match is found, the device is considered illegal, an illegal device alarm message (including the client ID, the matched options and values, and a timestamp) is created and stored in the illegal_devices list for future reference, and the server notifies Kea to immediately discard the message without further processing, such as assigning an IP address. Alarm records can be queried using the illegal-device-monitor command or viewed in the visual interface. If a match is unsuccessful, the next device value will be matched using regular expressions. Once all device values ​​have been checked using regular expressions and none have been matched, the message is considered normal, and the process ends.

[0097] Taking option61 as an example, if the MAC address to be matched by option61 is configured in blacklist_v4.conf as 52:54:00:e8:48:a9 (the MAC address of the network card under test on the client), the client creates the / etc / dhcp / dhclient.conf file and configures the values ​​of option60 and option61:

[0098] # cat / etc / dhcp / dhclient.conf

[0099] timeout 60;

[0100] retry 60;

[0101] reboot 10;

[0102] select-timeout 5;

[0103] initial-interval 2;

[0104] interface "ens9" {

[0105] send vendor-class-identifier "Huawei";

[0106] send dhcp-client-identifier 52:54:00:e8:48:a9;

[0107] }

[0108] The client sends a request:

[0109] # dhclient -r ens9 && dhclient -4 -v ens9 -s 10.44.60.145

[0110] Once the server verifies a successful match in the blacklist, it adds the device to the list of illegal devices, displaying the illegal option option61 and its corresponding illegal value 52:54:00:e8:48:a9.

[0111] Example 4: Lease Conflict Monitoring

[0112] like Figure 4 As shown, lease conflict monitoring is used to monitor address conflicts, that is, IP addresses to be allocated have been occupied by other devices. It uses the ICMP Echo Request / Reply mechanism to determine if an address conflict exists; if a conflict is detected, it is recorded in the alarm list.

[0113] First, configure the abnormal request detection switch KY_LCONFLICY_OPEN=yes to enable the lease conflict detection switch.

[0114] Next, configure the dhcp4 or dhcp6 configuration file, add the conflict detection plugin libdhcp_ping_check.so and related parameter configurations, such as configuring enable-ping-check, enabling or disabling ping checks, and min-ping-requests (configuring the minimum number of ECHO requests to be repeatedly sent before an address becomes available without receiving a ping reply, etc.).

[0115] Before the server prepares to provide an IP address lease to a client, the ping_check plugin first sends an ICMP Echo Request (ping) to that IP address. The ping_check plugin listens for ping replies. If a ping reply is received within a specified time (corresponding to...) Figure 4 The message "Received ICMPReply" indicates that the IP address is already in use by another device on the network, meaning there is a lease conflict. Add the conflict information (IP address, time) to the lease conflict list. This can be viewed using the `lease-conflict-get` command or by checking the alarm records in a visual interface. If no reply is received, it is considered that there is no conflict, and the process ends.

[0116] This invention provides a network anomaly alarm monitoring method that enables real-time monitoring and notification processing of service anomalies, address pool anomalies, lease anomalies, request anomalies, and high availability anomalies in DHCPv4 and DHCPv6. It allows for early risk prediction, helping users quickly locate problems and minimize the impact of failures. Users can view anomaly information via commands and also view alarm records in real-time through a visual interface for easy observation. Different anomaly information is assigned different alarm levels for quick identification of alarm importance. The processing status of anomaly information is automatically updated; for the same anomaly record, if the anomaly end time is detected, it is marked as "processed"; otherwise, it is marked as "unprocessed." It can also be integrated with industry standards to proactively push alarm information.

[0117] In this invention, "DHCPv4" refers to the network protocol of IPv4 networks, whose core function is to automatically assign IP addresses and associated network configuration parameters to IPv4 devices.

[0118] In this invention, "DHCPv6" refers to an extended protocol adapted to IPv6 networks, used to provide automatic address allocation and network configuration for IPv6 devices, while being compatible with the features of IPv6.

[0119] Although the present invention has been described using the above preferred embodiments, it is not intended to limit the scope of protection of the present invention. Any changes and modifications made by those skilled in the art to the above embodiments without departing from the spirit and scope of the present invention shall still fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be defined by the claims.

Claims

1. A method for monitoring network anomaly alarms, characterized in that: The monitored object is the DHCP server, and the monitoring types include service anomalies, address pool anomalies, lease anomalies, request anomalies, and high availability anomalies; among them, Service exceptions include Agent exceptions, Kea exceptions, and database exceptions; Address pool anomalies are caused by abnormal DHCPv4 or DHCPv6 address pool utilization. Lease exception refers to lease conflict exception; Request exceptions include high-frequency request exceptions and illegal device exceptions; High availability anomalies include heartbeat anomalies, service failover, and backup node anomalies. Alarm monitoring is enabled via the KY_MACHINES_OPEN switch. Monitoring for service anomalies, address pool anomalies, lease anomalies, request anomalies, and high availability anomalies is controlled by specific switches. In service anomaly monitoring, the monitoring method for Agent anomalies and Kea anomalies is as follows: detect the process of Agent or Kea-dhcp service. If the Agent or Kea-dhcp service stops after two consecutive detections, record and report the anomaly. The method for monitoring database anomalies is as follows: determine the service status of the primary and backup database nodes by checking the database connection status; if both primary and backup database nodes stop, record and report the anomaly. The monitoring method for lease irregularities is as follows: Step S11: Configure the abnormal request detection switch KY_LCONFLICY_OPEN=yes to enable the lease conflict detection switch; Step S12: Configure the dhcp4 or dhcp6 configuration file, add the conflict detection plugin libdhcp_ping_check.so and related parameter configurations; Step S13: Monitor whether the same IP is bound repeatedly. If it is bound repeatedly, there is a lease conflict. The monitoring method for high-frequency request exceptions is as follows: Step S21: Configure the abnormal request detection switch KY_ILLREQ_OPEN=yes to enable the high-frequency request abnormal detection switch; Step S22: Configure the dhcp4 or dhcp6 configuration file, load the security enhancement plugin libdhcp_guard_alert.so and the configuration related to high-frequency request detection; Step S23: The client sends a DHCP request. After the server receives the message, it calls pkt4 / 6_receive to determine whether it is a DISCOVER / SOLICIT message. If it is not, the message is ignored. If it is, the alarm plugin is called to process the message, update the high-frequency request count and write it to the high-frequency request counter. The total number of client requests is obtained by reading the high-frequency counter. Step S24: If the request count is greater than or equal to the threshold, a high-frequency request alarm is triggered; The monitoring method for illegal device anomalies in request exceptions is as follows: Step S31: Configure the abnormal request detection switch KY_ILLREQ_OPEN=yes to enable the illegal device abnormal detection switch; Step S32: Configure the dhcp4 or dhcp6 configuration file, load the security enhancement plugin libdhcp_guard_alert.so and the path to the illegal device blacklist file; Step S33: After the client sends the request, the server obtains the configuration file option 60, option 61, option 1 or option 16 from the request message; it performs regular expression matching with the device values ​​in the blacklist one by one according to the matching rules, and if a match is successful, it is considered an illegal device; The monitoring method for address pool anomalies is as follows: Step S41: Configure the subnet utilization detection switch KY_SUBNETS_OPEN=yes to enable subnet utilization anomaly monitoring, and configure the subnet utilization threshold KY_SUBNET_ADDRUTIL; Step S42: Trigger the subnet information acquisition operation, extract subnet information, acquire subnet data, calculate the utilization rate of each subnet, and extract the subnet name or identifier for subsequent identification; Step S43: Traverse each subnet and compare the current utilization rate of the subnet with the preset threshold in real time; Step S44: When the current utilization rate of the subnet is greater than or equal to the threshold, record the alarm information; Step S45: Continue with the detection of the next subnet.

2. The network anomaly alarm monitoring method as described in claim 1, characterized in that: Step S13 includes: Step S131: The client sends an ICMP ping request for a specific IP address; Step S132: The server prepares to allocate an IP address by sending an ICMP ping request to the target IP. Step S133: Listen for ping replies. If a ping reply is received within the specified time, it indicates a lease conflict. Add the conflict information to the lease conflict list. If no ping reply is received within the specified time, it indicates that there is no lease conflict.

3. The network anomaly alarm monitoring method as described in claim 2, characterized in that: In step S12, the relevant parameter configuration includes enable-ping-check, enabling or disabling ping checks.

4. The network anomaly alarm monitoring method as described in claim 1, characterized in that: Step S44 includes: distinguishing between initial detection and continuous detection using the subnetMap table. If there is no corresponding subnet record in the subnetMap table, it is the first detection. If the current utilization rate of the subnet is greater than or equal to the threshold, an alarm is recorded and a record is added to the subnetMap table as follows: Status = Over threshold, last utilization rate = current subnet utilization rate, consecutive count = 1. If the current utilization rate of the subnet is less than the threshold, a record is added to the subnetMap table as follows: Status = Normal, last utilization rate = current subnet utilization rate. If a corresponding subnet record exists in the subnetMap table, continuous monitoring continues: If the current subnet utilization is less than the threshold, the consecutive count in the subnetMap table is reset to 0, the status to normal, and the previous utilization rate equal to the current subnet utilization rate; if the current subnet utilization is greater than or equal to the threshold, the difference is further assessed: If the difference is ≥1%: record 1 "post-change abnormal alarm" and update the previous utilization rate of the subnetMap table to equal the current subnet utilization rate; if the difference is <1%: only update the "most recent record time" of the subnetMap table and do not trigger a new alarm.

5. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1-4.

6. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method described in any one of claims 1-4.

Images