A traffic acquisition method and system based on eBPF

By combining eBPF and VXLAN virtual appliances in a Kubernetes environment, a lightweight traffic collection method was implemented, which solved the problem of traffic collection under high concurrency and high change frequency, met the needs of traffic analysis and security detection, and supported the expansion of the collection end.

CN122137794APending Publication Date: 2026-06-02HANGZHOU HARMONYCLOUD TECH CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
HANGZHOU HARMONYCLOUD TECH CO LTD
Filing Date
2026-03-10
Publication Date
2026-06-02

AI Technical Summary

Technical Problem

In a Kubernetes environment, existing traffic collection methods suffer from low performance, high resource consumption, high policy linkage complexity, and difficult operation and maintenance in high-concurrency and high-change-frequency scenarios, making it difficult to efficiently achieve traffic guidance and analysis under cloud virtual network conditions.

Method used

The traffic collection method based on eBPF is adopted. Traffic identification and filtering are performed in kernel space through mapping table to generate tunnel metadata. The encapsulation and transmission are completed in kernel space using VXLAN virtual device, avoiding the resource overhead caused by user space transfer and copying, and realizing lightweight traffic encapsulation and forwarding.

Benefits of technology

It reduces the complexity of BPF, lowers CPU and memory overhead, avoids bandwidth pressure on cloud virtual networks, supports traffic analysis and security detection needs in Kubernetes environments, and supports horizontal scaling of the data collection end.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122137794A_ABST
    Figure CN122137794A_ABST
Patent Text Reader

Abstract

This invention discloses a traffic acquisition method and system based on eBPF, belonging to the field of digital information transmission technology. The method includes: filtering first metadata based on the mapping relationship between indicators, network identifiers, and target locations; obtaining second metadata along with its network identifier and target location; generating tunnel metadata; and sending the tunnel metadata to a VXLAN virtual device. The first metadata is filtered and marked using a mapping table; the identification and redirection of the first metadata are completed in kernel mode, avoiding resource overhead caused by user-mode transfer and copying; only the filtered traffic is mirrored, avoiding bandwidth pressure on the cloud virtual network caused by full mirroring; packet encapsulation is uniformly processed by the kernel-mode VXLAN virtual device, reducing the complexity of header processing and the risk of failure; the mapping table updates changes to the objects of the first node, reducing manual maintenance; and meeting the needs of traffic analysis, auditing, and security detection.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of digital information transmission technology, specifically to a traffic acquisition method and system based on eBPF. Background Technology

[0002] In cloud-native (Kubernetes) environments, services are deployed in Pods / Workloads as the smallest unit, with frequent instance elastic scaling and migration, and rapid changes in network topology and IP / port mappings. To meet requirements for observability, intrusion detection, auditing and forensics, and canary analysis, it is often necessary to copy and send a portion of network traffic to a specified target location, such as analysis / security / collection nodes, to achieve granular traffic analysis of specific namespaces, workloads, or services. In traditional virtual machine or physical machine environments, common solutions include: User-space packet capture and forwarding based on AF_PACKET: User space sends and receives Layer 2 frames via the AF_PACKET raw socket, modifies them as needed, and forwards them to another interface. AF_PACKET is the interface for interaction between user space and the Linux kernel network stack. User space directly sends and receives Ethernet frames via the AF_PACKET raw socket, which is a Layer 2 send / receive and forwarding method. This involves kernel / user space round trips, copying, and system call overhead; the forwarding efficiency is much lower than the kernel-space forwarding path, and CPU usage and packet loss risks are significant in high-concurrency scenarios.

[0003] TC-based BPF redirection / mirroring: A BPF application is loaded at the TC ingress / egress hook point, redirecting or mirroring traffic to a specific interface or user-space handler. Some packet sending and receiving implementations require header expansion or contraction, and encapsulation / decapsulation are performed in user space, which poses a risk of impacting the original business application and network stack behavior.

[0004] Patent CN121000642A discloses a traffic acquisition method and device. A third eBFP program receives a first traffic flow and a second traffic flow, encapsulates them, and sends them to the traffic control TC output direction of the physical forwarding interface, which then transmits them to the target storage device. The encapsulation / decapsulation is performed by the third eBFP program in user space, increasing complexity and risk.

[0005] It is evident that in Kubernetes scenarios with large-scale high concurrency and high change frequency, the above common solutions have significant shortcomings in terms of performance, resource consumption, policy linkage and operation and maintenance complexity: redirecting traffic to user space or relying on external switches / bypass devices to achieve forwarding is difficult to implement or too costly under cloud virtual network conditions.

[0006] Therefore, it is necessary to design a lightweight traffic collection method and system to reduce the complexity of eBFP and achieve lightweight traffic encapsulation and forwarding. Summary of the Invention

[0007] To address the aforementioned technical problems in the existing technology, this invention provides a traffic acquisition method and system based on eBPF, which accurately identifies traffic and achieves lightweight encapsulation of traffic.

[0008] The first aspect of this invention discloses a traffic collection method based on eBPF, comprising the following steps: collecting first metadata of a first node; obtaining a mapping table of the first metadata, the mapping table including a mapping relationship between indicators, network identifiers, and target locations; filtering and mirroring the first metadata according to the mapping relationship to obtain second metadata, its network identifier, and at least one target location; generating tunnel metadata according to the second metadata, its network identifier, and the target location; sending the tunnel metadata to a VXLAN virtual device; encapsulating the tunnel metadata through the VXLAN virtual device to obtain a mirrored packet, and sending the mirrored packet to the target location.

[0009] Preferred methods for unsealing mirrored packets include: Upon receiving the image message, the image message is decrypted to obtain third-party metadata; Based on the network identifier and mapping relationship, identify the metric and metric value to which the third metadata belongs.

[0010] Preferably, the metrics for the mapping table are selected from: namespace, workload, container group, IP, port, and tag; The target location includes the VTEP address, and the network identifier is VNI; In the tunnel metadata, tunnel_id is set to VNI, and remote_ipv4 / remote_ipv6 is set to the VTEP address of the target location; The tunnel metadata also includes any of the following fields or a combination thereof: TOS, TTL, DF flag, checksum policy.

[0011] Preferably, the mapping table is written into the BPF map of the first node by the K8S management module; The mapping table is dynamically deleted and modified by the K8S management module.

[0012] Preferably, the mapping relationship includes: Map container group IPs or service IPs to workloads or policy domains; The workload or policy domain is mapped to the network identifier, the list of target locations, VXLAN_IFINDEX, and the rate limit. The target location list includes at least one target location.

[0013] Preferred methods for data collection and statistics include: Based on eBPF, perform statistical analysis on any of the following data or combinations thereof, and report the results to the Kubernetes management module: The number of times the mapping table was hit, the number of bytes of the first metadata, the second metadata, and the tunnel metadata, the reason for the first metadata being discarded, and the encapsulation failure.

[0014] Preferably, bpf_skb_set_tunnel_key() is called to generate tunnel metadata; Call bpf_clone_redirect() to send tunnel metadata to the VXLAN virtual device.

[0015] Preferably, the first metadata is filtered and mirrored in kernel mode; tunnel metadata is generated in kernel mode. VXLAN virtual devices are deployed in kernel mode.

[0016] A second aspect of the present invention provides a data acquisition system for implementing the above-described traffic acquisition method, comprising an acquisition module, an eBPF module, and a VXLAN management module; The eBPF module includes a mapping management submodule and a tunnel metadata generation submodule; The acquisition module is used to acquire the first metadata of the first node; The mapping management submodule is used to obtain the mapping table of the first metadata; The tunnel metadata generation submodule is used to filter and mirror the first metadata according to the mapping relationship of the mapping table to obtain the second metadata, its network identifier, and at least one target location; it is also used to generate tunnel metadata according to the second metadata, its network identifier, and the target location. The VXLAN management module is used to create and manage VXLAN virtual devices. VXLAN virtual devices are used to encapsulate tunnel metadata, generate mirror packets, and send the mirror packets to the target location.

[0017] Preferably, the data acquisition system also includes a Kubernetes (K8S) management module. The K8S management module is used to distribute the mapping table to the BPF map of the first node; The mapping management submodule reads the mapping table from the BPF map; The tunnel metadata generation submodule is also used to count the number of times the mapping table is hit, the number of bytes of the first metadata, the second metadata and the tunnel metadata, the reason for the first metadata being discarded, and the encapsulation failure, and report them to the K8S management module. The target location is equipped with an unblocking module and an identification module. The unblocking module is used to unblock the mirrored message and obtain third-party metadata. The identification module is used to extract the indicator and indicator value to which the third-party metadata belongs based on the network identifier.

[0018] Compared with existing technologies, the advantages of this invention are as follows: First metadata is filtered and marked through a mapping table; identification and routing of first metadata are completed in kernel mode, avoiding resource overhead caused by user-mode migration and copying; only filtered traffic is mirrored, avoiding bandwidth pressure on the cloud virtual network caused by full mirroring; packet encapsulation is uniformly handled by the kernel-mode VXLAN virtual device, reducing the complexity and failure risk of header processing in BPF; object changes of the first node are updated through the mapping table, reducing manual maintenance; it meets the traffic analysis, auditing, and security detection requirements in the Kubernetes environment and supports horizontal scaling of the collection end. Attached Figure Description

[0019] Figure 1 This is a flowchart of the traffic acquisition method based on eBPF of the present invention; Figure 2 This is the logical block diagram of the data acquisition system. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] The present invention will now be described in further detail with reference to the accompanying drawings: Example 1 provides a traffic collection method based on eBPF, such as... Figure 1 As shown, it includes the following steps: Step S1: Collect the first metadata of the first node.

[0022] The first node can be a cloud node, a container, a container group Pod, etc.

[0023] Step S2: Obtain the mapping table of the first metadata, which includes the mapping relationship between indicators, network identifiers, and target locations.

[0024] The metrics include: namespace, workload_name, container group (POD), IP address, port, and tag.

[0025] Step S3: Using eBPF and the mapping relationship, filter, copy / mirror the first metadata to obtain the second metadata, its network identifier, and at least one target location.

[0026] Step S4: Generate tunnel metadata based on the second metadata, its network identifier, and the target location.

[0027] Specifically, the target location includes the VTEP address, and the network identifier is the VNI. The tunnel_id in the tunnel metadata is set to the VNI, and remote_ipv4 / remote_ipv6 is set to the VTEP address of the target location. The tunnel metadata can also set fields such as TOS, TTL, DF flag, and checksum policy. ToS stands for Type of Service; TTL represents Time to Live; the DF flag is the fragmentation flag, DF = 1 disables fragmentation, and DF = 0 enables fragmentation. The target location is a second node different from the first node.

[0028] Step S5: Send the tunnel metadata to the VXLAN virtual device.

[0029] Step S6: Encapsulate the tunnel metadata through a VXLAN virtual device to obtain a mirror packet, and send the mirror packet to the target location.

[0030] The message includes an outer IP header, a UDP header, a VXLAN header (including a VNI field), and the original Layer 2 frame / inner message. Encapsulation is performed within the kernel's VXLAN virtual device, automatically reusing existing kernel capabilities to handle MTU, fragmentation, GSO / GRO, checksums, etc., thereby achieving lightweight, efficient, and stable transmission.

[0031] Step S7: After receiving the mirror message, the endpoint at the target location decrypts the mirror message and obtains the third metadata.

[0032] Step S8: Identify the metric and metric value to which the third metadata belongs based on the network identifier and mapping relationship.

[0033] Metrics and metric names can be obtained through mapping tables and network identifiers (VNIs); third-party metadata can also be isolated through VNIs.

[0034] This invention filters and marks primary metadata through a mapping table; it completes the identification and redirection of primary metadata in kernel mode, avoiding CPU and memory overhead caused by user-mode transfer and copying; it only mirrors the filtered traffic, avoiding bandwidth pressure on the cloud virtual network caused by full mirroring; VXLAN encapsulation is handled uniformly by the kernel device, reducing the complexity and failure risk of header processing in BPF; it updates changes to objects on the primary node through the mapping table, reducing manual maintenance; it can filter and mirror traffic to one or more specified locations based on workload, IP, port, and other conditions, meeting the traffic analysis, auditing, and security detection needs in the Kubernetes environment, and supporting horizontal scaling of the collection end.

[0035] In step S1, the List-Watch mechanism can be used to monitor changes in objects such as namespace, workload (Deployment / StatefulSet / DaemonSet, etc.), Pod, Service / Endpoint, etc., and obtain metadata such as PodIP, exposed port, tag, and node.

[0036] The network data in the metadata consists of a 5-tuple, including source / destination IP, source / destination port, protocol, etc.

[0037] In step S2, the first metadata can be filtered and associated using preset policies and their corresponding mapping tables to form "traffic attribution" and "policy domains." A policy domain is a combination of policies used for traffic management. Filtering can be done by namespace / workload tags, port, protocol, sampling rate, etc., and can be selected and set according to the business scenario.

[0038] In one specific embodiment, the dataset of second metadata is obtained by filtering by workload, and one or more target locations can be assigned to these second metadata. A unique network identifier (VNI) is assigned to each workload of the second metadata, and the mapping relationship between workload and VNI is maintained through a mapping table, but not limited thereto.

[0039] It can also assign one or more target locations to workloads, including target VTEP IPv4 / IPv6, target port, weight / priority, etc., and can dynamically update the target locations in the mapping table based on network connectivity status.

[0040] The strategies and their mapping tables can be written into the BPF map of the first node by the K8S management module, and dynamic deletion and modification are supported.

[0041] In one specific embodiment, the mapping relationship is represented as follows: PodIP / ServiceIP {workload_id / policy_id}; workload_id {VNI, list of target locations (set of target VTEPs), VXLAN_IFINDEX, rate limit, etc.}. PodIP / ServiceIP is mapped to the workload; the workload is mapped to the network identifier, list of target locations, VXLAN_IFINDEX, and rate limit, where the list of target locations includes at least one target location.

[0042] In steps S3 and S4, eBPF is mounted on the target network interface card / virtual network interface card TC ingress hook point to perform operations such as identification, filtering, statistics, writing tunnel metadata and mirroring traffic redirection.

[0043] eBPF performs statistics on the number of mapping table hits, the number of bytes of the first metadata, second metadata, and tunnel metadata, the reason for the first metadata being discarded, encapsulation failures, etc., and reports them to the K8S management module.

[0044] In step S4, tunnel metadata can be written by calling bpf_skb_set_tunnel_key().

[0045] Optionally, multi-target location processing is supported. For the VTEP address of each target location, the corresponding remote_ipv4 / remote_ipv6 is written and cloned / mirrored once, so as to realize "the same second metadata is mirrored to multiple collection nodes at the same time" and realize the horizontal expansion of the collection end.

[0046] In steps S5 and S6, the VXLAN virtual device operates in "tunnel metadata" mode, which is used to complete encapsulation / transmission based on the tunnel metadata written by BPF.

[0047] In step S5, bpf_clone_redirect() can be called to send tunnel metadata to the ifindex of the VXLAN virtual device. The bpf_clone_redirect function serves as an implementation method to import a specified traffic mirror copy that has been written into the tunnel metadata into the VXLAN device.

[0048] In a Kubernetes environment, this invention generates and maintains a mapping relationship of "workload VNI target acquisition endpoint (target VTEP / acquisition node) list" in real time based on the workload and sends it to the BPF map. This enables eBPF to write tunnel metadata without modifying the original service packets and drive the kernel VXLAN virtual device to encapsulate and send the second metadata according to the target acquisition endpoint, thereby forming a dynamically updatable and multi-destination scalable traffic mirroring acquisition closed loop.

[0049] The VXLAN message format and its encapsulation / decapsulation process are existing technologies and will not be described further in this invention. Since the encapsulation is completed within the kernel VXLAN device, existing kernel capabilities can be automatically reused to handle MTU, fragmentation, GSO / GRO, checksums, etc., thereby achieving lightweight, efficient, and stable transmission.

[0050] The second metadata remains unchanged and continues to be processed normally along the kernel protocol stack, thus ensuring business continuity; the tunnel metadata does not change the actual byte content of the packet, and the traffic collection link does not interfere with the original business link.

[0051] In steps S7 and S8, the endpoint of the target location identifies its policy domain / workload through the VNI in the VXLAN header, and the corresponding policy domain / workload can be looked up through the mapping relationship of the mapping table.

[0052] This invention uses a mapping table to filter and mark primary metadata, avoiding the transmission of full traffic. The marked values ​​are converted into kernel executable parameters, enabling automatic traffic collection throughout the lifecycle of the primary node Pod and allowing for traffic redirection via mirroring. Furthermore, it supports differentiated configuration and expansion based on metric dimensions and target locations.

[0053] eBPF is only responsible for the identification, filtering, and isolation of the first metadata, as well as the generation of tunnel metadata. Encapsulation and transmission are handled by the kernel VXLAN virtual device, which reduces program complexity and improves stability. The VXLAN virtual device can be reused within the first node.

[0054] By using cloning to redirect traffic, the original business package remains unmodified and its original path is not changed, thus avoiding any impact on business continuity; at the same time, sampling or rate limiting can be enabled as needed to control mirror overhead.

[0055] Tunnel element generation and packet encapsulation are both completed in kernel mode, enabling high-speed and efficient traffic collection and mirroring.

[0056] Example 2 provides a data acquisition system, such as Figure 2 As shown, it includes acquisition module 1, eBPF module 2, K8S management module 3, and VXLAN management module 4; eBPF module 2 includes mapping management submodule 5 and tunnel metadata generation submodule 6, which can be implemented through eBPF programs; The acquisition module 1 is used to acquire the first metadata of the first node. Multiple acquisition modules 1 can be arranged within the first node.

[0057] The mapping management submodule 5 is used to obtain the mapping table of the first metadata.

[0058] The tunnel metadata generation submodule 6 is used to filter and mirror the first metadata according to the mapping relationship of the mapping table to obtain the second metadata and its network identifier and at least one target location; it is also used to generate tunnel metadata according to the second metadata and its network identifier and target location.

[0059] The tunnel metadata generation submodule 6 is also used to perform statistics on the number of hits in the mapping table, the number of bytes of the first metadata, the second metadata and the tunnel metadata, the reason for the first metadata being discarded, the encapsulation failure, etc., and report them to the K8S management module 3.

[0060] VXLAN management module 4 is used to create and manage VXLAN virtual devices. VXLAN virtual devices are used to encapsulate tunnel metadata, generate mirror packets, and send the mirror packets to the target location.

[0061] The K8S management module 3 distributes the mapping table to the first node, receives statistical data uploaded by the first node, and is also used to update the configuration of the eBPF module.

[0062] The target location is equipped with an unblocking module and an identification module. The unblocking module is used to unblock the mirrored message and obtain third-party metadata. The identification module is used to extract the indicator and indicator value to which the third-party metadata belongs based on the network identifier.

[0063] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A traffic acquisition method based on eBPF, characterized in that, Includes the following steps: Collect the first metadata of the first node; Obtain a mapping table of first metadata, the mapping table including the mapping relationship between indicators, network identifiers and target locations; Based on the mapping relationship, the first metadata is filtered and mirrored to obtain the second metadata, its network identifier, and at least one target location; Based on the second metadata, its network identifier, and target location, tunnel metadata is generated; Send the tunnel metadata to the VXLAN virtual device; The tunnel metadata is encapsulated using a VXLAN virtual device to obtain a mirror packet, which is then sent to the target location.

2. The flow rate acquisition method according to claim 1, characterized in that, It also includes methods for unblocking mirrored packets: Upon receiving the image message, the image message is decrypted to obtain third-party metadata; Based on the network identifier and mapping relationship, identify the metric and metric value to which the third metadata belongs.

3. The flow rate acquisition method according to claim 1, characterized in that, The mapping table metrics are selected from: namespace, workload, container group, IP, port, and tag; The target location is the VTEP address, and the network identifier is the VNI. In the tunnel metadata, tunnel_id is set to VNI, and remote_ipv4 / remote_ipv6 is set to the VTEP address of the target location; The tunnel metadata also includes any of the following fields or a combination thereof: TOS, TTL, DF flag, checksum policy.

4. The flow rate acquisition method according to claim 3, characterized in that, The mapping table is written into the BPF map of the first node by the K8S management module; The mapping table is dynamically deleted and modified by the K8S management module.

5. The flow rate acquisition method according to claim 3, characterized in that, The mapping relationship includes: Map container group IPs or service IPs to workloads or policy domains; The workload or policy domain is mapped to the network identifier, the list of target locations, VXLAN_IFINDEX, and the rate limit. The target location list includes at least one target location.

6. The flow rate acquisition method according to claim 1, characterized in that, It also includes methods for data collection and statistics: Based on eBPF, perform statistical analysis on any of the following data or combinations thereof, and report the results to the Kubernetes management module: The number of times the mapping table was hit, the number of bytes of the first metadata, the second metadata, and the tunnel metadata, the reason for the first metadata being discarded, and the encapsulation failure.

7. The flow rate acquisition method according to claim 1, characterized in that, Call bpf_skb_set_tunnel_key() to generate tunnel metadata; Call bpf_clone_redirect() to send tunnel metadata to the VXLAN virtual device.

8. The flow rate acquisition method according to claim 1, characterized in that, Filter and mirror the first metadata in kernel mode; generate tunnel metadata in kernel mode; VXLAN virtual devices are deployed in kernel mode.

9. A data acquisition system for implementing the traffic acquisition method as described in any one of claims 1-8, characterized in that, Includes a data acquisition module, an eBPF module, and a VXLAN management module; The eBPF module includes a mapping management submodule and a tunnel metadata generation submodule; The acquisition module is used to acquire the first metadata of the first node; The mapping management submodule is used to obtain the mapping table of the first metadata; The tunnel metadata generation submodule is used to filter and mirror the first metadata according to the mapping relationship of the mapping table to obtain the second metadata, its network identifier, and at least one target location; It is also used to generate tunnel metadata based on the second metadata, its network identifier, and the target location; The VXLAN management module is used to create and manage VXLAN virtual devices. VXLAN virtual devices are used to encapsulate tunnel metadata, generate mirror packets, and send the mirror packets to the target location.

10. The data acquisition system according to claim 9, characterized in that, It also includes a Kubernetes (K8S) management module. The K8S management module is used to distribute the mapping table to the BPF map of the first node; The mapping management submodule reads the mapping table from the BPF map; The tunnel metadata generation submodule is also used to count the number of times the mapping table is hit, the number of bytes of the first metadata, the second metadata and the tunnel metadata, the reason for the first metadata being discarded, and the encapsulation failure, and report them to the K8S management module. The target location is equipped with an unblocking module and an identification module. The unblocking module is used to unblock the mirrored message and obtain third-party metadata. The identification module is used to extract the indicator and indicator value to which the third-party metadata belongs based on the network identifier.