WEBVTT 00:00.000 --> 00:16.160 So, I don't have a run, and I'm going to talk about SQL network functions with VPP and my 00:16.160 --> 00:29.520 experience doing that with VPP, so let me go next, okay, so about me, I'm working at Cisco 00:29.520 --> 00:35.840 in the class security business unit, working on VPP for some use, and almost 20 years of pushing 00:35.840 --> 00:45.360 packets around, which start to be a big long, I guess, and what I'm going to show with you is my 00:45.360 --> 00:58.800 experience with running a service, which has 50K active, like signals, and what it takes to 00:58.800 --> 01:11.440 get there with VPP. So that's roughly what we're going to cover, so first way, so how to scale 01:11.440 --> 01:19.120 IPSEC, I go very briefly on VPP because you already had to talk about that, I shall 01:19.280 --> 01:28.320 it, what's going on with IPSEC and VPP recently, and then I do a deep dive on what are the 01:28.320 --> 01:36.240 models of operations for IPSEC and VPP, what is the scale in terms of tunnels, in terms of performance, 01:36.240 --> 01:42.720 in terms of memory, then how do we go to make that, and a brief wrapper. 01:42.800 --> 01:51.600 All right, so why is it so up to scale IPSEC, so first you have some scale requirements, 01:51.600 --> 01:59.600 like with IG1 system, for example, where all tunnels are automated, etc, you can have a lot of 01:59.600 --> 02:10.640 tunnel created to your items, so to the thousands or tens of thousands, you also have functions 02:10.640 --> 02:16.720 like 5T UPS, for example, in mobile, where again you can have a lot of different tunnels with 02:16.720 --> 02:24.000 IP and with, and then you have the bandwidth issue, right, so something else might require a 02:24.000 --> 02:28.880 very high bandwidth by themselves, and then when you aggregate all those tunnels together, 02:30.000 --> 02:36.880 you can have to process a lot of throughput. And finally, when you have a lot of different 02:36.960 --> 02:43.920 customers, like different companies, etc, obviously, you can not use the same 02:44.960 --> 02:50.000 routing tables for everyone, and so there was also a challenge in terms of scaleings and 02:50.000 --> 02:59.600 number of births, and if you look at what we traditionally do, you can use obviously the Linux 02:59.600 --> 03:07.120 Scannel IPSEC stack, which is well known and very robust, but it has limited performance 03:08.000 --> 03:14.000 compared to what you can do, and also, sometimes it can be a challenge to operate in 03:14.000 --> 03:20.960 containerized environment, because you don't necessarily have the, you know, admin rights to 03:20.960 --> 03:29.360 actually operate those tunnels, and again, if you need a lot of birth, it can be a 03:29.360 --> 03:37.360 challenge, and finally, when you want to operate at that scale, you really, really want 03:37.360 --> 03:43.360 something that is programmable, otherwise, if you do everything which has trips, and 03:43.360 --> 03:47.360 and think like this, it can really become very complex, very quickly. 03:50.080 --> 03:56.560 So VVP, for those who are not there for the previous talks, it's open in the 03:56.560 --> 04:02.800 put-through software that runs in user space, and that's packet processing, it's a full network stack, 04:02.800 --> 04:10.160 so there is routing, there is there is turning, now we also have session management, etc, 04:11.040 --> 04:20.640 it runs on different platforms, mostly X86 and ARM servers and GPUs, and one of the key 04:21.600 --> 04:28.960 differentiation with VVP is the performance as a scale, and you also have the ability to 04:28.960 --> 04:36.480 customize the processing, thanks to the plug-in-able architecture of VVP, so we, we evenly 04:37.680 --> 04:44.080 use that property in our systems, so we have the ability to pick and choose, 04:44.400 --> 04:52.720 which feature we want, and how we want to plug them. And again, it's very important to 04:52.720 --> 04:55.440 have something complicated API driven for automation. 04:57.680 --> 05:04.080 Alright, so despite the IPSEC being quite an old protocol, and you know, there's 05:04.080 --> 05:11.040 our more modern and sexy protocol, like we regard for example, there's still a lot of 05:11.040 --> 05:19.040 activity in IPSEC, and I live with the IPSEC, and it's still king in enterprise, so we still have 05:20.880 --> 05:27.120 performance optimization in IPSEC, we still have new features, supported in IPSEC, and I see 05:27.120 --> 05:33.600 that the match is over there, we'll contribute to the net issue both for IPv6, so I guess, 05:35.200 --> 05:40.240 as an aside, I guess that means that IPv6 is probably ready for production, now that we have 05:40.240 --> 05:47.680 to careful not, and so a lot of things that are happening in that space. 05:49.440 --> 05:57.600 In VVP, you have mostly three models of operations for IPSEC, you have the traditional 05:57.600 --> 06:04.000 policy-based model of operations, so in policy-based IPSEC, it's a bit of a legacy module, 06:04.560 --> 06:15.040 you basically enter holes to match which traffic should go into which tunnel, so you might 06:15.040 --> 06:24.560 say, all the traffic this time to those address range to port 80, most goes through the tunnel, 06:24.560 --> 06:30.800 but no that kind of traffic, so you can mix and match which traffic you want to go through which tunnel. 06:31.760 --> 06:41.040 It was one of the first models of operation for IPSEC, so it's still quite, quite widely used. 06:42.400 --> 06:48.720 The thing is, when you scale the number of tunnels, you scale the number of holes, and holes are 06:48.720 --> 06:56.560 expensive, so in terms of scale, one thing to be aware of is be conscious about the number of holes, 06:56.560 --> 07:06.480 and be aware that catching, for example, for those holes, verdicts are important, and we'll see 07:06.480 --> 07:16.480 that later. Second much of operation is upon two points interfaces, so in that mode, it's more intuitive, 07:16.480 --> 07:23.920 you create one virtual interface, and you just configure your routing tables to say, okay, 07:23.920 --> 07:29.600 all traffic this time to those prefixes, most goes through my interface, which is my tunnel. 07:29.600 --> 07:35.600 In terms of scale, again, here's a challenge for each tunnel, you need one interface, 07:35.600 --> 07:42.000 so if you have 100 tunnels, that's okay, but if you start to have tens of thousands of tunnels, 07:42.000 --> 07:50.400 it starts to be a challenge. And finally, the last mode is 0.2md, so in that mode, again, 07:50.480 --> 07:55.920 you always present tunnels as an interface, but you have a single interface for all your tunnels, 07:56.560 --> 08:02.240 and you disjump the gate between all those tunnels based on the next one, so when you program your 08:02.240 --> 08:09.200 routing, you say, okay, all traffic this time to this specific prefix, must go through my IP second 08:09.200 --> 08:14.560 interface, which is my virtual interface, but to this next one, and the next one is actually your 08:14.640 --> 08:20.080 P, so at the end point of the remote endpoint of the tunnel. So in that mode, you can have a 08:20.080 --> 08:26.240 single interface, and a lot of different tunnels, so it's it's more scalable. 08:28.960 --> 08:34.880 In terms of performance, there are quite a lot of different, so all those figures were taken for 08:34.880 --> 08:44.480 from CIT, that magic just printed before. CIT for us is great, because we have a trove of 08:44.480 --> 08:51.360 performance data on a trove of platform, and we can conquer different scenarios, so those are 08:51.360 --> 08:57.200 shows them. So here, for example, that's the test with tens of thousands of tunnels, tens of 08:57.200 --> 09:08.480 night sectors, using IES 256 GCM, or in the light slate, and we accept 0.5% of packet drop. 09:10.480 --> 09:17.680 And you can see that the default policy mode, for example, doesn't perform very well, and doesn't 09:17.680 --> 09:24.720 scale very well. If you enable the cache, which is the second column for policy mode, it's 09:24.720 --> 09:30.800 much better, because in that case, you know you have to evaluate all the rules for every packet, 09:30.800 --> 09:38.400 but once you evaluate all the ones, you cache the verdict, and you have a kind of floatable 09:38.400 --> 09:42.800 that keeps that verdict, so when the next packet is come through, you just match the session, 09:42.800 --> 09:48.560 you say, okay, I know the rule, I know I know where to send it. And finally, you can see that 09:48.560 --> 09:54.560 for the point-to-point mode, and point-to-multi-point would be similar in terms of performance. 09:54.560 --> 10:02.960 For the point-to-point mode, it has a bit better performance, because here you don't have the 10:04.160 --> 10:09.040 rule matching, you go through the regular flip-lookup, which is very, very optimized. 10:10.960 --> 10:16.880 And you can see that it's scale pretty well. So the takeaway here is if you use policy mode, 10:17.520 --> 10:26.080 don't forget to enable the cache. In terms of performance and scale, there is another issue, 10:26.080 --> 10:31.600 which is the maximum performance you can get in terms of cryptography from a single core. 10:32.320 --> 10:38.960 Because it's not necessarily easy to distribute the processing of an IPsect tunnel on multiple 10:38.960 --> 10:46.800 cores, because when you start to do that, you start to run into issues with a packet, 10:46.800 --> 10:52.320 the ordering, and that kind of stuff. So there are means to avoid that, but it makes things more complex. 10:52.320 --> 10:58.240 So usually, we try to keep one tunnel on one core. But if we do that, we are limited to the 10:58.240 --> 11:04.640 performance of a single core. So you can see that VPP can do almost a 30 gigabits per second 11:04.720 --> 11:15.360 in a single core with an MRI epis, which is already good, but if you require to support 40 gig, 11:15.360 --> 11:19.840 then you need something else. And this is where I think when this crypto comes in, 11:19.840 --> 11:27.040 that's the mode of operations where IPsect, the IPsect and VPP can upload crypto operations 11:27.520 --> 11:34.480 to other cores, or to an MRI scenario. So here all those figures are with software, 11:34.480 --> 11:39.280 so we upload operations to other cores, but you can also upload an MRI scenario. 11:40.160 --> 11:49.680 And in that mode, that requires to match our performance for a single tunnel first. So 11:49.680 --> 11:55.520 for example, with four cores, we can process up to 17 gigabits per second for a single IPsect tunnel. 11:56.480 --> 12:02.240 But the other benefit is for the loading balance. So when you have a multi-tenanted system, 12:02.240 --> 12:07.440 what can happen is you don't control the distribution of the tunnels on the core, 12:07.440 --> 12:12.720 because that is controlled by the hardware, which load balance flows on the cores. 12:13.280 --> 12:18.640 So what can happens is you can get a lucky, and you can have two big tunnels, 12:18.640 --> 12:26.000 ending on the same cores. And in that case, you are going to be both on a value of performance, right? 12:26.000 --> 12:31.200 So again, I think from this crypto helps in that, because it spreads the crypto workloads, 12:31.200 --> 12:35.920 which is the most instance you work with here on multiple cores, and so it makes sure that it's 12:35.920 --> 12:44.480 more balanced. So that helps. Finally, last scale issues that you're likely to encounter 12:44.720 --> 12:55.520 is the memory consumption. So especially IPv4 feed is in VVP. I think from the feed with an mtry. 12:55.520 --> 13:03.360 It's a predetermined way to do it. It's efficient, but it can consume a lot of memory depending 13:03.360 --> 13:13.280 of how you structure it. The default in VVP is 1688, and that gives you better performance, 13:13.360 --> 13:20.000 because at worst, you do three lookups, but that consume much more memory. So you also have 13:20.000 --> 13:26.560 an implementation with ADA, and that is something you want to use if you have a lot of VVs, 13:26.560 --> 13:33.040 because it's really, really decreased as a memory. For us, it's a difference between 13:34.080 --> 13:42.160 having to use 15 gig of memory versus 10 gig of memory, for example. And also, it's a good kind of 13:42.560 --> 13:53.360 operation. Finally, automation. VVP expose the binary API, and we have different bindings for that. 13:54.480 --> 14:02.320 What works very well for us is to write our agents in GoLang. So we have the agents, 14:02.320 --> 14:08.560 which is because it is the local brains that controls the VVP programming, and that takes all the data 14:08.560 --> 14:18.320 coming from the control plane management plane. And using GoLang is nice, because we can integrate 14:18.320 --> 14:29.600 with a lot of high quality library to consume VVP. And actually, Maxine will talk about GoVGP later, 14:29.600 --> 14:41.920 that we use a lot to plug our system with BGP. So using an agent in GoLang is really good for that, 14:41.920 --> 14:52.720 so I really recommend. And so to wrap up. So first, identify the IPseq mode you want to use. 14:53.600 --> 15:01.520 The easier to use and manage is 0.2 point, usually, but it doesn't grow past 100 of tunnels. 15:02.960 --> 15:09.440 And then 0.2 multi-point is probably the one to consider a nest. You have a requirement for 15:09.440 --> 15:17.600 a policeman. I think crypto. You should really use that, because it doesn't enable, it gives you 15:17.600 --> 15:26.480 more performance for single tunnels. Memory, don't forget about the IP4M fry that can 15:26.480 --> 15:33.360 really consume a lot of memory. And then, yeah, go along for, for agents it's great in my experience. 15:33.360 --> 15:40.240 And with that, we have some time for questions.