Unified DPI automatic inspection method and device for asymmetric network

Abstract

The invention relates to the technical field of communication, in particular to an asymmetric network unified DPI automatic inspection method and device.The method comprises the steps that a dial testing machine periodically sends dial testing messages containing DPI equipment information to a target drone, dial testing data information is obtained according to response information of the target drone, and the dial testing data information is uploaded to a server; the server obtains the related information in the XDR ticket, compares the dial test data information with the related information in the XDR ticket, and can locate the faulty DPI equipment according to the dial test message containing the DPI equipment information; meanwhile, the running state of the whole unified DPI system is monitored in real time by checking the consistency between the dial test data information and the final relevant information in the XDR ticket, and the problem attribution can be found and positioned in time through the method no matter the interface down, the system down, the cpu overload, the memory overload, the software exception or other unknown faults.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to an asymmetric network unified DPI automatic inspection method and device. Background Art

[0002] In the mobile operator network, users usually have multiple exits when accessing the Internet. When users access Internet services, not all traffic returns along the original route. For some services, the upstream and downstream traffic have inconsistent transmission paths. For this type of traffic, the Deep Packet Inspection (DPI) equipment at each exit and the XDR (full name: X Detailed Record) server determine whether synthesis is required based on the XDR call record. After synthesis, it is output to the File Transfer Protocol (FTP) server to complete traffic statistics for subsequent use by other services.

[0003] Since the operator's network and computer room are built gradually, there are problems such as different batches of DPI equipment and XDR servers, differences in software versions, and inconsistency in equipment manufacturers. How to confirm that the equipment on the network is always operating normally, how to promptly discover anomalies in XDR call records, and when an anomaly occurs, how to quickly locate which manufacturer's DPI device has a problem has become a more difficult problem.

[0004] In view of this, overcoming the defects of the prior art is an urgent problem to be solved in the field of this technology. Summary of the invention

[0005] The technical problem to be solved by the present invention is how to quickly locate a faulty DPI device when there is an anomaly in traffic statistics.

[0006] The present invention adopts the following technical solution:

[0007] In the first aspect, a unified DPI automated inspection method for an asymmetric network is provided, wherein a dialing machine is set in the user area and a target machine is set at each exit of the operator;

[0008] The method comprises:

[0009] Control the dial test machine to send a dial test message containing DPI device information to the target machine at a preset frequency, and the target machine sends a response message to the dial test machine after receiving the dial test message, and obtains the dial test data information according to the dial test message and the response message;

[0010] Uploading the dial test data information to a server, and periodically reading the XDR call record in the server to obtain relevant information in the XDR call record;

[0011] Compare and analyze the dial test data information with the relevant information in the XDR call record. If they are consistent, it means it is normal; if they are inconsistent, print the problem information and locate the faulty DPI device based on the problem information.

[0012] Preferably, the dial test message is accessed by http, and the dial test message includes: target machine IP address+uplink traffic DPI device manufacturer_DPI device number+downlink traffic DPI device manufacturer_DPI device number+dialing test timestamp.

[0013] Preferably, there is a difference within a preset range between the dialing timestamp and the timestamp counted by the DPI device.

[0014] Preferably, the step of setting up a dialing machine in the user area and setting up a target machine at each exit of the operator includes:

[0015] According to the number of operator's exports, a dialing machine is set in the user area, and a target machine is set at each operator's export; the uplink traffic of each dialing machine is designated to go through a fixed operator export, and the downlink traffic of each target machine is designated to go through a fixed operator export. The traffic direction is determined by setting the target machine accessed by the dialing machine.

[0016] Preferably, the periodically reading the XDR call record in the server to obtain relevant information in the XDR call record includes:

[0017] Determine the storage location of the XDR call record on the server, set a time period for reading, and use a reading interface or tool to read the XDR call record from the storage location;

[0018] Extract relevant information from the read XDR call record according to the need to check the network traffic, wherein the relevant information in the XDR call record includes at least one of the traffic size, source IP and destination IP, port information and protocol type;

[0019] The extracted relevant information is organized into a data set in the form of a list or dictionary containing multiple attribute fields to facilitate subsequent comparative analysis.

[0020] Preferably, comparing and analyzing the dial test data information with relevant information in the XDR call record includes:

[0021] Compare the number of entries in the dial test data information with the number of entries filtered from the XDR call record;

[0022] Compare the number of uplink bytes, downlink bytes, uplink packets, and downlink packets;

[0023] Compare the source IP, source port, target IP, and destination port.

[0024] Preferably, the method further comprises:

[0025] Each DPI device obtains the number of sub-items of the dial test message belonging to itself and sent by the dial test machine to complete the current round of testing;

[0026] When the number of dial-test messages received by the DPI device reaches the number of sub-entries allocated to it by the dial-test machine, a reception completion signal is sent to the server;

[0027] When the server detects that the dial test message sent by the dial test machine reaches the total number of entries, it confirms whether there is a first DPI device that fails to send a reception completion signal to the server. If so, the first DPI device is a faulty DPI device;

[0028] When generating an XDR call record, the server identifies the first DPI device as a faulty device and removes the comparison item corresponding to the first DPI device.

[0029] Preferably, the method further comprises:

[0030] Determine the traffic characteristics between the dial test machine and the target machine, as well as the target exit to which the uplink traffic of each dial test machine and the downlink traffic of each target machine need to be directed, and set policy routing rules based on the traffic characteristics and the target exit;

[0031] Applying the policy routing rule to the interface in the operator network connected to the network where the dialing machine and the target machine are located;

[0032] Test whether the uplink traffic of the test machine and the downlink traffic of the target machine are directed to the target exit according to the policy routing rules.

[0033] In a second aspect, an asymmetric network unified DPI automated inspection device is provided, the asymmetric network unified DPI automated inspection device comprising: a processor and a memory for storing processor executable instructions;

[0034] The processor is configured to execute the asymmetric network unified DPI automated inspection method described in the first aspect.

[0035] In a third aspect, a non-volatile computer storage medium is provided, wherein the computer storage medium stores computer executable instructions, and the computer executable instructions are executed by one or more processors to complete the asymmetric network unified DPI automated inspection method described in the first aspect.

[0036] In a fourth aspect, a chip is provided, comprising: a processor and an interface, for calling and running a computer program stored in the memory from a memory, and executing the asymmetric network unified DPI automated inspection method as described in the first aspect.

[0037] In a fifth aspect, a computer program product comprising instructions is provided. When the instructions are executed on a computer or a processor, the computer or the processor executes the asymmetric network unified DPI automated inspection method as described in the first to fourth aspects and any one of the aspects.

[0038] Compared with the prior art, the present invention has the following beneficial effects:

[0039] The present invention periodically sends a dial test message containing DPI device information to a target machine through a dial test machine, obtains dial test data information according to response information of the target machine, and uploads the dial test data information to a server; the server obtains relevant information in an XDR call sheet, and compares the dial test data information with relevant information in the XDR call sheet, and can locate the faulty DPI device according to the dial test message containing the DPI device information; at the same time, by verifying the consistency between the dial test data information and relevant information in the final XDR call sheet, the operating status of the entire unified DPI system is monitored in real time, and no matter whether it is an interface down, a system down, a CPU overload, a memory overload, a software abnormality or other unknown faults, the method can timely discover and locate the problem attribution. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0041] Figure 1 It is a schematic diagram of a communication network architecture in the prior art provided by an embodiment of the present invention;

[0042] Figure 2 An asymmetric network unified DPI automated inspection method provided by an embodiment of the present invention;

[0043] Figure 3 It is a schematic diagram of a communication network architecture between a dialing machine and a target machine provided by an embodiment of the present invention;

[0044] Figure 4 It is a schematic diagram of the flow trend of a dial test machine and a target machine provided by an embodiment of the present invention;

[0045] Figure 5 This is a schematic diagram of dial test data information provided by an embodiment of the present invention;

[0046] Figure 6It is a schematic diagram of a process of reading relevant information in an XDR call record provided by an embodiment of the present invention;

[0047] Figure 7 This is a schematic diagram of relevant information in an XDR call record provided by an embodiment of the present invention;

[0048] Figure 8 It is a structural schematic diagram of an asymmetric network unified DPI automatic inspection device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0049] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0050] Unless the context requires otherwise, throughout the specification and claims, the term "including" is to be interpreted as open inclusion, that is, "including, but not limited to". In the description of the specification, the terms "one embodiment", "some embodiments", "exemplary embodiments", "examples", "specific examples" or "some examples" and the like are intended to indicate that specific features, structures, materials or characteristics associated with the embodiment or example are included in at least one embodiment or example of the present disclosure. The schematic representation of the above terms does not necessarily refer to the same embodiment or example. In addition, the specific features, structures, materials or characteristics may be included in any one or more embodiments or examples in any appropriate manner, that is, although they may be carried in the embodiments or examples of the above terms due to reasons such as the order and position of appearance, it is not limited to that they can be carried in combination by one embodiment or example.

[0051] In the description of the present invention, the terms "first" and "second" are used only for descriptive purposes, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features. Thus, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. In the description of the embodiments of the present disclosure, unless otherwise specified, the meaning of "multiple" is two or more. In addition, for example, the same type of nouns may be described as two independent individuals by adding "A" and "B" at the end. In this case, the corresponding features defined as "A" and "B" are only used to distinguish the same type of individuals for description purposes, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features.

[0052] When describing some embodiments, the expressions "coupling", "coupling" and "connection" and their derivatives may be used. For example, when describing some embodiments, the term "connection" may be used to indicate that two or more components are in direct physical or electrical contact with each other. For another example, when describing some embodiments, the term "coupling" may be used to indicate that two or more components are in direct physical or electrical contact. However, the terms "connection" or "coupling" may also refer to two or more components that are not in direct contact with each other, but still cooperate or interact with each other, such as "optical path coupling", "wireless connection", etc. The embodiments disclosed herein are not necessarily limited to the contents of the present invention.

[0053] In addition, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0054] Embodiment 1:

[0055] Before describing this embodiment in detail, the flow trend process of users accessing Internet services is first introduced. In one embodiment, Figure 1 As shown, including:

[0056] When users access Internet services, the operator generally has multiple exits, such as operator exit 1, operator exit 2, and operator exit 3. Each exit of the operator has a corresponding DPI device for counting traffic (such as manufacturer 1 DPI1, manufacturer 1 DPI2, and manufacturer 2 DPI3). The transmission path of the downlink response message (i.e., downlink traffic) of the user accessing the Internet service may be inconsistent with the transmission path of the uplink request message (i.e., uplink traffic). When the paths are inconsistent, the DPI devices at different exits are required to synthesize the traffic. If the DPI devices belong to the same manufacturer, the manufacturer synthesizes it in its own way (such as synthesis server 1). If the DPI devices are from different manufacturers, they are synthesized through XDR call records (such as synthesis server 2). The XDR call records are finally output to FTP server 1 and FTP server 2 for subsequent business use.

[0057] In the above-mentioned prior art, in order to monitor the normal operation of the DPI device and XDR, snmp alarms are usually enabled for the DPI device and the XDR server. Conventional interface down (i.e., the physical state of the interface is down, and the interface cannot work properly), system down (i.e., the physical state of the system is down, and the system cannot work properly), CPU overload, and memory overload faults can send alarm information to the network management platform through snmp alarms. For inaccurate traffic statistics caused by software problems in the DPI device and the XDR server, both manufacturers will be required to check their own equipment, and the manufacturer will analyze and determine which manufacturer has the problem. If it is a continuous problem, it can be quickly checked and identified. If it is an occasional problem, it may be difficult to judge or even impossible to locate. Traditional methods cannot guarantee the timeliness of the occurrence and discovery of inaccurate traffic statistics events.

[0058] In order to solve the above problems, the embodiment of the present invention proposes an asymmetric network unified DPI automatic inspection method. In one embodiment, Figure 2 As shown, the method includes:

[0059] Step 101: Set up a dialing machine in the user area and a target machine at each exit of the operator.

[0060] Among them, a DPI device and a corresponding XDR server are respectively set up at each outlet of the operator. The dialing machine in the user area establishes communication with the target machine through the outlet of the corresponding operator. The dialing machine can be a PC (full name in English: Personal Computer), and the target machine is the corresponding network server. In the actual application scenario, the corresponding dialing software needs to be installed on both the PC and the network server to send and respond to specific dialing messages. More specific explanations are not given in this embodiment.

[0061] In one embodiment, Figure 3 As shown, according to the number of operator's outlets, a dial test machine is set in the user area, and a target machine is set at each operator's outlet; the uplink traffic of each dial test machine is designated to go through a fixed operator outlet, and the downlink traffic of each target machine is designated to go through a fixed operator outlet. The target machine accessed by the dial test machine is set to determine the traffic direction. It is worth noting that Figure 3 There are not multiple dial test machines and target machines. For ease of understanding, a dial test machine group and a target machine group are designed. When there are 3 dial test machines and 3 target machines, their corresponding relationship is referenced Figure 4 .

[0062] The hardware layout of the entire detection system is planned based on the number of outlets of the operator. A dialer is placed in the user area, and a target machine is set up at each outlet of the operator. This layout enables the detection range to cover all outlet links of the operator, ensuring that the network conditions related to each outlet can be fully detected and analyzed.

[0063] Among them, for each dialing machine, the data (i.e., uplink traffic) sent to the network (target machine) has a clear flow path and will not change at will. For example, the uplink traffic of dialing machine 1 is always transmitted through the operator's exit 1. Similarly, the downlink traffic of each target machine is also designated to go through a fixed operator exit and then return to the dialing machine. In other words, the data sent by the target machine (i.e., downlink traffic) has a fixed sending direction. For example, the downlink traffic sent by target machine 2 is always transmitted through the operator's exit 2. In this way, the path of the data in the process of being transmitted back to the user area can be accurately controlled, forming a complete and clear correspondence with the uplink traffic path of the dialing machine.

[0064] In one embodiment, referring to Figure 4 If the designated test machine 1 accesses the target machine 3, the upstream traffic of the test machine goes to the operator's exit 1, and the downstream traffic of the target machine goes to the operator's exit 3.

[0065] exist Figure 4 In the figure, the (101.1.1.1) after the dial test machine 1 is the IP address of the dial test machine 1, the (company1_DPI01) after the exit 1 is the DPI device corresponding to the operator exit 1, and the (201.1.1.1) after the target machine 1 is the IP address of the target machine 1. The same is true for the others, which will not be repeated in this embodiment.

[0066] In order to avoid affecting the subsequent traffic monitoring process due to data transmission errors caused during the initial network configuration, in one embodiment, the method also includes: determining the traffic characteristics between the dialing machine and the target machine, and the target exit to which the uplink traffic of each dialing machine and the downlink traffic of each target machine need to be directed, and setting policy routing rules according to the traffic characteristics and the target exit; applying the policy routing rules to the interface in the operator network that is connected to the network where the dialing machine and the target machine are located; and testing whether the uplink traffic of the dialing machine and the downlink traffic of the target machine are directed to the target exit according to the policy routing rules.

[0067] Traffic characteristics include many aspects, such as traffic size, traffic protocol type (such as TCP, UDP, etc.), traffic priority, etc. Knowing the traffic size between the dialer and the target machine can help estimate the load of the network link and provide a basis for planning a reasonable routing strategy.

[0068] The uplink traffic of each dial test machine and the downlink traffic of each target machine have their target exits to be directed to. For example, in order to comprehensively detect the network performance and equipment working status of each operator's exit, it will be planned in advance which dial test machine's uplink traffic should go to which specific exit, and which exit the target machine's downlink traffic should return from, so as to build an orderly and comprehensive detection link. Clarifying the target exit is the key to setting up routing rules in the future, ensuring that the traffic can be accurately transmitted in the expected direction.

[0069] Formulate policy routing rules based on the determined traffic characteristics and target exits. Policy routing is a more flexible routing method than traditional destination address-based routing, allowing network administrators to determine the forwarding path of data packets based on a variety of conditions (such as the traffic size, protocol type, priority, etc. mentioned above). For example, you can set the rule to "when the traffic protocol type is Transmission Control Protocol (TCP) and the traffic size exceeds a certain threshold, forward it from the operator's exit 1", or "for high-priority traffic, guide it to be transmitted through the operator's exit 2", etc." Through targeted policy routing rule settings, precise control of the flow of traffic between the dialing machine and the target machine can be achieved.

[0070] After formulating the corresponding policy routing rules, apply the policy routing rules to the interface in the operator network that is connected to the network where the dial test machine and the target machine are located. Although the policy routing rules have been set and applied, the actual network environment is complex and changeable. There may be various factors that cause the rules to fail to take effect correctly, such as configuration conflicts of network devices, software vulnerabilities, or hardware failures, which may affect the actual flow of traffic. Therefore, it is necessary to test whether the traffic is actually directed to the target exit according to the policy routing rules, and to discover potential problems and make adjustments in time to avoid affecting the subsequent monitoring results.

[0071] In one embodiment, the testing method may include: deploying corresponding traffic monitoring tools on the dialing machine and the target machine, observing the actual flow of the upstream and downstream traffic to see whether it is consistent with the set target exit. For example, check from which exit of the operator the traffic data packet sent by the dialing machine finally leaves the network, and from which exit of the operator the traffic received by the target machine enters the network. At the same time, the traffic statistics function in the operator network, routing table viewing and other means can also be combined to assist in verification. If it is found that the traffic does not reach the target exit according to the rules, it is necessary to further investigate whether it is a problem with the rule setting or a failure in the network equipment, and then make corrections and optimizations in a timely manner to ensure that both the upstream and downstream traffic are transmitted through the preset operator exit.

[0072] Step 102: Control the dial test machine to send a dial test message containing DPI device information to the target machine at a preset frequency. After receiving the dial test message, the target machine sends a response message to the dial test machine, and obtains the dial test data information according to the dial test message and the response message.

[0073] In one embodiment, the dialing machine sends a dialing message containing DPI device information to the target machine at a preset frequency. The preset frequency can be flexibly determined according to the actual network conditions, detection requirements, etc. In one embodiment, the preset frequency can be 3s. Figure 4 As shown, for example, the dialing strategy sets three dialing machines (dialing machine 1, dialing machine 2 and dialing machine 3) to dial one target machine every 3 seconds, ensuring that each target machine is dialed 60 times per minute, an average of once per second.

[0074] After receiving the dial test message, the target machine will promptly return the response information to the dial test machine, and then extract and organize the dial test data information based on the dial test messages and response information. The dial test data information will include many aspects such as message transmission time, number of packets, content accuracy, etc.

[0075] By regularly sending and receiving messages, the data interaction scenario in the real network environment is simulated. The collected dial-up data information can intuitively reflect the real-time communication status of the link where the DPI device is located. It has key reference value for subsequent judgments on whether the equipment is working normally and the quality of network data transmission. At the same time, it can also capture occasional abnormal situations in time.

[0076] Step 103: Upload the dialing data information to the server, and periodically read the XDR call record in the server to obtain relevant information in the XDR call record.

[0077] Among them, Figure 5 The figure shows the dial test data information reported by the dial test machine. The collected dial test data information is first transmitted to the server through the dial test machine. The server can be an FTP server with powerful data storage and processing capabilities. After that, the XDR call list is read in a certain period in the server. The XDR call list contains rich network service details, such as network usage time, traffic consumption and other multi-dimensional information, from which some content related to this detection is extracted, such as relevant information corresponding to the service processed by the DPI device.

[0078] Step 104: Compare and analyze the dial test data information with the relevant information in the XDR call record. If they are consistent, it means it is normal; if they are inconsistent, print the problem information and locate the faulty DPI device based on the problem information.

[0079] The obtained dial test data information and the relevant information in the XDR call list are compared and analyzed one by one, for example, key indicators such as traffic statistics, the number of uplink bytes, the number of downlink bytes, the number of uplink packets, and the number of downlink packets are compared. In one embodiment, the comparison and analysis of the dial test data information and the relevant information in the XDR call list includes: comparing the number of entries in the dial test data information with the number of entries filtered out from the XDR call list; comparing the number of uplink bytes, the number of downlink bytes, the number of uplink packets, and the number of downlink packets; comparing the dial test source IP, the dial test source port, the target machine IP, and the destination port.

[0080] The source port of the dial test refers to the port number used by the sender (i.e., the dial test machine), and the destination port refers to the port number used by the receiver (i.e., the target machine). When transmitting data, the source port and the destination port are used in pairs to ensure that the data can reach the target device correctly. Each port is associated with a specific application or service and is allocated according to the standard. More specific details are not given in this embodiment.

[0081] If all comparison results are consistent, it means that the DPI equipment and related business processes are in normal operation at the current stage of the network and under the corresponding link. On the contrary, once inconsistencies are found, the problem information of the difference part will be printed out and clearly presented to the relevant operation and maintenance personnel for review. Based on these problem information, the location of the faulty DPI equipment and possible causes of the fault can be accurately identified. Compared with traditional methods, it can more efficiently deal with various network problems related to DPI equipment such as inaccurate traffic statistics, ensuring the stable and efficient operation of the network.

[0082] Among them, since the dial test message contains the specific information of the DPI device (including the manufacturer and serial number, etc.), when a problem occurs in the above comparison process, the corresponding dial test message can be found to locate the faulty DPI device.

[0083] In one embodiment, the dial test message is accessed using http, and the dial test message includes: target machine IP address+uplink traffic DPI device manufacturer_DPI device number+downlink traffic DPI device manufacturer_DPI device number+dialing test timestamp.

[0084] Among them, http is an application layer protocol widely used in the Internet, with many advantages such as strong versatility, easy implementation and understanding, etc. Using http access to send dial-up test messages can conveniently use the existing network infrastructure and related technologies for data transmission, and most network devices and systems have good compatibility and support for the http protocol, which can ensure that the dial-up test message can be smoothly sent from the dial-up test machine to the target machine in different network environments, reducing transmission obstacles caused by protocol compatibility issues.

[0085] The purpose of the target machine IP address is to specify the specific destination of the dial test message. The dial test machine can accurately send the message to the corresponding target machine based on the target machine IP address, ensuring that the data can accurately reach the designated detection link endpoint and achieve effective information exchange.

[0086] Among them, the content about "Manufacturer of Uplink Traffic DPI Device_DPI Device Number" mainly records the DPI device information related to upstream traffic. Clarifying the manufacturer of the DPI device will help to quickly contact the corresponding manufacturer for investigation and communication when problems arise. DPI devices from different manufacturers may differ in function implementation, configuration methods, etc. By marking the manufacturer, the responsible party can be accurately located. The DPI device number uniquely identifies a specific DPI device. In a network environment containing many devices, different DPI devices can be accurately distinguished by the number, which is convenient for subsequent analysis and judgment of the operating status of specific devices.

[0087] The "Downlink traffic DPI device manufacturer_DPI device number" corresponds to the upstream traffic part and is used to record the relevant information of the DPI device involved in the downstream traffic. It also facilitates the subsequent distinction between devices from different manufacturers and the location of specific device status. When problems are found in the downstream traffic detection, this part of information can quickly identify which manufacturer's DPI device may have a fault or improper handling, and then carry out targeted troubleshooting.

[0088] The dial test timestamp records the specific time when the message is sent. On the one hand, it can be used to measure the transmission time of the message in the network. By comparing the sending time and the time when the target machine responds after receiving the message, the time consumed for data transmission can be calculated, thereby judging whether the transmission efficiency of the network link is normal. For example, if the transmission time is too long, it may mean that the link is congested or the device is processing slowly. On the other hand, when performing multiple dial tests and data analysis in the future, the timestamp can help sort the detection data in chronological order, making it convenient to compare and analyze the network status in different time periods, and check whether the network performance is stable. In one embodiment, referring to Figure 5 , a dial test message URL, for example:

[0089] http: / / 203.1.1.3 / company1_DPI01_company2_DPI01_1700000000.

[0090] In one embodiment, since the transmission takes time, there is a difference within a preset range between the dial test timestamp and the timestamp counted by the DPI device. Specifically, when the dial test machine sends a dial test message containing a dial test timestamp, the dial test message needs to be transmitted to the DPI device via a network link. In this process, due to the influence of various factors such as the processing speed of the network device, link bandwidth, and network congestion, the uncertainty of the transmission time will be caused. For example, during the peak period of the network, data may be queued in routers, switches and other devices waiting to be forwarded, thereby increasing the transmission time.

[0091] Even after the message reaches the DPI device, it takes a certain amount of time for the DPI device to process the data. The DPI device may need to perform deep packet inspection on the message, including parsing the protocol, checking the content, etc. This process will also cause time delays. Therefore, there will be a difference between the time when the dial test machine sends the message (dial test timestamp) and the time when the DPI device counts the relevant data of the message (DPI device statistics timestamp).

[0092] The existence of the preset range is to determine whether the DPI device is working properly within a reasonable error range. If there is no preset range, once a slight time difference occurs, the DPI device may be misjudged to be faulty, resulting in unnecessary troubleshooting. The setting of the preset range usually takes into account the normal delay of the network, and may need to be determined by multiple measurements and evaluations of the network. For example, in a relatively stable local area network environment, the transmission delay may be small, and the preset range can be set between a few milliseconds and tens of milliseconds; while in a wide area network or complex Internet environment, due to longer network links and more devices passing through, the transmission delay may be large, and the preset range may be expanded to hundreds of milliseconds or even seconds. At the same time, the performance indicators of the DPI device itself will also affect the setting of the preset range. A high-performance DPI device has a fast processing speed, and the corresponding preset range may be relatively narrowed. More specific explanations will not be given in this embodiment.

[0093] In one embodiment, Figure 6 As shown, in step 103, periodically reading the XDR call record in the server to obtain relevant information in the XDR call record includes:

[0094] Step 1031: Determine the storage location of the XDR call record in the server, set a reading time period, and use a reading interface or tool to read the XDR call record from the storage location.

[0095] On the server side, we must first clarify where the XDR call records are stored. This involves the specific storage path of the server, a specific database table, or a designated area stored in a distributed storage system. For example, XDR call records may be classified by date and stored in a folder on the server hard disk. Each subfolder corresponds to a different month and contains the call record files generated every day of that month; or they may be stored in a table in a relational database, using the table name and related fields to distinguish call records of different time periods and different business types. Only by knowing the storage location accurately can we find the target for subsequent reading operations.

[0096] Reasonable reading time cycle is set, such as the frequency of network traffic changes, the timeliness requirements of detection, and the processing capacity of the server. If the network traffic changes frequently and needs to be monitored in a timely manner, the reading cycle may be set shorter, such as reading once every minute; if the network is relatively stable and the timeliness requirements are not so high, in order to reduce the burden of frequent reading on the server, the cycle can be set slightly longer, such as reading once every few minutes.

[0097] In one embodiment, a suitable reading interface or tool can be selected according to the storage form of the XDR call record and the technical architecture of the system in which it is located. If the XDR call record is stored in the local file system of the server in the form of a file, tools related to file reading operations such as the `open function in the Python language may be used to open the file and read the content; if it is stored in a database, it is necessary to use the query interface provided by the corresponding database management system. For example, for a MySQL database, query and read operations can be performed through SQL statements combined with the corresponding Python database connection library, so as to obtain the data content of the XDR call record.

[0098] Step 1032: extract relevant information from the read XDR call record according to the inspection requirements, wherein the relevant information in the XDR call record includes at least one of the traffic size, source IP and destination IP, port information and protocol type.

[0099] In one embodiment, due to different purposes of checking network traffic, the information focused on is also different. This embodiment clearly requires extracting content closely related to network traffic inspection from the read XDR call records, that is, key information such as traffic size, source IP and destination IP, port information, and protocol type.

[0100] The traffic volume can directly reflect the busyness of the network link and the data transmission volume. For example, it can determine whether there are abnormal traffic peaks or valleys in a certain period of time, and then analyze whether there are problems such as network congestion or business abnormalities. The source IP and destination IP can clearly show the source and destination of the data, help track the flow path of network traffic, and determine which nodes are interacting with data. Port information is very helpful for understanding the ports used by specific applications and troubleshooting port-related configuration or security issues. For example, the common HTTP service uses port 80 by default.

[0101] Step 1033: Organize the extracted relevant information into a data set in the form of a list or dictionary containing multiple attribute fields to facilitate subsequent comparative analysis.

[0102] In one embodiment, Figure 7 As shown, the extracted relevant information is sorted to become a data set in the form of a list or dictionary containing multiple attribute fields. When using the list form, for example, each traffic record can be used as an element, and each element can store attribute values ​​such as traffic size, source IP, destination IP, port information, and protocol type in a fixed order, so that it is convenient to access and traverse these data through indexes; if the dictionary form is used, the unique identifier of the traffic record (such as a serial number, etc.) can be used as the key, and the corresponding value is a dictionary. The keys in the dictionary are "traffic size", "source IP", "destination IP", "port information", "protocol type", etc., and the corresponding values ​​are the specific content extracted.

[0103] In one embodiment, Figure 5 and Figure 7 As shown, in step 104, for example, the printed question information is:

[0104] SIP:101.1.1.1 / DIP:203.1.1.3;

[0105] URL: http: / / 203.1.1.3 / company1_DPI01_company2_DPI01_1733788807, the number of downlink messages is inconsistent (detailed information: the number of downlink messages of the dial test machine is 132, the number of downlink messages of the XDR call list is 108, and the error is 24). The above problem information indicates that when the dial test machine 1 accessed the target machine 3 at 08:00:07 Beijing time on 2024-12-10, the number of messages counted by company2_DPI01 was missing 24 messages. Then the DPI device company2_DPI01 is located as a faulty device. In one embodiment, after locating the faulty DPI device, the method further includes: after locating the faulty DPI device, rechecking the faulty DPI device, querying whether there are error packets and packet loss on the corresponding interface, and whether there are error packets and packet loss in the software, so as to obtain recheck information, and feed back the recheck information to the server.

[0106] Among them, after the faulty DPI device has been located through the previous steps, the faulty DPI device is roughly determined based on the problem found by comparing the dial test data information with the relevant information in the XDR call record, but the specific fault manifestation and root cause still need to be further confirmed.

[0107] DPI devices often have multiple interfaces for data input and output. Check whether there are errors in the data received or sent from the interface, such as mismatch of the checksum of the data packet, tampering of key information in the header, or parsing errors. You can use professional network monitoring tools to capture data packets at the interface and analyze whether each data packet complies with the specifications based on the corresponding network protocol standards to determine whether there are any error packets.

[0108] The query of packet loss is to check whether there is any packet loss during the data transmission process. This can be determined by comparing the number of packets sent by the sender and the number of packets actually received by the receiver, or by using some network performance monitoring software, which can count indicators such as the packet loss rate of a certain interface in a specific time period. For example, if 100 packets are sent but only 90 are received by the receiver, it means that there is a certain degree of packet loss, which may be caused by various reasons such as interface hardware failure, link instability, or device buffer overflow.

[0109] In addition to the hardware interface, the software level of the DPI device may also have packet errors and packet loss problems. When the software performs deep packet inspection, analysis, processing and forwarding operations on data packets, if there are program vulnerabilities, algorithm errors, or improper memory management, it may cause data packets to be erroneous or lost. To check whether the software has error packets, you can check the software's log files. Many DPI device software will record abnormalities in the process of processing data packets, such as which data packets are marked as error packets because they do not meet the internal parsing rules.

[0110] For software packet loss queries, on the one hand, you can obtain relevant information from the statistical module inside the software to see if there are any records of data packets being lost in the software processing flow; on the other hand, you can simulate specific network traffic scenarios, send data packets with known numbers and characteristics to the device, and then observe the data packets that the software ultimately outputs to determine whether there is packet loss.

[0111] In order to improve the comparison efficiency of comparing the dial test data information with the relevant information in the XDR call record, in one embodiment, each DPI device respectively obtains the number of sub-items of the dial test message belonging to itself sent by the dial test machine to complete the current round of testing; when the number of dial test messages received by the DPI device reaches the number of sub-items allocated to itself by the dial test machine, it sends a reception completion signal to the server; when the server detects that the dial test message sent by the dial test machine reaches the total number of entries, it confirms whether there is a first DPI device (the first here has no special meaning and can be any DPI device) that has not sent a reception completion signal to the server, and if so, the first DPI device is a faulty DPI device; when generating an XDR call record, the server identifies the first DPI device as a faulty device and eliminates the comparison item corresponding to the first DPI device.

[0112] The "number of sub-items of the dial test message belonging to itself" refers to the number of related dial test messages that each DPI device should receive according to the dial test strategy of the dial test machine. Figure 4 , the dialing strategy is: set 3 dialing machines (dialing machine 1, dialing machine 2 and dialing machine 3) to dial a target machine every 3 seconds, ensuring that each target machine is dialed 60 times per minute, an average of once per second. Then the DPI device company1_DPI01 needs to receive 20 dialing messages in one minute. When company1_DPI01 receives 20 dialing messages, it sends a reception completion signal to the server.

[0113] According to the above example, the total number of entries within one minute is 60. When the server obtains the report that the dial test machine group (i.e., dial test machine 1, dial test machine 2, and dial test machine 3) has completed 60 dial test messages, for example, the server receives the receiving completion signals sent by company1_DPI01 and company1_DPI02 respectively, but does not receive the receiving completion signal sent by company2_DPI01 (i.e., the first DPI device), it will directly determine that the DPI device company2_DPI01 has a fault.

[0114] In the subsequent process of comparing the dial test data information with the relevant information in the XDR call record, first remove the comparison items corresponding to the dial test message containing company2_DPI01 information. For example, refer to Figure 7 (In the URL from top to bottom, the comparison items in the third line and the comparison items in the sixth line) can be directly skipped without comparison analysis, and then other comparison items are compared, so as to save the comparison time of the server and improve the comparison efficiency. In this embodiment, the dialing machine periodically sends a dialing test message containing DPI device information to the target machine, and obtains the dialing test data information according to the response information of the target machine, and uploads the dialing test data information to the server; the server obtains the relevant information in the XDR call sheet, and compares the dialing test data information with the relevant information in the XDR call sheet, and can locate the faulty DPI device according to the dialing test message containing the DPI device information; at the same time, by verifying the consistency between the dialing test data information and the relevant information in the final XDR call sheet, the operating status of the entire unified DPI system is monitored in real time. Whether it is interface down, system down, CPU overload, memory overload, software abnormality or other unknown faults, this method can be used to timely discover and locate the problem.

[0115] Embodiment 2:

[0116] In Example 1, an asymmetric network unified DPI automated inspection method is provided. In this embodiment, an asymmetric network unified DPI automated inspection device is proposed. The asymmetric network unified DPI automated inspection device includes: a processor and a memory for storing processor executable instructions; wherein the processor is configured to execute the asymmetric network unified DPI automated inspection method described in Example 1.

[0117] like Figure 8 As shown, the asymmetric network unified DPI automatic inspection device includes a processor 21 and a memory 22, wherein the processor 21 and the memory 22 can be connected via a bus or other means.

[0118] The processor 21 may be a central processing unit (CPU). The processor 21 may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or a combination of the above chips.

[0119] The memory 22, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer executable programs and modules, such as program instructions / modules corresponding to the asymmetric network unified DPI automated inspection method in Embodiment 1 of the present invention. The processor executes various functional applications and training processes of the processor by running the non-transitory software programs, instructions and modules stored in the memory.

[0120] The memory 22 may include a program storage area and a training storage area, wherein the program storage area may store an operating system and application programs required for at least one function; the training storage area may store training created by the processor, etc. In addition, the memory may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 22 may optionally include a memory remotely located relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The one or more modules are stored in the memory 22, and when executed by the processor 21, execution such as Figure 1 The asymmetric network unified DPI automatic inspection method in the embodiment 1 is shown. The specific details of the above asymmetric network unified DPI automatic inspection method can be referred to in Figure 1 , Figure 2 and Figure 3 The corresponding descriptions and effects in the embodiments shown in the figure can be understood and will not be repeated here.

[0121] This embodiment also provides a computer storage medium, which stores a computer program. The computer program can be executed by a processor to complete the asymmetric network unified DPI automated inspection method described in Example 1.

[0122] The computer storage medium stores computer executable instructions, and the computer executable instructions can execute the asymmetric network unified DPI automated inspection method in any of the above method embodiments. Among them, the storage medium can be a disk, an optical disk, a read-only memory (ROM), a random access memory (RAM), a flash memory, a hard disk (HDD), or a solid-state drive (SSD); the storage medium can also include a combination of the above types of memory.

[0123] The specific steps of the asymmetric network unified DPI automatic inspection method are shown in Example 1 and will not be repeated in this embodiment.

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

Claims

1. An asymmetric network unified DPI automated inspection method, characterized in that: A dialing machine is set in the user area, and a target machine is set at each exit of the operator; the method comprises: Control the dial test machine to send a dial test message containing DPI device information to the target machine at a preset frequency, and the target machine sends a response message to the dial test machine after receiving the dial test message, and obtains the dial test data information according to the dial test message and the response message; Uploading the dial test data information to a server, and periodically reading the XDR call record in the server to obtain relevant information in the XDR call record; Compare and analyze the dial test data information with the relevant information in the XDR call record. If they are consistent, it means it is normal; if they are inconsistent, print the problem information and locate the faulty DPI device based on the problem information.

2. The asymmetric network unified DPI automated inspection method according to claim 1, characterized in that: The dial test message is accessed by http, and the dial test message includes: target machine IP address+uplink traffic DPI device manufacturer_DPI device number+downlink traffic DPI device manufacturer_DPI device number+dialing test timestamp.

3. The asymmetric network unified DPI automated inspection method according to claim 2, characterized in that: There is a difference within a preset range between the dialing timestamp and the timestamp counted by the DPI device.

4. The asymmetric network unified DPI automated inspection method according to claim 1, characterized in that: The setting of the dialing machine in the user area and the setting of the target machine at each exit of the operator includes: According to the number of operator's exports, a dialing machine is set in the user area, and a target machine is set at each operator's export; the uplink traffic of each dialing machine is designated to go through a fixed operator export, and the downlink traffic of each target machine is designated to go through a fixed operator export. The traffic direction is determined by setting the target machine accessed by the dialing machine.

5. The asymmetric network unified DPI automated inspection method according to claim 1, characterized in that: The periodically reading the XDR call record in the server to obtain relevant information in the XDR call record includes: Determine the storage location of the XDR call record on the server, set a time period for reading, and use a reading interface or tool to read the XDR call record from the storage location; Extract relevant information from the read XDR call record according to the inspection requirements, wherein the relevant information in the XDR call record includes at least one of traffic size, source IP and destination IP, port information, and protocol type; The extracted relevant information is organized into a data set in the form of a list or dictionary containing multiple attribute fields to facilitate subsequent comparative analysis.

6. The asymmetric network unified DPI automated inspection method according to claim 1, characterized in that: The comparing and analyzing the dial test data information with the relevant information in the XDR call record includes: Compare the number of entries in the dial test data information with the number of entries filtered from the XDR call record; Compare the number of uplink bytes, downlink bytes, uplink packets, and downlink packets; Compare the source IP, source port, target IP, and destination port.

7. The asymmetric network unified DPI automated inspection method according to claim 1, characterized in that: The method further comprises: Each DPI device obtains the number of sub-items of the dial test message belonging to itself and sent by the dial test machine to complete the current round of testing; When the number of dial-test messages received by the DPI device reaches the number of sub-entries allocated to it by the dial-test machine, a reception completion signal is sent to the server; When the server detects that the dial test message sent by the dial test machine reaches the total number of entries, it confirms whether there is a first DPI device that fails to send a reception completion signal to the server. If so, the first DPI device is a faulty DPI device; When generating an XDR call record, the server identifies the first DPI device as a faulty device and removes the comparison item corresponding to the first DPI device.

8. The asymmetric network unified DPI automated inspection method according to claim 1, characterized in that: The method further comprises: Determine the traffic characteristics between the dial test machine and the target machine, as well as the target exit to which the uplink traffic of each dial test machine and the downlink traffic of each target machine need to be directed, and set policy routing rules based on the traffic characteristics and the target exit; Applying the policy routing rule to the interface in the operator network connected to the network where the dialing machine and the target machine are located; Test whether the uplink traffic of the test machine and the downlink traffic of the target machine are directed to the target exit according to the policy routing rules.

9. An asymmetric network unified DPI automatic inspection device, characterized in that: The asymmetric network unified DPI automated inspection device comprises: a processor and a memory for storing processor executable instructions; The processor is configured to execute the asymmetric network unified DPI automated inspection method as described in any one of claims 1-8.

10. A non-volatile computer storage medium, characterized in that: The computer storage medium stores computer executable instructions, and the computer executable instructions are executed by one or more processors to complete the asymmetric network unified DPI automated inspection method as described in any one of claims 1-8.

Images