An anomaly detection method, device, computer program product, and storage medium

Abstract

Embodiments of the present application provide an exception detection method, device, computer program product and storage medium. A part of table entries in a target flow table can be filtered out and offloaded to a target network card to obtain a target table entry combination to be tested; during processing of a data flow by the target network card based on the target table entry combination, whether an exception occurs in a performance index is monitored to find whether there is an abnormal risk of the target network card under the target table entry combination. It can be known that in the exception detection process, the part of table entries is filtered out to form the table entry combination, the target flow table is changed from a constant to a variable by flexibly forming the table entry combination on the basis of the target flow table, and thus whether the flow table offloading is a cause of triggering the network card exception can be effectively analyzed. Accordingly, in the embodiments of the present application, a new exception cause analysis angle, i.e., a flow table offloaded to the network card, is proposed, and whether the network card exception is possibly triggered by the flow table offloading can be analyzed, and thus the accuracy of the network card exception detection can be effectively improved.

Description

Technical Field

[0001] This application relates to the field of network technology, and in particular to an anomaly detection method, device, computer program product, and storage medium. Background Technology

[0002] In traditional network architectures, flow tables are typically managed and processed by the control plane within the software stack. However, with the advent of smart NICs, flow tables can be offloaded to the smart NIC itself. This means that network traffic processing functions that were originally handled by the control plane can be partially or entirely offloaded to the hardware level of the smart NIC.

[0003] Currently, smart network interface cards (NICs) are used in scenarios such as intelligent computing, playing a crucial role. Their hardware offloading capability improves network transmission performance. However, if a smart NIC malfunctions, it will negatively impact network transmission performance and the efficiency of computing resource utilization.

[0004] Therefore, there is an urgent need for a solution that can effectively detect anomalies in smart network cards. Summary of the Invention

[0005] This application provides an anomaly detection method, device, computer program product, and storage medium in several aspects to improve the accuracy of network card anomaly detection.

[0006] This application provides an anomaly detection method, including:

[0007] In response to an anomaly detection command for the target network interface card (NIC), a target flow table that needs to be offloaded to the target NIC is determined, the target flow table containing entries.

[0008] Some entries in the target flow table are unloaded onto the target network card to obtain the target entry combination to be tested;

[0009] If an abnormal performance metric is detected during the processing of a data stream by the target network interface card (NIC) based on the target entry combination, it is determined that the target NIC has an abnormal risk under the target entry combination.

[0010] Further, determining the target flow table that needs to be offloaded to the target network interface card includes:

[0011] If there are multiple flow tables that need to be unloaded to the target network card, the cascading relationship between the entries contained in the multiple flow tables is identified to obtain multiple cascading paths;

[0012] If any of the multiple cascaded paths does not meet the preset path constraints, then the entries contained in the target cascaded path are deleted from the multiple flow tables to obtain the target flow table that needs to be offloaded to the target network card.

[0013] Furthermore, the method also includes:

[0014] For any cascaded path, if a valid transmission destination cannot be indicated on the cascaded path, then the cascaded path is determined to not meet the preset path constraint conditions.

[0015] Further, some entries in the target flow table are offloaded to the target network interface card to obtain the target entry combination to be tested, including:

[0016] Select a subset of cascading paths from those existing in the target flow table;

[0017] The entries contained in the selected cascading paths are unloaded onto the target network interface card to obtain the target entry combination.

[0018] Further, from the cascading paths existing in the target flow table, a portion of the cascading paths are filtered, including:

[0019] Calculate the required concurrent data stream N to be supported by the target network interface card, where N is a positive integer;

[0020] From the cascading paths existing in the target flow table, N cascading paths are selected, and the communication terminals matched in the N cascading paths are different.

[0021] Further, the required concurrent data stream N supported by the target network interface card is calculated, including:

[0022] Determine the number of subnets existing in the network scenario where the target network interface card is located;

[0023] Determine the number of corresponding communication terminals in the subnet;

[0024] Based on the number of communication terminals and the number of subnets, the estimated number of communication terminals that the target network card needs to bridge is used as the data flow concurrency N.

[0025] Furthermore, based on the number of communication terminals and the number of subnets, the number of cross-subnet end-to-end data streams required to be supported in the subnet where the target network card is located is estimated, which is used as the data stream concurrency N, including:

[0026] If the number of communication terminals is taken as the average number of communication terminals in the subnet, then the square of the average number is calculated.

[0027] Calculate the product between the squared value and the number of subnets, and use it as the data stream concurrency N.

[0028] Furthermore, the method also includes:

[0029] Under the target entry combination, adjust the number of request queues in the target network interface card;

[0030] If, during the process of the target network interface card (NIC) processing the data stream based on the target entry combination, fluctuations in performance metrics are detected due to changes in the number of request queues, then it is determined that the abnormal risk of the target NIC under the target entry combination is related to the number of request queues.

[0031] Furthermore, the method also includes:

[0032] If, during the process of the target network interface card (NIC) processing the data stream based on the target table entry combination, it is detected that the performance indicators no longer fluctuate when the number of request queues is adjusted to within the target queue number range, then the target queue number range is output as a control suggestion parameter for the target NIC.

[0033] Furthermore, the method also includes:

[0034] Under the target entry combination, the target flow tables offloaded to the target network interface card are merged or split to adjust the number of flow tables offloaded to the target network interface card;

[0035] If, during the process of the target network interface card (NIC) processing the data stream based on the target entry combination, fluctuations in performance metrics are detected due to changes in the number of flow tables, then it is determined that the abnormal risk of the target NIC under the target entry combination is related to the number of flow tables.

[0036] Furthermore, the method also includes:

[0037] If, during the process of the target network interface card (NIC) processing the data stream based on the target table entry combination, it is detected that the performance indicators no longer fluctuate when the number of flow tables is adjusted to within the target flow table number range, then the target flow table number range will be output as a control suggestion parameter for the target NIC.

[0038] Furthermore, the method also includes:

[0039] Under the target entry combination, the number of matching masks configured in each of the included entries is adjusted sequentially;

[0040] If, during the process of the target network interface card (NIC) processing the data stream based on the target entry combination, fluctuations in performance metrics are detected due to changes in the number of matching masks in any entry, then it is determined that the abnormal risk of the target NIC under the target entry combination is related to the number of matching masks.

[0041] Furthermore, the method also includes:

[0042] If, during the process of the target network interface card (NIC) processing the data stream based on the target entry combination, it is detected that when the number of matching masks in the target entry is adjusted to within the target mask number range, the performance indicators no longer fluctuate, then the target mask number range corresponding to the target entry is output as a control suggestion parameter for the target NIC.

[0043] Furthermore, the method also includes:

[0044] After completing the test of the target entry combination, some entries are re-selected from the target flow table and offloaded to the target network card to obtain the next entry combination that is different from the target entry combination.

[0045] Continue to control the target network card to process the test data stream according to the next table entry combination, in order to determine whether the target network card has any abnormal risks under the next table entry combination.

[0046] This application embodiment also provides an anomaly detection method, applicable to a target network interface card deployed in any subnet of multiple subnets contained in a container network system, the method comprising:

[0047] In response to an anomaly detection command for the target network interface card (NIC), a target flow table that needs to be offloaded to the target NIC is determined, the target flow table containing entries.

[0048] Some entries in the target flow table are unloaded onto the target network card to obtain the target entry combination to be tested;

[0049] If an abnormal performance indicator is detected during the process of the target network interface card (NIC) processing the data flow occurring within the subnet based on the target entry combination, it is determined that the target NIC has an abnormal risk under the target entry combination.

[0050] This application also provides a computing device, including a memory, a processor, and a communication component;

[0051] The memory is used to store one or more computer instructions;

[0052] The processor is coupled to the memory and the communication component to execute one or more computer instructions for use in the aforementioned anomaly detection method.

[0053] This application also provides a computer-readable storage medium for storing a computer program, which, when executed by one or more processors, causes the one or more processors to perform the aforementioned anomaly detection method.

[0054] This application also provides a computer program product, including a computer program that, when executed by one or more processors, causes the one or more processors to perform the aforementioned anomaly detection method.

[0055] In the anomaly detection scheme provided in this application embodiment, when it is necessary to offload a target flow table to a target network interface card (NIC), a portion of entries can be selected from the target flow table and offloaded to the target NIC to obtain a target entry combination to be tested. Based on this, the performance indicators can be monitored for anomalies during the data flow processing of the target NIC based on the target entry combination, thereby discovering whether there is anomaly risk for the target NIC under the target entry combination. It is understood that in this application embodiment, during the anomaly detection process, not all entries from all flow tables that need to be offloaded to the target NIC are used by default. Instead, a selection of entries is selected to form an entry combination. By flexibly constructing entry combinations based on the target flow table, the target flow table can be transformed from a constant into a variable. Therefore, by testing the entry combination, it is possible to effectively analyze whether the flow table offloading is the cause of NIC anomalies. Accordingly, this application embodiment proposes a new perspective for anomaly cause analysis: flow tables offloaded to the NIC, and can specifically analyze whether NIC anomalies may be caused by flow table offloading, thereby effectively improving the accuracy of NIC anomaly detection. Attached Figure Description

[0056] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0057] Figure 1 A logical schematic diagram of an anomaly detection method provided for an exemplary embodiment of this application;

[0058] Figure 2 A flowchart illustrating an anomaly detection method provided for an exemplary embodiment of this application;

[0059] Figure 3 A schematic diagram of a flow table provided for an exemplary embodiment of this application;

[0060] Figures 4-5 A schematic diagram illustrating an application scenario provided for an exemplary embodiment of this application;

[0061] Figure 6 This is a schematic diagram of the structure of a computing device provided for another exemplary embodiment of this application. Detailed Implementation

[0062] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0063] Before proceeding with a detailed description of the technical solutions provided in the various embodiments of this application, the following is a brief explanation of several technical concepts involved in this application.

[0064] A flow table is a data structure used for looking up and forwarding data streams. Each flow table contains a series of entries that define the processing actions for the data stream, such as forwarding, encapsulation, or dropping.

[0065] Flow table offloading can be understood as a mechanism that offloads flow tables, which were originally managed and processed by the control plane in the software stack, to the network interface card (NIC). The NIC hardware can then perform network traffic processing based on the offloaded flow tables. Because the NIC hardware has dedicated processing units and an optimized architecture, it can process and forward data streams more quickly based on flow tables. Therefore, it can effectively reduce latency caused by control plane processing, while also freeing up CPU and other computing resources to focus on other more important tasks.

[0066] A data stream, which can be understood as a flow in network transmission, serves as the carrier for transmitting a set of data packets / data messages. Data streams are transmitted within a network via network interface cards (NICs). A data stream typically corresponds to a source and a destination; that is, two communicating ends can exchange data streams within the network through NICs.

[0067] During their research, the inventors discovered that current network interface card (NIC) anomaly detection typically focuses on analyzing which data streams are causing the anomaly. After locating the culprit, methods such as intercepting the data stream are usually employed to mitigate the anomaly. However, often these intercepted data streams are not inherently problematic. Therefore, this traditional anomaly detection approach does not accurately identify the cause of the anomaly, leading to the interception of many innocent data streams and ultimately impacting network performance in the network environment.

[0068] Therefore, this embodiment proposes a new perspective for anomaly cause analysis: flow tables offloaded to the network interface card (NIC). This perspective differs from the data flow perspective in traditional anomaly detection schemes; instead, it focuses on the flow tables offloaded to the NIC. This new perspective effectively improves the limitations of traditional anomaly detection schemes, thereby enhancing the accuracy of NIC anomaly detection.

[0069] The anomaly detection scheme provided in this embodiment proposes a design concept: analyzing whether flow tables offloaded to the network interface card (NIC) could be the cause of NIC anomalies. In other words, it analyzes whether flow tables offloaded to the NIC could potentially cause NIC anomalies.

[0070] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0071] Figure 1 This is a logical schematic diagram of an anomaly detection method provided for an exemplary embodiment of this application. Figure 2 This is a schematic flowchart illustrating an anomaly detection method provided for an exemplary embodiment of this application. (Reference) Figure 1 This method can be executed by an anomaly detection device, which can be implemented as software, hardware, or a combination of both, and can be integrated into a computing device. (Reference) Figure 2 The method may include:

[0072] Step 100: In response to the anomaly detection command for the target network interface card, determine the target flow table that needs to be offloaded to the target network interface card, the target flow table containing table entries;

[0073] Step 101: Unload some entries from the target flow table onto the target network card to obtain the target entry combination to be tested;

[0074] Step 102: If an abnormality is detected in the performance indicators during the process of the target network card processing the data stream based on the target table entry combination, it is determined that the target network card has an abnormal risk under the target table entry combination.

[0075] In this embodiment, the target network interface card (NIC) can be any type of NIC that supports flow table offloading. This embodiment does not limit the type of the target NIC or its other functional attributes. For example, the target NIC may also support remote direct memory access (RDMA) functionality. No further examples of functional attributes will be given here.

[0076] Furthermore, this embodiment does not limit the network scenario in which the target network interface card (NIC) is located. The anomaly detection method provided in this embodiment is applicable to any network scenario that requires flow table offloading using a NIC. For example, container network scenarios. A container network can be understood as a complex but ordered network architecture composed of containers in multiple subnets, orchestrated using container orchestration tools such as Kubernetes. In a container network scenario, network traffic processing functions can be offloaded from the host operating system to the NIC; that is, the flow tables corresponding to the network traffic processing functions can be offloaded to the NIC. Of course, this network scenario is exemplified, and this embodiment is not limited to it. For example, it can also be applied to traditional physical networks and other network scenarios. Further examples of network scenarios are not provided here.

[0077] In this embodiment, the target network interface card (NIC) can be any NIC in the network scenario. For ease of description, the target NIC will be used as an example to illustrate the anomaly detection method. It should be understood that other NICs in the network scenario can also be detected using the anomaly detection method provided in this embodiment.

[0078] refer to Figure 2 In step 100, it is proposed that, in response to an anomaly detection command for the target network interface card, the target flow table that needs to be offloaded to the target network interface card can be determined.

[0079] In this embodiment, the timing of initiating the anomaly detection command is not limited. Therefore, the anomaly detection method provided in this embodiment can support flexible detection timing to address detection needs at various times. Several exemplary detection timings are provided below:

[0080] 1. Before unloading the flow table to the network card, the anomaly detection method provided in this embodiment can be used to predict whether the unloading of the flow table may cause network card anomalies.

[0081] 2. If network performance problems are encountered after the flow table has been unloaded to the network card, the anomaly detection method provided in this embodiment can be used to analyze whether the network card anomaly may be caused by the unloading of the flow table.

[0082] 3. When network topology changes occur in a network scenario (e.g., subnets are added or removed, or communication terminals within a subnet are added or removed), the anomaly detection method provided in this embodiment can be used to predict whether an unloaded flow table may cause network card anomalies.

[0083] It should be understood that the above-described detection timings are merely exemplary, and this embodiment is not limited thereto. Accordingly, the anomaly detection instruction in step 100 can be initiated according to the desired detection timing. Further examples of the detection timings supported in this embodiment will not be provided here.

[0084] In step 100, the target flow tables to be offloaded to the target network interface card (NIC) can be one or more. Preferably, in step 100, all flow tables to be offloaded to the target NIC can be identified as target flow tables, including those already offloaded and those requiring additional offloading. Of course, this embodiment is not limited to this; the target flow tables can also be flow tables that need to be additionally offloaded to the target NIC, etc. In other words, the target flow tables identified in step 100 can be understood as flow tables that need to be tested using the anomaly detection method provided in this embodiment.

[0085] As described in the conceptual explanation section above, a target flow table contains entries. A single target flow table can contain one or more entries.

[0086] Continue to refer to Figure 2 In step 101, it is proposed to unload some entries from the target flow table onto the target network card to obtain the target entry combination to be tested.

[0087] Here, as mentioned above, the number of target flow tables can be one or more. Accordingly, in step 101, if there are multiple target flow tables, entries can be filtered in each of the multiple target flow tables. The entries filtered from the multiple target flow tables form a target entry combination. For example, if two target flow tables, flow table A and flow table B, are determined in step 100, then in step 101, entries can be filtered in flow table A and in flow table B. The entries filtered from flow table A and the entries filtered from flow table B form the target entry combination in this embodiment.

[0088] It should be understood that, in the design concept of this embodiment, step 101 aims to transform the target flow table from a constant to a variable in step 100. By transforming different combinations of entries from the target flow table, it is possible to attempt to discover whether the target flow table has an impact on network card anomalies. Thus, in this embodiment, multiple different combinations of entries can be constructed from the target flow table in step 101. The target entry combination can be any one of the multiple different combinations of entries constructed from the target flow table.

[0089] Based on this design concept, in step 101, there is no limit to the number of entries selected from the target flow table, nor is there a limit to which specific entries are selected to form the target entry combination. The goal is to ensure that the entry combination formed in each round is different.

[0090] refer to Figure 1In this embodiment, the anomaly detection device can offload a portion of the entries selected from the target flow table to the target network interface card (NIC). It is understood that in this embodiment, not all entries from all target flow tables in step 100 are automatically offloaded to the target NIC; instead, only the entries selected in step 101 are offloaded. That is, this embodiment employs a non-full offloading mechanism.

[0091] It's worth noting that in step 101, when unloading entries, the unloading is still performed using the flow table method. That is, in step 101, the target flow table, after deleting some entries, is unloaded onto the target network interface card. This echoes the technical concept mentioned above of transforming the target flow table from a constant to a variable. Since the entries retained in the target flow table differ each round, the target flow table unloaded onto the target network interface card becomes a variable.

[0092] Based on this, refer to Figure 2 Step 102 states that if anomalies are detected in performance metrics during the data stream processing process of the target network interface card (NIC) based on the target entry combination, it is determined that the target NIC has an anomaly risk under the target entry combination. In other words, it is determined that the anomaly of the target NIC may be caused by the target entry combination.

[0093] refer to Figure 1 It is understandable that after the table entry is unloaded in step 101, the target network card can perform data stream processing based on the target table entry combination. The data stream here can be autonomously constructed by the anomaly detection device in this embodiment, or it can directly use the actual network traffic in the network scenario where the target network card is located, which is not limited here.

[0094] The performance metrics here can be understood as indicators used to characterize the network transmission performance corresponding to the data stream processed by the target network interface card. The performance metrics in this embodiment may include, but are not limited to, data throughput and transmission latency, etc., which will not be further exemplified here.

[0095] One practical application scenario proposes that if, during the process of the target network interface card (NIC) processing data streams based on the target table entry combination, an abnormality is detected in the performance indicators corresponding to any data stream processed by the target NIC, then it is determined that the target NIC has an abnormal risk under the target table entry combination.

[0096] In addition, in this embodiment, after the test of the target entry combination is completed, some entries can be re-filtered from the target flow table and unloaded onto the target network card to obtain a next entry combination that is different from the target entry combination; and the target network card can continue to be controlled to process the test data flow according to the next entry combination to determine whether the target network card has any abnormal risks under the next entry combination.

[0097] This echoes the point mentioned above, where multiple different combinations of entries can be constructed from the target flow table in step 101. In this embodiment, the multiple different combinations of entries constructed from the target flow table can be tested separately to analyze whether the target network card has any abnormal risks in the various combinations of entries.

[0098] In a practical application scenario: if an abnormal risk is detected in any combination of entries assembled by the target network card in step 101, it can be determined that flow table unloading may be the cause of network card abnormality.

[0099] It is understood that the final detection conclusion provided in this embodiment may include at least whether flow table offloading could be a cause of network interface card (NIC) anomalies. Based on this, it can provide a valid reference for subsequent risk control, suggesting that the rationality of flow table offloading on the target NIC be fully considered during the risk control process, thereby enabling faster and more accurate development of risk control solutions.

[0100] In summary, in this embodiment, when it is necessary to offload the target flow table to the target network interface card (NIC), a portion of entries can be selected from the target flow table and offloaded to the target NIC to obtain the target entry combination to be tested. Based on this, during the process of the target NIC processing data flow based on the target entry combination, performance indicators can be monitored for anomalies, thereby identifying any potential anomalies in the target NIC under the target entry combination. It is understood that in this embodiment, during anomaly detection, not all entries from all flow tables that need to be offloaded to the target NIC are used by default. Instead, a selection of entries is selected to form an entry combination. By flexibly constructing entry combinations based on the target flow table, the target flow table can be transformed from a constant into a variable. Therefore, by testing the entry combination, it is possible to effectively analyze whether the flow table offloading is the cause of NIC anomalies. Accordingly, this embodiment proposes a new perspective for anomaly cause analysis: flow tables offloaded to the NIC, and can specifically analyze whether NIC anomalies may be caused by flow table offloading, thereby effectively improving the accuracy of NIC anomaly detection.

[0101] In the above or following embodiments, various implementation methods can be used to determine the target flow table that needs to be offloaded to the target network interface card. A preferred implementation proposes:

[0102] If there are multiple flow tables that need to be unloaded to the target network card, the cascading relationship between the entries contained in the multiple flow tables is identified to obtain multiple cascading paths;

[0103] If there is a target cascading path among the multiple cascading paths that does not meet the preset path constraints, then the entries contained in the target cascading path are deleted from multiple flow tables to obtain the target flow table that needs to be offloaded to the target network card.

[0104] During their research, the inventors discovered that entries typically contain matching rules and actions. The matching rules in an entry determine whether a data stream meets the processing conditions of that entry, while the actions define the specific processing method for the matched data stream. Common actions include, but are not limited to, forwarding, encapsulation, decapsulation, dropping, and modifying data stream attributes. From the network interface card's (NIC) perspective, if a data stream is identified as matching a rule in a certain entry, the data stream can be processed according to the action associated with that rule.

[0105] In this system, each forwarding action in a flow table can be viewed as a connection point. Through these forwarding actions, entries in different flow tables can be cascaded to form a cascaded path. When a data flow enters the network interface card (NIC) and successfully matches a flow table entry, the forwarding action in that entry is executed. This forwarding action may cause the data flow to enter the matching process of the next flow table entry, and so on, as if multiple flow tables are linked into a path through forwarding actions. Based on the cascaded path, the processing of data flow in the NIC can form a pipeline-like operation. From the moment the data flow enters the NIC, it flows sequentially between different flow tables according to the preset forwarding actions in the entries. Each flow table performs corresponding processing on the data flow until the data flow finally leaves the NIC and is delivered to the required communication endpoint.

[0106] Based on this, the preferred implementation proposes that, according to the network transmission requirements in the network scenario, the cascading paths that need to be offloaded to the target network card can be pruned, and invalid cascading paths that do not meet the network transmission requirements can be filtered out.

[0107] In this preferred implementation, network transmission requirements in different network scenarios can be adapted by reasonably designing path constraints. It is understood that network transmission requirements vary greatly across different network scenarios; therefore, the specific content of the path constraints is not limited here. In practical applications, path constraints can be flexibly set according to the corresponding network transmission requirements in the network scenario.

[0108] One exemplary design proposes that path constraints be designed to indicate a valid transmission destination. Such path constraints are typically suited to network transmission requirements in network scenarios such as "ensuring correct end-to-end transmission of data streams." Therefore, the path constraints stipulate that the cascaded path must guide the data stream to a valid transmission destination; that is, the cascaded path must ensure that the data stream is correctly delivered to the destination communication end, achieving end-to-end transmission. It should be understood that the path constraints here are merely exemplary, and this embodiment is not limited to them; further examples will not be provided here.

[0109] Figure 3This is a schematic diagram of a flow table provided for an exemplary embodiment of this application. (Reference) Figure 3 There are three flow tables that need to be offloaded to the target network interface: flow table Matching table (T1), flow table Matching table (T2), and flow table Matchingtable (T3). Figure 3 The encapsulation context table shown is an encapsulation context, which can be understood as configuring encapsulation actions independently in a table. This table is not a flow table, but it is used in conjunction with the three flow tables mentioned above. Figure 3 The document also shows three exemplary quantity flows: A, B, and C.

[0110] like Figure 3 As shown, for data flow B, a matching loop occurs between flow table (T1) and flow table (T3). That is, the concatenated path corresponding to data flow B is: [Protocol = IPv6; Action: Forward to T3] - [Protocol = IPv6; Action: Forward to T1]. This path cannot indicate a valid destination for data flow B, therefore, it is invalid. For data flow C, the matched concatenated path is: [Source address = VXLAN; Action: Context 5, Forward to T2] - [Destination address: 172.16.122.0 / 24; Action: Drop] & [Source and destination addresses without tunnel settings]. Data flow C will be dropped, and a valid destination cannot be indicated for it; therefore, this concatenated path is also invalid. It is understandable that both of these invalid concatenated paths violate the topology constraints (end-to-end transmission) in the network scenario. Figure 3 The actions described in the diagram, such as "Context 4" and "Context 5", are related to context and can be understood as jumping to the corresponding context in the encapsulation context table to perform encapsulation actions on the data stream according to the context in the encapsulation context table. No further explanation will be given here.

[0111] For data flow A, the corresponding concatenation path is: [Source address = 172.16.122.0, 24; Action: Forward to T2] - [Destination address: 172.16.206.0, 24; Action: Context 4, Forward to VXLAN] & [Tunnel address encapsulated as source address = 10.1.1, destination address = 10.1.1.2]. This matched concatenation path encapsulates data flow A and forwards it to the VXLAN tunnel interface (i.e., the underlying network of other subnets) according to the encapsulated tunnel address. Therefore, this concatenation path indicates a valid transmission destination and is a valid concatenation path. VXLAN (Virtual eXtensible Local Area Network) is a network virtualization technology that improves the scalability of large-scale cloud computing deployments and is an extension of VLANs. VXLAN is a tunneling technology that can establish Layer 2 Ethernet network tunnels on top of Layer 3 networks, thereby achieving Layer 2 interconnection across regions.

[0112] As can be seen, not all cascading paths can correctly deliver data streams to the desired destination when multiple flow tables need to be offloaded to the target network card. Figure 3 The cascading paths matching data streams B and C cannot meet this requirement. Therefore, the anomaly detection device in this embodiment can identify invalid cascading paths in the flow table and... Figure 3 These invalid cascading paths are deleted from the flow table shown.

[0113] In this preferred implementation, by pruning cascaded paths based on preset path constraints, invalid cascaded paths in the flow table can be effectively filtered out, so that the target flow table determined for the target network card in step 100 retains valid cascaded paths.

[0114] Based on this, in step 101 of this embodiment, a target entry combination can be constructed from the target flow table after invalid cascading paths have been filtered out. This reduces the solution space in this embodiment from the source, that is, it reduces the number of entries that need to be tested from the source, thereby improving the anomaly detection efficiency in this embodiment.

[0115] In summary, this embodiment provides an implementation method for determining the target flow table. Accordingly, on the one hand, it can promptly detect design flaws in the flow table entries that need to be offloaded to the target network interface card (NIC), preventing these design flaws from being introduced into the target NIC and thus avoiding NIC anomalies caused by them; on the other hand, after eliminating the factor of design flaws in the flow table entries themselves, the anomaly detection method provided in this embodiment can focus more on analyzing whether the retained valid cascading paths might cause NIC anomalies.

[0116] It is worth noting that the above implementation method is merely exemplary. Other implementation methods can also be used in this embodiment to determine the target flow table that needs to be offloaded to the target network card. For example, without pruning, the complete flow table mentioned above that needs to be offloaded to the target network card can be determined as the target flow table. This method does not affect the solution of the aforementioned technical problem in this embodiment, but it can indicate in the detection conclusion that the abnormal risk of the target network card under the target flow table combination may be due to a design defect in the flow table itself.

[0117] In the above or following embodiments, various implementation methods can be used to determine which entries are selected from the target flow table to form the target entry combination. One alternative implementation proposes:

[0118] It is possible to filter some cascading paths from those existing in the target flow table;

[0119] The entries contained in the selected cascading paths are unloaded onto the target network interface card to obtain the target entry combination.

[0120] In this optional implementation, the cascading path is used as the filtering unit to filter entries in the target flow table. This filtering method allows for closer relationships between the filtered entries. Since all filtered entries are located within the cascading path, they can be tested without difficulty, thus effectively analyzing whether an entry might cause network interface card (NIC) anomalies when it is used (i.e., located within the cascading path).

[0121] In this optional implementation, the number of cascading paths contained in the target entry combination is not limited, and non-full testing is sufficient.

[0122] A further proposed optimal screening scheme is as follows:

[0123] The required concurrent data stream N to be supported by the target network interface card can be calculated, where N is a positive integer;

[0124] From the cascading paths existing in the target flow table, select N cascading paths, where the communication endpoints matched in the N cascading paths are different.

[0125] In this optimal selection scheme, the size of the selected cascading paths is set to match the data flow concurrency required by the target network interface card (NIC). Data flow concurrency can be understood as the maximum network traffic that the target NIC needs to process per unit time. Referring to the previous concept explanation section, the two ends of a data flow are communication ends, and the NIC can bridge between these communication ends to support the transmission of data flows. Therefore, the data flow concurrency required by the target NIC is related to the number of communication ends that the target NIC needs to bridge. Data flow concurrency can be equal to the number of communication ends that need to be bridged through the target NIC; the source and destination ends of the data flow constitute a pair of communication ends.

[0126] The preferred filtering scheme also mentions that the communication terminals matched in the N cascading paths selected from the target flow table are different. This ensures that the N cascading paths selected in this preferred filtering scheme can cover all communication terminals required for bridging by the target network card, i.e., N pairs of communication terminals. Thus, the anomaly detection scheme provided in this embodiment allows the target network card to continue working normally in the network scenario. Offloading the entries contained in the N selected cascading paths to the target network card ensures that any data flow occurring on the target network card can be matched to a cascading path without obstacles, thereby ensuring that the target network card can process any actual data flow without obstruction. Therefore, the "entry filtering" in this embodiment will not affect the normal operation of the target network card.

[0127] An exemplary calculation scheme for calculating data flow concurrency may be: determining the number of subnets in the network scenario where the target network interface card (NIC) is located; determining the number of communication terminals corresponding to each subnet; and estimating the number of communication terminals that the target NIC needs to bridge based on the number of communication terminals and the number of subnets, as the data flow concurrency. Of course, this embodiment is not limited to this exemplary calculation scheme; other calculation schemes can also be used to estimate the data flow concurrency for the target NIC. For example, the cascading paths in the target flow table can be grouped according to the matched communication terminals, and the number of groups obtained can be used as the data flow concurrency, etc. Further examples of calculation schemes corresponding to data flow concurrency will not be provided here.

[0128] This exemplary calculation scheme proposes to estimate the number of communication endpoints that the target network interface card (NIC) needs to bridge, based on the number of communication endpoints and the number of subnets, as the data flow concurrency. This can effectively estimate the number of cross-subnet end-to-end data flows that the target NIC needs to process.

[0129] In this exemplary calculation scheme, the number of communication endpoints required to be bridged by the target network interface card can be estimated according to the following expression:

[0130] N = k * n 2 .

[0131] Where N is the number of communication terminals that the target network card needs to bridge, which can be used as the data concurrency that the target network card needs to support; k is the number of subnets in the network scenario where the target network card is located; and n is the average data of the communication terminals contained in the k subnets.

[0132] As can be seen, based on this expression, in this exemplary calculation scheme, the average number of communication terminals in the subnet is used to represent the corresponding number of communication terminals in the subnet. By calculating the square of this average number and the product between the square and the number of subnets, the data flow concurrency N can be obtained.

[0133] Based on this, in the preferred filtering scheme provided in this embodiment, k*n can be filtered from the target flow table. 2 There are several cascading paths, each matching a different communication endpoint (specifically, a pair of communication endpoints). The anomaly detection device can offload the entries contained in these cascading paths to the target network interface card (NIC) to obtain a target entry combination. This allows the target entry combination to support extreme data flow concurrency on the target NIC—simultaneous data flow between all communication endpoints bridged by the target NIC—ensuring that any data flow occurring on the target NIC can be matched to a cascading path.

[0134] Considering that different cascading paths may not necessarily pass through all target flow tables, from the perspective of a single target flow table, the size of the entries in a single target flow table may reach k*n. 2 Of course, the number of entries may be less than the size of the table entry. Therefore, the size of entries within a single target flow table is not limited here, but is determined based on the selected k*n entries. 2 Once the actual table entry distribution of each cascading path is determined, that's sufficient.

[0135] In summary, this embodiment provides an optional implementation method for determining which entries to select from the target flow table to form the target entry combination, using cascading paths as the selection unit, and further proposes a method for selecting k*n entries. 2 The cascading paths are offloaded to the target network interface card (NIC) to obtain the target entry combination, which reduces the solution space in this embodiment to a reasonable size. This minimizes the solution space in this embodiment while ensuring that all possible data flows on the target NIC can be matched with the cascading path, thereby improving the detection efficiency of the constructed entry combinations.

[0136] It is worth noting that other implementation methods can also be used in this embodiment to determine which entries to select from the target flow table to form the target entry combination. For example, cascading relationships can be ignored, and entries can be selected independently in different target flow tables. Another example is that other numbers of cascading paths can be selected from the target flow table. Further examples of implementation methods are not provided here. It is understood that different implementation methods do not affect the solution of the aforementioned technical problem in this embodiment—analyzing whether the target network card has any abnormal risks under the target entry combination. However, due to the different solution space scales and the different discreteness of entries in the target entry combination caused by different implementation methods, the detection efficiency may differ in this embodiment.

[0137] In the above or below embodiments, it is also proposed that if it is determined that the target network card has an abnormal risk under the target entry combination, the reasons for the abnormal risk of the target network card under the target entry combination can be further analyzed.

[0138] Therefore, this embodiment proposes to adjust the configuration parameters under different causal dimensions during the data flow processing of the target network card based on the target table entry combination, in order to analyze what causes the target network card to have abnormal risks under the target table entry combination.

[0139] This embodiment proposes an exemplary cause dimension: request queue. Under this cause dimension, a configuration parameter is proposed: the number of request queues.

[0140] The request queue is a component of the network interface card (NIC), a data structure used to store and manage data streams. Its working principle is roughly as follows: when the NIC receives a data stream, it first places the data stream into the receive request queue, waiting for the NIC to process and receive it in a certain order. Similarly, when the NIC needs to send a data stream, the data stream first enters the send request queue, waiting for the NIC to process and send it in a certain order. In a NIC, the receive request queue and the send request queue usually exist in pairs, and can be referred to as queue pairs. Furthermore, the number of receive request queues and send request queues in a NIC can be one or more.

[0141] Based on this, and for this exemplary cause dimension, this embodiment proposes:

[0142] Under the target entry combination, adjust the number of request queues in the target network interface card (NIC). If, during the process of the target NIC processing data streams based on the target entry combination, performance metrics are observed to fluctuate due to changes in the number of request queues, then it is determined that the abnormal risk of the target NIC under the target entry combination is related to the number of request queues.

[0143] In practical applications, configuration parameters under other factors can be kept unchanged, while adjusting the number of request queues in the target network interface card (NIC) to more specifically detect whether performance metrics fluctuate due to changes in the number of request queues. If performance metric fluctuations are detected, it indicates that the request queue number configuration is unreasonable, which may be the cause of abnormal risks for the target NIC under the target entry combination. Therefore, it can be determined that the abnormal risks of the target NIC under the target entry combination are related to the number of request queues. This provides an important reference for subsequent risk control, prompting a focus on whether the number of request queues is reasonable during the risk control process.

[0144] Furthermore, if no performance fluctuations are detected during the data stream processing by the target network interface card (NIC) based on the target entry combination, it can be determined that the abnormal risk of the target NIC under the target entry combination is unrelated to the number of request queues. This still provides an important reference for subsequent risk control, where the number of request queues on the target NIC does not need to be considered.

[0145] Furthermore, regarding this exemplary cause dimension, this embodiment also proposes:

[0146] If, during the process of processing data streams based on target table entries by the target network interface card (NIC), it is detected that the performance metrics no longer fluctuate when the number of request queues is adjusted to within the target queue number range, then the target queue number range will be output as a suggested parameter for adjustment of the target NIC.

[0147] In an exemplary interval search scheme: the adjustment step size can be gradually reduced. First, a larger adjustment step size is used to locate the interval of candidate queue numbers, and then a smaller adjustment step size is used to gradually reduce the interval of candidate queue numbers until the target queue number interval where the performance index no longer fluctuates is found.

[0148] For example, you can first use an adjustment step size of 10 to find a candidate queue size range. If, during testing, you find that the performance metrics are consistent when the number of request queues is 100 and 90, then [100, 90] can be identified as the candidate queue size range. Then, you can reduce the adjustment step size to 2 to continue searching within this candidate queue size range. If, during testing, you find that the performance metrics are consistent when the number of request queues is 100 and 95, then [100, 95] can be identified as the target queue size range. Of course, the search ends when the adjustment step size reaches a preset threshold (i.e., 2), but it can also end under other conditions. For example, the consistency between the performance metrics caused by two adjacent request queue sizes must meet a preset standard, such as being completely equal. There is no restriction on when to end the search here.

[0149] In this way, by outputting the target flow table quantity range, a more detailed reference can be provided for subsequent risk control procedures. It can be suggested that during the risk control process, the number of request queues on the target network card can be adjusted to the target queue quantity range in order to try to resolve the anomaly of the target network card.

[0150] This embodiment also proposes another exemplary cause dimension: flow table size. Under this cause dimension, a configuration parameter is proposed: the number of flow tables.

[0151] Regarding this exemplary cause dimension, this embodiment proposes:

[0152] Under the target entry combination, the target flow tables are merged or split to adjust the number of flow tables offloaded to the target network interface card;

[0153] If, during the process of processing data streams based on target table entries, performance metrics are observed to fluctuate due to changes in the number of flow tables, then the anomaly risk of the target network interface card under the target table entry combination is determined to be related to the number of flow tables.

[0154] Merging or splitting the target flow tables that are offloaded to the target network interface card can be understood as keeping the selected entries in the target flow tables unchanged, splitting some target flow tables, or merging some target flow tables to adjust the number of flow tables offloaded to the target network interface card.

[0155] In practical applications, configuration parameters under other factors can be kept unchanged, while adjusting the number of flow tables offloaded to the target network interface card (NIC) to more specifically detect whether performance metrics fluctuate due to changes in the number of flow tables. If performance metric fluctuations are detected, it indicates that the flow table configuration is unreasonable, which may be the cause of abnormal risks for the target NIC under the target table entry combination. Therefore, it can be determined that the abnormal risks of the target NIC under the target table entry combination are related to the number of flow tables. This provides an important reference for subsequent risk control, prompting a focus on whether the number of flow tables is reasonable during the risk control process.

[0156] Furthermore, if no performance fluctuations are detected during the processing of data streams based on the target NIC's entry combinations, it can be determined that the abnormal risk of the target NIC under the target entry combinations is unrelated to the number of flow tables. This still provides an important reference for subsequent risk control, where the number of flow tables on the target NIC does not need to be considered.

[0157] Furthermore, regarding this exemplary cause dimension, this embodiment also proposes:

[0158] If, during the process of the target network interface card (NIC) processing data streams based on the target table entries, it is detected that the performance indicators no longer fluctuate when the number of flow tables is adjusted to within the target flow table number range, then the target flow table number range will be output as a suggested parameter for adjustment of the target NIC.

[0159] In an exemplary interval lookup scheme: the adjustment step size can be gradually reduced. First, a larger adjustment step size is used to locate the interval of candidate flow table quantity, and then a smaller adjustment step size is used to gradually reduce the interval of candidate flow table quantity until the target flow table quantity interval where the performance index no longer fluctuates is found.

[0160] In this way, by outputting the target flow table quantity range, a more detailed reference can be provided for subsequent risk control procedures. It can be suggested that during the risk control process, the flow table quantity on the target network card can be adjusted to the target flow table quantity range in order to try to resolve the anomaly of the target network card.

[0161] This embodiment also proposes another exemplary cause dimension: the size of the matching mask. Under this cause dimension, a configuration parameter is proposed: the number of matching masks.

[0162] Regarding this exemplary cause dimension, this embodiment proposes:

[0163] Under the target table entry combination, the number of matching masks configured in each of the included entries is adjusted sequentially;

[0164] If, during the process of the target network interface card (NIC) processing the data stream based on the target table entry combination, performance metrics are detected to fluctuate due to changes in the number of matching masks in any table entry, then the abnormal risk of the target NIC is determined to be related to the number of matching masks.

[0165] As mentioned earlier, a table entry can contain matching rules and actions, and the match mask is the tool used to implement the matching rules. The network interface card (NIC) can flexibly match multiple fields in the data stream based on the match mask configured in the table entry. Fields in the data stream can include, but are not limited to, MAC addresses, IP addresses, and port numbers. Match masks can be configured for some or all fields in the table entry, and different fields can be configured independently. This allows for various complex traffic scheduling and management strategies, such as forwarding data streams based on different VLAN IDs, source IP address ranges, or destination port number ranges.

[0166] In practical applications, configuration parameters under other cause dimensions can be kept unchanged, and the number of matching masks configured in each entry within the target entry combination can be adjusted sequentially to more specifically detect whether performance metrics fluctuate due to changes in the number of matching masks in the entries. If performance metric fluctuations are detected, it indicates that the number of matching masks configured in some entries is unreasonable, which may be the cause of abnormal risks for the target network interface card (NIC) under the target entry combination. Therefore, it can be determined that the abnormal risks of the target NIC under the target entry combination are related to the number of matching masks. This provides an important reference for subsequent risk control, prompting a focus on whether the number of matching masks in the entries is reasonable during the risk control process.

[0167] Furthermore, if no performance fluctuations are detected during the target network interface card's (NIC) data stream processing based on the target entry combination, it can be determined that the anomaly risk of the target NIC under the target entry combination is unrelated to the number of matching masks in the entry. This still provides an important reference for subsequent risk control, where the number of matching masks in the entry does not need to be considered.

[0168] Furthermore, regarding this exemplary cause dimension, this embodiment also proposes:

[0169] If, during the process of the target network interface card (NIC) processing the data stream based on the target entry combination, it is detected that the performance indicators no longer fluctuate when the number of matching masks in the target entry is adjusted to within the target mask number range, then the target mask number range corresponding to the target entry will be output as a control suggestion parameter for the target NIC.

[0170] If a performance metric is detected to fluctuate due to a change in the number of matching masks in any entry, that entry can be used as the target entry, and the range of target mask counts can be further searched for the target entry.

[0171] In an exemplary range lookup scheme: for a target entry, the adjustment step size can be gradually reduced. First, a larger adjustment step size is used to locate the range of candidate mask numbers, and then a smaller adjustment step size is used to gradually reduce the range of candidate mask numbers until the target mask number range where the performance index no longer fluctuates is found.

[0172] In this way, by outputting the range of target mask numbers for the target entries, a more detailed reference can be provided for subsequent risk control procedures. This can suggest that during the risk control process, the number of matching masks configured in the target entries that can be offloaded to the target network card should be adjusted to the target mask number range in order to attempt to resolve the anomalies of the target network card.

[0173] In summary, this embodiment proposes several exemplary causal dimensions and monitors the performance fluctuations of the target network interface card (NIC) under different causal dimensions and target entry combinations by adjusting configuration parameters under different causal dimensions. This allows for analysis of which causal dimension is associated with the anomaly risk of the target NIC under the target entry combinations. Furthermore, it can further test suggested ranges for mitigating NIC anomalies under different causal dimensions and corresponding configuration parameters, and output these as suggested control parameters for the target NIC. This provides a more refined reference for subsequent risk control, offering more accurate prompts and improving the efficiency of anomaly resolution in the risk control process.

[0174] It is worth emphasizing that the above-mentioned exemplary cause dimensions are designed independently in this embodiment. However, the cause dimensions in this embodiment are not limited to these. This embodiment supports the introduction of more cause dimensions to analyze in a more multidimensional way what causes the target network card to have abnormal risks under the target entry combination.

[0175] Figures 4-5 This is a schematic diagram illustrating an application scenario provided for an exemplary embodiment of this application. (Reference) Figure 4 The target network interface card (NIC) is located in a container network, which contains multiple subnets. The target NIC resides within one of these subnets. Each subnet contains multiple containers, which act as communication endpoints. The network transmission requirement for this container network is to support pairwise communication between containers within the network. Figure 5 A schematic diagram of the internal structure of the target network interface card (NIC) is shown. In this application scenario, the target NIC is a NIC that supports RDMA functionality, hereinafter referred to as RNIC.

[0176] In this embodiment, two components are abstracted from the internal structure of the target network interface card: queue pairs and virtual switches (eSwitch). These are the components of interest in this embodiment.

[0177] In this application scenario, we primarily focus on the RNIC's data path (i.e., the pipeline for processing data streams), as this is most relevant to data processing performance. Specifically, each container can bind to one or more Virtual Devices (VFs) of the RNIC. Containers can use the RDMA verb to request RNIC resources and can transmit data streams via the high-performance RDMA protocol. When the data stream sent by the container is received by the RNIC through the VF, the data stream will be queued in a container queue (i.e.,...). Figure 5 The data (either the receive request queues RX Queues or the send request queues TX Queues shown in the diagram) is then distributed to the eSwitch component of the RNIC. The eSwitch component consists of multiple flow tables used to match the data flow and then apply recorded actions to it. These flow tables are offloaded from the control plane of the software stack.

[0178] After abstracting the components of the RNIC, we propose possible architectural models for further inference of the RNIC. Specifically, we need to search all entry configurations within the container network. If we have this information, we can further infer the more detailed impact of the (abstracted) components and entry configurations of the RNIC on performance. However, this process faces the problem of composability explosion between components and entry configurations. Modern RNICs are programmable network interface cards (NICs) capable of offloading large numbers of flow tables and data flows. Even for the offloading of a single flow table, an RNIC can have hundreds of entries, each with multiple matching rules and actions. The number of matching masks supported in each flow table is also large; for example, the matching mask in a single entry in some flow tables can be 192 bits long, covering different protocols, sources, and destinations, from MAC layer to transport layer fields. Moreover, the matching mask for different fields in each entry can be configured independently. Furthermore, flow tables can be linked through forwarding actions in each entry to form a more flexible packet processing pipeline, i.e., cascaded paths, in the data path. This makes the RNIC component structure and the interaction in the RCN packet processing process more complex. Putting all possible combinations together, the solution space for combinations is very large, i.e., O(m*p) possible matchers, where m is the number of flow tables and p is the average number of entries. It should be noted that in container networks, the actual values ​​of m and p can reach 100 or even larger.

[0179] This embodiment does not use such a large-scale solution space, but instead reduces the solution space.

[0180] According to the above... Figure 3 As an example, we also propose filtering out cascading paths that do not meet preset path constraints, thereby retaining only the entries contained in valid cascading paths.

[0181] In addition, we propose that besides performing a certain degree of deduction on the RNIC structure to set constraints and simplify the solution space, we can further reduce the solution space through some prior knowledge. For example, if it is determined that the current application scenario uses VXLAN network virtualization technology, then there is no need to search other flow tables related to network virtualization technologies (such as NAT flow tables). That is, flow tables that are irrelevant to the actual application scenario can be directly filtered out, which can avoid the increase in solution space caused by these irrelevant flow tables.

[0182] Because we have filtered out invalid cascading paths, we can effectively reduce our solution space. Furthermore, we avoid testing configurations that we know will cause performance issues, to prevent missing workloads that reveal the root cause of performance problems.

[0183] Ultimately, we only need to test the combination of eSwitch and queue pairs to ensure correct end-to-end data streaming between containers. To cover the various data flows that may occur in RNIC, we also propose designing the solution space to O(k*n). 2 The size of the container network is k*n, where k is the number of subnets in the container network, n is the average number of containers in each subnet, and k*n is the average number of containers in each subnet. 2 This represents the number of cascading paths selected from the flow table to be unloaded. The solution space determined by this is much smaller than the O(m*p) mentioned earlier, which effectively reduces the solution space we need to test.

[0184] Preliminary testing. Based on the solution space defined above, we can construct multiple entry combinations from the flow tables that need to be unloaded to the RNIC, and the cascading paths in each entry combination can cover all containers that the RNIC needs to bridge. This allows us to search for entry combinations that may cause RNIC anomalies.

[0185] Therefore, to address potential performance anomalies caused by flow table unloading, directly brute-forcing searches for anomalies and their causes would require traversing a large solution space, rendering it unusable in actual production. To solve this problem, we analyzed the RNIC execution flow and proposed path constraints, which significantly reduce the solution space.

[0186] Local Analysis. Once the initial testing process reveals network interface card (NIC) anomalies, we can continue with local analysis of the table entries causing the anomalies to identify the causal relationship between the cause dimension and the performance issue. We can gradually change the configuration parameters under different cause dimensions and test the performance changes. The cause dimensions we test may include, but are not limited to: the number of request queues, the size of the flow table, and the size of the match mask. If the performance problem is alleviated or exacerbated after adjusting the configuration parameters under a certain cause dimension (e.g., increasing or decreasing the number of request queues or flow tables), we can infer that the relevant cause dimension is related to the performance problem.

[0187] In this application scenario, testing revealed that RNIC performance degraded on certain traffic types as the number of flow tables increased. Furthermore, testing also showed that RNIC performance changed when the number of match masks configured in a particular flow table entry changed.

[0188] Taking matching masks as an example, specifically, the RNIC can determine the entries that match the data stream based on the matching mask, thereby determining how to process the data stream. Multiple matching masks can be configured in a single entry, each corresponding to a different field. In this application scenario, it was observed that when the number of matching masks configured in a certain entry offloaded to the RNIC increases, new data streams in the RNIC will be matched with the newly added matching masks, resulting in a decrease in data stream processing performance. Therefore, we can infer that the matching masks in the flow table may be located in the critical path of RNIC packet processing, i.e., related to RNIC anomalies.

[0189] Therefore, in this application scenario, the number of flow tables and the number of matching masks can be determined as the reasons why RNIC exhibits anomalies under this combination of entries.

[0190] In this application scenario, we can continue to try to find the range of target flow table quantity and target mask quantity under this combination of entries, and output them as control suggestion parameters.

[0191] In summary, in this application scenario, the anomaly detection scheme provided in this embodiment can detect:

[0192] 1. Is it possible for performance issues to occur after flow tables are offloaded to RNIC?

[0193] 2. If it causes performance issues, it can further pinpoint the cause of the performance problems after the flow table is unloaded to RNIC.

[0194] 3. Furthermore, based on the identified causes, it can provide suggested ranges for the corresponding configuration parameters, thereby providing more refined guidance for subsequent risk control procedures.

[0195] It should be noted that some processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 101, 102, etc., are merely used to distinguish different operations and do not represent any execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel.

[0196] Figure 6 This is a schematic diagram of the structure of a computing device provided for another exemplary embodiment of this application. For example... Figure 6 As shown, the computing device includes: a memory 60, a processor 61, and a communication component 62.

[0197] Processor 61, coupled to memory 60, is used to execute computer programs in memory 60 for:

[0198] In response to an anomaly detection command for the target network interface card (NIC), a target flow table that needs to be offloaded to the target NIC is determined, the target flow table containing entries.

[0199] Some entries in the target flow table are unloaded onto the target network card to obtain the target entry combination to be tested;

[0200] If an abnormal performance metric is detected during the processing of a data stream by the target network interface card (NIC) based on the target entry combination, it is determined that the target NIC has an abnormal risk under the target entry combination.

[0201] In an optional embodiment, when the processor 61 determines that a target flow table needs to be offloaded to the target network interface card, it may specifically be used to:

[0202] If there are multiple flow tables that need to be unloaded to the target network card, the cascading relationship between the entries contained in the multiple flow tables is identified to obtain multiple cascading paths;

[0203] If any of the multiple cascaded paths does not meet the preset path constraints, then the entries contained in the target cascaded path are deleted from the multiple flow tables to obtain the target flow table that needs to be offloaded to the target network card.

[0204] In an alternative embodiment, processor 61 may also be used for:

[0205] For any cascaded path, if a valid transmission destination cannot be indicated on the cascaded path, then the cascaded path is determined to not meet the preset path constraint conditions.

[0206] In an optional embodiment, when the processor 61 unloads some entries from the target flow table onto the target network interface card to obtain the target entry combination to be tested, it may specifically be used to:

[0207] Select a subset of cascading paths from those existing in the target flow table;

[0208] The entries contained in the selected cascading paths are unloaded onto the target network interface card to obtain the target entry combination.

[0209] In an optional embodiment, when the processor 61 filters a portion of the cascading paths from those existing in the target flow table, it may specifically be used to:

[0210] Calculate the required concurrent data stream N to be supported by the target network interface card, where N is a positive integer;

[0211] From the cascading paths existing in the target flow table, N cascading paths are selected, and the communication terminals matched in the N cascading paths are different.

[0212] In an optional embodiment, when calculating the required concurrent data flow N to be supported in the target network interface card, the processor 61 may specifically be used to:

[0213] Determine the number of subnets existing in the network scenario where the target network interface card is located;

[0214] Determine the number of corresponding communication terminals in the subnet;

[0215] Based on the number of communication terminals and the number of subnets, the estimated number of communication terminals that the target network card needs to bridge is used as the data flow concurrency N.

[0216] In an optional embodiment, when the processor 61 estimates the number of cross-subnet end-to-end data streams required to be supported in the subnet where the target network interface card is located, based on the number of communication terminals and the number of subnets, and uses this estimate as the data stream concurrency N, it can be specifically used for:

[0217] If the number of communication terminals is taken as the average number of communication terminals in the subnet, then the square of the average number is calculated.

[0218] Calculate the product between the squared value and the number of subnets, and use it as the data stream concurrency N.

[0219] In an alternative embodiment, processor 61 may also be used for:

[0220] Under the target entry combination, adjust the number of request queues in the target network interface card;

[0221] If, during the process of the target network interface card (NIC) processing the data stream based on the target entry combination, fluctuations in performance metrics are detected due to changes in the number of request queues, then it is determined that the abnormal risk of the target NIC under the target entry combination is related to the number of request queues.

[0222] In an alternative embodiment, processor 61 may also be used for:

[0223] If, during the process of the target network interface card (NIC) processing the data stream based on the target table entry combination, it is detected that the performance indicators no longer fluctuate when the number of request queues is adjusted to within the target queue number range, then the target queue number range is output as a control suggestion parameter for the target NIC.

[0224] In an alternative embodiment, processor 61 may also be used for:

[0225] Under the target entry combination, the target flow tables offloaded to the target network interface card are merged or split to adjust the number of flow tables offloaded to the target network interface card;

[0226] If, during the process of the target network interface card (NIC) processing the data stream based on the target entry combination, fluctuations in performance metrics are detected due to changes in the number of flow tables, then it is determined that the abnormal risk of the target NIC under the target entry combination is related to the number of flow tables.

[0227] In an alternative embodiment, processor 61 may also be used for:

[0228] If, during the process of the target network interface card (NIC) processing the data stream based on the target table entry combination, it is detected that the performance indicators no longer fluctuate when the number of flow tables is adjusted to within the target flow table number range, then the target flow table number range will be output as a control suggestion parameter for the target NIC.

[0229] In an alternative embodiment, processor 61 may also be used for:

[0230] Under the target entry combination, the number of matching masks configured in each of the included entries is adjusted sequentially;

[0231] If, during the process of the target network interface card (NIC) processing the data stream based on the target entry combination, fluctuations in performance metrics are detected due to changes in the number of matching masks in any entry, then it is determined that the abnormal risk of the target NIC under the target entry combination is related to the number of matching masks.

[0232] In an alternative embodiment, processor 61 may also be used for:

[0233] If, during the process of the target network interface card (NIC) processing the data stream based on the target entry combination, it is detected that when the number of matching masks in the target entry is adjusted to within the target mask number range, the performance indicators no longer fluctuate, then the target mask number range corresponding to the target entry is output as a control suggestion parameter for the target NIC.

[0234] In an alternative embodiment, processor 61 may also be used for:

[0235] After completing the test of the target entry combination, some entries are re-selected from the target flow table and offloaded to the target network card to obtain the next entry combination that is different from the target entry combination.

[0236] Continue to control the target network card to process the test data stream according to the next table entry combination, in order to determine whether the target network card has any abnormal risks under the next table entry combination.

[0237] Furthermore, such as Figure 6 As shown, the computing device also includes other components such as a power supply component 63. Figure 6 The diagram only shows some components and does not mean that the computing device includes only these components. Figure 6The components shown.

[0238] It is worth noting that the technical details of the above embodiments of the computing device can be referred to the relevant descriptions in the foregoing method embodiments. To save space, they will not be repeated here, but this should not cause any loss to the scope of protection of this application.

[0239] The above Figure 6 The memory in the memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0240] The above Figure 6 The communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.

[0241] The above Figure 6 The display in the document includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen can be implemented as a touchscreen to receive input signals from a user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors can sense not only the boundaries of the touch or swipe action but also the duration and pressure associated with the touch or swipe operation.

[0242] The above Figure 6 The power supply component provides power to the various components of the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which it resides.

[0243] The above Figure 6 The audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0244] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above-described method embodiments. The computer-readable storage medium includes volatile or non-volatile components, or a combination thereof, and can be removable or non-removable. Examples of computer-readable storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium.

[0245] Accordingly, this application also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, cause the processor to implement the steps in the above method embodiments. It should be understood that each step or combination of steps in the above method flow can be implemented by the computer program or instructions. Furthermore, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, enabling the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to function as an apparatus for implementing the corresponding functions in the above method embodiments.

[0246] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0247] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0248] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. An anomaly detection method, characterized in that, include: In response to an anomaly detection command for the target network interface card (NIC), a target flow table that needs to be offloaded to the target NIC is determined, the target flow table containing entries. Some entries in the target flow table are unloaded onto the target network card to obtain the target entry combination to be tested; If an abnormal performance metric is detected during the processing of a data stream by the target network interface card (NIC) based on the target entry combination, it is determined that the target NIC has an abnormal risk under the target entry combination.

2. The method according to claim 1, characterized in that, Determine the target flow table that needs to be offloaded to the target network interface card, including: If there are multiple flow tables that need to be unloaded to the target network card, the cascading relationship between the entries contained in the multiple flow tables is identified to obtain multiple cascading paths; If any of the multiple cascaded paths does not meet the preset path constraints, then the entries contained in the target cascaded path are deleted from the multiple flow tables to obtain the target flow table that needs to be offloaded to the target network card.

3. The method according to claim 2, characterized in that, Also includes: For any cascaded path, if a valid transmission destination cannot be indicated on the cascaded path, then the cascaded path is determined to not meet the preset path constraint conditions.

4. The method according to any one of claims 1-3, characterized in that, Some entries in the target flow table are offloaded to the target network interface card to obtain the target entry combination to be tested, including: Select a subset of cascading paths from those existing in the target flow table; The entries contained in the selected cascading paths are unloaded onto the target network interface card to obtain the target entry combination.

5. The method according to claim 4, characterized in that, From the cascading paths existing in the target flow table, a subset of cascading paths are selected, including: Calculate the required concurrent data stream N to be supported by the target network interface card, where N is a positive integer; From the cascading paths existing in the target flow table, N cascading paths are selected, and the communication terminals matched in the N cascading paths are different.

6. The method according to claim 5, characterized in that, Calculate the required concurrent data stream N supported by the target network interface card, including: Determine the number of subnets existing in the network scenario where the target network interface card is located; Determine the number of corresponding communication terminals in the subnet; Based on the number of communication terminals and the number of subnets, the estimated number of communication terminals that the target network card needs to bridge is used as the data flow concurrency N.

7. The method according to claim 6, characterized in that, Based on the number of communication terminals and the number of subnets, the estimated number of cross-subnet end-to-end data streams required to be supported in the subnet where the target network card is located is used as the data stream concurrency N, including: If the number of communication terminals is represented by the average number of communication terminals in the subnet, then the square of the average number is calculated. Calculate the product between the squared value and the number of subnets, and use it as the data stream concurrency N.

8. The method according to any one of claims 1-3 or 5-7, characterized in that, Also includes: Under the target entry combination, adjust the number of request queues in the target network interface card; If, during the process of the target network interface card (NIC) processing the data stream based on the target entry combination, fluctuations in performance metrics are detected due to changes in the number of request queues, then it is determined that the abnormal risk of the target NIC under the target entry combination is related to the number of request queues.

9. The method according to claim 8, characterized in that, Also includes: If, during the process of the target network interface card (NIC) processing the data stream based on the target table entry combination, it is detected that the performance indicators no longer fluctuate when the number of request queues is adjusted to within the target queue number range, then the target queue number range is output as a control suggestion parameter for the target NIC.

10. The method according to any one of claims 1-3 or 5-7, characterized in that, Also includes: Under the target entry combination, the target flow tables offloaded to the target network interface card are merged or split to adjust the number of flow tables offloaded to the target network interface card; If, during the process of the target network interface card (NIC) processing the data stream based on the target entry combination, fluctuations in performance metrics are detected due to changes in the number of flow tables, then it is determined that the abnormal risk of the target NIC under the target entry combination is related to the number of flow tables.

11. The method according to claim 10, characterized in that, Also includes: If, during the process of the target network interface card (NIC) processing the data stream based on the target table entry combination, it is detected that the performance indicators no longer fluctuate when the number of flow tables is adjusted to within the target flow table number range, then the target flow table number range is output as a control suggestion parameter for the target NIC.

12. The method according to any one of claims 1-3 or 5-7, characterized in that, Also includes: Under the target entry combination, the number of matching masks configured in each of the included entries is adjusted sequentially; If, during the process of the target network interface card (NIC) processing the data stream based on the target entry combination, fluctuations in performance metrics are detected due to changes in the number of matching masks in any entry, then it is determined that the abnormal risk of the target NIC under the target entry combination is related to the number of matching masks.

13. The method according to claim 12, characterized in that, Also includes: If, during the process of the target network interface card (NIC) processing the data stream based on the target entry combination, it is detected that when the number of matching masks in the target entry is adjusted to within the target mask number range, the performance indicators no longer fluctuate, then the target mask number range corresponding to the target entry is output as a control suggestion parameter for the target NIC.

14. The method according to any one of claims 1-3 or 5-7, characterized in that, Also includes: After completing the test of the target entry combination, some entries are re-selected from the target flow table and offloaded to the target network card to obtain the next entry combination that is different from the target entry combination. Continue to control the target network card to process the test data stream according to the next table entry combination, in order to determine whether the target network card has any abnormal risks under the next table entry combination.

15. An anomaly detection method, characterized in that, The method, applicable to target network interface cards deployed within any subnet of multiple subnets contained in a container networking system, includes: In response to an anomaly detection command for the target network interface card (NIC), a target flow table that needs to be offloaded to the target NIC is determined, the target flow table containing entries. Some entries in the target flow table are unloaded onto the target network card to obtain the target entry combination to be tested; If an abnormal performance indicator is detected during the process of the target network interface card (NIC) processing the data flow occurring within the subnet based on the target entry combination, it is determined that the target NIC has an abnormal risk under the target entry combination.

16. A computing device, characterized in that, Includes memory, processor, and communication components; The memory is used to store one or more computer instructions; The processor is coupled to the memory and the communication component and is used to execute one or more computer instructions for use in the anomaly detection method according to any one of claims 1-15.

17. A computer-readable storage medium for storing a computer program, characterized in that, When the computer program is executed by one or more processors, the one or more processors perform the anomaly detection method according to any one of claims 1-15.

18. A computer program product, characterized in that, The invention includes a computer program that, when executed by one or more processors, causes the one or more processors to perform the anomaly detection method according to any one of claims 1-15.

Images