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

This is an example of creating a UDP load-balancer in Rust as an eXpress Data Path (XDP) type eBPF program using the aya framework.

ⓘ 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.

Prerequisites

• A Linux system with Kernel 5.8.0+

ⓘ 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:

Install 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 cargo-generate:

The bpf-linker program will be required so that our XDP program can be built and loaded into the Linux kernel properly:

Finally, bindgen will need to be installed for C code bindings in Rust:

Scaffolding our project

Aya provides a template for cargo which can be used to scaffold a new XDP program and provide a lot of the code right out-of-the-box.

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-ebpf the XDP eBPF code that will be loaded into the kernel
• demo the userspace program which will load and initialize the eBPF program
• demo-common shared code between the kernel and userspace code
• xtask build and run tooling

eth0

lo

Update the file demo/src/main.rs and change the default iface from eth0 to lo:

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.:

In the 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.

C 

/sys/kernel/btf/vmlinux

xtask

aya_tool

Create the file xtask/src/codegen.rs:

You'll need to load the codegen code in xtask/src/main.rs:

And the aya_tool dependency will need to be added to xtask/Cargo.toml:

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 try_demo function:

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 demo-ebpf/src/main.rs file:

ⓘ 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 IPPROTO_UDP and ETH_P_IP for you.

demo-ebpf/src/main.rs

ⓘ 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.

try_demo

XdpContext

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 demo-ebpf/src/main.rs:

ⓘ 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 9875:

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.

XdpContext

Port Redirection

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 (9876).

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.

Update the Cargo.toml file to include a new demo-server directory in our workspace:

Create the relevant directories:

Add a demo-server/Cargo.toml for the new crate:

Then add the programs demo-server/src/main.rs:

This program will listen on ports 9876, 9877 and 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 demo-common/src/lib.rs:

ⓘ Note: The structs that you create for BPF maps will need to be memory aligned to the value of mem::align_of::() (commonly, 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.

BackendPorts

HashMap

BackendPorts

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 demo/Cargo.toml:

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 demo-ebpf/src/main.rs file:

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 demo/src/main.rs:

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:

Enable Load-Balancing

With our 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.

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.

Next Steps

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!

Conclusion

That's it! Well, almost. For full source and further reading check out https://github.com/shaneutt/ebpf-rust-udp-loadbalancer-demo.