🔒 Cloudflare Magic Cloud Networking

Hey everyone, welcome to Cloudflare TV. My name is Ankur Aggarwal. I'm based out of San Francisco and I'm a product manager here at Cloudflare, focusing in our SASE suite or Zero Trust suite of products. Thank you for joining for Security Week. We've had a number of great launches today and today I'm joined by both Ben and Steve from our product team to talk about two of those launches. So first I'm going to turn it over to Steve to chat a little bit about our launches around our Magic Cloud networking. Thanks Ankur, only a little bit. I've got so much to say. So where do I start? First of all, my name is Steve Welham. I'm based out of Seattle and I'm the product manager within our network services group for public cloud networking and interconnect. And this is part of not only how we bring self-hosted apps into Cloudflare 1, our SASE and NAS solution, but it's also how we generally integrate to cloud-based services which are increasingly the way that enterprises are rolling out new self-hosted apps and services these days. There's a bit of an origin story here and the origin story is that I was working on network orchestration at Nafeli Networks. We turned our focus there to specifically public cloud network orchestration. We started working with Cloudflare as a startup actually in the Cloudflare Launchpad program and our team has now joined Cloudflare to integrate this orchestration technology into the Cloudflare platform and it will be called Magic Cloud Networking. It's a new set of capabilities aimed at public cloud integration for networking and network security. And yeah, highly relevant because many of our customers are in one or more public clouds and use Cloudflare as well to provide enhanced network services. So what's the problem we're trying to solve? Well, the exact problem we hear from our customers actually varies between individuals and organizations, but there is a common theme. And the common theme is this desire for a unified end-to -end management experience, better understanding of the costs. And with Magic Cloud Networking, we facilitate this with this single pain outcome for our customers through the Cloudflare dashboard and API. And how does it work? The public clouds like Cloudflare are API first. What that means being API first is that when you build your product, you build the programmability of it openly first. And then when you go and build interfaces for your customers, whether they're UIs or CLIs or infrastructure as code libraries, you're on top of this API layer. So the major cloud providers, AWS, Azure, GCP, Oracle, IBM, they operate in the same model. And so we can leverage those programmable interfaces as well. And I think importantly, this is not about recreating the cloud's own user interface. There would be many problems with taking that as a strategy. And we're instead targeting specific workflows to our customers, network engineers, security engineers, IT staff are doing. And so the public cloud integrations we're doing are focused in two areas. There are those that are related to Cloudflare product. So for instance, let's imagine that you are setting up policies for self-hosted apps in the cloud, being able to discover those apps and track those apps that are part of your policies on the Cloudflare side. So this is about integrations that make Cloudflare better and easier to use with the public clouds. And then there's also the fact that we've got these great customers who have got pain points working in public cloud. And the clouds themselves are not going to address all of those or not fast enough. And there will be a better experience from our customers getting that improved UX from our single pain. So we're augmenting existing UIs and APIs and automation stacks to solve specific problems. We're not replacing, we're not introducing new problems. Yeah. And that really is great because we start to give kind of customers that holistic view. So could you tell us a little bit more about how is this different than what customers are doing today? Yeah. So I think there's three dimensions to this. The first dimension is cloud maturity. So when you look at any enterprise adopting public cloud, they are somewhere on a spectrum of how experienced they are and how mature they are in operating the cloud. And the CNCF, which is the Cloud Network Compute Foundation have what's called a cloud maturity index. And as you progress along that index, you go from, I'm just working with the cloud and I'm clicking in the UI all the way to like super mature, multiple clouds, everything's automated, pipeline driven, defined in infrastructure as code. And infrastructure as code, just by the way, this is a way of defining the configuration of infrastructure, cloud infrastructure, cloud network infrastructure using effectively software. And there are many examples of this. So there's like Azure Bicep, AWS Cloud Formation, Pulumi, HashiCorp, Terraform, and there's software development tools. There's a lot you can do with the software development tools to build in basically your own cloud management system. And many enterprises that are very far along this maturity scale, they're very familiar with the pitfalls of building your own cloud management solution. So one first key difference is that we're providing automation and it's out of the box and we're being opinionated on specifically automating around networking. Another dimension here is the data plane. So when we talk about the data plane in networking, we're talking about the pipes, the cables, the ports, the physical path over which all of our, or sometimes a virtual path over which our information flows. And many traditional solutions in this area introduce a new data plane, whether that's a VPN overlay, a service mesh overlay, or a network as a service. And that comes with a few issues as well in terms of it effectively separates you from what the cloud already built for you. And so you actually begin to lose some things like observability and control, and you lock yourself into a new data plane, which means you can then no longer easily benefit from the innovations that the cloud provider are providing to you. So we're unique in that we're using the cloud API only. We're providing a management plane integration and that differs. I think the third dimension here is single cloud. So if you're working with the native cloud providers, you're in AWS, you're in Azure, you're in GCP, you are using an interface which only addresses that cloud. And actually oftentimes there are even silos within the cloud. Like if you've got two accounts with different billing structures in the cloud, then there's no end-to-end connectivity, even if you connect those things together and they're the same provider. So this is a problem that we're really well positioned to solve for customers because we're cloud agnostic. We have customers operating in all the public clouds. We have customers operating in hybrid and private cloud environments. And so we have this kind of unique network end-to-end view, and that enables us to act differently and to provide something that actually is unified and end-to-end. Yeah, and that's a great point because there have been so many customers I've talked to over the past couple of years that have been either just through acquisition, basically they get hoisted upon new cloud providers and new cloud environments, and the complexity for their IT and security teams to start managing each one of those and getting them all connected together, as well as getting just a good view on what's going on, is really difficult because they can have a policy of saying, okay, everything must be in cloud X. But it turns out once you make an acquisition, you just have to now also deal with cloud Y and Z. So it is great that we're actually getting these tools out there. So can you give us some examples of these capabilities of the three problems we're solving for customers? Yeah, sure. I'll talk about a few of the features that will be in the closed beta. So first of all, if this is interesting to you, you're listening to this as one of our customers or prospects, then go to the website, sign up for the closed beta, and that's the best way to stay on top of this. So initial capabilities here are performing an inventory of your cloud networks. So the ability to basically absorb and discover within the Cloudflare dashboard and API, what you've got in all of these disparate environments. So bringing that into a single responsive UI, which is then the basis for actually how we facilitate integration across our products. The second, very straightforward, but common use case is actually automating the deployment and what we call lifecycle management of Cloudflare on-ramps. So on -ramps are ways that you get your traffic into Cloudflare. We support several, and Ben's about to talk about a type of on -ramp, the interconnect, so I won't steal his thunder. There's also things like IPsec site-to-site VPNs. We have things like Cloudflare tunnel. And then for users, we have walk client, that is an on -ramp. So when we're talking about public clouds, two of the on-ramps that particularly require orchestration are interconnect and IPsec site-to-site VPNs, because we're able to use things like transit gateways and VPN gateways. And the status quo today is that you go and configure all the things on one side, configure all the things on the other side, and then you get a connection up and running. We will orchestrate this end-to -end and perform lifecycle management. And what that means is, this is more than just like one and done, I've deployed. It's actually, once I've deployed this configuration, I then manage it going forward. And that means monitoring it, doing key rotations, detecting if somebody's gone into the cloud's own portal and change something, and alerting the person that created this that, hey, the secure connectivity you created today, that's there tomorrow and the next day and the next day, which is critically important in cloud, because there's so much churn and change. Another feature is around dynamic routing updates. So being able to share routes that are in cloud, in Cloudflare, like MagicWAN routes, being able to push those into static routing tables, so basically software-defined route redistribution. And last but not least, another cool feature that we see a lot of interest in is facilitating network security groups. So the clouds have a very capable software-defined network. It has built-in layer 4 firewalling, which you can do super micro-segmentation with. Every VM can have its own firewall. And that's wonderful, but also that's a management pain. Anyone who's managed firewalls before would probably, they wouldn't be very happy if you told them, hey, here's 1,000 firewalls to manage. And so we can facilitate that, obviously, with automation, and that enables you to achieve east-west filtering in the cloud. So yeah, those are some ideas of the initial capabilities that are coming out soon. And then, yeah, very excited to announce this and really look forward to working with our customers to solve even more of their pain points, help them solve their cloud migration integration. That's absolutely awesome, Steve Blake. Honestly, this is like a huge pain point for customers and being able to get all that kind of centralized view and control on that traffic. And really, Stephen, their networks, I know, will be super powerful. So as Steve mentioned, if you're seeing the blog post, please do sign up for the beta. We will have updates coming soon about how you can use this and even participating in that beta. So I'm going to turn it over to Ben now to kind of talk about, one, intro yourself, two, talk about CNI. And then that's also one of the on-ramps that Steve just mentioned. So please take it away. Yeah, absolutely. Thanks, Ankur. And Steve, I'm really excited about a lot of the magic cloud networking, specifically because the breadth of cloud deployments can very quickly become overwhelming. And I think this is going to help customers simplify their networking config overall as they connect into Cloudflare. My name is Ben Ritter. I'm a product manager here at Cloudflare. I am also in the Seattle area. And my day job is a product manager for Magic Transit, which is our layer 3 DDoS mitigation product. And I've sort of been moonlighting a second job and helping out with Cloudflare Network Interconnect for the last six months or so. And I'm really excited today because of the fact that we announced a new faster on-ramp to connect your network to Cloudflare, and that is Express Cloudflare Network Interconnect. And at its crux, a CNI, or Cloudflare Network Interconnect, is a way for customers to connect their network router to Cloudflare. And this allows them effectively to bypass the public Internet and have a fast, performant, and predictable and reliable connection up to Cloudflare and then ultimately out to the Internet. And today, we announced Express CNI. And with today's announcement, customers can order these CNIs actually directly from the Cloudflare dashboard or from their account. And the Cloudflare site will be provisioned in about three minutes. I love how in the blog post, you even said it. It's truly like, hit submit, go make a coffee, come back, it's provisioned. Yeah. There's a lot of coffee nerds here at Cloudflare. I'm sure I'm not the only one of them. So I had to kind of work that in there somehow. But yeah, I think it underscores how quickly this provisioning process is and how simple we want to make it for customers to ultimately connect and protect their networks behind Cloudflare. So I know with CNIs in the past, there were many kind of restrictions or kind of connection methods, especially for, say, Magic WAN or transit customers. Could you tell us a little bit more about kind of what changes now? Yeah, absolutely. So Magic Transit, Magic WAN are both products that operate at the network layer, meaning they are interacting with IP packets that we receive on behalf of our customers. And ultimately, we need some sort of way of taking traffic and getting it back to customers, whether it's for Magic WAN, where we receive a whole bunch of traffic on the public Internet and we filter traffic for DDoS or Magic WAN, where we're sort of providing connectivity between locations. And in the past, we only sort of had one CNI methodology. And the challenge was that for us to get cleaned traffic back to a customer, we had to use something that network engineers are familiar with. It's called a GRE tunnel. And this is where we took our customers' traffic and we put it inside another packet called a GRE tunnel and then sent that to them. So they were kind of getting a copy of their data in another packet. And this worked for most folks. And we still absolutely are going to use this all the time, especially when customers or potential customers call us sort of when they're under the duress of a DDoS attack and we need to get them up and running quickly. So it's not going away anytime soon. But the challenge for a lot of folks is that configuring their routers to be able to accept this traffic on a GRE tunnel gets complicated very quickly. And there's sort of a few reasons, I guess, down that line. Yeah. And definitely one of them that I know that is a bit near and dear to my heart is MSS. Could you explain a little about what MSS is and how we're at least removing that requirement? You're going to make me explain MSS on Client Side TV. That's okay. Okay. Yeah. So when we take traffic and need to put it into another packet or a GRE tunnel, we are reducing the overall size of the packet that can go into that tunnel. And the reason is because at the beginning of the GRE packet is something called a GRE header. And it takes up a certain number of bytes. So we reduce the amount of space that we can use for our tunnel packets or our customers' traffic from about 1500 bytes down 30 or 40 bytes. And don't quote me on the numbers, but you get the gist of it. We have to reduce the packet size. And the challenge is that different hosts and servers, speakers on the Internet aren't aware of the fact that their traffic is going over this GRE tunnel. And ideally, we don't want to have to ask our customers to make any sort of config changes to handle this. But what often we would have to do is to make some rather complex changes on routers so that the routers can inform any sort of TCP conversations that it sees starting, that they should now use a smaller maximum segment size within that TCP conversation to fit within the smaller MTU or the reduced MTU caused by the GRE tunnel overhead. So yeah, pretty complex, wonky network engineering stuff. If you've lost me and you're not a network engineer, that's fine. I would say sort of the key takeaway is that Express CNI supports getting traffic from Magic Transit and Magic WAN without any sort of requirement for a GRE tunnel, which is excellent if you have a router, for example, that cannot forward GRE traffic at line rate, or if you have a router that doesn't have the software feature to be able to adjust MSS, it definitely sort of simplifies the configuration and onboarding for these network services products and decreases the friction overall. Thanks for going through that. I know it's not the easiest topic to address, but the idea is the fact that we can get a network cable directly from a Cloudflare router to your router, and we can get you the packets routed over that without any additional, say, configuration over that particular connection. Now, I know with also the Express CNI connections, there are multiple different options. Could you walk us through the kind of different options we have within CNI? Yeah, so today what we've announced is the ability for Magic WAN and Magic Transit customers to go onto the Cloudflare dashboard and the ability to order Express CNIs. The type that we are supporting today are called direct CNIs. So these are CNIs where customers are in the same data center or co-location facility as Cloudflare or one of our locations. You can find your data center directly on our website when you pull up the new interconnect section of the dashboard. And when you order this direct CNI, you're able to ultimately order a cross-connect that connects you to Cloudflare's router. We also have partner CNIs, which is where we leverage a virtual connectivity partner such as Equinix or Megaport or Packet Fabric. There's a couple others as well where customers may already be connected to one of these providers and they want to have them facilitate the connection over to Cloudflare. We don't support setting those up in the UI today, but it's something we're working on in the future. And then finally, there is Cloud CNI, which works similarly as well, where customers can connect and bring in traffic from their public cloud environments like AWS, GCP, and Oracle. And lastly, how much does all of this cost? That's my favorite part. Yeah, so this is definitely a unique Cloudflare strategy. CNI is offered for the low, low cost of $0. So Cloudflare does not charge any sort of port fee for the CNI to get traffic in and out of Cloudflare. There are costs associated with the potential products that you may put on top of them, for example, Magic Transit or Magic LAN, but the CNI itself does not have a cost associated with it. And this means that if, for example, with Magic LAN, you're paying for an expensive MPLS circuit to connect or backhaul traffic between locations, or with Magic Transit, you're currently getting all your traffic delivered over the public Internet or a transit provider, you're probably paying for that bandwidth to some other mechanism or to some other entity. And if you move that traffic over to a CNI, you may be in a situation where you can reduce your overall Internet service provider spend by shipping the traffic over to the CNI. And I know this is also something that, so this is something I pay attention a lot to, of just like how our network's constructed, how our colos operate, especially kind of the hardware we use. So I know on our blog, we've often talked about the next gen of servers that were our metals that we're putting out at each one of our colos. Are we adding additional hardware to support the CNI effort, or how are we making that happen really on the backend there? Yeah, behind the scenes, there's a lot of software and some new hardware that powers and makes this all possible. So the team has actually been physically deploying, shipping these new routers out to locations all around the world. And when we turn them up, or they go live, new locations will show up on the Cloudflare dashboard, meaning it's a new location that customers can order one of these Express CNIs. And to be able to make these features possible, things like the ability to support the traffic forwarding without requiring customers to do any sort of GRE tunnel. We've done a lot of custom software development on this routing platform. In fact, our team internally at Cloudflare developed a network operating system, which makes all these features possible. Awesome. And then just, I guess, one last question. What's next for CNI? We've got quite a good fit. And I'm glad Steve's here, because he's working with me on this as well. But Express CNI, as I said, we want to bring the convenience and ease and speed of these features over to other platforms as well. So we want to make it just as easy to physically or virtually connect up to the public cloud and to virtual connectivity partners for CNIs. And then later this year, this is kind of an open secret, but I don't mind saying that here on Cloudflare CNI, we're working toward building more BGP control on the Express CNI platform, which is really critical to our Magic Transit, Magic WIM customers. Yeah. And I know it's something customers are really looking forward to, especially when they manage a failover or traffic kind of balancing between their connections to Cloudflare. So it's amazing to see really what's happened and the developments we've had with CNI. And so customers today can sign up for CNI through the dashboard, through the UI, and there'll be more to come there. So I want to thank everyone for joining us here on Cloudflare TV. Thank you, Steve and Ben, for walking through both our cloud efforts as well as CNI connections. And everyone, please stay tuned to our blog. We have two more days of posts coming up and thank you for joining. Awesome. Thank you, Akram.