Preview of Cisco Cloud Delivered Campus Fabric

My name is Alex Berger. I am a principal engineer here at Cisco. And today we're gonna be talking about a bunch of work we've been doing to deliver, uh, campus fabric through Meraki dashboard.

Um, joining me today is gonna be, uh, Nico Dero, who's a senior TME on Cloud managed Switching, who's gonna do some demos of the actual, um, you know, functionality. But before we get into that, um, I just wanna highlight something that I think you've heard a few times now. Uh, we've been really busy trying to get the cloud enabled for more platforms from Catalyst, like we've been working on, you know, the 93 hundreds.

Uh, historically, uh, we took our first step with iOS XE with the MS three 90, but we know customers have been buying lots and lots of, uh, different catalysts. And so with our 1718 release, we're actually introducing support for the 95 hundreds, as well as the rest of the 9,200 portfolio. So the, uh, cxs, et cetera.

And we have more things we're trying to get brought into dashboard, and we'll be coming over the next, uh, probably the next year, if not the next six to eight months. But not only on platforms. Uh, we've been putting a lot of work, we're also building tons of features to support larger environments where there's, you know, requirements like VRF support, BGP, um, you know, routed in interfaces in our PVST, but all of this building towards being able to support large, large environments and large campuses.

However, we all know there's tons of challenges with, you know, traditional networks, the spanning tree, uh, routing down the access layer from just management sprawl, like having to manage each device as an individual entity. Um, that becomes difficult when you have like rapid troubleshooting and someone starts making changes, try to fix a problem, you end up with sprawl in your configurations. You end up having things deviate from a standard.

Um, trying to take care of large layer two environments, especially if you have requirements for layer two adjacency becomes difficult because you have to start stretching, uh, VLANs and introducing spanning tree in large capacities. Um, and then the last piece here is, uh, really security can be difficult as well, especially if you use traditional or legacy mechanisms like VAN assignment. Uh, some devices don't like having VLANs change most, in fact.

Um, and then visibility into those policies and how they're actually being, uh, instantiated in the network and what's actually happening with those policies. Like what's being blocked, what's being permitted, um, and keeping all of that, you know, together and, and well managed. And so we've been trying to take a lot of those challenges and bring that into an actual campus fabric.

And so today we're gonna see this preview of cloud managed fabric. I'm gonna go through and just explain like kind of our focus areas, and then the real cool part's gonna be when Nico goes and does the demo. But we've been looking at this as a way to try to reduce the amount of management sprawl, create a single logical entity that you manage, uh, you know, across networks in Meraki dashboard.

If you're not familiar with networks, we usually have them as like logical buckets of devices that get similar configuration. But when you get into larger campuses, you may be breaking those into multiple networks to manage them as like, you know, building a, building B, and that can become difficult. But we also wanted to make sure that we could build a product that could be built on top of existing networks.

So I don't know how many people have tried to, you know, turn up a, you know, a more modern network when there's already existing hardware, but that takes a lot of work, a lot of hands-on, and a lot of times you have to start building it on a separate set of hardware. So you gotta swing cables, deal with, uh, large, uh, outage windows. And so really focusing on that brownfield portion.

And we also introduced some cool things around staging configurations. Uh, that's not something normal in Meraki dashboards, so I'll talk about that here in a moment. But also trying to make sure we can tackle security and handle, you know, some of the most rigid security requirements for microsegmentation and control of endpoints.

And then, as I mentioned earlier, you know, when you stretch L two, in most cases, that causes all sorts of fun things like having to have a single VLAM present across your campus for things that require that layer two adjacency is painful. And then we are gonna be building out a lot of things around assurance, but trying to keep that very tailored to knowing that the fabric is working well, knowing how things are operating in general. When I mention seamless integration, I don't mean that we're going to like immediately convert a network into a fabric.

Um, but what we want to allow is you to build a fabric on top of that network. And that doesn't mean that it's gonna be perfect immediately, but allows you to start with what you have and then move things into the fabric. And so we're gonna have some tool sets to allow you to migrate, uh, segments, but we wanna make sure also that we don't make you build fabric down to the axis layer, because that can also be painful, especially if you don't have all the hardware necessary.

And so we will have support, full support for, you know, starting fabric at the distribution so that you can keep that access layer intact, but still have, sorry, did you have a question? Uh, hard, uh, just a comment. Hardware or licensing.

Yeah, no, it, it, it was, it's really to try to make it as flexible as possible so that, yeah, you don't have to redo your whole network. Now with the, lemme take some water here real quick. On the underlay side, we wanted to make sure that yes, you're gonna build a fabric on top of this network, but you probably have devices that have static ips or requirements that you're not gonna really go and touch every single device.

And so being able to take existing subnets and move those into the fabric. And so we're gonna have an entire workflow for looking at all the devices as part of the fabric. And then you can pick a subnet and just move it into the fabric and then choose where it's present.

So you could deploy it across the board as in any cast, you know, uh, subnet or pick just a couple leaves where it needs to be present and then prune it from the rest. And then once you've migrated everything outta the underlay, um, we're gonna build tooling to actually help optimize that underlay so that it works well and, uh, is as resilient as possible. Now, not all network devices can handle tens of thousands of Mac addresses and handle tons and tons of broadcast traffic.

And so we've been spending a lot of time also making sure we have the tooling in place so that you can, uh, optimize that topology and optimize how those subnets are, are presented on the network. And so, for instance, be able to go in and turn down, uh, bum traffic replication between leaves so that southbound devices don't necessarily get impacted by large scale environments. And also give you the ability, as I mentioned earlier, to just selectively place those segments on different leaves based on what the requirements are in the, in the network.

And that helps us build towards supporting things like distributed wireless. If you're familiar with Meraki Wireless, we usually standardize with bridge mode, which means that the AP is a trunk into the switch. And those L two segments have to be present across the topology for like seamless roaming.

And so with that tuning, we can then create a subnet for AP management so that we can share those fast roaming keys. But then the endpoint segments or the wireless client segments can be restricted from seeing every broadcast packet on the planet so that we can have a very scalable environment to work in. One key piece here too is from a security perspective, this fully integrates with our adaptive policy feature set, which is just TrustSec with inline tags.

And I'll talk about that here in just a second. Now, if you've seen anything about some of the work being done in wireless, we did just recently introduce a campus gateway, which allows you to take a traditional WLC based design and make it cloud managed, essentially. So we can start tunneling stuff back to a centralized point of presence, and with fabric we'll just act as a transit.

However, we can still maintain that same tagging, the same behavior for security policy and bringing all that back in, uh, back together so that no matter how you have it deployed, if you need a giant environment for seamless roaming across tens of thousands of endpoints, you can use a campus gateway and still get all those benefits of the security policy. And then the ease of use from that management. This slide always takes a while to load.

Alright, the other piece to this is we wanted to build this with security in mind. And as I mentioned, we have full support for adaptive policy. And then some of the cool parts about this are, we can still take that inline tagging so you don't have to have every device be part of the fabric to actually use the microsegmentation and policy, but it's also fully integrated with our access manager, which is our cloud delivered, uh, kind of NAC product, and allows us to do dynamic authorization of endpoints and association of those tags, but carry those tags in and out of the fabric so that you can have, you know, for instance, a user like Darren here connected, get the employee SGT ah, there we go.

And then have that actual SGT hit the leaf, get moved into the VXLAN header, and then get moved back out into the CMD header where those S GTS live, and then have a firewall be able to process a very granular policy on that endpoint, irrespective of, you know, the fabric topology. As long as we have those tags in, we can send them out. So that means if you have like a third party tagger, tagger and you actually had, um, your VXLAN fabric configured properly, you could pass traffic just fine.

Yeah. So we, uh, from a VXLAN perspective, we just moved that SGT into the GPID field in the header. So yeah, it essentially, yeah, transparently just move them across.

It's transparent. Yeah. Yep.

Okay, So the, before I hand this over to Nico, I've got two more slides. We wanted to make sure that the setup is easy and Nico's gonna show this, but it's really five steps, and it's really only three steps to get everything configured. You create the fabric, assign the roles that you need, create a, a fabric, VRF, and then any new subnets if you're going to use those, configure your border border routing, which is just ingress egress, routing in and out of the fabric.

And this is where we then offer the, the preview and stage function. So you can stage it and then review that with your team. And then at the fifth step is just to click the deploy button.

Once you click deploy, we push the configuration down, and this is where we're going to introduce the underlay migration workflow. So you can validate that everything's working in the fabric, and then start moving those segments in, um, over time. Now, I, I really like this part just because I, I've been wanting to try to get this built for a couple years, and this is a really good reason.

So we finally have built in a staging function so that you can start building config and then save it, but don't deploy it. And that means that you can update configs, review them with the team, plan an actual change window, and not have to do everything during that change window. If the only way that you normally deploy configs, like in dashboard, is to build them all, click save, and then it deploys.

Your change window increases dramatically, even if you just have small changes to make. And so this gives us the ability to actually have those configs. And even day two, if you keep updating, you can stage review and then deploy.

It just allows us to like, kind of make it a little bit more user friendly and a little bit more, uh, integrated into most customers change, um, controls. All right. Now before I hand this to Nico, last thing I wanted to lead with or leave with is we really have been trying to look at fabric is not just a tick box.

It's about trying to provide customers something that provides value, but allows them to take their existing network and add that value and then be able to modernize the network versus trying to, uh, you know, build things in parallel and have to, you know, deal with a lot of the costs and, and expense that comes with that. And try to make sure at the end that we can also provide, you know, the security policies necessary to operate a large campus and be able to control, you know, resources as necessary. So, Nico didn't say this, but I wanted to put this on here for fun.

Uh, he's gonna come up here and do a demo now of the actual user experience and a full setup. Alright, uh, well, great, uh, great to be back here again. Uh, thank you very much for your time.

And, and this is a very exciting times 'cause we're, we're about to demo, uh, basically our cloud orchestrated EVPN fabric. So this is a standard network, as you can see here. We've got a, uh, uh, multitude of these catalyst switches, right?

Everything from the 9,300 x 93 hundreds. As you can see, as we bring in hardware, we're also trying to leverage that, the capability underlying of, of the hardware to be able to, uh, develop new features in fabric being one of them. So these switches, nothing, uh, super exciting about them outside of, uh, they've been deployed, uh, with static ips, just a straight, uh, layer two switch at this, uh, point.

There's nothing really on it. Uh, and I can show you that too, right? Uh, on top of everything we're doing with fabric and new features, we're also building out the tool sets to be able to troubleshoot this and manage it, right?

So here I've got one of the LEAF devices I'm gonna jump into, uh, CLI terminal, right? So we're also not losing all the, uh, capabilities you have for troubleshooting or that you've known and you've learned, right? So, you know, show IBGP summary this, you can see nothing's there.

Show VRF. We really don't have anything configured on this device. And this is a, you know, a good starting point to, uh, you know, getting these switches, uh, configured to get them, uh, static ip.

And that's really all you need to begin. So we're gonna go ahead and create this fabric, right? So under orchestration or organization, sorry, we have this fabric, uh, page.

So this is the, the first step on generating that, uh, fabric workflow. We're gonna create a new fabric, and you can see here how we automatically create a name. You, of course, you can customize it.

Uh, and, uh, A-B-G-P-A-S-N of course, you can modify that as well. Here. This is where you would select your network or networks.

Uh, in this case, I'm just gonna use one. But this allows you to select multiple networks. So then as you create fabrics or as you create subnets, you can, you can have that subnet, uh, exists over multiple leaves across multiple networks.

So it's not just contained to one site. This kind of gives that a little flexibility. If you have a location that has a subnet, maybe you want to expand that subnet to another location, this is a great way of taking that.

And, you know, being able to, uh, expand that fabric as well. Now, when we create the fabric, we do need to, um, you know, generate some loop acts, uh, which is also a new concept to Meraki. But you can see here that we're gonna give it a loop back pool so that when we generate loop backs, it's gonna dynamically, uh, create those, uh, interfaces from this pool.

And, uh, of course you can customize that. Now we're gonna assign the roles to these switches. You can see here that I can go in and select, you know, this is a border device.

I wanna go in, maybe do a multiple select on these spines, but this is where you sign the rolls. We have a, a single roll, uh, per device right now, of course, we're gonna have multi rolls. So if you want to do a, uh, border leaf, uh, that is coming shortly.

And of course you can also do some searching. So we can do some, you know, fast configuration, but you know, that's really all you need to do at the, uh, you know, the no level. So once we define those rolls, uh, you can see here, right?

We've got the borders, we've got the spines, we've got the leaves, we're gonna go to the next step here. And that's where we, you know, define our VR Fs. Now, we'll automatically create A-A-V-R-F called fabric that will have auto rd RT on it, so that we do a lot of that complexity behind the scenes.

If you want to go off grid and, you know, do your own thing, you totally can, right? And that's what we want to do is be able to have a, a very powerful way of creating a fabric, but not, uh, nerf the capabilities of being able to have it customizable. So down here we have subnets.

Now with any good fabric, we do need a egress, uh, subnet. So we're gonna start off with a, you know, uh, egress sub subnet subnet, and it's gonna be VLAN 50. Um, there you go, man.

I, there you go. Uh, keyboard is hard. And then you don't type like this normally.

Yep. I mean, like, uh, exactly. This is, uh, not the standing desk I'm used to.

Um, and then, you know, what we're gonna do is just define that, uh, egress vlan. 'cause anything that, uh, you know, fabrics are really cool, but if we can't get things in and out of it, it's, uh, it's a very fancy network, right? Uh, and we're gonna disable any of the, uh, any casted bummer replication on that device.

Now, egress only has to exist on the border, right? So this is, uh, just showing you how we can create these subnets. And you define where those subnets exist.

Egress only on the border, but this is gonna be our first fabric vlan. Now the naming is important 'cause we also are tying into a lot of the other features and capabilities we build into dashboard, like the dynamic vlan, assignment vlan naming here. We're gonna call this fabric, you know, VLAN N 1 0 1, just because something like super, you know, um, creative here.

So this is gonna be a fabric VLAN 1 0 1. And this is where we'll, uh, define our, you know, uh, the details. So we create our, uh, you know, gateway or any cast.

We're of course gonna use a, uh, external DHCP server. You can see down here we've got any cast and bummer replication enabled. If we want disable, uh, bu replication for our greater scale, or we don't really need it for like a guest network.

This allows us to, uh, configure that. And then here we had define where we want this subnet to exist. If we, you know, have a it existing on a few, uh, switches and we wanna expand it, we can go in there and it's just very easy to create that, that scope.

Yep. And then, uh, after we create that, of course we can create multiple subnets, but just for the demo, we're gonna do one next step is that border routing configuration. How do we get traffic in and out?

Now we can leverage, uh, static IP if we want to, but here we're gonna use an IGP 'cause uh, fabric's pretty dynamic and we want to have it integrate with our existing setup without having to manually configure a bunch of things. So here we're just gonna create an OSPF instance. You can see how it already knows at the border level, which subnet, uh, we can choose.

If you had multiple egresses, you could select that, but that's essentially creates that OSPF, uh, IGP so that it can peer and, um, you know, both learn the default route and inject it into the fabric, but also share, uh, traffic outbound as well. Nico? Yes, before you get too far, you, you kind of glossed through a, a part of vxlan it's pretty important, which is the route targets and the route Yes.

Distributors and I, I rec, I, I've done this before, so I, I recognize that, you know, the auto mm-hmm. Is a, a really great functionality. Um, but if you don't do auto, you can really break things in a hot hurry.

Yeah. And, Uh, I'm wondering what kind of guardrails you put on it so that if somebody's coming in here is the first time they're doing vxlan, and you know, they're not super familiar with all of the, you know, the weeds that grow up in vxlan. How do you keep somebody from just Doing something bad, Making a huge fat mess?

Well, that's, I mean, I, I, I feel like we could have a whole session just on that, right? For sure. So, I mean, it's a delicate balance we're trying to do is try to build some powerful capabilities, uhhuh, but without having to have like, you know, guardrails or, you know, too many, uh, um, you know, soft points on it.

Um, that is definitely something we're gonna get into. 'cause we want to, the ability to go really crazy eeb, GP Pureing, uh, you know, expanding existing, uh, fabrics for right now. Um, the auto is there as just a, a guideline is That, is that like the default?

Yes, It's the Default. So like, I could go in and just say, I want, I don't know what I'm doing with RD and, and mm-hmm. RT default as it's auto.

I could keep moving on and Yeah. And, and I, I think, like, I think if you started expanding into other fabrics or routing into larger environments, that may break stuff. But if you just had a small lab and you did your own, uh, RD rts, though, we use those values on all the configurations, so it would technically work.

Uh, but it, yeah, it could get a little, yeah. So the, where I'm coming from is I've, I've worked with some customers who they go on the internet and they're looking for, they're, they're trying to this VX land thing out. And there are some guides out there that tell you to specify the RD and the Yeah.

And the, um, and the rt. And you can get into a lot of trouble if you don't understand exactly what you're doing and, you know, and then you need to phone a friend for absolutely. For some help.

So, yeah. So right now we don't even let you use, uh, manual define. So we're just locking it in as only auto RDRT.

So oh, oh, better. We do have that, uh, VRF list, so you can see what you have configured in the organization, but you, you can't go in and, um, uh, use the non-auto RDRT, at least from what we're gonna release for the initial launch. Okay?

Try to protect against that. And you can see here I've created a couple other RFS and they're not, we can't, I can't use them, right? I would, you have to create a net new VRF for the fabric, okay?

And, uh, yeah, you can basically disable it, but there's no custom. So, okay, I guess we do have some guardrails. Um, so the next step, right?

And, uh, is, you know, we, we've defined everything. And this gives us our summary page. So here we can review the role people, devices, um, the ips, make sure we have everything we have configured pro correctly, the subnets that we're gonna generate, make sure we didn't fat finger anything.

And then the, uh, you know, the IGP that we're gonna use, the next step is to move to staging. So here it creates this fabric, uh, workflow. And then we're gonna jump into it.

Now, this is where we can review, we can share it with our peers. We can get comments on it. We can make sure that we have that change control window open, uh, the right, uh, resources on board to start deploying it.

We can look at the roles you can see here. Um, you know, so everything is nice and summarized in this, uh, environment here, uh, border, uh, configurations as well as the fabric subnets. Now you can preview changes, comment, and deploy.

We're just gonna go ahead and comment, deploy. Uh, and this is where we'll start rolling out the fabric. There you go.

Fabric deployed. Now you're thinking, well, prove it to me. Right?

Well, here you go. Right? Uh, it's great to say that it's configured, but now we want to leverage the tools that are in dashboard to actually troubleshoot this, to verify that it's deployed and, and what does it actually give us?

So, you know, we've got our fabric deployed. We're gonna go to our switches. So, you know, we've got, um, our like leaves and we don't have to configure the borders or spines anymore.

Everything is gonna be, uh, configured at the port level, right? We can go in and edit a port. But before I do that, I wanna show you that we have VLAN n profiles.

So in our VLAN n profiles, this is where we can define the VLANs in the environment. We will auto-create that fabric VLAN N 1 0 1, and this creates this really nice abstraction layer where we can see the fabrics that are in use. We like can leverage the name.

And you can see here that if I wanted to, you know, move our, you know, wired clients from VLAN 11 to 1 0 1, it's a pretty simple change. Uh, if I can get it. There you go to flip those VLANs around.

Now everything that is, uh, you know, mapped as a fabric VLAN gets, you know, mapped to the, to the, to the fabric environment. Um, on the switch itself, you can kind of see that, where I can go in and, you know, define the port. If I want to change it from like a camera VLAN to fabric, I just have to define that name.

I don't have to remember those, uh, VLANs itself. So, uh, going from there, we can also verify configuration by using our, you know, cloud CLI, right? Uh, we can now jump into that leaf switch and hopefully we've got, so jump into the CLI here, and then we can do show IP BGP summary, not active yet.

Show Meraki config up, right? And then if we want to go in and configure a port, right? And I wanna map it to, um, like say a camera to show you here, go edit.

And then you can change this here to camera vlan or vice versa. Uh, and then on the device itself, we can actually watch the configuration apply. Now the confi configuration probably already got pushed, but we're gonna do show Meraki config up, and then you can actually watch the configuration apply here.

Now, in parallel, you know, we can do a packet capture on this. So we have, uh, troubleshooting tools if we wanna go to the port level. And in this case, I think I need to go and see why I can't get my camera online.

And here it's on VLAN 10. I want to go into there and change that to that fabric vlan here. So it's the same workflow you're used to in Meraki, right?

We, we know have a device here that's on VLAN 10, has no IP or no valid ip. I wanna go ahead and disable and re-enable that port. Now we can also do a packet capture, and you know, packet capture takes a little time, but I've already done one.

And what's great is that when we do packet captures, we also are VXLAN aware. So in our cloud PCAP or intelligent P packet capture, you get all the, you know, ability to look at the packets. But we do have built in profiles.

So you can go down here and select vxlan. So this will automatically, uh, show you the view where we can see, you know, both ips, we bo you know, and hopefully you can see that here, maybe a little bit bigger. There you go.

But you can see the dual ips where you have the underlay and overlay ips. You can go down and see the, uh, vxlan, uh, header information, the VNI group policy ID if we're doing adaptive policy, right? And that's part of what's great about this VLAN profile is that, you know, here we have, uh, you know, of course I'm gonna flip this back to what it was, but here, if we have our, you know, vlan, uh, IDs to map to name, it's very easy to easily go in and map and adapt a policy to that as well.

So that if we want to have a very seamless way of doing that microsegmentation with fabric, it's as, uh, easy as making sure that, that those ports and those, uh, VLANs are tagged appropriately. So that being said, we can go back and take a look at the switch and make sure that we've got all the configuration applied show IP BGP summary not active yet. And then, so on this fabric, you can also see that once we deploy the fabric, it'll give us the summary page where you can see the fabric devices, how many multi rolls we have out there, the border configurations.

You can see here, I've got a couple BGP piers offline. Uh, but this gives us a, an idea of, you know, what was deployed. We have a topology view that Alex showed earlier where you'll see the devices.

We don't have the connectivity there yet, but that'll give you that, uh, topology of how things are laid out. And going up here, you also see the VR Fs that were deployed, the border configurations, but here are the subnet fabric, uh, subnets that were generated on each of the devices. So you can verify the configs are there.

Now, on top of that, we, it's not just static assignment, right? We have the ability to go into, like, access manager, access manager is our, you know, cloud, uh, radius, uh, and policy server. So we can go in and have ports dynamically assign, uh, ports to the fabric.

So you can see here, here's a rule where I'm gonna tie into, uh, a wireless where if it's, uh, if someone's connecting into the right AP with the right PSK, they're gonna map to that fabric VLAN 1 0 1. So we can now, uh, word previously mapped to maybe VLAN 10. This would map to VLAN 1 0 1.

So you can easily move devices into the fabric and verify that everything there is working. So I know we're hitting some time here. Any any questions that we can answer?

This is a preview Right now we're looking at, uh, launching this into public beta in like November timeframe, just to level set that I, I should have mentioned that earlier. But Quick question, Josh, from Diversified, do you have some targeted, uh, partners and or customers already lined up to help you in that? Absolutely.

I would assume so. Yes. Absolutely.

Good, good nods on that. Yeah, And we're gonna, we're gonna be having, uh, a fairly decent, uh, EFT phase where we're gonna be working with customers and getting a lot of feedback. 'cause like, yes, we made some very opinionated decisions, but we need to make sure that it meets customer requirements.

So we do have, um, roughly 10 so far that we're working, we're gonna be working with, um, the minute we get this into a spot where we can mm-hmm. You know, have people start taking advantage. So it is, it is hinging on us getting, uh, 17, 18, uh, iOS XE 1718 into dashboard and out for everybody, which is gonna hit in beta in July timeframe.

So we're gonna start building off of that, right? And, and that will, by the way, forgot to mention, um, we're gonna have support across the 95 hundreds, uh, 93 hundreds MS. Three nineties.

Um, so, So this will roll back into the existing catalyst line that are absolutely in Meraki dashboard and S3 90 specifically and Three nineties. Yeah, for sure. Yeah.

And what's great is that as we deploy, depending on the type of hardware you deploy, we're gonna keep track of the capacity. So as you, as you roll it out, as you use it, we're tracking how much is in use, how much is left in the, in the fabric to deploy. And that gives you those, uh, metrics to, you know, make sure it's successful.

So You've been, you did mention you were looking at, at dealing with Brownfield deployments. Is there a way to have Meraki in a read-only mode where all it's doing is it's not configuring equipment, it's just looking at what's there and maybe pulling like MAC table information or whatnot? Yeah, absolutely.

We have, um, the ability to run it in, uh, you know, cloud managed device config, right? Which was, uh, previously known as, uh, mount monitoring. Um, and that allows us to take existing switches that maybe we don't have the full capability to support the feature, like maybe E-I-G-R-P or something.

So you could have it where you have the full visibility to dashboard. We have remote CLI into it where you can read right via CLI, but we're not pushing config, we're not managing it. That allows you to run your brownfield config and still run all the tools, the alerting packet capture without affecting the, the config you have.

And then when we are ready to onboard it, we support all that features, then we could migrate it in. So that gives.