Dataplane programming with eBPF: architecture and tools

Dataplane programming with eBPF:
architecture and tools
Stefano Salsano – University of Rome Tor Vergata / CNIT
stefano.salsano@uniroma2.it
Lorenzo Bracciale – University of Rome Tor Vergata / CNIT
lorenzo.bracciale@uniroma2.it
8th IEEE International Conference on Network Softwarization
1st July 2022 // Milan, Italy

Tutorial highlights
• Software routers / packet processing devices: design choices
• Acceleration frameworks
• What is eBPF ?
• How does it work ?
2
• eBPF hello world (composition of 3 eBPF programs)
• eBPF “verification hell”
1.1
1.2
1.3 hands-on

Tutorial highlights
• eBPF network applications and frameworks
(InKeV, Polycube)
3
• eCLAT experiments
• eCLAT – eBPF Chains Language and Toolset
2.1
2.2
2.3 hands-on

The eCLAT-HIKe team
4
Andrea Mayer (HIKe lead)
Lorenzo Bracciale (eCLAT lead)
Paolo Lungaroni
Francesco Lombardo
Carmine Scarpitta
Giulio Sidoretti
Pierpaolo Loreti
Stefano Salsano

• We have reused public material available in several
presentations authored by:
Fulvio Risso, Thomas Graf, Michael Kehoe, Fabian Ruffy,
Suchakrapani Sharma
(full references at the end)
5
Ackowledgements

You can get your docker for the experiments here
• https://github.com/netgroup/eclat-docker/
tinyurl.com/eclat-docker
6
Hands-on experiments

Part 1.1
• Software routers / packet processing devices: design choices
• Acceleration frameworks
7

Dataplane programming
8
Routers
Servers
End Hosts
Firewall
Virtual Network Functions
(VNFs)

• Which are the design choices for a “Software routers” or a
“Packet processing device”, based on:
• Generic purpose processors
• Linux OS
• with the (obvious) goal to optimize the performance…
9
Dataplane Softwarization

• Routing
• Tunneling (encap/decap, e.g. VXLANs)
• NATs - NAPTs
• Firewalls
• Load Balancers
• Application-level processing
• Deep packet inspection
10
Different types of processing

Routers/Universal CPE etc
L2 Switch
VLAN/ Q-inQ
L3 Router
NAT
ACL (mac, ip, port)
11
Different types of processing
Broadband Network Gateway
L2 Switch
L3 Router
Classification
hQoS
ACL
TM (Policing, Metering)
Cloud Load Balancer
Bonding
VLAN / Q-in-Q
NAT
ACL (blacklist)
TM (policing, metering) L4
Load Balancer
Intrusion Prevention System
L2 Switch
L3 Router
Classification
NAT
ACL (mac, ip, port)

Forwarding and processing
framework/tools
• Linux Kernel
• VPP (FD.io)
• OvS
• Cilium
12
Taxonomy of solutions
Acceleration framework
(“fast IO”)
• DPDK (Hardware acceleration)
• Netmap
• eBPF

Packet processing in Linux kernel
(very simplified)
13
NIC NIC
User space
Kernel space
Driver Driver
Sockets
Read Write
Local processes
Input Output
Local
Forward

14
Source: https://commons.wikimedia.org/wiki/File:Netfilter-packet-flow.svg

Key issues
15
NIC NIC
User space
Kernel space
Driver Driver
Sockets
Read Write
Local processes
Input Output
Local
Forward
Swapping from kernel to user
and viceversa kills performance

Key issues
16
NIC NIC
User space
Kernel space
Driver Driver
Sockets
Read Write
Local processes
Input Output
Local
Forward
Kernel processing is designed
for “generality” and is not
optimized for specific use cases

Kernel bypass solution (e.g. DPDK)
17
NIC NIC
User space
Kernel space
Driver Driver
Sockets
Read Write
DPDK user space programs
Input Output
Local
Forward
DPDK
Driver
DPDK
Driver

Kernel bypass solution (e.g. DPDK)
18
Network Interface Cards (NICs)
User space
Kernel space
Network Driver
Linux Kernel
Applications
Network Interface Cards (NICs)
Network Driver
Linux Kernel
Applications
Without DPDK With DPDK
Poll-Mode Driver (PMD),
dedicated CPU(s)

• Coexistence/integration with kernel-based processing
• Hardware independence
• Interrupt mode vs. polling
• Complexity of interaction with existing features
• Security issues / risks of “freezing” the kernel
• Performance aspects
19
Considerations for in-kernel solutions
Overall requirements
Issues to be solved…

Part 1.2
• What is eBPF ?
• How does it work ?
20

eBPF provides an “in-kernel” solution addressing the issues
• Complexity… well defined interaction model with “hooks”
• Security / “freezing” “restricted” language, Virtual Machine,
verification approach
• Performance aspects specific hooks offer “high performance”
21
eBPF - extended Berkeley Packet Filter

• Virtual Machine (or Virtual CPU) running in the
Linux kernel
• Provides:
• The ability to write restricted C and run it in the kernel
• A set of kernel hook points invoking the eBPF program
• Extensible, safe and fast
• Alternative to user-space networking
22
driver
Hardware
XDP
Bridge hook
IP/routing
socket
Kernel
space
User space
eBPF XDP hook point
Your
Program
A programmable data plane in the Linux kernel!
https://ruffy.eu/presentations/p4c-xdp-lpc18-presentation.pptx
eBPF highlights

eBPF architecture
23
https://hsdm.dorsal.polymtl.ca/system/files/eBPF-5May2017%20(1).pdf

eBPF main features
• The eBPF VM implements a RISC-like assembly language in kernel space:
User-defined, “sandboxed” bytecode executed by the kernel
• The eBPF Linux module enables arbitrary code to be dynamically injected and
executed in the Linux kernel
• eBPF provides hard safety guarantees in order to preserve the integrity of the
system (e.g. eBPF does not allow unbounded loops) – eBPF Verifier
• Several “hooks” in the kernel, used to “trigger” eBPF programs (event based)
• All interactions between kernel / user space are done through eBPF “maps”
24

eBPF main features - eBPF VM (vCPU)
• eBPF VM implements a RISC-like assembly language in kernel space:
User-defined, “sandboxed” bytecode executed by the kernel
25
https://www.slideshare.net/RayJenkins1/understanding-ebpf-in-a-hurry-149197981
NB: the above bytecode is cBPF (the “old” version of eBPF)

eBPF main features – “dynamic” injection
• The eBPF Linux module enables arbitrary code to be dynamically injected and
executed in the Linux kernel
26
http://site.ieee.org/hpsr-2018/files/2018/06/18-06-18-IOVisor-HPSR.pdf
Verifier (!)

eBPF main features – safety / verifier
• eBPF provides hard safety guarantees in order to preserve the integrity of the
system (e.g. eBPF does not allow unbounded loops) – eBPF Verifier
• “Sandbox” approach => no invalid memory access
• The Verifier checks that the program has a maximum number of instructions (no
unbounded loops) and that all accesses to memory are valid
• Two main consequences:
• eBPF cannot execute arbitrary code (it’s not “Turing complete”)
• the verification is done “statically” by checking all execution paths.
Heuristics needs to be used to speed up the verification.
This results in “false positives”, i.e. programs that are rejected by the verifier although
they are valid
27

eBPF main features - hooks
• Several “hooks” in the kernel, used to “trigger” eBPF programs (event based)
• An event in the kernel can execute the eBPF code associated with its “event handler”
• Example events:
• Network packet received
• Message (socket layer) received
• Data written to disk
• Page fault in memory
• File in /etc folder being modified
28
Networking related
Other than Networking

eBPF main features - hooks
• Several “hooks” in the kernel are used to “trigger” eBPF programs (event based)
• not only for networking!
29
https://www.slideshare.net/ThomasGraf5/ebpf-rethinking-the-linux-kernel
Hooks

eBPF hooks and program types
30
https://cyral.com/blog/how-to-ebpf-accelerating-cloud-native/
• For a given hook, a specific eBPF
“program type” can be invoked.
• The “context” which is passed to
the eBPF program depends on
the hook.
• The capabilities of the eBPF
program depend on the hook, i.e.
different interactions with kernel
(helper functions) can be
invoked.

eBPF program types
31
https://www.slideshare.net/MichaelKehoe3/ebpf-basics-149201150

eBPF program types (for networking)
32
SOCKET-RELATED
• SOCKET_FILTER: Filtering actions (e.g. drop packets)
• SK_SKB: Access SKB and socket details with a view to redirect SKB’s
• SOCK_OPS – Catch socket operations
CGROUPS
• CGROUP_SKB – Allow or deny network access on IP egress/ ingress
• CGROUP_SOCK – Allow or deny network access at various socket-related events
LIGHTWEIGHT TUNNELS
• LWT_IN – Examine inbound packets for lightweight tunnel deencapsulation
• LWT_OUT – Implement encapsulation tunnels for specific destination routes
• LWT_XMIT – Allowed to modify content and prepend a L2 header
TRAFFIC CONTROL
• SCHED_CLS: A network traffic-control classifier
• SCHED_ACT: A network traffic-control action
XDP
• XDP: Allows access to packet data as early as possible (DDoS mitigation/ Load-balancing)

eBPF hooks (for networking)
33

34
Source: https://commons.wikimedia.org/wiki/File:Netfilter-packet-flow.svg
XDP_GENERIC
XDP_NATIVE
TC_INGRESS TC_EGRESS
SOCKET

XDP - eXpress Data Path
35
“Linux Kernels answer for DPDK (Released in 4.8)”
Features:
• Does not require specialized hardware
• Does not require kernel bypass
• Does not replace TCP/ IP stack
• Works with TCP/ IP stack with eBPF
XDP programs run as soon as the packet gets to the network driver
XDP programs need to exit with an action:
• XDP_TX
• XDP_DROP
• XDP_PASS

eBPF main features - maps
• The maps can be shared with user space
applications and among eBPF programs
• The eBPF programs are “stateless”:
the state is stored in the maps
• The maps helps dealing with concurrency
• Per-CPU maps
36

eBPF main features - maps
• The maps can be shared with user space
applications and among eBPF programs
• The eBPF programs are “stateless”:
the state is stored in the maps
• The maps helps dealing with concurrency
• Per-CPU maps
37

eBPF maps
38

eBPF maps
39
HASH - A hash table
ARRAY- An array map, optimized for fast lookup speeds
PROG_ARRAY - An array of FD’s corresponding to eBPF programs
PER_CPU_ARRAY - A per-CPU array, used to implement histograms
PERF_EVENT_ARRAY - Stores pointers to struct perf_event
CGROUP_ARRAY – Stores pointers to control groups
PER_CPU_HASH – A per-CPU hash table
LRU_HASH - A hash table that only retains the most recently used items
LRU_PER_CPU_HASH - A per-CPU hash table that only retains the most recently used items
LPM_TRIE - A longest-prefix match true, good for matching IP addresses
STACK_TRACE - Stores stack traces
ARRAY_OF_MAPS - A map-in-map data structure
HASH_OF_MAPS – A map-in-map data structure
DEVICE_MAP - For storing and looking up network device references
SOCKET_MAP – Stores and looks up sockets and allows redirection

eBPF helper functions (“BPF-helpers”)
BPF-helpers are “offered” by the Linux kernel and can be called from eBPF
programs. For example, they can be used to:
• print debugging messages
• get the time since the system was booted
• interact with eBPF maps
• manipulate network packets
More that 150 BPF-helpers are listed in the man page:
https://man7.org/linux/man-pages/man7/bpf-helpers.7.html
Caveat: “This manual page is an effort to document the existing eBPF helper functions. But as of this writing, the
BPF sub-system is under heavy development. New eBPF program or map types are added, along with new helper
functions. Some helpers are occasionally made available for additional program types. So in spite of the efforts of
the community, this page might not be up-to-date.”
40

eBPF tail calls
Tail calls are used to “chain” a set of independent eBPF programs.
A tail call is a “forward-only” call with no return to the calling program.
Each program is verified separately (and the number of tail call is limited in
order to guarantee the termination).
41

eBPF function calls
Recently, the concept of eBPF function calls has been introduced
(beforehand, all function calls in eBPF C code were “in-lined”)
42

Part 1.3 “hands on”
43
• eBPF hello world (composition of 3 eBPF programs)
• eBPF “verification hell”
Special thanks to Andrea Mayer for preparing these experiments

Example eBPF “chain”:
filtering, marking, counting, routing
We want to apply the following processing
1) filtering: match the IPv6 destination address in a list
2) the matching packets are “marked” by setting the TOS (aka DS-byte)
3) the matching packets are counted
4) the matching packets are forwarded, looking up the IPv6 destination address
in the kernel routing table
44

We run our experiments using the Docker container
Run the experiment:
/opt/eclat-daemon/# cd /opt/eclat-daemon/hike/testbed
/opt/eclat-daemon/hike/testbed# ./ddos_3stages_raw_testbed.sh
./ddos_3stages_raw_testbed.sh attaches a classifier to the XDP hook and loads 3 programs.
The classifier and the three programs are connected with raw tail calls.
45
Composition of 3 eBPF programs with tail calls

Key commands in ./ddos_3stages_raw_testbed.sh
mount -t bpf bpf /sys/fs/bpf/
mount -t tracefs nodev /sys/kernel/tracing # for pipetrace
bpftool prog loadall raw_ddos_mmrt.o /sys/fs/bpf/progs/rawddos type xdp
pinmaps /sys/fs/bpf/maps/rawddos
raw_ddos_mmrt.o is the object file that contains the object code of the classifier and of the 3 programs
The source file with the 3 programs (plus che initial classifier) is:
/opt/eclat-daemon/hike/src/raw_ddos_mmrt.bpf.c
46

In the source file /opt/eclat-daemon/hike/src/raw_ddos_mmrt.bpf.c it is possible to examine the
classifier and the three programs, respectively called:
• raw_classifier
• raw_ipv6_set_ecn
• raw_mon_ecn_event
• raw_ipv6_kroute
47

The script ddos_3stages_raw_testbed.sh creates a “TMUX” with two windows:
• TG – Traffic Generator
• SUT – System Under Test
48

In the traffic generator (TG) window, launch
# ping 12:1::2 a packet that is classified, marked and routed by eBPF
(ctrl-C to break)
# ping fc01::2 a packet that is NOT classified and it is routed by the kernel
(ctrl-C to break)
In the system under test (SUT) window, launch
# cat /sys/kernel/tracing/trace_pipe
(ctrl-C to break) shows the debug printout of the eBPF program
# bpftool map dump pinned /sys/fs/bpf/maps/rawddos/raw_mon_pcpu_map
shows the number of marked packets, by CPU
49

In the traffic generator (TG) window, launch
# ping -c 20 12:1::2 &>/dev/null &
it will generate 20 packets, with no display output
always in the same traffic generator (TG) window, launch
# tcpdump -l -n -e -x -v -i enp6s0f0
it will show the ping packets received back, marked with “class 0x01” i.e. ECN=1
50

Now edit the source file raw_ddos_mmrt.bpf.c
(/opt/eclat-daemon/hike/src/raw_ddos_mmrt.bpf.c)
Just uncomment the instruction
// bpf_printk("I'm gonna break'em all");
The program will be compiled but the verifier will deny loading!
51
The eBPF “verification hell”

Part 2.1
• eBPF network applications and frameworks
(InKeV, Polycube)
52

eBPF network applications
and frameworks

eBPF networking applications and frameworks
specificity
VERY specific Generic
Katran (2019)
L4Drop (2019)
Cilium (2018)
InKev (2016)
Polycube (2018)
eCLAT (2021)

eBPF networking applications
● 2019 L4Drop: created by Cloudflaire,
is a DDoS mitigation program using
eBPF and XDP
● 2019 Katran: L4 load-balancer
created by Facebook based on eBPF
and XDP
● 2018 Cilium: provide networking,
security, and observability for cloud
native environments (e.g.,
Kubernetes), supported by Google

InKev
Ahmed, Z., Alizai, M. H., & Syed, A. A. (2018). Inkev: In-kernel distributed network virtualization for dcn. ACM SIGCOMM Computer Communication
Review, 46(3), 1-6.

The goal
● Goal
○ Create a programmable platform for Network Virtualization
● What is Network Virtualization?
○ Is an abstraction to create logically isolated networking infrastructure
○ Mainly used in multi-tenant datacenters to separate the network connecting the workloads
(VMs) of each tenant
● What are Network Function and Network Service?
○ A Network Function is a traditional network appliances (e.g., bridge, router, NAT, etc.)
○ A Network Service involves multiple cooperating NFs
● What is a Virtual Network Function
○ An implementation of a Network Function in software

Expanding the in-kernel part
● Open vSwitch started putting all OpenFlow processing
into a kernel module for performance reasons
● Problems:
○ distributing and updating kernel modules
○ not accepted in upstream Linux (clearly…)
● Mitigation: divide!
○ Part in user space (e.g. ovswitchd in OVS)
○ Part in kernel space (e.g. datapath in OVS)
● Result
○ Thick user-space
○ thin implementation in the kernel not programmable
● But complex scenarios requires the flexibility of user
space
○ Performance problems again! (packet copies, context switching)

InKev approach
● Use the (new) eBPF
○ To make also the kernel part programmable
● Designs an open-Source orchestration architecture to dynamically manage
the insertion and deletion of programmable DP elements at any edge
● Now we have thicker kernel space

Virtual Network Function (VNF) e.g. router
or bridge
Network Graph Manager connects VNF to
create the the virtual network at each edge
Physical-to-Virtual Manager eBPF program
connected to TC hook
Transport Manager tunnels packets between
tenant VMs on different edges
Patch Panels: implements the actual stitching
to create a virtual graph between VNF
modules.
InKev Architecture

The code
https://github.com/zaafar/ebpf_turtle/tree/master/InKeV

Polycube
Miano, S., Risso, F., Bernal, M. V., Bertrone, M., & Lu, Y. (2021). A framework for eBPF-based network functions in an era of microservices. IEEE
Transactions on Network and Service Management, 18(1), 133-151.

The Goal
● The goal:
○ Create a common framework to network function developers
● What it provides:
○ high-level abstractions to solve common problems
○ create chain of NFs
○ system to allow remote configuration of nodes by SDN controllers,
orchestrators, network administrators
○ interoperable control plane implementations

Architecture
● Each Virtual Network Function is a
Cube
● A Cube’s fast path is composed by
one or more μCube
● Each μCube is an eBPF program
● slow path and the control/mgmt
planes are implemented in user
space

Service chaining
● A Polycube service chain uses
many cubes connected by
virtual ports
● Virtual ports are peered with a
Linux networking device or
another in-kernel NF instance
● eBPF programs do not have
the concept of port → Inserted
by the Input eBPF program
● eBPF maps are used to pass
configuration from user spaces
or to store μCube state.

The code
Polycube uses BCC
https://github.com/polycube-network/polycube

Network Functions implemented in Polycube
● Bridge
● DDoS Mitigator
● Firewall
● Dynamic Monitor
● Load Balancer (DSR)
● Packet Capture
● Policy-Based Forwarder
● Router NAT
● Iptables
● K8s Network Plugin

Part 2.2
69
• eCLAT – eBPF Chains Language and Toolset

Andrea Mayer
Lorenzo Bracciale
Paolo Lungaroni
Pierpaolo Loreti
Stefano Salsano
Giuseppe Bianchi
eBPF Chains Language And Toolset

eBPF for Network Virtualization: less joy than pain
● Joys:
○ Performance! Performance! Performance!
● Pains:
○ Require expert developers to write the code
○ …which must be verified by a picky kernel verifier
○ Lack of support for networking (eBPF was not born for that)
○ Lack of native support for modularity and composition
● How to build a framework for eBPF for Network Virtualization?
○ …re-using as much as code we can
○ …in a flexible way

eBPF
Monolith approach has obvious shortcomings…
One big eBPF program
Packet journey in eBPF
(XDP or TC
hook)
Input Output
(Drop,
Kernel
Network
Processing,
Quick reply)

eBPF
A straightforward approach to composition: chaining
eBPF programs
Program 1 Program 2 Program 3
(XDP or TC
hook)
Input Output
(Drop,
Kernel
Network
Processing,
Quick reply)
Tail call Tail call

eBPF
Problem #1: hardcoding the next hop
(XDP or TC
hook)
Input Output
(Drop,
Kernel
Network
Processing,
Quick reply)
Tail call Tail call
Program 1 holds the “address” of Program 2

Problem #1: …leaning to linear topology
➔ Patch-paneling cannot be enough (loops!)
➔ Passing value are not native (there are no function calls *)
eBPF
The next programs
depends from a state!
* https://lwn.net/ml/netdev/20200109063745.3154913-1-ast@kernel.org/

A practical example
eBPF
Fail2Ban is_blacklisted log
Implementing fail2ban in eBPF by composition.
Can we implement it with independent modules (eBPF programs)?
Custom classification
Independent monitor system
General logic

eBPF
Problem #2: programmability vs configurability of
eBPF “modules”
Firewall NAT Bridge
Tail call Tail call
● Param1
● Param2
● Param3
Can be enough for modeling many cases…
…but many custom applications are still cut out

eBPF “modules”
“If the packet rate for any IP destination D is over a
threshold R1, analyze all IP sources Sany that are
sending packet for this “overloaded” IP destination D. If
an IP source S in Sany is sending packets with a packet
rate over a threshold R2, put the IP (S, D) in a blacklist
for a duration of T seconds. During this interval T, drop
all packets in the blacklisted (S, D) couple and send a
sample of the dropped packets (e.g., one packet every
500 packets) to a collector.”
● The Firewall
○ params
● The Nat
○ params
● The Bridge
○ params
configurability programmabili
ty
How to do that?

eBPF “modules”
Eat from the
menu
Cook using raw
ingredients
Configure eBPF programs
● Easy
● Not much flexible
Write in eBPF
● Difficult
● Flexible

eBPF “modules”
Eat from the
menu
Cook using raw
ingredients
Use a
cookbook
“Higher abstraction” wrt the raw
ingredient solution
…but still very customizable
(allergic to milk? Use soya milk
instead!)

Two problems
1. Lack of good old function calling at eBPF level and poor composition ability
a. Historically eBPF only supports tail calls (no return) enabling only linear topologies
b. Change the composition of eBPF programs → change targets and recompile!
2. Lack of a high level system to express the logic
a. A patch-panel is not enough, logic can be complex and custom!
b. How different eBPF program can work together?
Two solutions
1. HIKe: brings function calling and modularity to eBPF
2. eCLAT: defines an high level language to express eBPF app logic

eCLAT
HIKe
high level language to
express eBPF app logic
Provide the eBPF support

eCLAT
HIKe
high level language to
express eBPF app logic
Provide the eBPF support
We will expand this one

Program the application logic with eCLAT Scripting
This is an eBPF program
Example of
eCLAT
script

eCLAT programs: bricks for YOUR application
Many “small” programs
Programs are shipped in
“packages”
Available on the eCLAT repo

Analogy: eCLAT and BASH Script
BASH
1. Combine independent Unix programs
2. Provide programmable environment
(variable definition, branching and looping
instruction)
3. Scripts are interpreted by BASH
eCLAT
1. Combine independent eBPF programs
2. Provide programmable environment
(variable definition, branching and looping
instruction)
3. Scripts are transpiled in eBPF and
loaded in memory by eCLAT deamon

How does it work?
1. User programs its application logic as an eCLAT script
a. The script may call functions corresponding to different, independent eBPF programs
2. eCLAT transpiles the eCLAT script in eBPF (from “python” to “C”)
a. The code produced cannot have problems with the kernel verifier. How? Thanks HIKe!
3. eCLAT downloads the necessary eBPF programs
a. Thanks to the eCLAT package manager
4. eCLAT runs everything in eBPF
a. Compile and inject the eBPF bytecode

practically?
./eclat --run myscript.eclat
That’s it

Architecture
Elements of eCLAT
1. Chains: your application logic here
2. Programs: eBPF programs slightly
modified to work with hIKE (few
lines of code needed)
3. Loaders: the entry points (rootless
eBPF program)

eBPF
eCLAT enables complex workflow
Loader 1 Chain 1 Program 3
(XDP or TC
hook)
Input Output
(Drop,
Kernel
Network
Processing,
Quick reply)
Program 1 Program 2
1
2 3
5
4
6 7 8

…expressed in an easy form, a script
“If the packet rate for any IP destination D is over a
threshold R1, analyze all IP sources Sany that are
sending packet for this “overloaded” IP destination D. If
an IP source S in Sany is sending packets with a packet
rate over a threshold R2, put the IP (S, D) in a blacklist
for a duration of T seconds. During this interval T, drop
all packets in the blacklisted (S, D) couple and send a
sample of the dropped packets (e.g., one packet every
500 packets) to a collector.”
programmabili
ty
How to do that?
With eCLAT
Remember the
complex task?

A
more
comple
x
exampl
e
Define constants
Import eBPF programs from the repo
If the flow is blacklisted,
redirect 1 packet out of 500 to a sink
And drop others
Configure the entry point
Custom profiling of flows
Monitor (count)

Conclusion
What does eCLAT do? Make programming eBPF NF easier
How? Defining an high level language and provide support at eBPF level
Where can I find available packages? http://eclat.netgroup.uniroma2.it
Docs? https://hike-eclat.readthedocs.io/
Is there a user-space packet processing? No
Quickstart? With the Docker https://github.com/netgroup/eclat-docker
Questions/collaborations? lorenzo.bracciale@uniroma2.it,
eCLAT just won a Geant Innovation Programme Award

Documentation for eCLAT
https://hike-eclat.readthedocs.io/
94

Part 2.3 “hands on”
95
• eCLAT experiments

We run our experiments using the Docker container
We demonstrate the DDoS mitigation example, implemented with the eCLAT script discussed before
The eCLAT source script is: /opt/eclat-daemon/test/eclat_scripts/ddos_tb_2_levels_sample_constants.eclat
Run the experiment:
/opt/eclat-daemon/# testbed/ddos_double_token_bucket_with_sampler.sh
96
DDoS mitigation example with eCLAT

The script ddos_double_token_bucket_with_sampler.sh creates a “TMUX” with 9 windows:
97

The script ddos_double_token_bucket_with_sampler.sh creates this virtual topology with
namespaces inside the container:
The experiment is fully described here:
https://hike-eclat.readthedocs.io/en/latest/experiments.html#ddos-mitigation-experiment
98

Roadmap / work in progress
Use eCLAT/HIKe for EIP Extensible In-band Processing
https://eip-home.github.io/eip/
EIP extends the functionality of IPv6 layer to support the
requirements of future Internet services / 6G networks.
IPv6 nodes can read/write EIP information in packet headers
(e.g. with an Option in the Hop-by-hop Extension Headers)
99

Thank you. Questions?
Contacts
Stefano Salsano
University of Rome Tor Vergata / CNIT
Lorenzo Bracciale
University of Rome Tor Vergata / CNIT
lorenzo.braccial@uniroma2.it
100

References
• Fabian Ruffy, Linux Network Programming with P4
https://ruffy.eu/presentations/p4c-xdp-lpc18-presentation.pptx
• Michael Kehoe, (c|e)BPF Basics
• Michael Kehoe, eBPF Workshop
https://www.slideshare.net/MichaelKehoe3/ebpf-workshop
• Fulvio Risso, Toward Flexible and Efficient In Kernel Network Function Chaining with
IOVisor, IEEE HPSR 2018,
• https://www.iovisor.org/technology/ebpf (quite old)
101

References
• Suchakrapani Sharma, “Trace Aggregation and Collection with eBPF” (2017)
https://hsdm.dorsal.polymtl.ca/system/files/eBPF-5May2017%20(1).pdf
• How to use eBPF for accelerating Cloud Native applications
https://cyral.com/blog/how-to-ebpf-accelerating-cloud-native/
• Thomas Graf, “Cilium - BPF & XDP for containers” (2016)
https://www.slideshare.net/Docker/cilium-bpf-xdp-for-containers-66969823
• Thomas Graf, “eBPF - Rethinking the Linux Kernel” (2020)
• Thomas Graf, “BPF & Cilium - Turning Linux into a Microservices-aware Operating
System” (2018) https://www.slideshare.net/ThomasGraf5/bpf-cilium-turning-linux-into-a-
microservicesaware-operating-system
102

Dataplane programming with eBPF: architecture and tools

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Dataplane programming with eBPF: architecture and tools

Semelhante a Dataplane programming with eBPF: architecture and tools (20)

Mais de Stefano Salsano

Mais de Stefano Salsano (18)

Último

Último (17)

Dataplane programming with eBPF: architecture and tools