So, hi everyone. So, today I'm going to talk also about VPP. I'm going to take a more
concrete example. We'll talk about levitation mid-handy, roll your on my level of
balancer with VPP. So, first, a few words about myself. I'm Nathan. I'm the software
engineering working for Cisco. And I'm doing mostly continually working, VPP and
VPP and also have a bit of trouble past with Python and JavaScript called applications.
So, before we start, a small bit of a word of warning. If someone is afraid of
that six-sixer, please be aware. I made the machine in that. Anyway, so let's get
solid. What I'm going to talk about is taking an example of flood applications where
you want to deploy in a typical cloud environment. And for which you want to have
good SLAs. So, typically what you want to do is have a redundancy, which typically means
having a lot of balancer in front of it. And you want that lot of balancer to have nice
properties like recovering for failures or seamless horizontal scanning. So, one of the issues
with other debock load balancing is that it comes with limitations. As typically, your hash
thresholds when the set of back end changes. So, that's why Maglev was actually made. And
Maglev is just a smart way of doing load balancing that offers the nice properties that
we are searching for. Namely, it's supposed to be relatively stable when the set of back
end changes, which is exactly what we want. And also, it has a few things that it's supposed
to work with. It recommends working with direct service return, DSR. So, that you don't
have to start stating the load balancer. You just for what I get a bonfire for the return.
In that way, you also spare a network hub on the way which is good for performance. And
one of the things in the paper is that it recommends working with a user space stack. But
that I'll come back to that later. So, how does it work? In practice, what you do is you
consider end buckets. And the buckets are going to be an interaction from flows to the application
back ends that you deploy. And typically, you want to choose emiratively big, so typically
100 times maximum number of back ends that you want to have. And sorry, pop up. So, that
you keep your hash space wide enough so that the back ends don't collide too much. So,
what you're going to do is for each of your application back ends, you're going to assign
to them a preference list, which is going to be just a permutation of the set 1 to m. And
then each of the back ends will receive that list as a preference list of the buckets. And
they will be with the other great algorithm on the side, choosing the buckets by their preference.
So, this, the reason we do that is this is to ensure that the back ends to back end mappings
will stay relatively stable when the set of back end changes because each of them is more
less guaranteed to get it's first pick and then it's second pick and so on. And then when you
have been coming flows, what you'll do is just regular hashing, you pick a bucket and that
bucket gives you the back end pair of the previous mapping. And that's it. That's all you have to
do your flows a little balance and life it does. So, to give you a bit more colors on what
on why it is exactly helps. If we take an example of two back ends, so here we have one green
and one blue. And we have there with their respective preference list and we have them choose the
buckets. We little balance if you flows that go into the back list and we consider the addition
of the third one, the red one, what will happen is that obviously that third back end will take
your third of the buckets, so probably a third of the flows. But it will leave the rest of the mapping
mostly untouched because of the preference list. So, both blue and green, they will keep their
preference list and so they will most likely keep their set of back ends stable. And given that
the number of buckets is high, you have a huge likelihood of having the same mapping in the end.
So, that way the flows are struggling to stay relatively minimal, which is not the case if you
consider an either a balance or based on just the hash and a module of it. So, that's for the
third, but how do we make this work in practice? So, if we go back to all to application and we say
that we deploy it in a cloud provider in VMs and each VM has its own IP address, one thing that we
have to account for is that ingress is typically constrained. So, you have to go through an infracton
struct that typically already does a translation on some kind. And at the same time, Egress is also
constrained because you typically don't want to send any packets as a cloud provider. So, what will
make it hard to do with the SO? Because you basically, as an application, you cannot issue packets
to an IP that's from an IP that is not assigned to from the introspective. Also something to note
is that if we want to do direct service return, we will need additional configuration to the
applications themselves because typically you want an cap and you want to terminate packets to an
IP that is not yours. So, that brings in additional complexity. So, for the sake of simplicity
in this example, I'm considering that instead of the SO, that is that all my grievances will
receive packets to a IP, not them with the back-and-eye feature, each is. So, ironically, one of the
issues that is that we have now to keep say it around, but nothing for a bit is returned back to the
to the uncapsi if we manage to extract the constraint of the deployment. So, let's consider
all of the answer. What we will do is provision a VM and we want the packets from the client IP
to the two of the MSIP, to be source-natted, not to be destination-natted to the back-and-eye
IP that we should. So, that's the MagLeft part. And the source-natted with the VM's IP so that
the traffic flows back to us and we can undo our work. So, in order to do that, we need an implementation
and, for honestly, unfortunately, that's not something that's natively offered by the kernel.
But also, as in the algorithm, there are many important implementation decals and also parameters
that you need to input. It's probably not going to be able to be leveraged out of the box.
And also, a full point is that we want this to be quite performance because we want to handle
the traffic of all the packets on the single VM. So, that sounds like a great use case for user-based
networking technology like VPP and that should not really come as a surprise being in the name of the
talk. So, yeah, let's start VPP then. So, in order to do that, one thing if you do is just
issued that document line. So, you pick a relatively recent release of VPP. You're free in a few
stands-up, basically you pass the PCI-ID of the interface and that's it. The thing is running without
anything more to you. But if you do that, one thing that may happen is that if we have a single
interface, which is the case on most VMs that you spun up for starters, you will lose access
because VPP has it, but not the host anymore. So, ideally, if you want to solve that, we'll add
an extra management interface, but not every deployment has this line around. So, we are a bit
a bit screwed if we go that way. And something that would be nice is to have a way to somehow
duplicate it zero inside the host. So, fortunately, that's something you can do. Making VPP act as a
event, as a bump in the wire, using the, what we call the pen feature, meaning we recreate
the tap interface in Linux. Give it the exact same configuration as in the host and just tell
you P pass every packet that you don't know what you do with to those. It's quite ugly from
network perspective because you're sharing IPs and that you're not supposed to do that. But
one of the benefits is that you're making the host life transparent and you manage to keep your
SSH stations open. So, that's, that's that is something. So, now, if we go back to our
Microsoft sorry, now that we have VPP instance running, what we need to do is just add the
Microsoft magic to it. So, and just the average one of the nodes available that was presented
before, that's going to do the fetching of the packet data, looking the appropriate set of
backends and just rewriting the addresses as we need. So, for that, we'll leverage a plug-in
called CNAT, standing for the demonic child of cloud and network adversensation for lack of a
bit of a name, that already has this kind of logic implemented because we don't want to
redo all the, all the checks and computations ourselves. And the thing that we still have to do is
make that piece of code where of the IPs that we, that we want to rewrite the package with.
So, for that, writing control plane logic in C is quite cumbersome. So, what we'll do is
pull in agents. So, why choose going because, because I do that on the, on my spare time.
And that way, what this allows us is to leverage all of our regulatory of the moment. So,
you can't throw in console, let's see, just pull whatever from GAB. Access, whether a series
of scoring mechanism, you available, available. And then, open a connection to the IP and talk,
talk to it through the binary API without. So, basically, you, you, you split a bit
the complaint and data by logic. You have all the complex and, uh, and even driven logic in
go-lank. And then you cross the binary API and you're just, uh, in C, the wing data plane.
And back a bit done relatively easily. You have an API of a library available. You just
initiate a connection to the IP. You tell that you want to migrate, NAT, DCP for AT,
to your, this, to, to, to your, your own IP. And then you want to realize that through the set of,
of backends that you have available. And that's it. Uh, you can't know, talk,
through the, to the backends using the, the, the, the, the, the address. So, that set things are
working, but I, I think it's still worth asking, why did we, did we, did we, did we regain something?
So, I, I, I, I, I, I, I, you're doing that, uh, brings in a few, a few benefits. So, one of them is that
we know have full control on the, the load balancer, how it's implemented, how it's configured,
uh, all that. Um, it's, it's, it's portable, which speaks for deployment uniformity, meaning you
have the same behavior, regardless of where do you apply that? If you have multiple crop providers,
if you're testing locally, you have, you have the exact same behavior. And also the thing is
reciting that way to deploy. Meaning you have a container, you can run it fairly much everywhere.
And underneath, if you have DPDK or some driver, that allows you to swap the, the interface
function. And finally, we're getting performance, um, we should be mostly, or
undergiven VM, we should be mostly IO bound, um, or most of the instance I, so throughput shouldn't
be an issue, pps, like ways to be way over the capacity of the instance. And that last one actually
raises a question, um, if we are IO bound under VM, that means that we don't use it, use all the
VMs. So we have specific use that we don't know what you do for. And also, um, before we were
talking about ancaps, uh, which means that we actually see that ideally we'll need to do more
network processing on the backends themselves. So that actually means that one thing that we could
do is collapse the whole infrastructure and do everything in the same place, meaning having the backends
running directly into the VM of, um, where what we do in my life. And what, so if you, if you collapse
the whole thing, what actually you end up doing is doing some kind of container networking.
Actually, this actually leads us towards the solution that's more or something like what humanity
is does. And so that was, that's actually why this first project, and let us to envision something
like a KalikoVP, which is, uh, doing a container to container and working the, um, MVP itself,
leveraging, uh, the control plane that humanity just provides, and actually having the, the best
of the world with my glad to port. And that's it. Thanks a lot for listening. I hope you enjoy this
talk, and just time for two questions if you have.