Writing an eBPF/XDP load-balancer in Rust
In today's cloud ecosystem the demands for high functioning and high performance observability, security and networking functionality for applications and their network traffic are as high as ever.
Historically a great deal of this kind of functionality has been implemented in userspace, but the ability to program these kinds of things directly into the operating system can be very beneficial to performance. The operating system has been a very challenging place to dynamically add functionality in the past, often requiring the development and management of very cumbersome kernel modules, but in recent years eBPF has become a burgeoning technology in the Linux Kernel which is changing all that.
What is eBPF?
eBPF is a simple and efficient way to dynamically load programs into the kernel at runtime, with safety and performance provided by the kernel itself using a Just-In-Time (JIT) compiler and verification process. There are a variety of different types of programs one can create with eBPF, but for the purposes of this example we're going to focus on creating an XDP program which can read and modify network packets.
Our goal is to build a small program that will load-balance ingress UDP traffic by port across multiple backend servers. Once you've completed this exercise, you should have a better understanding of how XDP programs work and be able to start your journey into the eBPF community.
ⓘ Note Looking for more information on eBPF in general? Check out the What is eBPF documentation.
eBPF Rust UDP LoadBalancer Demo
ⓘ Note This example assumes a fairly strong understanding of Linux, networking, and Rust programming.
⚠ Warning At the time of writing Aya is not a mature ecosystem for eBPF development. This demonstration is missing several things you would want for a production XDP program, and Aya itself is subject to significant change in the time between now and it's first
v1 release. This is for demonstration and learning purposes only, do not use in production.
- A Linux system with Kernel
ⓘ Note This demo was built and tested on an
x86_64 machine using Arch Linux with kernel version
5.19.11 and on Ubuntu
22.04.1. It would be expected to work on most modern Linux distributions. If you're having problems or if you're using BSD, Mac, Windows, e.t.c. it may be simplest to deploy Linux in a Virtual Machine.
Install Build Tools
To get started we will need some tools to aid in building and testing our code.
If running on Arch Linux, install the following packages:
Alternatively if you're on Ubuntu:
ⓘ Note the
PATH update above is needed on Ubuntu as default users do not always have
/usr/sbin in their path and this is where tools like
bpftool will be installed (which are needed for building your XDP program).
ⓘ Note Ubuntu doesn't have
rustup in the default repositories at the time of writing: you'll need to install it manually.
Setup Rust Build Environment
For this project we'll need both a
stable and a
nightly version of the Rust compiler. We'll also need to install a few Rust build tools.
Install and set
stable Rust as your default:
nightly and it's sources so that it's available as well (this will be needed to build the part of our program which gets loaded into the kernel):
To scaffold our project, we'll need to install
bpf-linker program will be required so that our XDP program can be built and loaded into the Linux kernel properly:
bindgen will need to be installed for
C code bindings in Rust:
Scaffolding our project
On your system in a directory where you'd like the code to be located, run the following to create a new sub-directory called
demo/ which will be our project home:
ⓘ Note in the future if you want to create a BPF program type other than XDP you can run without the
-d program_type=xdp argument to get an interactive setup.
Each of these directories contains different parts of your project:
demo-ebpfthe XDP eBPF code that will be loaded into the kernel
demothe userspace program which will load and initialize the eBPF program
demo-commonshared code between the kernel and userspace code
xtaskbuild and run tooling
, but for the purposes of our demo we'll use the
interface (loopback/localhost) as most systems conventionally have this interface by default (whereas the names of other interfaces can be vary).
Update the file
demo/src/main.rs and change the default
Once this is done, we can test the provided template program:
In another terminal on the same host you can trigger this program by sending
any data to the
lo interface, e.g.:
cargo xtask run terminal, you should see the program has reported some
packets that's it's processed:
Once you're seeing the
received a packet message it's working and we can move on to adding our own packet processing logic.
Codegen for Linux types
ⓘ Note: in this section we are going to use a generator to create bindings to required types in
C that we need to inspect packets. However at the time of writing the
aya maintainers were actively working on a new crate that would take care of this for you instead, so if you're reading this some time after it's published just keep in mind this is no longer the canonical way to do this.
types that the Kernel provides to our XDP program. Aya provides a simple way to generate Rust code for these types from
. We'll add a new task to our
module which uses the
package to generate the code.
Create the file
You'll need to load the codegen code in
aya_tool dependency will need to be added to
With that in place, you can run the generators:
This will emit a file named
demo-ebpf/src/bindings.rs which contains relevant
C types that will be needed to process packets in the upcoming sections.
Processing UDP Packets
Now that you have the types generated that are needed to inspect packets, let's open our
demo-ebpf/src/main.rs file up in an editor, and navigate to the
As you saw in our testing earlier, this is the code that was executed whenever a packet was received on the
lo interface. The result was simply the emission of a
received a packet message and then the packet was passed back to the kernel.
Next we're going to inspect the packet and find important datapoints (such as the relevant protocols being used) so that we can filter out anything that isn't a UDP packet.
We will need to import some of our code generated in the previous step, and we'll define some
consts which will help us navigate the memory space of the
XdpContext object we receive on each instantiation. Add these to your
ⓘ Note: similar to the codegen tools in the previous section, new crates are being actively developed at the time of writing which will include constants like
ETH_P_IP for you.
file as well:
ⓘ Note: using the raw pointers provided by the above functions will require the
unsafe keyword in Rust as accessing the memory of the
XdpContext this way inherently is not covered by Rust's safety guarantees. If you are not familiar with unsafe Rust then it would be highly recommended to pause here and read the Unsafe Rust Book to familiarize yourself.
function we'll be able to start decoding the memory of the
object we're being passed by the kernel.
We'll start by pulling the ethernet header, and checking whether the packet we're receiving is actually an IP packet or not. Add the following to the
try_demo function in
ⓘ Note: note the use of
unsafe here as alluded to above. At this point in
aya's lifecycle raw pointers and direct memory access will be needed, particularly within the XDP program itself. This isn't ideal, but we'll still be getting Rust's memory safety guarantees elsewhere (particularly our userspace code) and also the BPF loading process in Linux includes memory safety checks for our XDP code for additional safety.
Lastly we'll decode the UDP header and check the port that the packet is coming in on:
With this our program should be reporting on any UDP packets sent to port
9875. We can test this with the following:
Now in another terminal on the same system send data via UDP on port
If everything is working properly, your program in should inform you of the ingress packet:
ⓘ Note: if you're wondering what the packet at the end of the log is (since it doesn't get reported as UDP) that is an ICMP response back to us to let us know that the port isn't available for the UDP traffic as we don't have any server listening on that port yet, so the kernel simply refused it.Now we know how to decode information from the
, next we'll try modifying the packet to change the flow of traffic.
Now that we understand how to inspect UDP packets in our XDP program, we'll try modifying the port to send packets meant for
9875 to a different port (
Before we make changes to our XDP program to support this, we'll take a second to add a small UDP listen server which will help us to illustrate our tests.
Cargo.toml file to include a new
demo-server directory in our workspace:
Create the relevant directories:
demo-server/Cargo.toml for the new crate:
Then add the programs
This program will listen on ports
9878 for UDP data and print the contents and information about them to
STDOUT, including which specific port the data came in on. This is meant to emulate different backends which we will eventually be load-balancing traffic to.
You can test the program by running the following:
In another terminal on the same system, send data to any of them:
If everything is working properly, you should see an update from the server program:
Now we're ready to upgrade our simple port redirect to a load-balancer which distributes UDP traffic between these three ports.
Routing rules with BPF maps
The kernel provides maps in BPF programs as a means for userspace programs to communicate with the underlying XDP program, and visa versa.
To allow the userspace program to inform the XDP program as to which backend ports traffic should be distributed to, we will create a
BackendPorts data-structure in
ⓘ Note: The structs that you create for BPF maps will need to be memory aligned to the value of
4), and have no padding. In the above example this is already accounted for, but in the future when you create maps with
aya you'll need to keep this in mind or the BPF verifier will refuse to load your code with
invalid indirect read from stack. See the documentation in the aya book regarding "Alignment, padding and verifier errors" for more information.
where the key is the frontend port and the value is the
object which includes a list of all the available ports for sending traffic and an index which allows us to provide round-robin style load-balancing.
We'll add a dependency on the newer version of
aya so that we have access to the
bpf::bindings module. Add the dependency to
Next we'll update our XDP program to initialize a map when loaded into the Kernel. This map will associate the inbound destination port (as the map key) with the
Backends for that port (as the map value). We'll need to add the following uses first to our
Then add the map itself to the same file:
Our userspace program will populate the map with routing data, so we'll need to update that as well. Add some uses to
And then add the following code underneath the
program.attach call to load the BPF map with data the XDP program can use to route traffic:
Backends map in place we're now in a position to use it to dynamically distribute incoming UDP traffic. Update the the
try_demo function in
demo-ebpf/src/main.rs to look like this:
In the above we retrieve the
Backends for any incoming traffic by that traffics destination port (if any), update the destination port in the packet, and then update the backends index so that the next packet will reach one of the other ports, then we pass the packet back to the kernel.
ⓘ Note: For brevity some things were left out of this demo, such as updating the IP and UDP header checksums for modified packets. For this demo they weren't required, but if you take your learning further you'll need to update your packet checksums. See the Aya Documentation for more information.You can now run your programs:
And in another terminal, start the UDP listen server:
And in one final terminal, send UDP data to port
9875 multiple times:
ⓘ Note: you'll need to
CTRL+c in between each of these commands
And that's it! You've now created a simple demonstration load-balancer that distributes UDP traffic for a given port to a number of backends.
At this point you should understand how to start a new XDP project with
aya, and the basics of how to read and manipulate information in network packets
processed by your XDP program.
From here you should be able to experiment further with things like adding more criteria for routing packets (such as source and destination IP) as well as manipulating the destination IP.
Make sure to read the Aya Book for more XDP examples, and even examples of other types of eBPF programs you can try out. Keep in mind that this example is not intended to be used as a basis for a production implementation. Happy coding!
That's it! Well, almost. For full source and further reading check out https://github.com/shaneutt/ebpf-rust-udp-loadbalancer-demo.