Packet capture method and device and physical server

Abstract

The invention relates to a packet capturing method and device and a physical server, and the method comprises the steps: carrying out the matching of a flow message when the received flow message is determined to be a target message, and obtaining a matching result; wherein the target message comprises a software forwarding message or a hardware forwarding message; the software forwarding message comprises a message used for slow path forwarding processing; the hardware forwarding message comprises a message for hardware unloading; and according to a matching result, executing a packet capturing operation for the traffic message. Through the technical scheme of the invention, not only can the message after hardware unloading be captured, but also the message before hardware unloading can be captured.

Description

Technical Field

[0001] The present application relates to the field of cloud computing technology, and in particular to a packet capturing method, device and physical server. Background Art

[0002] DPU (Data Processing Unit) network function offloading mainly offloads the traffic of the virtual machine switch on the cloud computing host by hardware, thereby reducing the CPU (Central Processing Unit) computing power consumed on the network and improving forwarding performance. When the network traffic on the DPU is abnormal, it is necessary to capture packets to troubleshoot and locate the problem. Among them, the message abnormality may occur before or after the hardware offloading is completed.

[0003] However, if you use the traditional OVS-DPDK (Open vSwitch with Data Plane DevelopmentKit) to directly capture packets on the DPU bridge through the tcpdump command, you can only capture packets after the hardware is uninstalled, but not packets before the hardware is uninstalled. Summary of the invention

[0004] Based on this, it is necessary to provide a packet capture method, device and physical server to address the above technical issues.

[0005] In a first aspect, in one embodiment, the present application provides a packet capture method, which is applied to a smart network card, and the method includes:

[0006] When it is determined that the received traffic message is a target message, the traffic message is matched to obtain a matching result; wherein the target message includes a software forwarding message or a hardware forwarding message; the software forwarding message includes a message used for slow path forwarding processing; the hardware forwarding message includes a message used for hardware unloading;

[0007] Based on the matching results, the packet capture operation is performed on the traffic packets.

[0008] In one of the embodiments, determining that a received traffic message is a target message includes:

[0009] Determine whether the traffic packet is a software forwarding packet or a hardware forwarding packet according to the forwarding type label of the traffic packet;

[0010] The forwarding type label includes a software forwarding label and a hardware forwarding label; the forwarding type label is obtained according to the message header of the traffic message.

[0011] In one embodiment, matching the traffic message to obtain a matching result includes:

[0012] If the traffic message is a software forwarding message, the message type of the traffic message is determined according to the first message information through the filter table; the first message information includes at least one of the five-tuple of the software forwarding message, the vxlan id, and the representative port PF id;

[0013] If the traffic message is a hardware forwarding message, the message type of the traffic message is determined according to the second message information through the filter table; the second message information includes at least one of the five-tuple of the hardware forwarding message, the vxlan id, the representative port PF id, and the flow_id of the hardware flow table;

[0014] Based on the packet type of the traffic packet, a matching result is obtained.

[0015] In one of the embodiments, the filter table is used to distinguish the message types including UPCALL type, REJECT type and DROP type;

[0016] Among them, the UPCALL type is used to indicate that the traffic packets identified by the filter table are packets sent from the hardware processor of the smart network card to the software processor; the REJECT type is used to indicate that the traffic packets identified by the filter table are packets injected from the software processor back to the hardware processor; the DROP type is used to indicate that the traffic packets identified by the filter table are packets that need to be discarded.

[0017] In one embodiment, when the traffic message is a software forwarding message, a packet capture operation is performed on the traffic message according to the matching result, including:

[0018] If it is determined according to the matching result that the traffic message hits the UPCALL type of the filter table, then when the traffic message is sent to the software processor, at least one copy message identical to the traffic message is forwarded to the kernel space of the software processor through a preset forwarding path, and the copy message is captured;

[0019] If it is determined according to the matching result that the traffic packet hits the REJECT type of the filter table, at least one copy of the same traffic packet as the traffic packet injected back from the software processor to the hardware processor is forwarded to the kernel space through a preset forwarding path, and the copy is captured;

[0020] If the traffic packet is determined to hit the DROP type of the filter table based on the matching result, the traffic packet is captured.

[0021] In one embodiment, when the traffic message is a hardware forwarding message, a packet capture operation is performed on the traffic message according to the matching result, including:

[0022] If it is determined according to the matching result that the hardware flow table corresponding to the hardware forwarding message is an uninstalled hardware flow table, a capture mark is added to the uninstalled hardware flow table, and the flow-id of the uninstalled hardware flow table is added to the flow table monitoring list;

[0023] If it is determined according to the matching result that the hardware flow table corresponding to the hardware forwarding message is the hardware flow table that is performing the unloading action, a capture mark is added to the management hardware unloading flow table, and the flow-id of the hardware flow table that is performing the unloading action is added to the flow table monitoring list; wherein the management hardware unloading flow table is used to perform traffic management of hardware unloading;

[0024] Based on the preset forwarding path, the corresponding hardware forwarding message is captured according to the capture mark on each flow table.

[0025] In one of the embodiments, the preset forwarding path includes a first virtual interface and a second virtual interface;

[0026] The first virtual interface is connected to the second virtual interface in communication; the first virtual interface includes a debug port on a software processor; and the second virtual interface is added to the kernel state by means of an af-packet.

[0027] In one embodiment, the method further comprises:

[0028] Capture the flow table management message forwarded through the target interface, and determine whether to add the flow-id of the flow table corresponding to the flow table management message to the flow table monitoring list based on the matching result between the flow table management message and the filter table;

[0029] The target interface includes a flow table management port for communication connection between the software processor and the hardware processor of the smart network card.

[0030] In a second aspect, in one embodiment, the present application provides a packet capture device, which is applied to a smart network card, and the device includes:

[0031] A matching module, used for matching the traffic message when determining that the received traffic message is a target message to obtain a matching result; wherein the target message includes a software forwarding message or a hardware forwarding message; the software forwarding message includes a message for slow path forwarding processing; the hardware forwarding message includes a message for hardware unloading;

[0032] The packet capture module is used to perform packet capture operations on traffic packets according to the matching results.

[0033] In a third aspect, in one embodiment, the present application further provides a physical server, including an intelligent network card; the intelligent network card is used to execute the packet capture method described in any method embodiment of the first aspect above.

[0034] The packet capture method, device and physical server, when determining that the received traffic message is a target message, matches the traffic message to obtain a matching result; wherein the target message includes a software forwarding message or a hardware forwarding message, the software forwarding message includes a message used for slow path forwarding processing; the hardware forwarding message includes a message used for hardware unloading; according to the matching result, a packet capture operation is performed on the traffic message. The present application can capture both messages after hardware unloading and messages before hardware unloading. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0036] Figure 1 An application environment diagram of a packet capture method in an embodiment;

[0037] Figure 2 A schematic diagram of a flow chart of a packet capture method in an embodiment;

[0038] Figure 3 A schematic diagram of a flow chart for determining a flow message type in an embodiment;

[0039] Figure 4 A schematic diagram of a process for obtaining a matching result in one embodiment;

[0040] Figure 5 A schematic diagram of a process of grabbing software forwarding messages in one embodiment;

[0041] Figure 6 A schematic diagram of a process of capturing a hardware forwarding message in an embodiment;

[0042] Figure 7 A schematic diagram of signal transmission for capturing traffic messages in an embodiment;

[0043] Figure 8 FIG. 4 is a structural block diagram of a packet capture device in an embodiment. DETAILED DESCRIPTION

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

[0045] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0046] It is understood that in this application, terms such as "first", "second", etc. are only used to distinguish similar objects, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features. It is understood that "at least one" means one or more, and "a plurality" means two or more.

[0047] When used herein, the singular forms "a", "an", and "said / the" may also include plural forms, unless the context clearly indicates otherwise. It should also be understood that the terms "include / comprise" or "have" and the like specify the presence of stated features, wholes, steps, operations, components, parts, or combinations thereof, but do not exclude the possibility of the presence or addition of one or more other features, wholes, steps, operations, components, parts, or combinations thereof. At the same time, the term "and / or" used in this specification includes any and all combinations of the relevant listed items.

[0048] With the development of cloud computing network technology, hardware offloading technology for offloading DPU network functions has emerged. Currently, hardware offloading technology mainly offloads the traffic of virtual machine switches on cloud computing hosts, thereby reducing the CPU computing power consumed by the host on the network and improving forwarding performance. When network traffic on the DPU is abnormal, you can capture packets to troubleshoot and locate the problem. The above message anomalies may occur before or after hardware offloading.

[0049] However, if the traditional OVS-DPDK (Open vSwitch with Data Plane DevelopmentKit) is used for packet capture, on the one hand, this packet capture method cannot capture the packets after hardware unloading, and on the other hand, this packet capture method requires the automatic addition of a mirror port on the bridge br-int. When the mirror port is added to the bridge, the controller needs to re-send the software flow table, so that the hardware flow table is updated. It can be understood that when there are a large number of flow tables in the operating environment and large-scale flow table modifications are performed, it will not only affect the forwarding of the original packets, but also may cause unknown operating risks. Therefore, it is not advisable to use the traditional OVS-DPDK packet capture on the DPU.

[0050] To facilitate the understanding of the technical solution of the present invention, the technical feature terms that may appear in the embodiments of the present invention are first explained:

[0051] DPU (Data Processing Unit): DPU is a new type of programmable processor that focuses on data processing. Usually, DPU can be used as an independent embedded processor and integrated into the smart network card to focus on data processing. DPU has become one of the computing units in the data-centric accelerated computing model.

[0052] FPGA (Field-Programmable Gate Array): Field-programmable gate array can be regarded as the hardware part of the smart network card for hardware offload operations.

[0053] Representative port: A representative port is a virtual device that can be set in the SOC (System on Chip) of the smart NIC. Each virtio-net NIC on the host side has a corresponding representative port. If the representative port is hung on the OVS bridge, the representative port can represent the actual virtio-net NIC. At this time, when the flow table is sent to the representative port, the operation will also take effect on the actual NIC.

[0054] The packet capture method provided in the embodiment of the present application can be applied to Figure 1 In the application environment shown in the figure, Figure 1 As shown, a physical server 10 provided in an embodiment of the present application may include: a host side 13 and a smart network card 15.

[0055] Optionally, the physical server 10 may be an elastic bare metal server. In some examples, the elastic bare metal server provides complete IO resources while also having the flexibility and configurability of cloud services. The user's dynamic configuration of IO resources such as network devices, storage devices, and computing acceleration devices will take effect immediately and be reflected on the rented elastic bare metal server.

[0056] Exemplarily, the host side 13 includes at least one virtio-net network card; the smart network card 15 may include a software processor and a hardware processor. In some possible implementations, the software processor of the smart network card 15 may adopt SoC, and the hardware processor of the smart network card 15 may adopt FPGA. Optionally, the software processor may also include at least one representative port; further, the representative port may be hung on the OVS bridge, so that the representative port corresponds to the virtio-net network card on the host side 13.

[0057] In an exemplary embodiment, Figure 2 As shown, a packet capture method is provided, which is applied to Figure 1Taking the smart network card 15 in the example as an example, the method includes the following steps 202 to 204. Among them:

[0058] Step 202: When it is determined that the received traffic message is a target message, the traffic message is matched to obtain a matching result.

[0059] The target message includes a software forwarding message or a hardware forwarding message; the software forwarding message includes a message used for slow path forwarding processing; the hardware forwarding message includes a message used for hardware offloading. In some examples, the hardware forwarding message includes a traffic message forwarded through an FPGA.

[0060] Exemplarily, the smart network card may include a software processor and a hardware processor. Optionally, the software processor may adopt SoC, and the hardware processor may adopt FPGA. It is understood that the configuration of the software processor and the hardware processor is not limited to the implementation described in the above embodiment, and the software processor and the hardware processor may also adopt other implementations, which will not be described in detail here.

[0061] Furthermore, the messages processed by the slow path forwarding may include messages before and after processing by the OVS-DPDK of the smart network card; the messages processed by the slow path forwarding may also include traffic messages sent from the FPGA to the SoC; the messages processed by the slow path forwarding may also include traffic messages injected back from the SOC to the FPGA after VXLAN (Virtual Extensible Local Area Network) encapsulation or decapsulation by OVS-DPDK.

[0062] It can be understood that the message processed by the slow path forwarding is not limited to the implementation method mentioned in the above embodiment, as long as it is a message forwarded by the slow path, this embodiment does not specifically limit the specific type of the message processed by the slow path forwarding.

[0063] Exemplarily, the hardware forwarding message may include a message for hardware unloading. Optionally, the hardware forwarding message may also include a traffic message forwarded from the host side (host side) or the external network port through the FPGA.

[0064] In a feasible embodiment, the flow packets can be matched by setting a filter table. Exemplarily, the type of the corresponding message that can be matched can be set on the filter table according to the message information or forwarding path information of the flow packet, and when the flow packet matches the type set in the filter table, the relevant hit action is executed. Optionally, the hit action can include grabbing the flow packet corresponding to the hit filter table.

[0065] Specifically, when it is determined that the received traffic message is a software forwarding message or a hardware forwarding message, the traffic message may be matched to obtain a corresponding matching result.

[0066] Step 204: According to the matching result, a packet capture operation is performed on the traffic message.

[0067] Specifically, after the matching operation is performed on the traffic message, if the obtained matching result meets the set capture condition, the message capture operation is performed on the corresponding traffic message.

[0068] The above-mentioned packet capture method, when determining that the received traffic message is a target message, matches the traffic message to obtain a matching result; wherein, the target message includes a software forwarding message or a hardware forwarding message, the software forwarding message includes a message used for slow path forwarding processing; the hardware forwarding message includes a message used for hardware unloading; according to the matching result, a packet capture operation is performed on the traffic message, thereby achieving the ability to capture both the message after hardware unloading and the message before hardware unloading.

[0069] In one embodiment, if Figure 3 As shown, determining that the received traffic message is a target message includes the following steps S302. Among them:

[0070] Step S302: Determine whether the traffic message is a software forwarding message or a hardware forwarding message according to the forwarding type label of the traffic message.

[0071] The forwarding type label includes a software forwarding label and a hardware forwarding label; the forwarding type label is obtained according to the message header of the traffic message.

[0072] Exemplarily, a software forwarding label can be used to determine that a traffic message is a software forwarding message; a hardware forwarding label can be used to determine that the traffic message is a hardware forwarding message. Optionally, a forwarding type label can be set in the message header of the traffic message, and the information of the message header of the traffic message can be read to know whether the traffic message belongs to a software forwarding message or a hardware forwarding message.

[0073] To further illustrate, in a feasible embodiment, taking the smart network card including FPGA and SoC as an example, after the traffic message reaches the FPGA from the host side of the physical server or the external network port, the FPGA of the smart network card will add a hardware forwarding label to the traffic message; the forwarding type label can be parsed by reading the message header. If the traffic message does not meet the characteristics of the hardware forwarding message after parsing, the relevant capture operation of the hardware forwarding message will not be performed, so that the traffic message continues to be forwarded normally.

[0074] Specifically, the forwarding type label of the traffic packet can be obtained according to the relevant message information of the message header of the traffic packet, and based on the obtained forwarding type label, it is determined whether the traffic packet belongs to a software forwarding message or a hardware forwarding message.

[0075] In one embodiment, if Figure 4 As shown, matching the traffic message to obtain a matching result includes steps S402 to S406. Among them:

[0076] Step S402: If the traffic message is a software forwarding message, the message type of the traffic message is determined according to the first message information through the filter table.

[0077] Among them, the first message information includes at least one of the five-tuple of the software forwarding message, the vxlan id and the representative port PF id.

[0078] Exemplarily, when a packet capture command is issued to the smart network card, a globally effective filter table can be generated. Optionally, the filter table can be used to match the imported traffic message. If the message type of the imported traffic message meets the relevant conditions of the filter table match hit, the hit operation of the corresponding message type can be performed. Furthermore, the above-mentioned hit operation may include a related packet capture operation to capture the matching traffic message. It can be understood that the above-mentioned hit operation method is not limited to the implementation method mentioned in the above-mentioned embodiment. As long as it belongs to the relevant execution action of the matching traffic message, the present application does not specifically limit the hit operation.

[0079] Optionally, a distinguishable or identifiable message type may be set in the filter table. Exemplarily, when it is identified that the message type of the traffic message can match the corresponding type in the above filter table, it can be indicated that the traffic message matches the filter table.

[0080] It can be understood that the PF id (Physical Function Identity) of the first message information can be the physical port number of the BLUEFILED DPU seen in the host system. The vxlan id of the first message information can be a virtual local area network identifier.

[0081] Specifically, when the traffic message is a software forwarding message, the message type of the software forwarding message can be determined according to the setting of the filter table based on the five-tuple of the software forwarding message, the vxlan id and at least one of the representative port PF id.

[0082] Step S404: If the traffic message is a hardware forwarding message, the message type of the traffic message is determined according to the second message information through the filter table.

[0083] Among them, the second message information includes at least one of the quintuple of the hardware forwarding message, the vxlan id, the representative port PF id and the flow_id of the hardware flow table.

[0084] Exemplarily, flow_id can be a flow table entry identifier, which can be used to distinguish a flow. It can be understood that by allocating and managing the flow table entry identifier flow_id in the flow table, it helps to ensure the mutual exclusivity of each physical function using the same flow table, that is, to ensure that a flow table entry is only used by one physical function at the same time.

[0085] Specifically, when the traffic message is a hardware forwarding message, the message type of the hardware forwarding message can be determined according to the relevant matching settings of the filter table and according to at least one of the five-tuple of the hardware forwarding message, the vxlan id, the representative port PF id and the flow_id of the hardware flow table.

[0086] Step S406: Obtain a matching result based on the message type of the traffic message.

[0087] Exemplarily, the matching result may include whether the packet type of the traffic packet hits the filter table; if the matching result is that the packet type of the traffic packet hits the filter table, a corresponding hit action may be performed. Optionally, the hit action may include performing a packet capture operation on the traffic packet that hits the filter table.

[0088] Specifically, the filter table can be used to identify the packet type of the traffic packet, and based on whether the packet type of the identified traffic packet meets the preset matching hit condition, the matching result required for executing the subsequent capture operation is obtained.

[0089] In one of the embodiments, the filter table is used to distinguish the message types including UPCALL type, REJECT type and DROP type;

[0090] Among them, the UPCALL type is used to indicate that the traffic packets identified by the filter table are packets sent from the hardware processor of the smart network card to the software processor; the REJECT type is used to indicate that the traffic packets identified by the filter table are packets injected from the software processor back to the hardware processor; the DROP type is used to indicate that the traffic packets identified by the filter table are packets that need to be discarded.

[0091] Exemplarily, the hardware processor may adopt FPGA, and the software processor may adopt SoC.

[0092] Optionally, the DROP type traffic message may include a message discarded based on a security rule; the DROP type traffic message may also include a software forwarding message discarded because the CT (ConnectTracker) state is not established as the establish state and the hardware unloading is not performed normally.

[0093] Specifically, taking the above-mentioned hardware processor using FPGA and the software processor using SoC as an example, after the traffic message is imported into the filter table, if the filter table recognizes that the traffic message belongs to the UPCALL type, it means that the traffic message can be a message sent from the FPGA of the smart network card to the SoC; if the filter table recognizes that the traffic message belongs to the REJECT type, it means that the traffic message can be a message injected back from the SoC to the FPGA; if the filter table recognizes that the traffic message belongs to the DROP type, it means that the traffic message can be a message that needs to be discarded.

[0094] Optionally, corresponding to the fuzzy matching operation based on the message type in the above-mentioned embodiment (for example, message identification or differentiation based on UPCALL type, REJECT type, etc.), the filter table can also set fine matching rules to perform fine matching operations. For example, the fine matching rules can instruct the filter table to match messages with a specific message quintuple, a specific vxlan id, and a specific port vid. By setting fine matching rules, it is possible to achieve fine packet capture of specific messages (for example: original messages forwarded by smart network cards or return messages), so that specific types of messages can be captured and analyzed, thereby improving the flexibility of packet capture.

[0095] It can be understood that the above-mentioned fine matching rules are not limited to the implementation methods mentioned in the above embodiments. As long as they enable the filter table to match messages with specific message features, the present application does not make specific limitations on the fine matching rules.

[0096] Furthermore, when matching traffic packets based on the filter table, a fine matching operation may be performed first, and then a fuzzy matching operation based on the filter table that can identify the packet type may be performed.

[0097] In one embodiment, if Figure 5 As shown, when the traffic message is a software forwarding message, according to the matching result, a packet capture operation is performed on the traffic message, including steps S502 to S506. Among them:

[0098] Step S502, if it is determined according to the matching result that the traffic message hits the UPCALL type of the filter table, then when the traffic message is sent to the software processor, at least one copy message identical to the traffic message is forwarded to the kernel space of the software processor through a preset forwarding path, and the copy message is captured.

[0099] It can be understood that the traffic packet hitting the UPCALL type of the filter table indicates that the traffic packet belongs to the UPCALL type of traffic packet that can be identified by the filter table, and the current UPCALL type of traffic packet meets the matching hit condition of the filter table.

[0100] Optionally, the preset forwarding path may be a pair of virtual interfaces for establishing a communication connection.

[0101] Furthermore, the tcpdump command can be used to capture packets in the kernel space.

[0102] Specifically, taking the software processor as SoC and the hardware processor as FPGA as an example, when the traffic packet hits the UPCALL type of the filter table, the corresponding hit action can be executed. The hit action can be that when the traffic packet is sent to the SoC, at least one copy of the traffic packet identical to the traffic packet is forwarded to the kernel space of the SoC through a preset forwarding path, and the copy packet is captured in the kernel space.

[0103] Step S504, if it is determined according to the matching result that the traffic message hits the REJECT type of the filter table, at least one copy message identical to the traffic message injected back from the software processor to the hardware processor is forwarded to the kernel space through a preset forwarding path, and the copy message is captured.

[0104] It can be understood that the traffic packet hitting the REJECT type of the filter table indicates that the traffic packet belongs to the REJECT type traffic packet that can be identified by the filter table, and the current REJECT type traffic packet meets the matching hit condition of the filter table.

[0105] Specifically, taking the software processor as SoC and the hardware processor as FPGA as an example, when the traffic packet hits the REJECT type of the filter table, the corresponding hit action can be executed. The hit action can forward at least one copy of the traffic packet that is identical to the traffic packet injected from the SoC to the FPGA to the kernel space through a preset forwarding path, and capture the above copy message.

[0106] Step S506: If it is determined according to the matching result that the traffic message hits the DROP type of the filter table, the traffic message is captured.

[0107] It can be understood that the traffic packet hitting the DROP type of the filter table indicates that the traffic packet belongs to the DROP type traffic packet that can be identified by the filter table, and the current DROP type traffic packet meets the matching hit condition of the filter table.

[0108] Exemplarily, DROP type traffic packets may include packets discarded based on security rules; DROP type traffic packets may also include software forwarding packets discarded because the CT state is not established as the establish state and hardware unloading is not performed normally.

[0109] Specifically, when it is determined according to the matching result that the traffic message hits the DROP type of the filter table, the traffic message that needs to be discarded is captured. Optionally, the traffic message that needs to be discarded can be forwarded to the kernel space through a preset forwarding path, and the traffic message is captured.

[0110] In one embodiment, if Figure 6 As shown, when the traffic message is a hardware forwarding message, according to the matching result, a packet capture operation is performed on the traffic message, including steps S602 to S606. Among them:

[0111] Step S602: If it is determined according to the matching result that the hardware flow table corresponding to the hardware forwarding message is an uninstalled hardware flow table, a capture mark is added to the uninstalled hardware flow table, and the flow-id of the uninstalled hardware flow table is added to the flow table monitoring list (monitor-flow-list).

[0112] Optionally, the filter table can also be used to distinguish message types including HARDWARE type, FLOW_ADD type, FLOW_DEL type, FLOW_DUMP type, FLOW_MODIFY type, FLOW_STATS type and FLOW_STATIS type. It can be understood that the HARDWARE type can indicate that the hardware flow table corresponding to the hardware forwarding message identified by the filter table is an uninstalled hardware flow table; the FLOW_ADD type, FLOW_DEL type, FLOW_DUMP type and FLOW_MODIFY type can indicate that the hardware flow table corresponding to the hardware forwarding message identified by the filter table is performing an uninstallation action, such as performing a flow table addition action, a flow table deletion action, a flow table dump action, a flow table modification action, etc.

[0113] It can be understood that the message types used to distinguish by the above-mentioned filter table are not limited to the implementation methods mentioned in the above-mentioned embodiments, and can also include FLOW_STATS type and / or FLOW_STATIS type used to characterize flow table counting operations, etc. The present application does not specifically limit the message types used to distinguish by the filter table, as long as it can identify whether the hardware flow table corresponding to the current hardware forwarding message belongs to an uninstalled hardware flow table or a hardware flow table that is performing an uninstallation action.

[0114] Optionally, the message types used for distinguishing by the filter table may also include an ALL type; wherein the ALL type may indicate that all types of traffic messages identified by the filter table are messages that match and hit the filter table.

[0115] Exemplarily, at least one Capture monitoring table entry may be added to the uninstalled hardware flow table to implement adding a capture tag. Optionally, the flow table monitoring list may monitor and manage a specified flow table and / or the flow packets corresponding to the flow table according to the flow-id in the flow table.

[0116] Specifically, when it is determined according to the matching results that the hardware flow table corresponding to the hardware forwarding message is an uninstalled hardware flow table, a Capture mark is added to the uninstalled hardware flow table corresponding to the hardware forwarding message, and the flow-id of the uninstalled hardware flow table is added to the flow table monitoring list to monitor and manage the flow table and related messages corresponding to the flow-id, thereby facilitating the positioning of the relevant hardware forwarding messages and the corresponding hardware flow table, and effectively improving the efficiency of handling hardware uninstall message exceptions.

[0117] Step S604: If it is determined according to the matching result that the hardware flow table corresponding to the hardware forwarding message is the hardware flow table that is performing the unloading action, a capture mark is added to the management hardware unloading flow table, and the flow-id of the hardware flow table that is performing the unloading action is added to the flow table monitoring list.

[0118] The management of the hardware offloading flow table is used to perform the traffic management of the hardware offloading. Exemplarily, the management of the hardware offloading flow table can be used to manage the hardware flow table that is performing the offloading action and the hardware offloading process.

[0119] Optionally, the foc-state table entry of the management hardware offload flow table may be marked as capture, so as to add a capture mark to the management hardware offload flow table.

[0120] Specifically, when it is determined according to the matching results that the hardware flow table corresponding to the hardware forwarding message is the hardware flow table that is performing the unloading action, a capture mark is added to the management hardware unloading flow table, and the flow-id of the hardware flow table that is performing the unloading action is added to the flow table monitoring list to monitor and manage the hardware flow table that is performing the unloading action.

[0121] Step S606: based on the preset forwarding path and according to the capture mark on each flow table, the corresponding hardware forwarding message is captured.

[0122] Exemplarily, after each flow table is added with a capture mark, all related messages corresponding to the flow table need to be captured to monitor whether each hardware flow table and management hardware offload flow table are operating normally, thereby improving the efficiency of locating the abnormal position of the message.

[0123] Specifically, by presetting the forwarding path, the hardware forwarding message corresponding to each flow table can be captured according to the capture mark on each flow table.

[0124] Optionally, when the hardware flow table ages or the number of corresponding captured messages exceeds a preset threshold, the Capture monitoring table entry on the hardware flow table is deleted accordingly.

[0125] In one possible implementation, when the number of captured traffic packets of a specified type exceeds a preset number threshold of the specified type, the capture of the specified type of traffic packets is stopped; illustratively, the capture of the specified type of traffic packets can be stopped by deleting the Capture monitoring table entry corresponding to the above-mentioned specified type on the filter table.

[0126] In one of the embodiments, the preset forwarding path includes a first virtual interface and a second virtual interface.

[0127] The first virtual interface is connected to the second virtual interface in communication; the first virtual interface includes a debug port on a software processor; and the second virtual interface is added to the kernel state by means of an af-packet.

[0128] Exemplarily, the first virtual interface may include at least one virtual interface located in a software processor, and the second virtual interface may be added to the kernel state, so that the traffic message can enter the kernel state through the first virtual interface and the second virtual interface to implement subsequent packet capture operations.

[0129] Specifically, the captured traffic packets can enter the kernel state through the communication connection between the first virtual interface and the second virtual interface, so as to perform a packet capture operation on the traffic packets.

[0130] In order to make the purpose, technical solution and advantages of this application clearer, taking the software processor as SOC and the hardware forwarding message as FPGA as an example, by Figure 7 A schematic diagram of an exemplary captured traffic message is shown for further explanation.

[0131] in, Figure 7 The debug_port shown is the first virtual interface and the second virtual interface is Figure 7 The veth-peer port shown in the figure is added to the kernel state (i.e. Figure 7 In addition, FPGA can also send UPCAll messages (i.e., UPCALL type traffic messages) to SOC through upcall_port. Figure 7 The flow_port (i.e., FLOW port) in is used as the flow table management port between the SoC and the FPGA. Ns1 (Namespace, Ns) to Ns3 can be external forwarding nodes for traffic packets, and a communication connection can be established through the vport101 port to the vport103 port of the FPGA.

[0132] In one embodiment, the method further includes step S206.

[0133] Step S206, capturing the flow table management message forwarded through the target interface, and determining whether to add the flow-id of the flow table corresponding to the flow table management message to the flow table monitoring list based on the matching result between the flow table management message and the filter table;

[0134] The target interface includes a flow table management port for communication connection between the software processor and the hardware processor of the smart network card.

[0135] Exemplarily, the target interface may include a FLOW port, which may be used as a flow table management port between a software processor and a hardware processor (e.g., between an SoC and an FPGA). The flow table management message may be used to notify the software processor to perform a flow table addition action, a flow table deletion action, or a flow table modification action. The flow table management message may also be used to notify the hardware processor to perform a flow table addition action, a flow table deletion action, or a flow table modification action.

[0136] Optionally, the Op code (8 bits) of the flow table management message can be parsed and fuzzy matched with the filter table in combination with other matching items vid, ip, ip_protocol and port information to obtain the matching result between the flow table management message and the filter table.

[0137] In a possible implementation, the Op code (8 bits) of the flow table management message may include: adding flow table items, deleting flow table items, modifying flow table items, dumping flow table items (excluding encap action tbl and group tbl), reading statistics counts, writing encap action tbl, reading encap action tbl, writing group tbl, reading group tbl, and reporting flow table item active_bitmap. It is understandable that the Op code of the above-mentioned flow table management message is not limited to the implementation methods mentioned in the above-mentioned embodiments, and this application does not specifically limit the Op code.

[0138] Specifically, the flow table management message forwarded through the target interface can be captured, and based on the matching result of the flow table management message and the filter table, it is determined whether to add the flow-id of the flow table corresponding to the flow table management message to the flow table monitoring list, thereby facilitating the location of message anomalies such as the failure to send or sending errors of the hardware flow table.

[0139] In an exemplary embodiment, the method further includes: for a specified message header, performing a message header stripping operation on the captured software forwarding message and / or hardware forwarding message.

[0140] It is understandable that traffic packets forwarded by hardware processors (such as FPGA) may be added with some message headers, such as DPE message headers, and traffic packets carrying DPE headers cannot be directly identified by wireshark. Exemplarily, it is possible to set whether to perform message header stripping operations on captured messages. Optionally, in the issued capture command, it is possible to choose to strip the DPE header when capturing packets. The traffic packets after stripping the DPE header can be opened by wireshark, so that the mac, ip and other information in the message can be directly parsed.

[0141] The present application can maintain the continuity of packet capture logic, and can capture both software forwarding messages and hardware forwarding messages. The present application can also accurately and finely capture software forwarding messages, not only by capturing messages before entering OVS to locate whether the communication between FPGA and SoC is normal, but also by capturing messages that are injected back into FPGA after OVS processing to locate whether the software OVS processes the messages normally. In addition, the packet capture method of the present application cleverly avoids the idea of ​​dynamically adding mirror-ports to the OVS bridge for packet capture in the traditional method. The packet capture method of the present application will not cause the original underlying flow table to generate a large number of flow-modify (flow table modification), thereby ensuring that the message can be forwarded normally according to the original forwarding path, thereby achieving lossless packet capture and lossless hardware flow table unloading operations.

[0142] In order to make the purpose, technical solutions and advantages of this application clearer, the following is a further description of this application in conjunction with exemplary embodiments of specific application scenarios. It should be understood that the specific embodiments described here are only used to explain this application and are not used to limit this application. Taking the packet capture method in the above method embodiment as an example, the application is applied to two elastic soft metal servers (elastic bare metal A and elastic bare metal B), the specific implementation process is as follows:

[0143] Step 1: Install the ovs rpm package with the capture function on the elastic soft metal server. The capture function can be used to implement the packet capture method described in any of the above method embodiments. After the ovs rpm package is installed, a pair of path ports (i.e., virtual interfaces) will be automatically generated on the smart network card of the elastic soft metal server, namely, the debug-port port (corresponding to the first virtual interface) and the veth-peer port (corresponding to the second virtual interface). The veth-peer port is added to the kernel state in af-packet mode by default.

[0144] Step 2: When EBM A and EBM B can communicate normally and there is no hardware flow table for hardware offload in the FPGA, issue the capture command on EBM A and set capture=on (i.e., start packet capture), type=upcall (i.e., capture UPCALL type traffic packets), dpe-strip=on (i.e., strip DPE packet headers), protol=TCP, and pattern="ipA >ipB:portB" in the capture command. In this mode (pattern), the purpose is to capture the UPCALL type software forwarding packets sent to OVS in the first packet.

[0145] Step 3: Run the tcpdump command on Smart NIC A (that is, the Smart NIC of EBM A) to capture the packets on the veth-peer port.

[0146] Step 4: Use Elastic Bare Metal A as the client and Elastic Bare Metal B as the server to establish a TCP connection and monitor the portB service port of Elastic Bare Metal B. The portB service port is the service port opened on the Elastic Bare Metal.

[0147] Step 5: At this point, the message captured on Smart NIC A is a TCP message with source IP address of EBM A, destination IP address of EBM B, and destination port of port B. The captured message is the first packet sent by the host side of EBM A to OVS-DPDK, and is a software forwarding message of the UPCALL type, and the message does not carry a DPE message header.

[0148] Step 6: Elastic Bare Metal A stops streaming and sets the capture command to capture=off to disable the capture function, and checks whether the capture list is empty. For example, when the capture list is empty, the corresponding capture operation is no longer performed.

[0149] Step 7: Re-enable the capture function and set the capture command to capture=on, type=reject, dpe-strip=on, protol=TCP, and pattern to "ipA >ipB:portB". The pattern is used to characterize the direction of traffic. In this mode, the purpose is to capture the REJECT type software forwarding message of the first packet sent to OVS.

[0150] Step 8: After the hardware flow table ages, check that the hardware flow table of the hardware unloaded is empty. At this time, run the tcpdump command on Elastic Bare Metal A again to capture the packets on the veth-peer port.

[0151] Step 9: Re-establish the traffic on Elastic Bare Metal A. Similarly, use Elastic Bare Metal A as the client and Elastic Bare Metal B as the server to establish a TCP connection and monitor port B.

[0152] Step 10: At this time, the message captured on Smart NIC A is a TCP message with source IP address of EBM A, destination IP address of EBM B, and destination port of port B. The captured message is a REJECT type traffic message after the first packet sent from the host side of EBM A is sent to OVS-DPDK and then encapsulated by OVS for vxlan, and the message does not carry a DPE message header.

[0153] Step 11: Elastic Bare Metal A continues to start a new capture command. The purpose of this command is to capture hardware forwarding packets. Set the capture command to: capture=on, type=hardware-forward, dpe-strip=on, protol=TCP, pattern="ipA:ipB:portB", and set a certain capture quantity threshold in the capture command. Set the threshold to 10,000 packets.

[0154] Step 12: At this time, the messages captured on Smart NIC A are bidirectional messages after hardware unloading. When 10,000 messages are captured, the capture command disappears automatically and monitoring is turned off.

[0155] Step 13: Re-enable the packet capture function on EBM A and capture the private messages (corresponding to flow table management messages) sent by SoC on the FLOW port to manage hardware offload. After capturing the required number of messages, stop the flow.

[0156] Step 14: After the hardware flow table ages, start capturing packets on Smart NIC A, and the two EBMs start to run flows. After the hardware flow table is delivered, the ADD-FLOW management message (i.e., the flow table management message used to add a flow table) generated on the FLOW port can be captured.

[0157] It can be understood that the above steps 1 to 14 are only one of the exemplary execution processes combined with actual application scenarios. The present application obviously has other implementation methods in actual application scenarios, which will not be repeated here.

[0158] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0159] Based on the same inventive concept, the embodiment of the present application also provides a packet capture device for implementing the packet capture method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more packet capture device embodiments provided below can refer to the limitations on the packet capture method above, and will not be repeated here.

[0160] In one embodiment, Figure 8 As shown, the present application provides a packet capture device 800, which is applied to a smart network card. The device 800 includes:

[0161] The matching module 802 is used to match the traffic message when determining that the received traffic message is a target message to obtain a matching result; wherein the target message includes a software forwarding message or a hardware forwarding message; the software forwarding message includes a message for slow path forwarding processing; the hardware forwarding message includes a message for hardware unloading;

[0162] The packet capture module 804 is used to perform a packet capture operation on the traffic message according to the matching result.

[0163] In one of the embodiments, the matching module 802 is also used to: determine whether the traffic packet is a software forwarding packet or a hardware forwarding packet based on the forwarding type label of the traffic packet; wherein the forwarding type label includes a software forwarding label and a hardware forwarding label; the forwarding type label is obtained based on the packet header of the traffic packet.

[0164] In one embodiment, the matching module 802 is further configured to:

[0165] If the traffic message is a software forwarding message, the message type of the traffic message is determined according to the first message information through the filter table; the first message information includes at least one of the five-tuple of the software forwarding message, the vxlan id, and the representative port PF id;

[0166] If the traffic message is a hardware forwarding message, the message type of the traffic message is determined according to the second message information through the filter table; the second message information includes at least one of the five-tuple of the hardware forwarding message, the vxlan id, the representative port PF id, and the flow_id of the hardware flow table;

[0167] Based on the packet type of the traffic packet, a matching result is obtained.

[0168] In one of the embodiments, the filter table is used to distinguish the message types including UPCALL type, REJECT type and DROP type;

[0169] Among them, the UPCALL type is used to indicate that the traffic packets identified by the filter table are packets sent from the hardware processor of the smart network card to the software processor; the REJECT type is used to indicate that the traffic packets identified by the filter table are packets injected from the software processor back to the hardware processor; the DROP type is used to indicate that the traffic packets identified by the filter table are packets that need to be discarded.

[0170] In one embodiment, when the traffic message is a software forwarding message, the packet capture module 804 is further used to:

[0171] If it is determined according to the matching result that the traffic message hits the UPCALL type of the filter table, then when the traffic message is sent to the software processor, at least one copy message identical to the traffic message is forwarded to the kernel space of the software processor through a preset forwarding path, and the copy message is captured;

[0172] If it is determined according to the matching result that the traffic packet hits the REJECT type of the filter table, at least one copy of the same traffic packet as the traffic packet injected back from the software processor to the hardware processor is forwarded to the kernel space through a preset forwarding path, and the copy is captured;

[0173] If the traffic packet is determined to hit the DROP type of the filter table based on the matching result, the traffic packet is captured.

[0174] In one embodiment, when the traffic message is a hardware forwarding message, the packet capture module 804 is further used to:

[0175] If it is determined according to the matching result that the hardware flow table corresponding to the hardware forwarding message is an uninstalled hardware flow table, a capture mark is added to the uninstalled hardware flow table, and the flow-id of the uninstalled hardware flow table is added to the flow table monitoring list;

[0176] If it is determined according to the matching result that the hardware flow table corresponding to the hardware forwarding message is the hardware flow table that is performing the unloading action, a capture mark is added to the management hardware unloading flow table, and the flow-id of the hardware flow table that is performing the unloading action is added to the flow table monitoring list; wherein the management hardware unloading flow table is used to perform traffic management of hardware unloading;

[0177] Based on the preset forwarding path, the corresponding hardware forwarding message is captured according to the capture mark on each flow table.

[0178] In one of the embodiments, the preset forwarding path includes a first virtual interface and a second virtual interface;

[0179] The first virtual interface is connected to the second virtual interface in communication; the first virtual interface includes a debug port on a software processor; and the second virtual interface is added to the kernel state by means of an af-packet.

[0180] In one embodiment, the apparatus 800 further includes:

[0181] A flow table management message capture module is used to capture the flow table management message forwarded through the target interface, and determine whether to add the flow-id of the flow table corresponding to the flow table management message to the flow table monitoring list based on the matching result between the flow table management message and the filter table; wherein the target interface includes a flow table management port for communication connection between the software processor and the hardware processor of the smart network card.

[0182] Each module in the above-mentioned packet capture device can be implemented in whole or in part by software, hardware or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each module above.

[0183] In one embodiment, the present application further provides a physical server, including an intelligent network card; the intelligent network card is used to execute the steps of the packet capture method described in any of the above method embodiments.

[0184] In one embodiment, a computer device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above method embodiments when executing the computer program.

[0185] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0186] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0187] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0188] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0189] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A packet capture method, characterized in that: Applied to a smart network card, the method includes: When it is determined that the received traffic message is a target message, the traffic message is matched to obtain a matching result; wherein the target message includes a software forwarding message or a hardware forwarding message; the software forwarding message includes a message for slow path forwarding processing; the hardware forwarding message includes a message for hardware unloading; According to the matching result, a packet capture operation is performed on the traffic message.

2. The method according to claim 1, characterized in that The step of determining that the received traffic message is a target message includes: Determining, according to the forwarding type label of the traffic message, whether the traffic message is the software forwarding message or the hardware forwarding message; The forwarding type label includes a software forwarding label and a hardware forwarding label; and the forwarding type label is obtained according to a message header of the traffic message.

3. The method according to claim 1, characterized in that: The matching of the traffic message to obtain a matching result includes: If the traffic message is the software forwarding message, the message type of the traffic message is determined according to the first message information through the filter table; the first message information includes at least one of the five-tuple of the software forwarding message, the vxlan id and the representative port PF id; If the traffic message is the hardware forwarding message, the message type of the traffic message is determined according to the second message information through the filter table; the second message information includes at least one of the quintuple of the hardware forwarding message, the vxlan id, the representative port PF id, and the flow_id of the hardware flow table; The matching result is obtained based on the message type of the traffic message.

4. The method according to claim 3, characterized in that The filter table is used to distinguish the message types including UPCALL type, REJECT type and DROP type; Among them, the UPCALL type is used to characterize that the traffic message identified by the filter table is a message sent from the hardware processor of the smart network card to the software processor; the REJECT type is used to characterize that the traffic message identified by the filter table is a message injected back from the software processor to the hardware processor; the DROP type is used to characterize that the traffic message identified by the filter table is a message that needs to be discarded.

5. The method according to claim 4, characterized in that When the traffic message is a software forwarding message, performing a packet capture operation on the traffic message according to the matching result includes: If it is determined according to the matching result that the traffic message hits the UPCALL type of the filter table, then when the traffic message is sent to the software processor, at least one copy message identical to the traffic message is forwarded to the kernel space of the software processor through a preset forwarding path, and the copy message is captured; If it is determined according to the matching result that the traffic message hits the REJECT type of the filter table, at least one copy of the traffic message that is the same as the traffic message injected back from the software processor to the hardware processor is forwarded to the kernel space through the preset forwarding path, and the copy message is captured; If it is determined according to the matching result that the traffic message hits the DROP type of the filter table, the traffic message is captured.

6. The method according to claim 5, characterized in that When the traffic message is a hardware forwarding message, performing a packet capture operation on the traffic message according to the matching result includes: If it is determined according to the matching result that the hardware flow table corresponding to the hardware forwarding message is an uninstalled hardware flow table, a capture mark is added to the uninstalled hardware flow table, and the flow-id of the uninstalled hardware flow table is added to the flow table monitoring list; If it is determined according to the matching result that the hardware flow table corresponding to the hardware forwarding message is a hardware flow table that is performing an unloading action, a capture mark is added to the management hardware unloading flow table, and the flow-id of the hardware flow table that is performing the unloading action is added to the flow table monitoring list; wherein the management hardware unloading flow table is used to perform traffic management of hardware unloading; Based on the preset forwarding path, and according to the capture mark on each flow table, the corresponding hardware forwarding message is captured.

7. The method according to claim 5 or 6, characterized in that: The preset forwarding path includes a first virtual interface and a second virtual interface; Among them, the first virtual interface and the second virtual interface are communicatively connected; the first virtual interface includes a debug port on the software processor; and the second virtual interface joins the kernel state through af-packet.

8. The method according to claim 3, characterized in that The method further comprises: Capture the flow table management message forwarded through the target interface, and determine whether to add the flow-id of the flow table corresponding to the flow table management message to the flow table monitoring list based on the matching result between the flow table management message and the filter table; The target interface includes a flow table management port for communication connection between the software processor and the hardware processor of the smart network card.

9. A packet grabbing device, characterized in that: Applied to a smart network card, the device comprises: A matching module, for matching the received traffic message to obtain a matching result when determining that the received traffic message is a target message; wherein the target message includes a software forwarding message or a hardware forwarding message; the software forwarding message includes a message for slow path forwarding processing; the hardware forwarding message includes a message for hardware unloading; The packet capture module is used to perform a packet capture operation on the flow message according to the matching result.

10. A physical server, characterized in that: It includes an intelligent network card; the intelligent network card is used to execute the packet capture method described in any one of claims 1 to 8.

Images