Shulou(Shulou.com)05/31 Report--

Today, I will talk to you about how to carry out eBPF application analysis, many people may not know much about it. In order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

Recently, I have been studying eBPF and the current application case, and found this article. This article describes the mainstream application scenarios in the market very clearly. But the degree of dissemination is not enough, and the keyword search is not the first to appear. Therefore, I also simply adjusted the next format to send out. The original link can not be found, if it involves copyright, please contact me. EBPF is a hot spot in the current network development field, and netconf also has many related topic. Later, I will implement the source code of eBPF/XDP, the application scenarios, and the current situation will also be sorted out one after another.

Introduction

The Linux kernel community recently released bpfilter, a high-performance network filtering kernel module provided by Linux BPF, to replace netfilter as the underlying kernel implementation of iptables's long-term support, and to realize the painless transition from Linux users to BPF heart replacement.

BPF may be a little new to us, but when I talk about popular network packet capture and analysis tools such as tcpdump and Wireshark, you must have heard of and may have used them. Their underlying packet filtering implementation is using BPF. So he is not a new technology, and he has been with us for a long time. At present, BPF has grown into a highly flexible and feature-rich framework, which can greatly expand the functions of Linux without sacrificing system performance and security. BPF's strong flexibility, stability and rich features make industry leaders such as Google, facebook and Netflix Linux kernel forward-looking enterprise users have extended an olive branch to it, using BPF to achieve network security, load balancing, performance monitoring, troubleshooting and other uses. The Brendan Gregg of Netflix first called it the BPF Superpowers of Linux.

The following describes how to overload the iptables kernel subsystem in these large enterprise practices, resulting in redundancy, low performance and other problems, as well as how the new kernel uses the new features to gracefully solve these problems from the bottom.

Over the past 15 years, the Linux kernel community has built many kernel subsystems, including TPC/IP stack, iptables (netfiter), and so on, and we have seen BPF develop, grow and grow step by step in the process. Now the new transformation of the kernel makes us realize that BPF is not just another function, but represents a fundamental technological transformation that will change all aspects of Linux from network to security in time. The transformation from iptables to bpfilter is only an important step for BPF to revitalize and modernize the field of Linux network stack. To explain why this exciting step has taken place, let's first introduce the historical evolution of iptables in the kernel.

The Origin of iptables and Sequential filtering

For many years, iptables has been the most important tool for implementing firewalls and network packet filters on Linux. From the original ipchains, many linux veteran drivers may have initially come into contact with ipchains, the predecessor of iptables, which was introduced in the linux kernel 2.2.10. Then iptables was introduced in 2001 when linux kernel version 2.4.0 was introduced. Since then, for many years, iptables has brought both convenience and trouble to users. On the one hand, enjoy the flexibility and quick repair. On the other hand, in order to debug 5000 heavy filtering rules and difficulties, want to scold mother for this.

When iptables began its life cycle when it replaced its predecessor, ipchains, 20 years ago, the scope of firewall functionality was simple and clear:

Protect local applications from unwanted network traffic (INPUT chain)

Protect local applications from sending unwanted network traffic (OUTPUT chain)

Filter network traffic forwarded / routed by the Linux system (FORWARD chain).

After that, the speed of the network was very slow, and the days passed very slowly. Do you still remember dialing with Modem, 201 card in the dormitory? That was when iptables was originally designed and developed. The standard practice for implementing access control lists (ACLs) with iptables is to use a continuous list of rules, that is, each network packet received or sent matches the list of rules one by one until they match or mismatch. However, line-by-line processing has obvious drawbacks: the cost of filtering packets increases linearly with the number of rules added.

Trade-off: ipset

As time went by, the speed of the network began to improve, and the rules for setting iptables increased from a dozen to thousands. Traversing sequential iptables lists has become intolerable from a performance and latency perspective.

The community quickly discovered the bottleneck: a long list of rules either rejected or allowed a separate combination of IP addresses and ports. For this reason, ipset is introduced to manage IP addresses. Ipset allows you to store a combination of IP addresses and ports in a hash table. In iptables, you only need to refer to the key name of the hash in ipset, which greatly reduces the number of iptables rules, and the IP address information in the ipset hash is resident in memory and matches very quickly. But this is only a temporary balance of "headache cures the head, foot pain cures the foot".

More unfortunately, ipset does not apply to all situations. In recent years, with the rise of container technology, an obvious problem is kube-proxy, which is a component of Kubernetes. Containers use iptables and-j DNAT rules to provide load balancing for services. It adds multiple iptables rules for each back-end service. For each service added to Kubernetes, the list of iptables rules to traverse grows exponentially. The recent KubeCon topic examines the performance details of kube-proxy in detail. The research results show that with the growth of the number of services, the network latency and performance decline are incalculable. Another major disadvantage of iptables is the inability to implement incremental updates. Each time you add a new rule, you must update the entire list of rules. The result is 160000 iptables rules for 20, 000 Kubernetes services, which take 5 hours to assemble.

The use of IP/ port-based mechanisms generally has many other obvious disadvantages, especially in container application environments. Containers need to be deployed and deleted frequently. This can lead to rapid changes in the use of individual IP addresses. An IP address may be used by a container for a few seconds, and then switched to a container after a few seconds. This puts pressure on systems that rely on secure filtering using IP addresses because all nodes in the cluster must always know the latest IP-to-container mapping. Although this is hardly difficult within a cluster, it can be challenging in distributed cross-cluster applications. We will not repeat these here, you can refer to the relevant official documents such as docker,k8s.

Unify everything with BPF

The new development of revolutionary BPF is even more exciting, which is to completely replace the kernel part (netfiter) of iptables with BPF in a completely transparent manner, that is, no changes are required to existing iptables clients and libraries.

Interested students can go to the linux kernel mailing list to find the relevant discussion. The proposal is written by Daniel Borkmann (Covalent) and the network maintenance section is written by David Miller (Red Hat) and Alexei Starovoitov (Facebook).

The following chart provided by Quentin Monnet on FRnOG 30 shows some early test results of bpfilter compared to iptables and nftables.

These early test data show impressive performance advantages and are an example of the power of BPF. The only thing we need to note is that bpfilter and BPF themselves cannot solve the performance problems caused by the use of sequential filtering by iptables. To completely solve this problem, we must use the underlying kernel of BPF and native BPF applications.

After reading the above, do you have any further understanding of how to analyze eBPF applications? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.