Packet grabbing method, apparatus and physical server

Abstract

The application relates to a packet capturing method, device and physical server. The method comprises the following steps: when it is determined that a received traffic packet is a target packet, the traffic packet is matched to obtain a matching result; the target packet comprises a software forwarding packet or a hardware forwarding packet; the software forwarding packet comprises a packet used for slow path forwarding processing; the hardware forwarding packet comprises a packet used for hardware offloading; and according to the matching result, a packet capturing operation for the traffic packet is performed. Through the technical scheme, the packet after hardware offloading can be captured, and the packet before hardware offloading can also be captured.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a packet capture method, apparatus, and physical server. Background Technology

[0002] DPU (Data Processing Unit) network function offloading primarily involves hardware offloading of traffic from virtual machine switches on cloud computing hosts, thereby reducing the CPU (Central Processing Unit) computing power consumed on the network and improving forwarding performance. When network traffic on the DPU becomes abnormal, packet capture is needed to troubleshoot and locate the problem. Packet anomalies can occur either before or after hardware offloading is completed.

[0003] However, if you use the traditional OVS-DPDK (Open vSwitch with Data Plane Development Kit) to capture packets on the DPU's bridge using the tcpdump command, you can only capture packets after the hardware is unloaded, but not packets before the hardware is unloaded. Summary of the Invention

[0004] Therefore, it is necessary to provide a packet capture method, device, and physical server to address the aforementioned technical problems.

[0005] In one embodiment, this application provides a packet capture method applied to a smart network interface card (NIC), the method comprising:

[0006] Once it is determined that the received traffic packet is the target packet, the traffic packet is matched to obtain the matching result; among them, the target packet includes software forwarding packets or hardware forwarding packets; software forwarding packets include packets used for slow path forwarding processing; hardware forwarding packets include packets used for hardware offloading.

[0007] Based on the matching results, perform packet capture operations on the traffic packets.

[0008] In one embodiment, determining that a received traffic packet is a target packet includes:

[0009] Based on the forwarding type label of the traffic packet, determine whether the traffic packet is a software forwarding packet or a hardware forwarding packet;

[0010] The forwarding type label includes software forwarding labels and hardware forwarding labels; the forwarding type label is obtained from the packet header of the traffic packet.

[0011] In one embodiment, the traffic packets are matched to obtain matching results, including:

[0012] If the traffic packet is a software forwarding packet, the packet type of the traffic packet is determined by the filter table based on the first packet information; the first packet information includes at least one of the following: the five-tuple of the software forwarding packet, the VXLAN ID, and the PF ID representing the port.

[0013] If the traffic packet is a hardware forwarding packet, the packet type of the traffic packet is determined by the filter table based on the second packet information; the second packet information includes at least one of the following: the hardware forwarding packet's 5-tuple, VXLAN ID, representative port PF ID, and the hardware flow table's flow_id;

[0014] Matching results are obtained based on the message type of the traffic packets.

[0015] In one embodiment, the filter table is used to distinguish message types including UPCALL, REJECT, and DROP.

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

[0017] In one embodiment, when the traffic packet is a software-forwarded packet, a packet capture operation is performed on the traffic packet based on the matching result, including:

[0018] If the matching result determines that the traffic packet matches the UPCALL type in the filter table, then when the traffic packet is sent to the software processor, at least one copy of the traffic packet will be forwarded to the kernel space of the software processor through a preset forwarding path, and the copy will be captured.

[0019] If the matching result determines that the traffic packet matches the REJECT type in the filter table, then at least one copy of the traffic packet that is the same as the traffic packet injected from the software processor to the hardware processor will be forwarded to the kernel space through the preset forwarding path, and the copy packet will be captured.

[0020] If the matching results determine that the traffic packet matches the DROP type in the filter table, then the traffic packet is captured.

[0021] In one embodiment, when the traffic packet is a hardware-forwarded packet, a packet capture operation is performed on the traffic packet based on the matching result, including:

[0022] If the hardware flow table corresponding to the hardware forwarding packet is determined to be an unloaded hardware flow table based on the matching results, then a capture mark is added to the unloaded hardware flow table, and the flow-id of the unloaded hardware flow table is added to the flow table monitoring list.

[0023] If the matching results determine that the hardware flow table corresponding to the hardware forwarding packet is the hardware flow table that is currently performing an offloading action, then add a capture flag to the management hardware offloading flow table and add the flow-id of the hardware flow table that is currently performing an offloading action to the flow table monitoring list; whereby, the management hardware offloading flow table is used for traffic management of hardware offloading.

[0024] Based on the preset forwarding path, the corresponding hardware forwarding packets are captured according to the capture flags on each flow table.

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

[0026] The first virtual interface and the second virtual interface are connected for communication; the first virtual interface includes a debug port on the software processor; the second virtual interface is added to the kernel mode via af-packet.

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

[0028] Capture flow table management messages 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 between the software processor and the hardware processor of the smart network interface card.

[0030] Secondly, in one embodiment, this application provides a packet capture device applied to a smart network interface card (NIC), the device comprising:

[0031] The matching module is used to match traffic packets when it is determined that the received traffic packet is the target packet, and obtain the matching result; wherein, the target packet includes software forwarding packets or hardware forwarding packets; software forwarding packets include packets used for slow path forwarding processing; hardware forwarding packets include packets used for hardware offloading.

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

[0033] Thirdly, in one embodiment, this application also provides a physical server, including a smart network interface card (NIC); the smart NIC is used to execute the packet capture method described in any of the method embodiments of the first aspect above.

[0034] The aforementioned packet capture method, device, and physical server, upon determining that the received traffic packet is the target packet, match the traffic packet to obtain a matching result. The target packet includes software-forwarded packets or hardware-forwarded packets. Software-forwarded packets include packets used for slow path forwarding; hardware-forwarded packets include packets used for hardware offloading. Based on the matching result, packet capture operations are performed on the traffic packet. This application can capture packets both after hardware offloading and before hardware offloading. Attached Figure Description

[0035] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0036] Figure 1 This is a diagram illustrating the application environment of the packet capture method in one embodiment.

[0037] Figure 2 This is a flowchart illustrating a packet capture method in one embodiment;

[0038] Figure 3 This is a flowchart illustrating the process of determining the type of traffic packets in one embodiment;

[0039] Figure 4 This is a flowchart illustrating the process of obtaining matching results in one embodiment;

[0040] Figure 5 This is a flowchart illustrating the process of capturing forwarded packets by the software in one embodiment;

[0041] Figure 6 This is a flowchart illustrating the process of capturing hardware-forwarded packets in one embodiment;

[0042] Figure 7 This is a schematic diagram of signal transmission for capturing traffic packets in one embodiment;

[0043] Figure 8 This is a structural block diagram of a packet-catching device in one embodiment. Detailed Implementation

[0044] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

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

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

[0047] When used herein, the singular forms of “a,” “an,” and “the” may also include the plural forms unless the context clearly indicates otherwise. It should also be understood that the terms “comprising / including” or “having,” etc., specify the presence of the stated features, wholes, steps, operations, components, parts, or combinations thereof, but do not preclude the possibility of the presence or addition of one or more other features, wholes, steps, operations, components, parts, or combinations thereof. Meanwhile, the term “and / or” as used in this specification includes any and all combinations of the associated listed items.

[0048] With the development of cloud computing network technology, hardware offloading technology has emerged to offload the network functions of the DPU. Currently, this technology primarily offloads traffic from 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 abnormal network traffic occurs on the DPU, packet capture can be used to troubleshoot and locate the problem. These abnormal packets can occur either before or after hardware offloading.

[0049] However, using the traditional OVS-DPDK (Open vSwitch with Data Plane Development Kit) for packet capture has two drawbacks. First, it cannot capture packets after hardware offloading. Second, it requires automatically adding a mirror port to the bridge br-int. Adding a mirror port to the bridge necessitates the controller re-issuing software flow tables, thus updating the hardware flow tables. Understandably, when a large number of flow tables exist in the runtime environment and large-scale flow table modifications are made, it not only affects the forwarding of existing packets but may also introduce unknown operational risks. Therefore, using the traditional OVS-DPDK for packet capture on the DPU is not advisable.

[0050] To facilitate understanding of the technical solution of this invention, the technical features and proper nouns that may appear in the embodiments of this invention will first be explained:

[0051] DPU (Data Processing Unit): A DPU is a new type of programmable next-generation processor focused on data processing. Typically, a DPU can be used as a standalone embedded processor or integrated into a smart network interface card (NIC) to concentrate on data processing. The DPU has become one of the computing units in data-centric accelerated computing models.

[0052] FPGA (Field-Programmable Gate Array): A field-programmable gate array, which can be regarded as the hardware part of a smart network interface card (NIC) that performs hardware offloading operations.

[0053] Representative Port: A representative port is a virtual device that can be configured within the System on Chip (SOC) of a smart network interface card (NIC). Each virtio-net NIC on the host side has a corresponding representative port. If a representative port is connected to an OVS bridge, it can represent the actual virtio-net NIC. In this case, when a flow table is issued to the representative port, the operation will also take effect on the actual NIC.

[0054] The packet capture method provided in this application embodiment can be applied to, for example, Figure 1 The application environment shown. Among them, such as... Figure 1 As shown, a physical server 10 is provided in an embodiment of this application. The physical server 10 may include a host side 13 and a smart network card 15.

[0055] Optionally, physical server 10 can be an elastic bare metal server. In some examples, elastic bare metal servers provide full I / O resources while also offering the flexibility and configurability of cloud services. Dynamic configurations of I / O resources such as network devices, storage devices, and compute acceleration devices by the user will take effect immediately on the rented elastic bare metal server.

[0056] For example, the host side 13 includes at least one virtio-net network interface card (NIC); the smart NIC 15 may include a software processor and a hardware processor. In some possible implementations, the software processor of the smart NIC 15 may be a SoC (System-on-a-Chip), and the hardware processor of the smart NIC 15 may be an FPGA (Field-Programmable Gate Array). Optionally, the software processor may also include at least one delegate port; furthermore, the delegate port may be connected to an OVS (Optical Version 15) bridge, thereby making the delegate port correspond to the virtio-net NIC on the host side 13.

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

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

[0059] The target message includes either a software-forwarded message or a hardware-forwarded message; software-forwarded messages include messages used for slow path forwarding; hardware-forwarded messages include messages used for hardware offloading. In some examples, hardware-forwarded messages include traffic messages forwarded via the FPGA.

[0060] For example, a smart network interface card (NIC) may include a software processor and a hardware processor. Optionally, the software processor may be a System-on-a-Chip (SoC), and the hardware processor may be an FPGA. It is understood that the configuration of the software processor and hardware processor is not limited to the implementation methods described in the above embodiments, and other implementation methods may also be used, which will not be elaborated here.

[0061] Furthermore, the packets processed by slow path forwarding can include packets before and after processing by the OVS-DPDK of the smart network card; the packets processed by slow path forwarding can also include traffic packets sent from the FPGA to the SoC; the packets processed by slow path forwarding can also include traffic packets injected back from the SoC to the FPGA after being encapsulated or decapsulated by OVS-DPDK using VXLAN (Virtual Extensible Local Area Network).

[0062] It is understood that the packets for slow path forwarding processing described above are not limited to the implementation methods mentioned in the above embodiments, as long as they belong to the slow path forwarding packets. This embodiment does not specifically limit the specific type of packets for slow path forwarding processing.

[0063] For example, hardware forwarding packets may include packets for hardware offloading. Optionally, hardware forwarding packets may also include traffic packets forwarded from the host side (host side) or external network interface via the FPGA.

[0064] In one feasible embodiment, a filter table can be configured to match traffic packets. For example, based on the packet information or forwarding path information of the traffic packets, the filter table can be configured with corresponding packet types that can be matched. When a traffic packet matches a type set in the filter table, a relevant matching action is performed. Optionally, the matching action may include capturing the traffic packets that match the filter table.

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

[0066] Step 204: Based on the matching results, perform packet capture operations on the traffic packets.

[0067] Specifically, if the matching result obtained after matching the traffic packets meets the set capture conditions, then the corresponding traffic packets will be captured.

[0068] The packet capture method described above determines that the received traffic packet is the target packet, and then matches the traffic packet to obtain the matching result. The target packet includes software forwarding packets or hardware forwarding packets. Software forwarding packets include packets used for slow path forwarding processing; hardware forwarding packets include packets used for hardware offloading. Based on the matching result, a packet capture operation is performed on the traffic packet, thereby enabling the capture of packets both after hardware offloading and before hardware offloading.

[0069] In one embodiment, such as Figure 3 As shown, determining that a received traffic packet is a target packet includes the following steps, S302. Wherein:

[0070] Step S302: 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.

[0071] The forwarding type label includes software forwarding labels and hardware forwarding labels; the forwarding type label is obtained from the packet header of the traffic packet.

[0072] For example, a software forwarding tag can be used to determine whether a traffic packet is a software forwarding packet; a hardware forwarding tag can be used to determine whether the traffic packet is a hardware forwarding packet. Optionally, a forwarding type tag can be set in the header of the traffic packet, and it can be determined whether the traffic packet is a software forwarding packet or a hardware forwarding packet by reading the information in the header of the traffic packet.

[0073] To further illustrate, in a feasible embodiment, taking a smart network interface card (NIC) including an FPGA and a SoC as an example, after a traffic packet arrives at the FPGA from the host side of the physical server or the external network port, the FPGA of the smart NIC will attach a hardware forwarding tag to the traffic packet. The forwarding type tag can be parsed by reading the packet header. If the parsed traffic packet does not conform to the characteristics of a hardware forwarding packet, the relevant capture operation of the hardware forwarding packet will not be performed, and the traffic packet will continue to be forwarded normally.

[0074] Specifically, the forwarding type label of a traffic packet can be obtained from the relevant packet information in the packet header, and the traffic packet can be determined as either a software forwarding packet or a hardware forwarding packet based on the obtained forwarding type label.

[0075] In one embodiment, such as Figure 4 As shown, the traffic packets are matched to obtain the matching results, including steps S402 to S406. Wherein:

[0076] Step S402: If the traffic packet is a software forwarding packet, then the packet type of the traffic packet is determined by the filter table based on the information of the first packet.

[0077] The first message information includes at least one of the following: the five-tuple of the software forwarding message, the VXLAN ID, and the PF ID representing the port.

[0078] For example, when a packet capture command is issued to the smart network interface card (NIC), a globally effective filter table can be generated. Optionally, the filter table can be used to match imported traffic packets. If the packet type of the imported traffic packets meets the relevant conditions for matching in the filter table, a matching operation for the corresponding packet type can be performed. Further, the above-mentioned matching operation may include packet capture operations related to capturing the matched traffic packets. It is understood that the above-mentioned matching operation method is not limited to the implementation methods mentioned in the above embodiments, as long as it belongs to the relevant execution action of the matched traffic packets. This application does not specifically limit the matching operation.

[0079] Optionally, distinguishable or identifiable message types can be set in the filter table. For example, when the message type of a traffic message is identified as matching the corresponding type in the filter table, it can be said that the traffic message matches the filter table.

[0080] It is understandable that the PF id (Physical Function Identity) of the first message can be the physical port number of the BLUEFILED DPU seen in the host system. The vxlan id of the first message can be the virtual LAN identifier.

[0081] Specifically, when the traffic packet is a software forwarding packet, the packet type of the software forwarding packet can be determined based on at least one of the following: the five-tuple of the software forwarding packet, the VXLAN ID, and the PF ID representing the port, according to the settings of the filter table.

[0082] Step S404: If the traffic packet is a hardware forwarding packet, then the packet type of the traffic packet is determined by the filter table based on the second packet information.

[0083] The second message information includes at least one of the following: the 5-tuple of the hardware forwarding message, the VXLAN ID, the PF ID representing the port, and the flow_id of the hardware flow table.

[0084] For example, 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 exclusion of various physical functions using the same flow table, that is, to ensure that a flow table entry is only used by one physical function at a time.

[0085] Specifically, when the traffic packet is a hardware forwarding packet, the packet type of the hardware forwarding packet can be determined according to at least one of the following: the 5-tuple of the hardware forwarding packet, the VXLAN ID, the representative port PF ID, and the flow_id of the hardware flow table, based on the relevant matching settings of the filter table.

[0086] Step S406: Based on the packet type of the traffic packet, obtain the matching result.

[0087] For example, the matching result may include whether the packet type of the traffic packet matches the filter table; if the matching result is that the packet type of the traffic packet matches the filter table, then the corresponding matching action can be performed. Optionally, the matching action may include performing packet capture operations on the traffic packets that match the filter table.

[0088] Specifically, the packet type of traffic packets can be identified through the filter table, and the matching results required for subsequent capture operations can be obtained based on whether the identified packet type meets the preset matching conditions.

[0089] In one embodiment, the filter table is used to distinguish message types including UPCALL, REJECT, and DROP.

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

[0091] For example, the hardware processor described above can be an FPGA, and the software processor can be a SoC.

[0092] Optionally, DROP type traffic packets may include packets dropped based on security rules; DROP type traffic packets may also include software forwarding packets that are dropped because the CT (ConnectTracker) status is not established and hardware offloading has not been performed properly.

[0093] Specifically, taking the example of an FPGA as the hardware processor and a SoC as the software processor, after importing the traffic packet into the filter table, if the filter table identifies the traffic packet as belonging to the UPCALL type, it means that the traffic packet can be a packet sent from the FPGA of the smart network card to the SoC; if the filter table identifies the traffic packet as belonging to the REJECT type, it means that the traffic packet can be a packet injected back from the SoC to the FPGA; if the filter table identifies the traffic packet as belonging to the DROP type, it means that the traffic packet can be a packet that needs to be discarded.

[0094] Optionally, corresponding to the fuzzy matching operation based on packet type in the above embodiments (e.g., packet identification or differentiation based on UPCALL type, REJECT type, etc.), the filter table can also be configured with fine-grained matching rules for fine-grained matching operations. For example, fine-grained matching rules can instruct the filter table to match packets with specific packet 5-tuples, specific VXLAN IDs, and specific port VIDs. By setting fine-grained matching rules, it is possible to perform fine-grained packet capture on specific packets (e.g., original packets or injection packets forwarded by smart network cards), thereby enabling the capture and analysis of specific types of packets and improving the flexibility of packet capture.

[0095] It is 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 characteristics, this application does not impose specific limitations on the fine matching rules.

[0096] Furthermore, when matching traffic packets based on the filter table, a fine-grained matching operation can be performed first, followed by a fuzzy matching operation based on the packet types identifiable by the filter table.

[0097] In one embodiment, such as Figure 5 As shown, when the traffic packet is a software forwarding packet, a packet capture operation is performed on the traffic packet based on the matching result, including steps S502 to S506. Wherein:

[0098] In step S502, if the matching result determines that the traffic packet matches the UPCALL type in the filter table, then when the traffic packet is sent to the software processor, at least one copy of the traffic packet is forwarded to the kernel space of the software processor through a preset forwarding path, and the copy is captured.

[0099] It can be understood that if a traffic packet hits the UPCALL type in the filter table, it means that the traffic packet belongs to the UPCALL type that the filter table can recognize, and the current UPCALL type traffic packet meets the matching hit conditions of the filter table.

[0100] Optionally, the preset forwarding path can be a pair of virtual interfaces that establish a communication connection.

[0101] Furthermore, packet capture can be performed in kernel space using the tcpdump command.

[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 in the filter table, the corresponding hit action can be executed. The hit action can be to forward at least one copy of the traffic packet to the kernel space of the SoC through a preset forwarding path when the traffic packet is sent to the SoC, and capture the copy packet in the kernel space.

[0103] Step S504: If the traffic packet matches the REJECT type in the filter table based on the matching result, then at least one copy of the traffic packet that is the same as the traffic packet injected from the software processor to the hardware processor is forwarded to the kernel space through a preset forwarding path, and the copy packet is captured.

[0104] It can be understood that if a traffic packet hits the REJECT type in the filter table, it means that the traffic packet belongs to the REJECT type that the filter table can recognize, and the current REJECT type traffic packet meets the matching hit conditions 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 in 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 the same as the traffic packet injected from the SoC to the FPGA to the kernel space through a preset forwarding path, and capture the above-mentioned copy packet.

[0106] Step S506: If the matching result determines that the traffic packet matches the DROP type in the filter table, then capture the traffic packet.

[0107] It can be understood that if a traffic packet hits the DROP type in the filter table, it means that the traffic packet belongs to the DROP type that the filter table can recognize, and the current DROP type traffic packet meets the matching hit conditions of the filter table.

[0108] For example, DROP type traffic packets may include packets dropped based on security rules; DROP type traffic packets may also include software forwarding packets that are dropped because the CT state is not established and hardware offloading has not been performed normally.

[0109] Specifically, if the matching result determines that a traffic packet matches the DROP type in the filter table, the matching traffic packet that needs to be dropped is captured. Optionally, the matching traffic packet that needs to be dropped can be forwarded to the kernel space through a preset forwarding path, and the traffic packet can be captured.

[0110] In one embodiment, such as Figure 6 As shown, when the traffic packet is a hardware forwarding packet, a packet capture operation is performed on the traffic packet based on the matching result, including steps S602 to S606. Wherein:

[0111] Step S602: If the hardware flow table corresponding to the hardware forwarding packet is determined to be an unloaded hardware flow table based on the matching result, then a capture mark is added to the unloaded hardware flow table, and the flow-id of the unloaded hardware flow table is added to the flow table monitoring list (monitor-flow-list).

[0112] Optionally, the packet types that the filter table can distinguish may also include HARDWARE, FLOW_ADD, FLOW_DEL, FLOW_DUMP, FLOW_MODIFY, FLOW_STATS, and FLOW_STATIS types. It can be understood that the HARDWARE type indicates that the hardware flow table corresponding to the hardware forwarding packet identified by the filter table is an offloaded hardware flow table; the FLOW_ADD, FLOW_DEL, FLOW_DUMP, and FLOW_MODIFY types, on the other hand, indicate that the hardware flow table corresponding to the hardware forwarding packet identified by the filter table is undergoing an offloading operation, such as flow table addition, deletion, dumping, or modification.

[0113] It is understood that the packet types used by the filter table to distinguish are not limited to the implementation methods mentioned in the above embodiments. They may also include FLOW_STATS and / or FLOW_STATIS types used to characterize flow table counting operations. This application does not specifically limit the packet types used by the filter table to distinguish, as long as it can identify whether the hardware flow table corresponding to the current hardware forwarding packet belongs to an unloaded hardware flow table or a hardware flow table that is currently performing an unload operation.

[0114] Optionally, the message types that the filter table can distinguish may also include the ALL type; where the ALL type can indicate that all types of traffic messages identified by the filter table belong to the messages that match the filter table.

[0115] For example, adding a capture tag can be achieved by adding at least one Capture monitoring entry to the unloaded hardware flow table. Optionally, the flow table monitoring list can monitor and manage a specified flow table and / or the traffic packets corresponding to the flow table based on the flow-id in the flow table.

[0116] Specifically, when the matching result determines that the hardware flow table corresponding to the hardware forwarding packet is an offloaded hardware flow table, a Capture tag is added to the offloaded hardware flow table corresponding to the hardware forwarding packet, and the flow-id of the offloaded hardware flow table is added to the flow table monitoring list to monitor and manage the flow table corresponding to the flow-id and related packets. This facilitates the location of related hardware forwarding packets and corresponding hardware flow tables, effectively improving the efficiency of handling hardware offloaded packet anomalies.

[0117] Step S604: If the hardware flow table corresponding to the hardware forwarding packet is determined to be the hardware flow table that is performing an offloading action based on the matching result, then add a capture mark to the management hardware offloading flow table and add the flow-id of the hardware flow table that is performing an offloading action to the flow table monitoring list.

[0118] The hardware offload flow table is used for traffic management during hardware offload. For example, the hardware offload flow table can be used to manage hardware flow tables currently performing offload operations and the hardware offload process.

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

[0120] Specifically, when the matching result determines that the hardware flow table corresponding to the hardware forwarding packet is the hardware flow table that is performing an offloading action, a capture mark is added to the management hardware offloading flow table, and the flow-id of the hardware flow table that is performing an offloading action is added to the flow table monitoring list in order to monitor and manage the hardware flow table that is performing an offloading action.

[0121] Step S606: Based on the preset forwarding path, capture the corresponding hardware forwarding packets according to the capture markers on each flow table.

[0122] For example, after each flow table is marked with a capture tag, the relevant packets corresponding to that flow table need to be captured in order to monitor whether each hardware flow table and the management hardware offload flow table are operating normally, thereby improving the efficiency of locating abnormal packet locations.

[0123] Specifically, by pre-setting forwarding paths, hardware forwarding packets corresponding to each flow table can be captured based on the capture flags on each flow table.

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

[0125] In one possible implementation, when the number of traffic packets of a specified type exceeds a preset threshold for that specified type, the capture of traffic packets of that specified type is stopped. For example, the capture of traffic packets of that specified type can be stopped by deleting the Capture monitoring entry for the specified type on the filter table.

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

[0127] The first virtual interface and the second virtual interface are connected for communication; the first virtual interface includes a debug port on the software processor; the second virtual interface is added to the kernel mode via af-packet.

[0128] For example, the first virtual interface may include at least one virtual interface located in the software processor, and the second virtual interface may be added to the kernel mode, so that traffic packets can enter the kernel mode through the first virtual interface and the second virtual interface to realize subsequent packet capture operations.

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

[0130] To make the purpose, technical solution, and advantages of this application clearer, an example is taken with a software processor as a SOC and a hardware packet forwarding FPGA. Figure 7 The following diagram illustrates an exemplary method for capturing traffic packets.

[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 is added to kernel mode (i.e., Figure 7 (The gray shaded area in the image). Additionally, the FPGA can also send UPCALL messages (i.e., UPCALL type traffic messages) to the SOC via the upcall_port. Figure 7 The flow_port (i.e., the FLOW port) 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 communication connections can be established through the vport101 to vport103 ports of the FPGA.

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

[0133] Step S206: Capture the flow table management messages 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.

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

[0135] For example, the target interface may include a FLOW port, which can serve as a flow table management port between a software processor and a hardware processor (e.g., between a SoC and an FPGA). Flow table management messages can be used to notify the software processor to perform flow table addition, deletion, and modification actions. Flow table management messages can also be used to notify the hardware processor to perform flow table addition, deletion, and modification actions.

[0136] Optionally, the matching result between the flow table management message and the filter table can be obtained by parsing the Op code (8 bits) of the flow table management message and combining it with other matching items such as vid, ip, ip_protocol and port information to perform a fuzzy matching operation.

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

[0138] Specifically, it can capture flow table management messages 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, thereby providing convenience for locating message anomalies such as hardware flow table not being issued or issuing errors.

[0139] In one exemplary embodiment, the method further includes: performing a header stripping operation on the captured software-forwarded packets and / or hardware-forwarded packets for a specified header.

[0140] It's understandable that traffic packets forwarded via hardware processors (such as FPGAs) may have headers added, such as DPE headers. Traffic packets carrying DPE headers cannot be directly recognized by Wireshark. For example, the configuration can be set to perform header stripping on captured packets. Optionally, the capture command can be configured to strip the DPE header during packet capture. Traffic packets stripped of the DPE header can then be opened with Wireshark, allowing direct parsing of MAC address, IP address, and other information within the packets.

[0141] This application maintains the continuity of packet capture logic, capturing both software-forwarded and hardware-forwarded packets. Furthermore, it allows for precise and detailed capture of software-forwarded packets. This includes capturing packets before they enter OVS to determine if communication between the FPGA and SoC is normal, and capturing packets after OVS processing and injected back into the FPGA to determine if the software OVS processing of packets is normal. In addition, this application cleverly avoids the traditional approach of dynamically adding mirror ports to the OVS bridge for packet capture. This method does not cause a large number of flow modifications to the underlying flow tables, ensuring that packets are forwarded normally along the original forwarding path, thus achieving lossless packet capture and lossless hardware flow table offloading.

[0142] To make the objectives, technical solutions, and advantages of this application clearer, the following exemplary embodiments in conjunction with specific application scenarios further illustrate this application. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit this application. Taking the packet capture method in the above method embodiments applied to two elastic soft metal servers (elastic bare metal A and elastic bare metal B) as an example, the specific implementation process is as follows:

[0143] Step 1: Install the OVS RPM package with capture functionality on the Elastic Soft Metal Server. The capture functionality described above 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 interface card of the Elastic Soft Metal Server: 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 space by default using the af-packet method.

[0144] Step 2: With elastic bare metal A and elastic bare metal B able to communicate normally and no hardware flow table for hardware unloading in the FPGA, issue a capture command on elastic bare metal 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 header), protol=TCP, and pattern="ipA >ipB:portB" in this mode (pattern). The purpose of this mode is to capture the first packet sent to OVS as a UPCALL type software forwarding packet.

[0145] Step 3: Execute the tcpdump command in smart NIC A (i.e., the smart NIC of elastic bare metal A) to capture packets on the veth-peer port.

[0146] Step 4: Establish a TCP connection with Elastic Bare Metal A as the client and Elastic Bare Metal B as the server, and monitor the portB service port of Elastic Bare Metal B. The portB service port is the service port that is enabled on the Elastic Bare Metal.

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

[0148] Step 6: Stop packet capture on the elastic bare metal A and set the capture command to capture=off to disable the capture function. Check the capture list to see if the packet capture monitoring command is empty. For example, when the capture list is empty, the corresponding packet capture operation will no longer be executed.

[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 represent the traffic direction. The purpose in this mode is to capture the REJECT type software forwarding packet sent to OVS in the first packet.

[0150] Step 8: After the hardware flow table ages, check that the hardware flow table of the hardware unloading is empty. At this time, execute the tcpdump command again on the elastic bare metal A to capture the packets on the veth-peer port.

[0151] Step 9: Reconnect the flow to the elastic bare metal A. Similarly, establish a TCP connection between elastic bare metal A as the client and elastic bare metal B as the server, and monitor port B.

[0152] Step 10: At this point, the packet captured on Smart NIC A is a TCP packet with source IP A, destination IP B, and destination port B. This captured packet is a REJECT type traffic packet sent from the host side of Elastic Bare Metal A to OVS-DPDK, and then encapsulated by OVS using VXLAN. This packet does not contain a DPE header.

[0153] Step 11: The 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 as follows: capture=on, type=hardware-forward, dpe-strip=on, protol=TCP, pattern="ipA:ipB:portB". At the same time, set a certain capture quantity threshold in the capture command, which is set to capture 10,000 packets.

[0154] Step 12: At this point, the packets captured on smart network card A are bidirectional packets after the hardware is unloaded. After capturing 10,000 packets, the capture command will automatically disappear and monitoring will be turned off.

[0155] Step 13: Re-enable packet capture on the elastic bare metal A and capture the private packets (corresponding to flow table management packets) sent by the SoC on the FLOW port for managing hardware offloading. After capturing the required number of packets, stop packet capture.

[0156] Step 14: After the hardware flow table ages, start packet capture on smart NIC A. Both elastic bare metal devices start flow capture. After the hardware flow table is issued, you can capture the ADD-FLOW management message (i.e., the flow table management message used to add flow tables) generated on the FLOW port.

[0157] It is understood that steps 1 to 14 above are only one exemplary execution process combined with a real application scenario. Obviously, this application has other implementation methods in real application scenarios, which will not be elaborated here.

[0158] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0159] Based on the same inventive concept, this application also provides a packet capture device for implementing the packet capture method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more packet capture device embodiments provided below can be found in the limitations of the packet capture method described above, and will not be repeated here.

[0160] In one embodiment, such as Figure 8 As shown, this application provides a packet capture device 800, applied to a smart network interface card (NIC). The device 800 includes:

[0161] The matching module 802 is used to match the traffic packet when it is determined that the received traffic packet is the target packet, and obtain the matching result; wherein, the target packet includes software forwarding packets or hardware forwarding packets; software forwarding packets include packets used for slow path forwarding processing; hardware forwarding packets include packets used for hardware offloading.

[0162] The packet capture module 804 is used to perform packet capture operations on traffic packets based on the matching results.

[0163] In one embodiment, the matching module 802 is further configured to: determine whether a 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 packet is a software forwarding packet, the packet type of the traffic packet is determined by the filter table based on the first packet information; the first packet information includes at least one of the following: the five-tuple of the software forwarding packet, the VXLAN ID, and the PF ID representing the port.

[0166] If the traffic packet is a hardware forwarding packet, the packet type of the traffic packet is determined by the filter table based on the second packet information; the second packet information includes at least one of the following: the hardware forwarding packet's 5-tuple, VXLAN ID, representative port PF ID, and the hardware flow table's flow_id;

[0167] Matching results are obtained based on the message type of the traffic packets.

[0168] In one embodiment, the filter table is used to distinguish message types including UPCALL, REJECT, and DROP.

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

[0170] In one embodiment, when the traffic packet is a software-forwarded packet, the packet capture module 804 is further configured to:

[0171] If the matching result determines that the traffic packet matches the UPCALL type in the filter table, then when the traffic packet is sent to the software processor, at least one copy of the traffic packet will be forwarded to the kernel space of the software processor through a preset forwarding path, and the copy will be captured.

[0172] If the matching result determines that the traffic packet matches the REJECT type in the filter table, then at least one copy of the traffic packet that is the same as the traffic packet injected from the software processor to the hardware processor will be forwarded to the kernel space through the preset forwarding path, and the copy packet will be captured.

[0173] If the matching results determine that the traffic packet matches the DROP type in the filter table, then the traffic packet is captured.

[0174] In one embodiment, when the traffic packet is a hardware-forwarded packet, the packet capture module 804 is further configured to:

[0175] If the hardware flow table corresponding to the hardware forwarding packet is determined to be an unloaded hardware flow table based on the matching results, then a capture mark is added to the unloaded hardware flow table, and the flow-id of the unloaded hardware flow table is added to the flow table monitoring list.

[0176] If the matching results determine that the hardware flow table corresponding to the hardware forwarding packet is the hardware flow table that is currently performing an offloading action, then add a capture flag to the management hardware offloading flow table and add the flow-id of the hardware flow table that is currently performing an offloading action to the flow table monitoring list; whereby, the management hardware offloading flow table is used for traffic management of hardware offloading.

[0177] Based on the preset forwarding path, the corresponding hardware forwarding packets are captured according to the capture flags on each flow table.

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

[0179] The first virtual interface and the second virtual interface are connected for communication; the first virtual interface includes a debug port on the software processor; the second virtual interface is added to the kernel mode via af-packet.

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

[0181] The flow table management message capture module is used to capture flow table management messages 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 the flow table management port used for communication connection between the software processor and the hardware processor of the smart network card.

[0182] Each module in the aforementioned packet capture device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0183] In one embodiment, this application also provides a physical server, including a smart network interface card (NIC); the smart NIC is used to perform the steps of the packet capture method described in any of the above method embodiments.

[0184] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0185] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

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

[0187] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this 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. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0188] The technical features of the above embodiments can be combined in any way. For the sake of brevity, 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 embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A packet capture method, characterized in that, Applied to smart network interface cards, the method includes: Once it is determined that the received traffic packet is the target packet, the traffic packet is matched to obtain a matching result; wherein, the target packet includes software forwarding packets or hardware forwarding packets; the software forwarding packets include packets used for slow path forwarding processing; the hardware forwarding packets include packets used for hardware offloading; Based on the matching results, perform packet capture operations on the traffic packets; The matching of the traffic packets to obtain a matching result includes: if the traffic packet is a software forwarding packet, then the packet type of the traffic packet is determined according to the first packet information through the filter table; the first packet information includes at least one of the five-tuple of the software forwarding packet, VXLAN ID, and PF ID representing the port; if the traffic packet is a hardware forwarding packet, then the packet type of the traffic packet is determined according to the second packet information through the filter table; the second packet information includes at least one of the five-tuple of the hardware forwarding packet, VXLAN ID, PF ID representing the port, and flow_id of the hardware flow table; the matching result is obtained based on the packet type of the traffic packet. When the traffic packet is a hardware forwarding packet, the step of performing packet capture operation on the traffic packet according to the matching result includes: if the hardware flow table corresponding to the hardware forwarding packet is determined to be an unloaded hardware flow table according to the matching result, then a capture mark is added to the unloaded hardware flow table, and the flow_id of the unloaded hardware flow table is added to the flow table monitoring list; if the hardware flow table corresponding to the hardware forwarding packet is determined to be a hardware flow table that is currently performing an unloading action according to the matching result, then a capture mark is added to the management hardware unloading flow table, and the flow_id of the hardware flow table that is currently performing an unloading action is added to the flow table monitoring list; wherein, the management hardware unloading flow table is used for traffic management of hardware unloading; based on a preset forwarding path, the corresponding hardware forwarding packet is captured according to the capture mark on each flow table; The preset forwarding path includes a first virtual interface and a second virtual interface; wherein, the first virtual interface and the second virtual interface are connected in communication; the first virtual interface includes a debug port on the software processor; the second virtual interface is added to the kernel mode via af-packet.

2. The method according to claim 1, characterized in that, The determination that the received traffic packet is the target packet includes: Based on the forwarding type label of the traffic packet, determine whether the traffic packet is a software forwarding packet or a hardware forwarding packet; The forwarding type label includes a software forwarding label and a hardware forwarding label; the forwarding type label is obtained from the packet header of the traffic packet.

3. The method according to claim 1, characterized in that, The filter table is used to distinguish message types including UPCALL, REJECT, and DROP. 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 back from the software processor to the hardware processor; and the DROP type is used to indicate that the traffic packets identified by the filter table are packets that need to be dropped.

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

5. The method according to claim 1, characterized in that, The method further includes: Capture flow table management messages 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 between the software processor and the hardware processor of the smart network card.

6. A packet-catching device, characterized in that, The device, applied to a smart network interface card, includes: The matching module is used to match the received traffic packet to obtain a matching result when it is determined that the received traffic packet is the target packet; wherein, the target packet includes software forwarding packets or hardware forwarding packets; the software forwarding packets include packets used for slow path forwarding processing; the hardware forwarding packets include packets used for hardware offloading. The packet capture module is used to perform packet capture operations on the traffic packets based on the matching results. The matching module is further configured to: if the traffic packet is a software forwarding packet, determine the packet type of the traffic packet based on the first packet information through the filter table; the first packet information includes at least one of the five-tuple of the software forwarding packet, VXLAN ID, and PF ID representing the port; if the traffic packet is a hardware forwarding packet, determine the packet type of the traffic packet based on the second packet information through the filter table; the second packet information includes at least one of the five-tuple of the hardware forwarding packet, VXLAN ID, PF ID representing the port, and flow_id of the hardware flow table; and obtain the matching result based on the packet type of the traffic packet. When the traffic packet is a hardware forwarding packet, the packet capture module is further configured to: if the hardware flow table corresponding to the hardware forwarding packet is determined to be an unloaded hardware flow table based on the matching result, add a capture marker to the unloaded hardware flow table and add the flow_id of the unloaded hardware flow table to the flow table monitoring list; if the hardware flow table corresponding to the hardware forwarding packet is determined to be an unloaded hardware flow table based on the matching result, add a capture marker to the management hardware unloaded flow table and add the flow_id of the unloaded hardware flow table to the flow table monitoring list; wherein, the management hardware unloaded flow table is used for traffic management of hardware unloading; based on a preset forwarding path, capture the corresponding hardware forwarding packet according to the capture marker on each flow table; The preset forwarding path includes a first virtual interface and a second virtual interface; wherein, the first virtual interface and the second virtual interface are connected in communication; the first virtual interface includes a debug port on the software processor; the second virtual interface is added to the kernel mode via af-packet.

7. A physical server, characterized in that, Includes a smart network interface card (NIC); the smart NIC is used to execute the packet capture method according to any one of claims 1 to 5.

Images