0:03All right. Hi, everyone. My name is Steve Wellam. I'm from Cloudflare's network services and infrastructure team. And today we're going to talk about WAN transformation at scale. This is a problem that we've been partnering with Accenture on for about the last year. And I wanted to bring someone along who could talk about this from the perspective of managing a network for users. numbering in her, I think, over 800,000 staff at Accenture. So to take that away, I'd like to introduce Accenture's global lead of network strategy and architecture, Naresh Chetri.

0:44Thank you.

0:54Oh. that? There are two clickers.

1:09Oh. Alright guys, the cloud is a new enterprise WAN. It's not a tagline but it's in production for Accenture. We have been using the public cloud.

1:26The public cloud has our WAN backbone for the last several years. But I wanted to share with you the journey of our network transformation at Accenture and the underlying rationale, why we did that and how we achieved that.

1:49Okay. So I think... the tagline, I think everybody agrees that the network follows the cloud and not the other way around. So to start off with, we had a legacy van. During this phase, all our applications were on -prem. At that time, we used our carrier MPLS from two global carriers. It served us well but the problem The problem was we couldn't do any route manipulation because the core was owned by the carriers, correct? So we were like the passengers on somebody else's bus. We could pick the seat, which is QoS, but we couldn't define the route.

2:37So as our on-prem data center footprint started expanding, our edge computing started expanding, we pivoted to private MPLS. Now, with private MPLS, we own the bus, so we could define our own direction. So you could use various techniques, such as traffic engineering, segment routing, wherein you could control the routes across your backbone and to the edge as well. And with private MPLS backbone, you control your core, which gives you flexibility. a wide variety of transport at the edge, correct? So you could use a regional MPLS carrier, you could use IPsec tunnel, you could use point -to -point tunnels, and so on.

3:31During this phase, cloud and SaaS services started becoming mainstream. So in this private MPLS phase, So we started moving our applications to the cloud and then I think it spanned for nearly four or five years. Post that, majority of our applications moved to the cloud. So there was no essentially a need for a private MPLS core or we would need a reduced core. Now since our applications was hosted in the cloud, So, what we did was we thought as an opportunity to use the cloud as a bag bowl to connect all our offices together.

4:25So, I think four or five years back, we moved to the cloud run as a bag bowl using AWS and Azure. So, we worked with them very closely to develop the solution. Obviously, there were some challenges at the onset because, as you know, on the traditional router, you have separate DRIB, FIB, but in the cloud -native component, it's a consolidated Obviously, there are some limitations in terms of prefix scout limit as well, so we had to work with both the cloud providers to overcome that and address any feature gap.

5:18So for us, the cloud is the new WAN backbone. We use the scale of the cloud to connect all our offices globally. We have been using Cloudflare services like DNS, WAF. uh for the last several years uh recently uh i've been working with steve and his team to evaluate the cloudflare van service while evaluating we found some feature gap like dynamic routing prefix scout i think which uh cloudflare has has addressed in the last couple of weeks so i think we'll be moving to uh the pilot phase and evaluating the Cloudflare or WAN services.

6:10But the bottom line is when you look at the Cloud WAN, it is the internet scale for the enterprise. Because let's say if you take an MPLS link or a point-to-point link, it is from company A or company B. But when you look at Cloud WAN, it is your internet scale. thing there is no other bigger network than the internet okay so and that's the only network in fact which it drives all our innovation agentic applications sas everything correct so you can't beat the internet so the cloud van is essentially bringing the internet scale to the enterprise customers so once you build the cloud van using the public cloud infrastructure then essentially you can use the same transport and consume various services correct so could use dns internet breakout any agentic ai workload correct security and so on now some of you might wonder like you know why are we sending everything through this cloud van?

7:31Why can't we go directly via the native internet? Yeah, it depends upon your workload. So some of the internet-exposed application, you can go straight out through your office. But for any application which requires a secure or private connectivity, you can ride this cloud van backbone, use the same transport, and consume multiple services.

7:59In closing, what I'll say is whenever you think about Cloud or Cloudflare, since we are at Connect, think of Cloud as a virtual backbone, which can tie in all your offices together. It can be your virtual data center for your virtual hosting, and lastly, think of as a virtual SaaS. Now, Virtual SaaS is interesting because you can develop SaaS services for yourself, but if you are a startup and if you're trying to develop some tools, you can host it on Cloudflare, and Cloudflare has all the stack right from connectivity. So you develop a tool or any services, and if any of your client wants to connect privately, then the Cloud Van is there.

8:50So Cloudflare provides the full stack right from... connectivity to application and to the Agentec AI workload as well. So that's my time. I'll hand it over to Steve.

9:05Thanks, Dersh. Oh, that's two. Which one is it? That one. Okay, cool. So I'm going to talk about how Cloudflare tackles this problem and the product that we positioned for that, which is Cloudflare WAN. to give you a run through of like how this works and I'm going to also speed run some of the operator experience to try and make it real for you. I'm just going to start out by stepping back a bit. This has always been, the network has never been just about the network, right? The network is a means to an end. It's about connecting, you know, we would have said clients to servers or users to applications, but ultimately in a world where there's machine to machine traffic bot to machine traffic user to bot traffic this is about service consumers on the left to service producers mostly on the right whether your service consumers are branch networks with cctv building management systems alarm systems iot devices devices where you need to connect a network or a whole network uh you have remote users for that we have our cloud flow one client uh you have external you which comprise genuine users, bots, and malicious actors.

10:22And the network has always had to provide whatever the application or use case needed, whether that was performance, i.e. we measure that in terms of bandwidth or latency or jitter, and increasingly security functions. We use the network to provide filtering and assertion and inspection. And that's what Cloudflare provides. Fundamentally, for the longest time, we have provided these inspection and network security functions in a way that's on demand, programmable via API, now completely orchestrated by agents if you want to do that that way. Everything's consumed as a service, and the challenge that we have with that traffic, your traffic, and providing all those services is how do we get...

11:13uh those services in line with your traffic flows and for the uh for the longest time the way we did that was with the internet uh we would intercept the um and we still do this is the most common on -ramp and off -ramp from cloudflare is the internet we take over the fqdn the domain name of the service we return an any cast address we there we call that orange clouding uh an application and that inserts cloudflare into the flow and then we deliver to the uh the origin via whether that is a direct over the internet or we use an off-ramp like cloudflare tunnel and over the years we've added more and more on -ramps and off -ramps cloudflare one client you'll know it as warp client or the 11111 client that is a type of connector to solve this type of problem and we have connectors that connect endpoints but what if your goal is to connect an entire network and your on-ramp is existing equipment that you've operationalized in your network.

12:16You've got firewalls, VPN concentrators. If you're in AWS or Azure, you might use virtual WAN, transit gateways, VPN endpoints. How do you connect with those? This is where Cloudflare WAN comes in. So Cloudflare WAN is our solution for connecting third-party network devices, cloud-native network functions to Cloudflare. using ipsec gre interconnect that's just plain ethernet handoffs whether they are directly to another cloud directly to your data center in a colo that we share um or through a partner like megaport or equinix fabric we have all of these different ways to bring your network your traffic to our network from an eyeball perspective or a service consumer perspective and deliver it to those far endpoints, those services.

13:11And frequently with the standard connectivity approaches, we also need to control the routing of these entire networks, which means BGP, the dynamic routing protocol that is common in all these situations. So Cloudflare WAN is a Cloud-WAN solution, but what's different about it? A number of things. So, I think one of the primary differences about Cloudflare WAN is we use our Anycast network. So what that means is if you are working with us over a tunnel over the internet, whether that's an IPsec or a GRE tunnel, the address that we give you is an Anycast IP address. So let's just imagine you've got equipment located in London, LA, Sydney.

13:56You will configure the same IP address, same Cloudflare IP address on all of that equipment. And the Anycast network will ensure that the Sydney traffic lands at our Sydney location, that the LA traffic lands at our LA traffic, the London traffic lands at our London location. So we always bring that traffic to the closest Cloudflare point of presence. And then from that point, you have control of all of the routing, which I'll go into a bit more detail in a minute. You don't have to pick any regions. Failover's built in. Sydney fell over, your traffic would go to Auckland or Melbourne, the network would just take care of it. You wouldn't have to configure multiple tunnels. You wouldn't have to worry about failover mechanisms. You don't have to manage the capacity. And this is all based in software. And that gives us some tremendous advantages in terms of agility.

14:44We're one of the first providers in the world to provide post -quantum IPsec interoperability. So IPsec now on Cloudflare is post-quantum. which is pretty unique so if you're connected to cloudflare you've got uh generally four use cases that are common um that we see those four use cases are secure application ingress this is where you want to use cloudflare's waft or cdn and you're trying to connect to origin servers that are on a private network that's connected via by maybe a gcp interconnect or an ipsec tunnel uh you can target any those endpoints we added that function earlier this year secure internet ingress you've got an entire network and you need to egress that traffic out but you want to policy control that you want to prevent data loss you want to stop command and control networks for malware zero trust access our access product our walk product the ability to use our platform to securely connect to any of those endpoints in that private network using our zero trust software.

15:54And then standard WAN traffic that, you know, we typically think about as WAN is obviously a use case as well, whether it's VPC, VPC, branch, VPC, branch, DC, or branch, branch.

16:08And so when talking about networking, it's often a case of like pointing at a box line diagram, and that's kind of sometimes a little bit hard to reason about. So I just want to speed run you through the actual user interface. Everything's API first. Everything is, you know, Terraform, infrastructure is code. We can Terraform it. We can tell agents to configure it for us, but a UI helps us really talk about it. So it all starts with configuring interfaces or IPsec tunnels, GRE tunnels, and interconnects. This can be done in the dashboard. One of the things, like Naresh mentioned, this year, actually we released this GA earlier this month, is BGP support. So the common... requested by large clients, specifically like retail, hundreds or thousands of sites, lots of networks to manage, very straightforward to configure, BGP configuration over IPsec, over GRE.

17:03And one of the requirements that we found working with Naresh's team and other retail locations was this notion that you need some level of BGP policy control. And what were we going to release? with our initial BGP release was basically import and export filters. So BGP filter profiles are a configure once, allow many, import export control. This is important for like, you might have hundreds of retail sites and the risk of your users or your technicians on site creating a larger WAN issue is something that we can restrict with BGP filters.

17:46Generally, setting up BGP networks obviously involves, BGP connections, involves a little bit of troubleshooting. So the BGP functionality includes in it logging. This is through LogPush, which is an API form of pushing logs to your storage buckets, but also integrated with our dashboards, Log Explorer, so you can view exactly what's going on in a BGP peering setup when you're establishing connections for the first time. The routing table, whether it's BGP routes or statically configured routes, is all visible within the UI. You really conceive of Cloudflare WAN as a single routing table, one big router that globally spans the entire planet. And you just decide how to send traffic from one site to another.

18:35You don't have to think about how traffic gets from A to B. That's what our network takes care of for you. What about when routes don't work? In working with one of our large customers, they had a cookie-cutter network problem, guest Wi-Fi sites, where in every one of their retail locations, a guest Wi-Fi network was built on 192.168.10, and that creates a routing problem because you can't have multiple routes to the same subnet. So we built automatic return routing. When you turn this on, we can bypass routing altogether. We just learn the return route. We connection track. When the traffic arrives from that site, we know where it came from. When the return traffic comes back from the internet, we know where to send it to without even consulting a routing table.

19:26Firewalling is built in. So if you want to control how within the WAN, what can talk to what, we have a very rich firewall rule building language. to decide what should and shouldn't be allowed. So you can policy control what happens between all of those connected networks, all from one place, globally configured in one place, distributed everywhere. And then finally, observability. We couldn't have a network platform without observability. And again, just built into the platform, you don't have to turn this on or enable it or anything. As soon as you start. using it. We're tracking all of your traffic. You have history. You have the ability to look at filters, see your traffic in packets, in bytes, to explore what's going on with your Cloudflare One deployment. So three things to take away.

20:17You're connecting once to Cloudflare, that entire network, whether it's IPsec, GRE, or interconnect. Everything is programmable. Everything is on demand instantly. You're not talking to providers. You're not going through contract setups, it's elastic, it's instant. And all of those functions that Cloudflare provides, they're all available to you. And so with that, thanks everyone.