F5, Inc. (FFIV) Earnings Call Transcript & Summary

Hi, everyone. Welcome to today's webinar Deploying F5 Distributed Cloud Services in Cisco ACI. My name is Stephanie Kubina, webinar Program Manager from F5. Before we get started, I'd like to go over a few basic housekeeping tip reminders. [Operator Instructions] If you have a question, please submit it in the QA engagement widget. We'll be addressing questions at the end of the presentation time permitting. Also, you can download various resources that you see in the resource engagement widget as well. At the end of the webinar, we do appreciate your input, if you can fill in the webinar survey, we do appreciate that. And also I'll be sending out an e-mail to the on-demand link of this webinar after the session is over. All right. So presenting today, we have Matt Harmon, Solutions Architect, F5 Distributed Cloud. Hi, Matt; and we have Jennifer Yeung, Principal Solutions Engineer, Business Development from F5. Okay. So Matt, I'm going to go ahead and give you control if you can please get us started. Thank you.

Absolutely. All right. Thank you, everybody. I'm happy you were able to join. As Stephanie said, I'm a Solution Architect for F5 Distributed Cloud. I cover North America and South America, mostly for large service providers, but I get involved in lots of things networking. So I do come from a networking background, I started off my career as a network engineer and actually went through a Cisco Academy through my schooling. So this is an area that is near and dear to my heart. And I hope it's of interest to you as we've known Cisco in the routing and switching game for a very, very long time. And F5 in the application delivery and application security space, and probably many of you are here today because you've used these 2 vendors, F5 and Cisco in your data centers for a long time. As we've evolved with Cisco ACI and as F5 has evolved with our attributed cloud platform, I think this is a really good, interesting topic of what does the -- what -- how do these 2 vendors play together in a space that is now within the data center but also outside the data center within a multi-cloud Fabric, right? So that's what we're going to focus on today, and I hope it's of interest to you and helpful for your initiatives. So for today, our objective is we're going to successfully deploy an F5 Distributed Cloud instance, CE, particularly into Cisco ACI to securely connect and deploy distributed application workloads in a hybrid or a multi-cloud environment quickly and efficiently. And how do we -- when we talk about that, we want to understand how do we connect the service that is the F5 Distributed Cloud to Cisco ACI, but also how do we attract traffic or route traffic to a listener that is specific to an application. So if you come from a BIG-IP background, we would call that a virtual server typically. But what is it in a Distributed Cloud context? So I'm going to go through some basic overview background and then I'm going to kick it over to Jennifer. Jennifer has done a fantastic job putting a ton of content together here. And then I'll be around to help answer questions at the end. So what is a customer edge? Well, first, let's talk about the whole Distributed Cloud platform and the different components that make up Distributed Cloud. So first in the purple box is our console or our global controller. This is the one and only control plane. So unlike a BIG-IP where it has a control plane locally and then you could also utilize BIG-IQ as a centralized manager control plane or even Panorama and Palo Alto, right? Panorama is a central manager. In this case, we -- this is not a central manager. It is the only control plane for the 2 different data points. You cannot go directly to a data point and make a change of any significance for application delivery and security. So what are the 2 data points. The 2 data points first is our regional edge. This is a SaaS-based regional data point that we have distributed across the globe. It is in -- within F5 facilities, it's a hosted platform in a facility of F5. And we can provide everything from Layer 3 to Layer 7 services out of our regional edges. They are multi-tenanted by default, and you can even bring hosted workloads. So we do utilize some Kubernetes frameworks under the hood to deliver these services. And actually, the communication between the controller and the regional edge is made up of hundreds of micro services inter-communicating to deliver the service. So that's really, really cool in the sense that it's a multi-cloud, modern application in itself as a SaaS product. But outside of SaaS, we also have our customer edge data point, and that's where we're going to be focusing today. The customer edge data plan is the exact same software we run in our regional edge, except for you can deploy it inside of your facility. So when I say facility, that could be your data center on a VMware, a hypervisor on Bare Metal, or in a hyperscaler like an Azure or an AWS or GCP or IBM Cloud, right? The fourth way to deploy the CE is, we actually take the pods and peel them out and put them right into your Kubernetes stack. So we can do some pretty interesting stuff. Kubernetes-to-Kubernetes no matter the flavor. I think I've got an EKS cluster running in AWS, and I want to communicate over to an OpenShift cluster running inside the data center. But I only want to extend 2 different services between those disparate flavors of Kubernetes, right? So really, really powerful from a proxy and app delivery perspective in the different models that we can deploy customer edges. And that model today is really going to be talking about integrating with Cisco ACI in attaching. The last 2 kind of great out components, these aren't necessarily -- they are part of the product, but not something that you consume. It's just -- they need to be there. So we have a global backbone that stitches together all of our regional edges and our controller, our console. And then we have people. We have some great people that maintain and operate the platform. They're doing upgrades every 4 to 6 weeks. And I always refer to the platform as a living, breathing thing. It will self-heal. But sometimes, even us, right, we need our doctors and our nurses. Our site reliability engineers are those doctors and nurses taking care of the underlying platform to deliver the service. So there's a couple of different traffic patterns. We're going to focus on the bottom traffic pattern, but just to kind of talk through them really quick, the regional edge only, RE only, that's using our SaaS data point and only our SaaS data point. So we ingress the client side traffic to the VIP, and we build a server-side connection out of the regional edge with a snap. Same thing can be done when a customer edge is sitting inside of your facility, and you're taking traffic directly there. But what's really cool is we can make geographically dispersed proxy architectures. So in the hybrid model, we're actually building a client-side connection from the client to the RE and then building a server side connection from the customer edge, inside interface, server-side interface to the server. So this gives a lot of power as the networks and the connectivity is local to the service. And that's true in the East-West model or the MCN model where we might have a web service inside of AWS, but we need to talk to an old database or app service still in the data center. And what if the IP addresses overlap? And lots and lots of use cases here that we're going to dive into, but we can make them geographically dispersed and take what we've known from BIG-IP in a proxy and break it out and expand it across the facilities. So looking at that a little bit deeper, you see the little red lines going across. By default, and we're going to talk a lot of defaults. We're going to build tunnels back to our global backbone. Those tunnels, again, by default, are IPsec tunnels, that can be SSL or TLS. And we use those as part of the routing Fabric. There's a software-defined network or an SDN that stitches all of this together. But that's abstracted from your purview as some would call it magic under the hood, but as a solution that's delivering features to you. We try to make that super, super easy. And we know that we have an app on one side in the West talking to an app that's over in the East, right? And that's all we have to define on the object that we call it, a load balancing object. Now I promised Jennifer, I would stay under 10 minutes, and I'm at 9:30. So I'm going to move over to her section of the presentation, and I'll be watching chat. If you would like to ask any questions or hackle me or ask about anything in my office up to you. Go ahead, Jennifer.

Thank you, Matt. So first, let us take a look how we can deploy CE in Cisco ACI because there are a couple of deployment options. First is the Layer 2 attach. In Layer 2 attach, we can connect the CE using a Layer 2 connection. And the CE can be a single node or a 3 node cluster. XE support VRRP, Virtual Router Redundancy Protocol for WIP advertisement. So when we have this feature enabled, there is a VRRP master for each of the custom WIP, each of the configurate WIP on the XE console. And since this is Layer 2 attach, we don't require any routing or Layer 3 service is required. So that means that you have 1 last layer to take care of. And when we connect the CE into Cisco ACI using Layer 2 attach, we can connect it as an endpoint of an endpoint group. Now besides the Layer 2 attach, we also have Layer 3 attach deployment option. And Layer 3 attach, we can connect the CE using a Layer 3 connection. Same here, the CE can be a single node or 3 node cluster. XE supports static routing and dynamic routing of BGP. So if you deploy more than just a single node, ECMP, Equal-cost multi-path will be their enabled by default and which allows each node to actively process traffic. But one thing to note that you decided to use BGP over static routing, make sure that you're an advanced user own the XE console because XE console supports RBAC, role-based access control and that's what you needed for BGP configuration. And when we connect CE to Cisco ACI using Layer 3 attach, we can connect it using Layer 3 out. So now quickly go over the deployment options in Cisco ACI. Now why don't we take a look at some of the examples of use cases. As a reminder, look what Matt has mentioned earlier, F5 XE have a very powerful capability, which we can distribute WIP and ISNet by deploying CE at different geographical locations. So for our first use case, multi-cloud, we're taking exactly that, to bring in multi-cloud workload. In this example, we deploy a CE into Cisco ACI. We injected WIP and 10.10.122.122 into the network. While we have the workflow across multi-cloud, which you can see we have a CE deployed on AWS and also have a CE deployed on Azure. And the CE is there to handle the stat communication to the efficient servers. And this is how we can bring in the multi-cloud workload. And this can be done, depends on your requirement. This can be done using either Layer 3 or Layer 2 attach deployment option. Now if you have BIG-IP already integrated into Cisco ACI Fabric, with on-premise workload, we can use F5 XE to bring your application into a hybrid multi-cloud environment. In this example, we first deployed CE to bring in the multi-cloud workload into network. Then next, we can just simply including the WIP, the 10.10.122.122 that we inject from F5 XE to the network as one of your pool member of your existing BIG-IP WIP, the 172.18.188.211 and as simple and as easy as that, you now bring your application into a hybrid multi-cloud environment. And again, it depends on your requirement. This can be done using Layer 3 or Layer 2 attach deployment option. Last but not least is cloud migration. If cloud migration is in your planning, F5 XE can assist you along the way, too. In this example, what we can do is we can deploy CE into Cisco ACI, again, to bring in the multi-cloud workload. And then we include WIP as one of the pool member of your existing BIG-IP WIP, the 10.10.133.133 so or spring your application into a hybrid multi-cloud environment. Next, after you complete migrating your workload to the cloud, and when it's time for the cutoff, we can update the WIP on XE with your BIG-IP. And with that, we can complete your cloud migration. And again, depends on your deployment or requirement. It can be done using either Layer 2 or Layer 3 deployment option. So up until now, we talked about what is F5 XE, especially or specifically the [ CNCN ] which is what this webinar is focusing on. We have talked about also different deployment options and share with you some of the examples of use cases of F5 XE in Cisco ACI. I think it's time for us to bring you to the XE console. So that you have an idea how to navigate when you're doing your F5 XE deployment. So in our demo, we're going to be using Layer 3 attach deployment option. As you can see in our topology, we have 2 cloud 1 on AWS and 1 on Azure. We deploy a CE at each of the cloud side with 2 origin servers, Hello-World. If you pay close attention, you will see that we're actually using the same subnet on AWS and on AWS. And to be more specific, we even assigned exact same IP address on the 2 servers, 10.131.111.66.77. This is the IP address overlapping problem, which Matt have mentioned about that F5 XE can solve. So it's not a problem for us because we're connecting using F5 XE, and F5 XE can resolve IP conflict across connected sites. So in another words, we can just connect this 2 sites as is which is a huge plus. Now let's move on to our on-premises or on-prem, the data center. We deploy a 3 node C cluster into our Cisco ACI environment. And as mentioned, we're using a Layer 3 attach deployment options. And instead of using static routing, we're using BGP. This cluster is VPC, Virtual Port Channel into Cisco ACI Fabric using Layer 3 or SVI. And for redundancy purpose, we hear each CE to each of the board's reach. So in other words, there will be a total of 6 BGP peers between F5 XE and Cisco ACI. The first case we want to show you is the multi-cloud. Here, we're going to be injecting WIP 10.10.111.111 from F5 XE into your network. While we have the workload across the multi-cloud, which is on the AWS and on Azure. The angle here is that the user on the left, the 172.16.249.220 will be able to reach the application Hello-World. So with that, let me just jump on to XE console. Okay. Now after you log into your XE console, you can go into multi-cloud network connect. And here on the site...

Hey, Jennifer, are you sharing your screen, it didn't refresh for me?

It is. Yes. And I see it.

I see it. This is Stephanie, I see it.

Okay.

Okay, great. So here on the page, you will see the sites which will list all your sites the CE deployment. As you can see, we have 2 cloud sites, right, one on AWS, that's on the JY SY4 AWS and then we have another cloud side that's Azure, which we deployed CE on, that's the JY SY5 Azure. And then we have our CE cluster deploy in Cisco ACI, that's a JY SY2 cluster. So let's take care of the networking side first, right? So remember, we said that we will be using BGP instead of static routing. So first thing to check is if you have the commission. You need to be an advanced user, right? So instead checking that you can also go to account setting, right here and make sure that you have the right permission. If you are an advanced user, if you go back to multi-cloud network connect, and under networking, you should see BGP pop-up in this pool menu. And this is the page that you want to be at for BGP configuration. Now you see that I already have a BGP configuration created for our sites. Our CE site in the Cisco ACI. So let me show you the configuration. Here, we specify which site that we would like to have BGP configuration. And as you see the highlight, I would like to have BGP configured on JY SY2 cluster, right? And then assigned a local AS number and the router ID. I just leave it to default, but if you won't specify your router ID with an IP through address, you can do so as well. And next thing is we will need to configure all our BGP peers. As I mentioned, I want redundancy. So each of the CE will have appear to each of the border leaf. So each CE, I have 2 BGP peer, 12.11 and 12.12 to each of the border leaf switch. And I have a total of 6 peers, as you can see here. So let's take a look at the BGP configuration. And I'm going to pick the first one to show you. So for the BGP peer configuration is very normal, like how you configure on any Layer 3 device. You specified the AS number and the remodel peer IP address. One thing to note on the XE, we use interface connectivity for BGP peering. So here, you need to specify which interface you will be using for this particular peer for BGP peering. And you need BGP authentication, and the F5 authentication is supported. Now I have configured all 6 of them. Once you configure all your BGP configuration, you can go to show status from the BGP config and it will show you the BGP peering status. So I can see that I have all green. And let me go to the first node to show you. The first node is a Master 0 with an IP of 172.18.128.6 and you can see that both peers are up, established. Let's take a look at the second one. That's the Master 1 with IP address ends with .10 and you can both of them are up, established. And the last node, Master 2 with the address ends with .14 and again, both of the peers are up. So all 6 peers between the F5 XE and Cisco ACI are up and established. That's great. So we take care of the networking. Now let's move on to our application side. With that, we're going to go to multi-cloud App Connect. So there's 2 things we need to accomplish. First, we have to create origin pools to include the servers on the cloud side, and then we're going to need to create a WIP to include the pool members just like how we do on a BIG-IP. So first thing, let's create a pool, right? So here, under low balancer, you can go to origin pools. And you can see that I already have 2 pools traded just for management purpose, I create 1 pool for each of the cloud sites. So I have 1 for AWS, and I have 1 for Azure. So let's take a look at AWS test pool. Here, when you define your pool, you need to specify the origin servers. As you can see here, I specified the 2 servers on AWS, the 10.131.111.66.77 and the most important is here, where are these 2 services are origin from. I specifically specify that these 2 servers are origin from the JY SY4 AWS. So for AWS pool, I specify that these 2 servers are origin from SY4 AWS. Just remember that we have the same IP address assigned on AWS and on Azure. So then the rest is the normal and default. This is Port 80. I leave everything that you call for the 1 algorithm and such, I create a health check object for health monitoring. But now let's take a look at the test pool on Azure. Here, I also put in the servers, which I have the 2 things IP address server, the 10.131.111.66.77. But see here, specified origin side for these 2 servers is coming from SY5 Azure. So for Azure test pool I specify the servers are coming from Azure and for AWS pool I specify the servers are coming from AWS, so even though they are having the same IP address. And now the rest is the same. Port 80, leave everything that defaults and also create an object for health monitoring. Now we created the pool. Next, we need to create a WIP. Let's go to HTTP load balancer. And he already create 1 called SY2 cluster app. So let's take a look at the config. Here, I have put in the domain header that is the xe.F5-demo.com. This is port 80. And now for the origins, I include the 2 pools that we created, one on AWS and one on Azure. And next, let's get to other settings. Now here is where we need to change it to custom so that we can assign a custom WIP for this HTTP load balancer. And we can also specify where we want the custom WIP to be advertised to. So now once you change the custom, let me show you the custom configuration. Here, you will see that I have specified an IP address. The first thing to make sure that you do is you turn on the events on the right here so that you can assign an IP address to your HTTP load balancer, which we call the custom WIP. As you see our assigned 10.10.111.111. And I instruct F5 XE to advertise this custom WIP to the inside network of the JY SY2 cluster. The inside network is where we VPC, Virtual Port Channel to the Cisco Fabric. And that's done for the configuration of F5 XE. But let me quickly recap what we just did, right? First, we take care of the networking. We configure the BGP on F5 XE to peer with Cisco ACI, then we take care of the application. We create 2 origin pools, 1 on AWS whereas origin servers and one on Azure on for its origin servers, then I create a HTTP load balancer with a custom WIP of 10.10.111.111. And I instruct F5 XE to advertise that custom WIP into Cisco Fabric, which is the inside integrate of our CE cluster. Now what we're going to expect next is, we should expect F5 XE to advertise the WIP to its peers, right, the BGP peers. So if I look at the right hand table I just see those routes being advertised. On XE console, you can check the BGP routing table. You can go to multi-cloud network connect, go to the sites, pick your site, which is a SY2 cluster. And then you go to tools. And here, you select show BGP routes. You can also check the BGP peering here as well as you can see. So now let's take a look at the BGP routing table. The first node here is Master 1. And if we go down, we can see that under exported advertise, this subnet, that is the WIP, that we just configured, that's 10.10.111.111/32. And we should see the same for the other 2 nodes. Let's check quickly. Master 2, in regard to export it, we see that. And if we go to the last node Master 0, we see that also. So that's right because XE is letting us know that it is advertising the WIP, the custom WIP of 10.10.111.111 to its BGP peers. Now if we go on to the Cisco ACI Fabric, we should see it on the BGP routing table. So let's check. And we should see routes and I would expect it to stamp multipath. Now let's check the first leaf. Here, we do see one coming from .14, and the other one comes from .10 and one come from .6, right? And we do see best path, multipath and multipath. Now let's check the other leaf, leaf 2. And we're seeing the same result .14, .10, .6. And again, best path, multi-path, multi-path, right? So now if we check the routing table, we should expect these 3 routes populated into the routing table as it will cross multi-path, and we do. Now let's go to user the 172.16.249.220 that happens around. Let me just share real quick. All right. Now if we -- see the history. Yes, here, right. 10.10.111.111 is xe.f5-demo.com. Now we can reach Hello-World and between AWS and Azure. So with that, we have bring in the multi-cloud workload for your application. Now next, what I would like to show you is the hybrid multi-cloud use case. Here, in our topology, we already integrated BIG-IP into Cisco ACI. As you can see, we already have the on-premise workflow from either directly on the Fabric or behind a legacy router. What we do next is we're going to include the WIP as one of the pool member of our existing BIG-IP WIP, 10.10.133.133 so that we can bring our application into a hybrid multi-cloud environment. So with that, I'm going to switch back to my screen, one second. And now before I jump on to the BIG-IP, let me just show you from the user perspective, like what does it see at the moment. So that is the 10.10.133.133 bigip.f5-demo.com. So at the moment, I can only see Hello-Land that is expected right, either Cisco that is directly connected to Fabric or behind a legacy router, right? That's all we see. Now let me jump on to the BIG-IP. Here you can see that we have the WIP peer to 10.10.133.133 and it has a pool called Layer 3 attach demo pool. So let's go to the pool Layer 3. And right now, we have 4 members. There's no in the diagram. They're all on the on-premise. To bring this application to a hybrid multi-cloud environment, all we need to do is to include as XE WIP as one of the pool member. That is a 10.10.111.111. Now if we go back to user and try to reach the same application again, we should see it include Hello-World, which you can see here. Now we just bring this application into a hybrid multi-cloud environment. This is another one. And one thing I forgot to show you earlier is you can actually check these requests on XE console too. So if I go back to my XE console and if we go to multi-cloud App Connect and go to performance, all the way at the bottom, find your HTTP load balancer, which in our case, is SY2 cluster out. Here you hit request, you can see the requests coming in on the cloud. So if you notice the last 2 is the requests coming in when we moved our location to hybrid multi cloud, right? You noticed that it doesn't show the origin, the client IP address. The reason is because on XE console, we have to trust, enable trust for the client header. So one easy fix is if we go back to the HTTP load balancer. Here go to settings, enable trust, and in my case, I'm going to be trusting S44, then hit apply. Now let's send some requests that will be hitting the cloud. That's one. Okay. So we have one on AWS and one on Azure. Now let's go back and check the requests again. Performance. Our HTTP load balancer and go to requests and let's refresh. See, we can see that now the request is coming in with the client IP address after we enabled the trust. So this is just something that want to bring it up that you can be aware of. Now let me go back to the last use case. Now we talk about cloud migration. So imagine now we have moved everything to the cloud, right? We have move all our on-premise workload to the cloud and is now is the cutoff time. We're ready to complete our migration. What we can do is we can update our XE information with the BIG-IP WIP information. And I'm going to show you real quick to complete our demo. Give me one second. Looks like there's some delay. Okay. Now -- can you just see my screen again, Matt or Steph?

Yes, we can see it. .

Yes.

Okay. Great. Awesome. Okay. Now what we're going to do is pretend this is our last stage of migration or cut off, right? What I'm going to do is, I'm going to go to the BIG-IP, I'm going to remove the WIP. In my case, I'm going to just disable it, right? And what I'm going to do next is I'm going to update the WIP information. So I'm going to go back to the HTTP load balancer. And I'm going to do is, I'm going to change to our domain header, right, to BIG-IP. And I'm going to also update our WIP, to 133.133 and hit apply. Now let's go back to the user. If it's working right, everything done. We can only see the Hello-World. Okay. So that completes our cloud migration, right? And that also concludes the demo. So let me switch back to the slide deck. Now before we open up for Q&A, just some key takeaways from today's session, right? As I have mentioned earlier, [ CNCN ] is what our focus, and one of the powerful capability that we can build the WIP and it's not -- by deploying CE at different geographical locations. And when we deploy CE in Cisco ACI, there are 2 deployment options. One is Layer 2 attach, which we connect to CE using a Layer 2 connection, NXE support VRRP or WIP advertisement. The other option is Layer 3 attach, which we connect to CE using a Layer 3 connection. NXE support, static routing and BGP. And last but not least, we have ran over some of the examples of use cases like multi-cloud, hybrid multi-cloud and also cloud migration. Last but not least, I just want to add that this is just a start. Once you have F5 XE into your network, you can also explore other functionality. Like Matt had mentioned it earlier, we can take care from Layer 3 all the way up to Layer 7. So you can follow it up, cloud defense, DNS, et cetera. We hope that you find this information useful. And hey, Steph, can you please open up for Q&A?

Okay. So all right. So we have a lot of questions. Let's see what we can get to today. Thanks, everybody. All right. So one question I'm seeing is, can we have more than 3 nodes in a cluster?

I can take that one.

Jennifer, do you want me to take that one?

Sure, either one. Yes, go ahead.

So yes, we can. So we use what's called worker nodes that can scale the cluster. So we focused on 2 attachment models today with -- specifically with Cisco ACI that is Layer 3 attach, BGP or static or Layer 2 VRRP. And when you add worker nodes, you have to set up the neighboring, right, in the case of BGP or update your static routes, VRRP will happen automatically. It will be additional for Wib's. But in that case, those worker nodes will participate in those attachment models and you can scale your cluster that way.

Okay. Thank you. Another good question here. Is part of the of Distributed Cloud based on ISTIO? What advantages does this provide?

Yes. So the inner communication isn't necessarily ISTIO under the hood, right? So this would be kind of part of the secret sauce on how we communicate our micro services. We do -- I actually think that bringing up ISTIO is an important concept here because we do have a -- I don't want to say -- it's not competitive to ISTIO but there's a competitive piece to ISTIO's product called Ambient. Ambient is there outside of cluster flavor multi-micro service communication solution. And we would be competitive to that solution where you have different flavors of Kubernetes. But under the hood, the way that we intercommunicate our micro-services is a little bit proprietary and it came to us, obviously, through building it, some of it, but also some acquisitions. So -- but not particularly ISTIO.

Okay. Thank you. Jennifer, I think this question is for you. Can you do this -- does it support other public clouds besides AWS and Azure?

Yes, certainly. Those are just my example in the demo that I have used AWS and Azure in my demo, but certainly, we support other type of cloud as well. Like Google Cloud, IBM Cloud, for example, and they all support it.

Okay. Thank you. Is there a customer recommendation when considering moving from BIG-IP Classic to Distributed Cloud or net?

I don't know that there's necessarily a recommendation, right? As F5, we have data plans for different services. Certainly, I obviously have an opinion because I work in the Distributed Cloud business unit, but there are certainly use cases where Distributed Cloud isn't a good fit or where we want to work together with the next team. So I would generally say your frontline SE that you work with should know best in collaboration on what kind of workloads, how your applications are defined, where they live and I would recommend working with the sales team.

All right. Thank you. Well, we have time for one more question here. Do we need to have same subnet for the BGP between ACI and CES?

Jennifer, you want that one?

Yes, I can take this one. I mean, yes, for BGP peering, right, so we should be in the same subnet. I assume that is a question for BGP peering.

You are right.

And I think the BGP peering between CE and the interface of the ACI Fabric, right, obviously, it has to be in a subnet. If we're doing VRRP or Layer 2 attach, of course, we have to be in the same subnet, right, Layer 2. But BGP neighbor relationships depending on how the Fabric is set up could potentially be set up where node 1 and in SVI is separate. I think it's probably easier to have them all in the same subnet and then just carve up smaller sections of that subnet. But I think that's kind of more of a personal preference on that one.

Okay. Well, thank you, everybody, for your time today. That's all the time we have for questions. Any questions we didn't address, we'll be addressing after this webinar. And thank you so much for this informative session, Matt and Jennifer. We look forward to seeing you in our future F5 webinars, and have a great day, everybody. Thank you.