So, I don't have a run, and I'm going to talk about SQL network functions with VPP and my
experience doing that with VPP, so let me go next, okay, so about me, I'm working at Cisco
in the class security business unit, working on VPP for some use, and almost 20 years of pushing
packets around, which start to be a big long, I guess, and what I'm going to show with you is my
experience with running a service, which has 50K active, like signals, and what it takes to
get there with VPP. So that's roughly what we're going to cover, so first way, so how to scale
IPSEC, I go very briefly on VPP because you already had to talk about that, I shall
it, what's going on with IPSEC and VPP recently, and then I do a deep dive on what are the
models of operations for IPSEC and VPP, what is the scale in terms of tunnels, in terms of performance,
in terms of memory, then how do we go to make that, and a brief wrapper.
All right, so why is it so up to scale IPSEC, so first you have some scale requirements,
like with IG1 system, for example, where all tunnels are automated, etc, you can have a lot of
tunnel created to your items, so to the thousands or tens of thousands, you also have functions
like 5T UPS, for example, in mobile, where again you can have a lot of different tunnels with
IP and with, and then you have the bandwidth issue, right, so something else might require a
very high bandwidth by themselves, and then when you aggregate all those tunnels together,
you can have to process a lot of throughput. And finally, when you have a lot of different
customers, like different companies, etc, obviously, you can not use the same
routing tables for everyone, and so there was also a challenge in terms of scaleings and
number of births, and if you look at what we traditionally do, you can use obviously the Linux
Scannel IPSEC stack, which is well known and very robust, but it has limited performance
compared to what you can do, and also, sometimes it can be a challenge to operate in
containerized environment, because you don't necessarily have the, you know, admin rights to
actually operate those tunnels, and again, if you need a lot of birth, it can be a
challenge, and finally, when you want to operate at that scale, you really, really want
something that is programmable, otherwise, if you do everything which has trips, and
and think like this, it can really become very complex, very quickly.
So VVP, for those who are not there for the previous talks, it's open in the
put-through software that runs in user space, and that's packet processing, it's a full network stack,
so there is routing, there is there is turning, now we also have session management, etc,
it runs on different platforms, mostly X86 and ARM servers and GPUs, and one of the key
differentiation with VVP is the performance as a scale, and you also have the ability to
customize the processing, thanks to the plug-in-able architecture of VVP, so we, we evenly
use that property in our systems, so we have the ability to pick and choose,
which feature we want, and how we want to plug them. And again, it's very important to
have something complicated API driven for automation.
Alright, so despite the IPSEC being quite an old protocol, and you know, there's
our more modern and sexy protocol, like we regard for example, there's still a lot of
activity in IPSEC, and I live with the IPSEC, and it's still king in enterprise, so we still have
performance optimization in IPSEC, we still have new features, supported in IPSEC, and I see
that the match is over there, we'll contribute to the net issue both for IPv6, so I guess,
as an aside, I guess that means that IPv6 is probably ready for production, now that we have
to careful not, and so a lot of things that are happening in that space.
In VVP, you have mostly three models of operations for IPSEC, you have the traditional
policy-based model of operations, so in policy-based IPSEC, it's a bit of a legacy module,
you basically enter holes to match which traffic should go into which tunnel, so you might
say, all the traffic this time to those address range to port 80, most goes through the tunnel,
but no that kind of traffic, so you can mix and match which traffic you want to go through which tunnel.
It was one of the first models of operation for IPSEC, so it's still quite, quite widely used.
The thing is, when you scale the number of tunnels, you scale the number of holes, and holes are
expensive, so in terms of scale, one thing to be aware of is be conscious about the number of holes,
and be aware that catching, for example, for those holes, verdicts are important, and we'll see
that later. Second much of operation is upon two points interfaces, so in that mode, it's more intuitive,
you create one virtual interface, and you just configure your routing tables to say, okay,
all traffic this time to those prefixes, most goes through my interface, which is my tunnel.
In terms of scale, again, here's a challenge for each tunnel, you need one interface,
so if you have 100 tunnels, that's okay, but if you start to have tens of thousands of tunnels,
it starts to be a challenge. And finally, the last mode is 0.2md, so in that mode, again,
you always present tunnels as an interface, but you have a single interface for all your tunnels,
and you disjump the gate between all those tunnels based on the next one, so when you program your
routing, you say, okay, all traffic this time to this specific prefix, must go through my IP second
interface, which is my virtual interface, but to this next one, and the next one is actually your
P, so at the end point of the remote endpoint of the tunnel. So in that mode, you can have a
single interface, and a lot of different tunnels, so it's it's more scalable.
In terms of performance, there are quite a lot of different, so all those figures were taken for
from CIT, that magic just printed before. CIT for us is great, because we have a trove of
performance data on a trove of platform, and we can conquer different scenarios, so those are
shows them. So here, for example, that's the test with tens of thousands of tunnels, tens of
night sectors, using IES 256 GCM, or in the light slate, and we accept 0.5% of packet drop.
And you can see that the default policy mode, for example, doesn't perform very well, and doesn't
scale very well. If you enable the cache, which is the second column for policy mode, it's
much better, because in that case, you know you have to evaluate all the rules for every packet,
but once you evaluate all the ones, you cache the verdict, and you have a kind of floatable
that keeps that verdict, so when the next packet is come through, you just match the session,
you say, okay, I know the rule, I know I know where to send it. And finally, you can see that
for the point-to-point mode, and point-to-multi-point would be similar in terms of performance.
For the point-to-point mode, it has a bit better performance, because here you don't have the
rule matching, you go through the regular flip-lookup, which is very, very optimized.
And you can see that it's scale pretty well. So the takeaway here is if you use policy mode,
don't forget to enable the cache. In terms of performance and scale, there is another issue,
which is the maximum performance you can get in terms of cryptography from a single core.
Because it's not necessarily easy to distribute the processing of an IPsect tunnel on multiple
cores, because when you start to do that, you start to run into issues with a packet,
the ordering, and that kind of stuff. So there are means to avoid that, but it makes things more complex.
So usually, we try to keep one tunnel on one core. But if we do that, we are limited to the
performance of a single core. So you can see that VPP can do almost a 30 gigabits per second
in a single core with an MRI epis, which is already good, but if you require to support 40 gig,
then you need something else. And this is where I think when this crypto comes in,
that's the mode of operations where IPsect, the IPsect and VPP can upload crypto operations
to other cores, or to an MRI scenario. So here all those figures are with software,
so we upload operations to other cores, but you can also upload an MRI scenario.
And in that mode, that requires to match our performance for a single tunnel first. So
for example, with four cores, we can process up to 17 gigabits per second for a single IPsect tunnel.
But the other benefit is for the loading balance. So when you have a multi-tenanted system,
what can happen is you don't control the distribution of the tunnels on the core,
because that is controlled by the hardware, which load balance flows on the cores.
So what can happens is you can get a lucky, and you can have two big tunnels,
ending on the same cores. And in that case, you are going to be both on a value of performance, right?
So again, I think from this crypto helps in that, because it spreads the crypto workloads,
which is the most instance you work with here on multiple cores, and so it makes sure that it's
more balanced. So that helps. Finally, last scale issues that you're likely to encounter
is the memory consumption. So especially IPv4 feed is in VVP. I think from the feed with an mtry.
It's a predetermined way to do it. It's efficient, but it can consume a lot of memory depending
of how you structure it. The default in VVP is 1688, and that gives you better performance,
because at worst, you do three lookups, but that consume much more memory. So you also have
an implementation with ADA, and that is something you want to use if you have a lot of VVs,
because it's really, really decreased as a memory. For us, it's a difference between
having to use 15 gig of memory versus 10 gig of memory, for example. And also, it's a good kind of
operation. Finally, automation. VVP expose the binary API, and we have different bindings for that.
What works very well for us is to write our agents in GoLang. So we have the agents,
which is because it is the local brains that controls the VVP programming, and that takes all the data
coming from the control plane management plane. And using GoLang is nice, because we can integrate
with a lot of high quality library to consume VVP. And actually, Maxine will talk about GoVGP later,
that we use a lot to plug our system with BGP. So using an agent in GoLang is really good for that,
so I really recommend. And so to wrap up. So first, identify the IPseq mode you want to use.
The easier to use and manage is 0.2 point, usually, but it doesn't grow past 100 of tunnels.
And then 0.2 multi-point is probably the one to consider a nest. You have a requirement for
a policeman. I think crypto. You should really use that, because it doesn't enable, it gives you
more performance for single tunnels. Memory, don't forget about the IP4M fry that can
really consume a lot of memory. And then, yeah, go along for, for agents it's great in my experience.
And with that, we have some time for questions.