Use with other projects

[arash-rasooli]

Hi
How can I use this firewall with other XDP projects?

[2] Raising RLimit...
[2] Loading XDP/BPF program at '/etc/xdpfw/xdp_prog.o'...
libbpf: elf: skipping unrecognized data section(8) .xdp_run_config
libbpf: elf: skipping unrecognized data section(9) xdp_metadata
[4] Retrieving interface index for 'wlo1'...
[3] Interface index for 'wlo1' => 2.
[2] Attaching XDP program to interface 'wlo1'...
libbpf: elf: skipping unrecognized data section(7) xdp_metadata
libxdp: Existing program is not using a dispatcher, can't replace; unload first
libbpf: elf: skipping unrecognized data section(7) xdp_metadata
libxdp: Existing program is not using a dispatcher, can't replace; unload first
[0] [WARNING] Failed to attach XDP program to interface 'wlo1' using available modes (1).
[0] [ERROR] Failed to attach XDP program to any configured interfaces.

I need to use this XDP firewall in front of my L4 load balancer. I'm using Facebook's Katran

[Anbool]

I'm also looking for something similar to what you're currently experiencing. I have a web server running in the kernel that conflicts with the one used in this project, and I'm quite frustrated by this problem.

[gamemann]

Hey, I apologize for the delay!

Chaining/running XDP programs together have always been a pain from my experience because so many projects use legacy methods to load the XDP/BPF programs which don't support the required functionality. So the other XDP programs you're trying to run alongside this tool will need to support it as well.

I was able to load both this and my XDP Proxy tools at the same time. However, they were using the default priority and action. Therefore, I've added a few options to the config.h file in a recent PR I just pushed.

// Whether to enable chaining multiple XDP programs with this tool (1 = enable. 0 = disable).
#define XDP_MULTIPROG_ENABLED 1

// The XDP program's run priority (used for running multiple XDP programs together).
#define XDP_MULTIPROG_PRIORITY 10

// The action that indicates it should go onto the next program (default XDP_PASS).
#define XDP_MULTIPROG_ACTION XDP_PASS

I set the XDP Firewall priority to 10 (so it runs first) and the XDP Proxy program to 20 so it runs last. I've also confirmed program logic works in both and if I disable chaining in the XDP Firewall tool, packets will not get to the XDP Proxy program which confirms it is using the newer functionality.

root@x-dev:/home/christian# xdp-loader status
CURRENT XDP PROGRAM STATUS:

Interface        Prio  Program name      Mode     ID   Tag               Chain actions
--------------------------------------------------------------------------------------
lo                     <No XDP program loaded!>
enp1s0                 xdp_dispatcher    native   492893 63e8febd672ce2c6
 =>              10     xdp_prog_main             492828 666d6f437794ce7c  XDP_PASS
 =>              20     xdp_prog_main             492902 8e9f4c1dbfd88d66  XDP_PASS
enp7s0                 xdp_dispatcher    native   492907 63e8febd672ce2c6
 =>              10     xdp_prog_main             492828 666d6f437794ce7c  XDP_PASS
 =>              20     xdp_prog_main             492902 8e9f4c1dbfd88d66  XDP_PASS

I hope this helps!

[Emmanuel326]

Hi @arash-rasooli, following up with what I found.

The error you’re seeing (Existing program is not using a dispatcher) isn’t related to legacy vs native mode, but rather a dispatcher mismatch.

Katran uses its own custom root XDP program with a BPF_PROG_ARRAY–based tail-call dispatcher. XDP-Firewall, on the other hand, now supports chaining via libxdp’s multiprog dispatcher (xdp_dispatcher), as recently added by @gamemann.

libxdp can only chain programs that are loaded under its own dispatcher, so a program attached via a custom dispatcher (like Katran’s) cannot be automatically chained with a libxdp-managed program.

What this means in practice:

XDP-Firewall can now be chained cleanly with other libxdp-aware XDP programs using priorities and actions.

Katran’s dispatcher and libxdp’s dispatcher are separate models, so they don’t interoperate directly.

To run both together today, they would need to share the same dispatcher architecture (either both under libxdp, or both under a custom prog-array dispatcher).

You can verify libxdp-based chaining using xdp-loader status, where xdp_dispatcher appears as the root program with chained entries underneath.

This avoids manual bpftool map manipulation, but it does require all chained programs to opt into the same dispatcher model.