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 kerneldemo
the userspace program which will load and initialize the eBPF programdemo-common
shared code between the kernel and userspace codextask
build and run tooling
eth0
, but for the purposes of our demo we'll use the lo
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 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
types that the Kernel provides to our XDP program. Aya provides a simple way to generate Rust code for these types from /sys/kernel/btf/vmlinux
. We'll add a new task to our xtask
module which uses the aya_tool
package to generate the code.
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 const
s 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
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.
try_demo
function we'll be able to start decoding the memory of the XdpContext
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 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.
Now we know how to decode information from theXdpContext
, next we'll try modifying the packet to change the flow of traffic.
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
in a HashMap
where the key is the frontend port and the value is the BackendPorts
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 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.
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.
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.