►
From YouTube: Getting Linux Based eBPF Programs to Run with eBPF for Windows - Poorna Gaddehosur & Anurag Saxena
Description
Getting Linux Based eBPF Programs to Run with eBPF for Windows - Poorna Gaddehosur, Microsoft & Anurag Saxena, Microsoft
At Microsoft, we started on the eBPF for Windows story as a recognition of the engineering agility that eBPF as a technology has fostered in the developer community. A fundamental goal for us with this effort has been to meet the developers where they are and because of this, enabling eBPF programs written for Linux to run on top of the eBPF for Windows platform is very important to us. What better way to demonstrate this than a very relevant real world use case! With help from Cilium devs, we have been working to get the Cilium Layer-4 Load Balancer (L4LB) eBPF program running on eBPF for Windows. In this presentation, we will talk about the path we took towards enabling the Cilium L4LB eBPF program on top of eBPF for Windows. We will provide a demo of the work and provide the information required for any developer to try this out on their own. The eBPF-for-Windows platform is fully open sourced and so is the demo code and the instructions required to run it.
A
Hello:
everyone,
my
name
is
anurak
sakshena,
I'm
currently
working
as
a
principal
engineer
in
coreos
networking
team
at
microsoft,
my
co-presenter
is
puna
gadda
hosur,
who
is
principal
group
engineering
manager
in
coreos
networking
organization
at
microsoft.
This
talk
is
to
demonstrate
how
linux
based
avpf
programs
can
be
run
using
evpl
for
windows.
A
The
agenda
for
this
talk
is:
we
will
go
over.
What
are
the
goals
for
this
presentation?
We
will
then
look
at
an
overview
of
cml
for
lb
on
linux.
We
will
then
have
an
overview
of
psyllium
l4
lb
using
ebp
for
windows.
We
will
then
go
through
the
demo
topologies
and
then
see
a
live
demo
of
pseleum
load
balancer
running
on
windows.
A
A
fundamental
goal
of
this
effort
is
to
meet
the
developers
where
they
are,
and
because
of
this,
it
is
important
to
ensure
and
demonstrate
portability
of
ebpf-based
solutions
which
are
in
production
today
from
linux,
to
windows
and
to
be
able
to
achieve
this
with
minimum
possible
changes
today.
To
demonstrate
this,
we
are
using
standalone,
psyllium,
l4
load,
balancer
solution,
psyllium
l4
lb
solution
uses
an
xtp
hook
to
implement
load
balancing
and
it
supports
both
source,
nat
and
dsr
modes.
A
To
give
a
quick
overview
of
linux
based
serial
alpha
led
solution,
it
uses
an
xtp
hook
with
xtpx
action
to
implement
the
lb
functionality.
Xtptx
is
one
of
the
actions
supported
by
xtp
hook,
which
basically
happens
the
packet
out
of
the
neck
on
which
it
arrived.
The
psyllium
xdb
program
also
uses
some
helper
functions,
such
as
xtp
adjust
head,
adjust
tail.
It
also
uses
map
lookup
and
update
helper
functions,
and
it
uses
tail
calls
apart
from
the
evpf
program,
which
implements
the
core
lb
functionality.
A
Psyllium
solution
also
consists
of
a
user
mode
cli
and
an
agent
which
compiles
loads
and
attaches
the
ebpf
program
in
linux.
This
agent
and
cli
is
also
responsible
for
taking
service
details
as
input
and
configuring.
The
required
front-end
backend
details
in
the
evpf
maps
for
load
balancing
the
traffic
between
back
end
celium
uses
maglev
hashing
algorithm
maglev
is
a
consistent,
hashing
algorithm
which
ensures
that
if
one
of
the
lv
nodes
goes
down,
the
other
lb
nodes
will
also
choose
the
same
backend.
For
that
five
double
traffic
for
demonstrating
pselium,
l4
lb
on
windows.
A
We
have
a
psyllium
agent
and
cli
inspired
user
mode
demo
agent
written
this
demo
agent
performs
the
same
tasks
of
compiling
and
installing
the
celium
http
program,
taking
an
lb
service
instance
as
input
and
configuring,
the
required
evpf
maps
for
load
balancing
to
work.
The
psyllium
ebpf
program
used
in
windows
is
almost
identical
to
the
program
used
on
linux.
95
to
96
of
the
code
is
common
to
both
linux
and
windows.
A
A
This
slide
shows
the
architecture
for
psyllium
l4
lv
using
evp
for
windows.
To
start
with,
we
have
the
ebp
of
a
windows
framework
already
installed
on
the
lb,
node
and
evpf
service
execution
context,
and
the
netevp
extension
which
implements
the
xtp
hook,
are
already
running
on
the
system.
Now,
when
a
psyllium
agent
is
initialized,
a
mode
is
provided
to
it
as
input
snap
or
dsr.
This
input
is
needed,
as
the
xtp
program
needs
to
be
compiled
for
a
specific
mode.
The
agent
also
gets
the
interface
name
as
an
input.
A
Once
the
agent
gets
these
as
input
it
fetches.
The
interface
properties
then
compiles
the
evpf
program
using
the
interface
properties
and
the
mode
it
was
provided
and
then
verifies
loads
and
attaches
the
program
to
the
xtp
hook
as
part
of
loading.
The
program,
the
required
maps,
are
also
created
in
the
kernel.
Now
that
the
xtp
program
is
loaded
and
attached,
the
agent
is
now
ready
to
take
input
for
any
lb
service
instance.
A
Now,
when
a
service
is
configured,
the
agent
gets
a
front-end
and
back-end
configuration.
Front-End
configuration
consists
of
the
front-end
ipn
port
and
back-end
configuration
consists
of
a
list
of
backend
ips
and
ports.
Once
the
agent
gets
this
information,
it
computes
a
maglev
hash
for
the
back-ends
in
the
service
and
updates
it
in
the
maglev
map.
It
also
updates
the
back-end
maps
service
maps
and
the
reverse
net
maps.
Now
the
control
path
is
set
up
for
the
load
balancing
to
work
for
the
configured
service,
moving
to
the
data
path.
A
So
when
an
incoming
packet
arrives
on
the
neck,
the
xtp
extension
invokes
the
psyllium
xdb
program.
The
http
program
then
inspects
the
incoming
packet
consults
the
various
maps
which
are
programmed
by
the
user
mode
agent
to
choose
a
backend
node
and
then,
depending
on
whether
snap
or
dsr
is
configured
either
so
snaps
the
packet
or
does
an
ip
and
ipn
cap.
The
packet
is
then
returned
to
the
extension
with
xdp
tx
action,
which
means
the
packet
is
need
to
be
hairpin
on
the
arriving
nick.
A
This
slide
shows
the
topology
for
the
demo
setup
for
demo.
We
are
using
five
vms.
One
of
the
vms
is
the
load
balancer
vm.
It
is
a
windows
server
and
has
celium
xtp
program
running
on
it.
The
other
four
machines
are
backend
nodes.
Two
of
the
backend
nodes
are
windows,
vms
and
the
other
two
are
open
to
linux.
Vms.
All
the
five
vms
are
connected
by
an
internal
switch
and
are
on
the
same
network.
The
ips
that
we
are
using
here
are
211
for
the
lb,
node
and
2110
to
21.40.
A
For
the
back
end
nodes.
The
whip
used
in
this
demo
is
411,
which
is
not
in
the
same
network
as
the
other
error
type
is,
since
this
is
an
internal
switch.
The
host
will
also
be
connected
to
the
same
switch
and
will
act
as
a
client
for
sending
requests
to
the
lb
node.
All
the
backend
servers,
the
four
packet
servers
are
running
a
web
server
listening
on
port
80.
A
So
for
snap
scenario
this
is
how
the
packet
flow
looks
like
the
browser
sends
a
request
using
its
source,
ip21100
some
source
port
x
and
sends
the
request
to
41
1
source
port
destination
port
80.
Once
the
lb
node
gets
this
packet,
it
chooses
one
of
the
backends
to
send
the
request
to,
and
then
in
case
of
a
snap
scenario,
it
so
snatch
the
packet
and
forwards
the
request
to
the
chosen
backend.
So
the
packet
on
the
wire
looks
like
with
source
ip
211,
which
is
the
ip
of
the
lb
node.
A
This
slide
shows
the
topology
for
the
dsr,
which
is
almost
similar
to
the
one
in
snap,
but
with
a
few
differences
since
in
dsr
the
packet
is
ipip
and
capped
on
the
lb
node.
The
backend
node
will
receive
an
ip
and
ip
packet
and
it
will
need
to
be
decap.
So
we
need
some
evpf
program
on
backend
to
become
those
packets.
So
for
this
demo
in
windows,
backend
servers,
we
are
using
an
xtp
ebpf
program
which
will
decap
those
ipine
ip
packets.
A
In
case
of
the
linux
backend
servers,
we
are
using
a
tc-based
evpf
program
to
tcap
those
packets.
This
is
how
the
packet
flow
looks
in
case
of
a
dsr
scenario.
As
earlier,
the
browser
sends
a
request
packet
to
the
lb
node,
using
its
source
ip21100
and
some
source
port
x,
destined
to
4111
source
destination
port
80..
Once
the
lb
node
receives
the
packet,
it
chooses
one
of
the
backend
nodes
and
then
does
an
ipn
ip
end
cap
and
forwards.
The
request
to
the
chosen
backend.
A
A
A
What
we
see
here
on
the
right
side
is
the
lb
node,
where
we
will
have
the
cilium
l4
load
balancer
solution
running.
Currently
it
has
the
evpl
for
windows
framework
already
installed
and
running.
What
we
see
on
the
left
side
is
a
web
browser
which
is
running
on
the
host,
and
this
will
act
as
a
client
for
sending
a
request
to
the
lb
node.
So,
as
a
first
step,
I
am
going
to
run
the
psyllium
based
agent,
and
this
celium
based
agent,
is
what
I
had
mentioned
earlier.
A
This
is
inspired
from
the
psyllium
cli
and
user
mode
daemon.
We
provide
a
mode
which
is
snap
right
now
and
the
name
of
the
interface
to
it.
Once
this
agent
receives
this
information,
it
queries
the
interface
properties
compiles.
The
ebpf
program
then
runs
the
program
to
the
verifier.
Once
the
program
has
been
verified,
it
will
load
and
attach
the
program
to
the
xdp
hook.
Once
that
is
done,
it
presents
us
with
a
cli
which
we
can
now
use
to
configure
an
lb
in
service
instance.
So
the
next
command
that
I'm
going
to
run.
A
A
A
A
What
we
can
see
here
is
this
is
showing
me:
what
are
the
active
connections
right
now?
One
thing
to
note
about
this
website
is
that
this
is
refreshing
every
three
seconds,
so
it
is
displaying
the
date
time
the
backend
server
ip,
the
name,
and
it
is
refreshing
every
three
seconds
so
coming
back
to
the
dump
state
command.
A
What
we
see
here
is
the
source
ip
is
2100,
our
destination
is
411,
which
is
the
web.
This
is
the
source
port
being
used
by
the
browser
right
now
and
the
backend
ip.
So
this
shows
what
backend
this
connection
is
landing
on
so
which
is
which
matches
with
here
and
what
we
see
here
is
tx
and
rx
bytes,
since
this
webpage
is
refreshing
every
three
seconds.
If
I
run
this
command
again,
what
we
can
see
that
the
tx
and
rx
pipes
are
increasing
compared
to
the
previous
one.
A
Now,
if
I
try
to
do
a
force
refresh
of
this
web
browser,
it
will
force
the
browser
to
use
a
different
source
port
and
possibly
will
hit
a
different
backend
server.
So
I
did
a
force
refresher
and
what
we
see
here
is
now
we
are
connected
to
linux
server
2,
which
will
back
an
ip
21
140..
So
if
I
run
the
service
dump
state
command
again,
what
we
can
see
here
is
now.
It
is
showing
me
two
connections.
One
of
them
is
closing,
which
is
the
previous
one
21
130,
which
was
the
previous
active.
A
If
I
run
this
command
again,
what
we
can
see
here
is
that
the
tx
and
rx
bytes
are
also
increasing,
since
this
page
is
refreshing
every
three
seconds
now,
if
I
force
refresh
this
web
page
a
couple
of
times
to
see,
if
I'm
able
to
hit
all
the
four
backend
notes.
So
right
now,
I'm
connected
to
linux
server.
Two,
my
force
refresh
this
is
linux
server,
one
now
windows
server,
one
and
windows
server
two,
so
we
have
kind
of
hit
all
the
four
backends.
If
I
show
the
dump
state,
we
see
five
connections
here.
A
A
It
should
be
sufficient,
so
if
you
look
at
the
first
packet,
it
shows
source
ip
is
21,
100
and
destination
is
411..
So
this
is
the
original
request
packet
coming
from
the
web
browser
to
the
lb
node.
If
we
look
at
the
second
packet,
its
source,
ip
has
now
become
2111
and
the
destination
is
21
120..
So
this
is
the
source
netted
packet
from
lb
note
to
the
backend
node
with
source
ip2101,
which
is
the
ip
of
the
lb
node
and
destination,
is
2120,
which
is
the
ip
of
the
backend
node.
A
If
we
look
at
the
third
packet,
this
is
the
response
packet
coming
back
from
the
backend
node
to
the
lb
node.
And
if
you
look
at
the
fourth
packet,
this
is
a
reverse
netted
packet,
whose
source
ip
has
now
become
411,
which
is
the
whip
and
the
destination
has
become
21
100,
which
is
the
ip
of
the
client.
A
So
this
command
updates
the
mode
to
dsr
what
this
command
does.
Is
it
recompils
the
ebpf
program
for
dsr
mode?
Then
it
again
runs
the
program
through
the
verifier,
reloads
and
reattaches
the
program
to
xtp
hook
and
then
reconfigures
the
service
that
we
had
earlier
configured
now.
If
we
stop
this
and
try
to
refresh
this
web
page,
what
we
see
is
that
we
are.
A
If
I
try
to
force
refresh
this
webpage
one
more
time
now
we
are
connected
to
windows
server,
one
and
if
I
try
to
dump
state
again
so
now,
the
previous
con
active
connection
is
now
moved
to
closing
state
and
the
new
active
is
21
1
10,
which
we
can
see
here.
One
thing
to
note
here
is
that
in
case
of
dsr,
the
tx
and
rx
bytes
are
shown
as
zero.
A
If
we
try
to
now
refresh
this
web
page,
a
couple
of
time
force
refresh
it
to
see
if
we
are
able
to
hit
all
the
four
backends
so
right
now
we
are
connected
to
windows
server
one
now
we
linux
server
one
windows,
server,
2
and
linux
server
2..
So
we
hit
all
the
four
back
ends.
If
you
see
here,
there
would
be
many
closing
connections,
because
I
because
I
force
refreshed
it
multiple
times,
but
there
is
only
one
active
connection
which
is
the
last
one
to
21
140..
A
And
if
you
look
at
the
first
packet,
so
this
is
the
packet
coming
from
21
100
destined
to
40
1
1,
which
is
the
original
request
packet
coming
from
the
browser
to
the
lb
node.
If
you
look
at
the
second
packet,
it's
actually
an
ip
ip
packet
going
from
lv
node
to
the
backend
node,
so
the
outer
ip
header
has
source
ip2111,
which
is
the
ip
of
the
lb
node
and
the
destination
is
2140,
which
is
the
ip
of
the
backend
node.
If
the
inner
ip
header
has
the
original
source
and
destination.
A
If
you
look
at
the
third
packet,
it's
actually
after
three
seconds
and
it
again
contains
the
source
ips
2100.
So
this
is
actually
the
second
request
coming
request
packet
coming
after
three
seconds,
so
we
do
not
see
any
response
packet
coming
back
to
the
lb
node.
So
this
is
dsr
working
in
action
here.