Delivering the Edge: Campus Gateway

My name's Travis Sch. I have Justin Li with me as well. Uh, to use Anand's.

Really bad joke. I'm the y he's the phi. Uh, but we're gonna talk a little bit about Campus Gateway Day, a new product that we're launching here very soon.

And there we go. Perfect. So, on agenda, we're gonna kind of split this into two sections.

I'm gonna talk a little bit what is Campus Gateway? Like, what, why did we build this, reset the problem statements so everybody understands. I don't think, you know, I'll have to go too deep on that for this audience.

And then I wanna talk a little bit about the architecture. Once we get through that. I'm gonna hand off to Justin.

Justin's gonna go through some day zero stuff. I'm gonna talk about the flow of how to get this thing into dashboard. And then he is got some cool demos for you.

So what is a campus gateway? Well, in short, what we heard from Matt, what we heard from Nick, you know, we need to meet our customers where they are, right? We have all premise customers, we have cloud customers, we have hybrid customers.

Oops, I need to go. Uh, but on the Meraki side and the cloud side, we weren't necessarily always able to meet that customer requirement. We didn't have this large scale concentrator style overlay network solution.

We had a couple other things. We had M Max's, we had distributed layer through roaming. We had various solutions that kind of meet, met certain needs, but didn't really do what we needed to do.

So, to be short and simple, it's a large campus ready solution. Seamless roaming at scale in design without redeploy. And to recap, like what is that customer ask, why did we do this?

And I kind of spoiled, varied the lead a little bit. There is, everybody comes to us, say, Hey, I wanna move to cloud. We, we hear it from universities, we hear it from manufacturing, we hear it from hospitality, you know, all these different cu customer verticals.

But they say, Hey, I have this, I have this controller, I have this overlay architecture that I want to keep in place for a variety of reasons. Could be, could be technical, could be layer eight, doesn't really matter. They say, don't make me change that.

Don't make me give that architecture up. I like that architecture when I go to the cloud. So then that kind of translates to a couple different technical requirements for us when we thought about building this product and how we would build it.

I'm not gonna dive too deep into those 'cause I'll cover those in the next slide. Um, but features, so from a launch set perspective, we, we worked really, really hard to make sure that this is an MVP thing, right? Like this meets all the needs of our customers when they want to deploy this.

Um, from a performance and scale perspective, I alluded to this that we've had other options. Like the MX didn't really kind of meet the need of what, what what we were starting to see out there. So scales to 5,000 aps, 50,000 clients, a hundred gig throughput per box.

And I say two, 200 gig clustered. Well, what does that mean? That, let me jump up to infrastructure.

Active, active redundancy stateful fail over on this. Justin's gonna cover how that works later on, he'll have some slides and show you that. Um, but these pairs, we load balance across these, uh, we call it a cluster in dashboard.

I'll show you a little bit more about how that works in dashboard. And again, keeping the Meraki way of configuring this is you're doing tunnel configuration for SSID. So kind of keeping, uh, with the way we do things in dashboards.

So it's not too much of a change from a security standpoint. Everything you need to run on a, uh, an enterprise network, the campus gateway acts as the radius proxy, much like you would have with an on-premise controller. Um, and then all the other features you typically see in these highly demanding environments from a macro level, AAA override named VA, all that sort of segmentation to a microsegmentation side on adaptive policy.

And then lastly on services, MDNS gateway with location services and support for wifi personal network. Just to take this backwards. Yeah.

What's the difference between a gateway and a controller? We will get to that. I will get to that.

Mm-hmm. Yep. It's a great question.

It's a great question Travis on. Yeah. Uh, the impetus, clearly Cisco's acting on, you know, customer, uh, feedback.

I guess, uh, is there any way to characterize, you know, how many customers, which segments are, you know, really driving the campus? Yeah, yeah. No, that's, it's a really good question.

I, I'll, we really started with the higher ed segment. I think this is where we heard a lot of this from our sellers and our firm customers. These, these are universities where they're lean.

They got maybe a couple guys, maybe only one guy running their network, right? They need that operational simplicity of the cloud in the Meraki dashboard, but they also wanna keep that architecture in place because as you can imagine, you have one or two guys doing all this. He's got multiple different things he is doing.

You know, to be able to change all that, um, was, is a lot. And, and I think a lot of those customers also saw the benefit of Meraki in something like the dorms where they could deploy dorms with Meraki distributed. And that works really great for 'em.

And then they say, Hey, I got this. I I got this centralized architecture in my campus where all my academic buildings are. I'd really love that, run that on Meraki, but I need a solution that matches that.

Good to know. Great question. Yes.

Yep. So getting kind of where you're asking, uh, what's the difference? This runs on the same hardware platform as A WLC.

It's a CW 9,800 H one that latest gen. Um, so from a hardware perspective, we're using that same hardware. We're getting closer and closer to that vision of single hardware platform.

And from a supportability standpoint, now this is gonna run, if you're familiar with Meraki software, R 31 2, this is not released. We're an R 31 right now. 31 1.

So that's gonna be the minimum software version. So just kind of some data sheet information here. And then from a supported access point standpoint, all wifi six, six E and wifi seven.

So anything that Anon and Nick were talking about, we support on this from a, from an access point standpoint. So that's kind of some basics. Now, let's talk about the architecture.

This is, this is the key differentiator here. Um, for those of you familiar with Meraki dashboard, which I'm sure everybody in this room is, you know, all your management lives up in the cloud, right? That is, that is very different from a controller where everything lives on controller.

You have management control and data playing kind of all wrapped up in one box. And it does everything well in dashboard. We're keeping all that stuff there.

We needed to keep that in place. We wanted to keep that in place. It's a very important construct of how cloud functions for Cisco.

So all your configuration, your monitoring, your licensing, all your troubleshooting, that still lives up in the cloud. And then also we're keeping things like a IRM, auto rf, rogue detection, all that also lives in the cloud as opposed to on-prem, on the box. So architecturally, that's a big difference there.

That, that stays up in the cloud. Down at the access point, we have a lot of functions built into the access points today from QS to rate limiting, uh, adaptive policy tagging all your client state machine happens at the ap. So we're leaving that all intact down there.

So really, what do we have left for the campus gateway at this point? I mean, at, at a basic level, it's data plane termination. It's doing your aaa, it's doing your MD and S, but it is also keeping your roaming key store and your client D information.

So that's the D store on there. So when I talk about roaming scale, that's how we're kind of handling a lot of that, being able to pump up that scale from a distributed, where we don't have the, the keys hashed across multiple aps. We don't have the client database across multiple aps.

We're keeping it in one central place to allow us to roam up to a thousand roams per second is the way we've tested this. So that's, that's the key differentiator. Does that, does that make sense?

Does that kind answer the question? So you took the management plane out of your controller? We, we took the management plane out, and it's not split Mac too, and they're on my next couple of slides here.

We also aren't using Cap Wap on this either. So, so again, the AP and the MCG, the campus gateway each have their own next tunnel connection. So the gateway is doing no control of the ap.

The there is no requirement, although we do enforce, and Justin will talk a little bit about how the firmware is handled. You know, there's, there's no requirement for the AP to run the same software as the, the gateway because again, it's all managed through dashboard and you do all your firmware management through dashboard. Just to follow up on that, that, uh, this is kind of the direction that I was seeing the Meraki managed Catalyst 9,800 platform, slowly moving to.

Mm-hmm. Why did Cisco see the need to kinda build this on the Meraki side moving center, as well as having the, the catalyst managed by Meraki? Because it, it seems like these, these two products, uh, managed 9,800 and the campus gateway are moving to the exact same destination at the same time.

You, you're saying the, the, the, the, like the cloud monitoring on the WLC? Yeah. Yeah, I think so.

That, that's always gonna be kind of that in-between option. I think where at least the, the cloud managed WLC is, it's never meant to be a fully managed thing. This was something that we'd started and said, Hey, we need to build a solution specific for cloud, right?

And we don't want to just plug in that controller. I, the, the, the thought was a little bit different here, that that will still be your primarily driven on-premise customers. This is maybe for your more cloud first customers.

Sorry, go ahead. Uh, So I see the roaming and key management on the campus gateway, but I mean, obviously if a campus is moving in this direction, they already have wireless controllers. So when you implement a ca a campus gateway, will that do the mobility roaming groups between?

No, no. We, we won't, we won't. That's a, that's a good question.

There is, there's no like, concept of mobility domains between those two. Okay. Yep.

And, and there's a reason why, like when I show you how I go to the next couple slides with, with the tunneling and, and how we store all that, like, D store is fundamentally different than how the WLC does it. I was gonna ask, 'cause I think every cloud managed wifi solution has, has, or has been adding something that's just a tunnel terminator and a ga a gateway appliance to sit there. I, my understanding is Meraki has been doing that through the, the firewalls that can be placed.

Mm-hmm. So what is the difference here? Yeah.

So, so let me, let me go on and Okay. And kind of hit some of these next couple slides. Um, yeah, let me, let me, let me address that.

Okay. 'cause I thought, I thought, I thought I had the, I had the tunnel slides next, but, so primarily scale, right? If you think about an MX four 50, that scale was limited to around 1500 tunnels, right?

And a tunnel. When, when that architecture is in play, it's psis id. So let's say I have 500 aps deployed on my campus and I have three SSIDs.

I want a tunnel that's already 1500 tunnels and that's IP second encrypted. The way we're doing it on the campus gateway is, it's a VXLAN and quick tunnel. It's one tunnel per ap.

And so you only have to think about the number of APS tunneling back. Now you still configure psis id. So you can do bridge and tunnel, sort of like a flex connect architecture, right?

You can send it back to an aggregator or keep it local. But we're also, we don't have the encryption overhead initially with this. And we have the higher scale platform, like I said, 5,000 aps.

So could They encrypt if they needed or wanted to for specific? Not not at launch. We're, we're we, we will later add that later.

Yeah. Yeah. Really few customers have that.

Yeah, Exactly. Exactly. And that's kind of why we, we set it for a later release.

Cool. Um, so I think I kind of mentioned this earlier. Campus Gateway and MRS are directly managed by dashboard, right?

So that, that's a big difference here. So all their firmware, all their config is generated independent of each other. You don't have to go through the campus gateway for an AP to get its config for it to do RRM or any of that sort of stuff.

So they're maintaining their own separate external connections. If it loses connectivity to the internet, it'll continue to operate, right? It'll continue to do that, but you just won't have Tory or config at that time.

Um, if for some reason you go in there and you can figure it wrong, set VAN 11 instead of 10 and you disconnect it from the network, there is a local status page, just like any other Meraki product, you'll notice that screenshot. It looks a little bit different than your traditional local status page. We've kind of revamped it.

It looks different on this product. Um, but this is kind of the direction that I be, the local status page is gonna go. But you can log into that for on-premise recovery.

If for some reason you can't get it to establish connectivity to the internet, some design requirements at launch. These, these are pretty important when we think about deployment. So at FCS at launch, MCG Mrs need to be in the same dashboard network, not same layer three, not same layer two, whatever.

I'm talking Meraki Dashboard networks from a configuration standpoint and in the name Campus Gateway, they need to be in kind of that same geolocation. So we're saying less than 20 millisecond round trip top. And then there's one cluster per Meraki network.

You can kind of see in my illustration there of if I have an org and I have multiple dashboard networks, I drop a Meraki camp, a pair of Meraki campus gateways. In each dashboard network, there are two nodes per cluster at launch. Uh, the network scale will scale up to 5,000.

Those of you familiar with our documentation today, we say roughly a thousand nodes per dashboard network. We've done a lot of optimization on the dashboard side itself to be able to handle the extra load of all those nodes. So we will change our guidance to say 5K nodes, period.

And there's no limit of dashboard networks with mcds in them, right? So if you have 30 networks for 30 buildings and you want to drop a campus gateway in each building, you can do that there. There's no limitation of number of nodes, but there is that org level device limit that still does apply.

Any questions on that? Let me pause there. I threw a lot of requirements at everybody.

Yeah. On the, uh, dashboard for these, um, I would say resource skill limited scenarios. Are you getting more, I would say, uh, demand for, you know, natural language interaction with the Meraki dashboard?

Is that something that's on the roadmap or something that you're hearing more request That that's not something I'm, I'm gonna talk about here? I think we probably have something, do we have something planned for that? Maybe.

But yeah, I think from an m CG perspective, it's kind of out bound for us, I think I'd say. Alright. Yes, fair.

As far as this product goes. Okay, so architectural difference here as well, right? So we are using quick tunnels to establish all our control plane, no Cap WAP here.

No cap WAP at all. Quick is used for, uh, our AP registration, client anchoring messages, some inner HA messages between the two different campus gateways and it's automatically encrypted by default by dashboard. Nothing anybody needs to touch or think about.

We're doing that on the backend for you. And each AP is gonna establish a quick tunnel to both members of the cluster. Again, nothing needs to be configured.

You'll see how this all flows when Justin gets up here and does his demos. It's that Same, uh, that same time limitation between the two, uh, plus, uh, two gateways in a cluster, right? It's 20 milliseconds or does it, Is it the, there is the inner cluster you're saying?

You're saying for the connectivity like our RP port? Yeah, Between two, I think that's, I think that's higher. Uh, so for the latency between the CGS in a, in a cluster, I'll be covering that in the next few slides.

Cool. And then, yeah, VXLAN for the data plane. So, uh, we're using that as the encapsulation header.

All the radius messages, messages are sent in there and any of your quoss or policy information gets carried in that tunnel header itself. Again, not encrypted at launch, we don't have that option. Something we'll be looking at adding later on.

Alright, so with that, that's a lot of architectural stuff. Are there any questions before I hand off to Justin? And I'm sure if there are you cover why the decision That go with quick on, on The tunneling as opposed to like say CAP Lab or just quick itself?

Yeah, just Like, Um, as a PM I'm gonna say it was an engineering decision, but that's, no, I, I think we, we, because there's certain things with CAP Lab of like as part of that protocol, the AP has to register to A WLC, the AP has to do a firmware check and all those sorts of things. We wanted to move away from that. And then so kind of naturally like, well, what makes sense?

And these were kind of the two that stood out I think, in terms of our, our overall strategy of what we want to use for, for these protocols. Yeah. And then just kind of to add to that, um, as Travis said, uh, with uh, the MCG and then the aps, they don't have to be, have the same software running.

So like with traditional nine 800 and Cap wap, you had to have same AP image had to match WLC. In this case, we don't have that hard limitation at launch. We will be enforcing having the same software image when you upgrade.

So for example, in our beta right now we're on 31 25. So when customers upgrade to that, both aps and CGS need to be on that image. But in the case, let's say you need a special engineering special image for MCG or a special engineering image on just a specific ap, we can load that on that without having to upgrade your entire network.

Alright, so we'll go to the day zero setup. So how do we actually onboard this MCG? And by the end of it, you'll really see how we really wanna make sure we can bring that scalability while still having that Meraki simple.

So for the onboarding, it's like any other Meraki device, you get your cloud id, you claim it and you add it to your network. Um, so the only difference is now is we have an onboarding flow, which I'll go through in the demo then just some, uh, quick, quick things on next tunnel. It's built natively into the MCG into the OS using TCP.

It's encrypted and we use the Cisco TAM module, uh, for, to kind of verify our identity. Okay. So, uh, one thing with the initial boot, um, is MCG when it comes up, all the ports, the 4 25 gig and then the eight 10 gig ports, they'll all be placed in the same port channel, uh, in trunk mode with LACP active enabled.

So when you do plug this into your network, please remember on your upstream switches, this will be, you have to put them all in the same port channel. That way the MCG, when it boots up, it can reach out to dashboard. And then in terms of, Hang on, but I, I feel compelled to, to to to note, uh, that Cisco acquired Meraki 13 years ago and in that 13 years, the very strong heritage of Meraki way of doing things has shown through including zero touch provisioning for every single thing you have purchased.

That doesn't sound like this. Why the departure from the Meraki norm that we've had for over a decade of, I wanna unbox this thing and zero touch provision it without touching the upstream switch. Yeah, that's a, that's a really good question.

So one of the reasons that we kind of brought into having an auto port channel come up at the first place is one that when it comes up, you don't have to, when you configure port channel on the box itself, you might lose confi uh, connectivity to dashboard until you do that, um, configuration on the upstream switch to have the matching port channel configs. Correct. Except we do APS today with two ethernet ports and you have infrastructure devices that you don't force a channel group config on yet.

We can do that on an ap, right? If it's good enough for two interfaces on an AP and I can do zero touch provisioning there. Why isn't it good enough for eight interfaces on an MCG?

Good question. Yeah, I think, I think the way we looked at it, Sam initially was this, this is an infrastructure device that lives in the IDF for better or for worse. That was the decision we took of like, hey, you're more, more often than not probably gonna have to configure a switch port anyways.

And more than likely, or at least we hope you're dropping in this the place of where A WLC was already configured. Right? So point taken, I get it.

Like it is, you're right, it is a departure where, hey we just plug this in access port, it comes up totally different. But also we kind of maybe thought of it from a little bit different perspective as well. But I think, you know, we've heard that feedback.

I think there's some things we could do to make that experience better for That'd Be great. If You just connect one cable technically will Work. It won't work.

It won't. Yeah. So It's LECP.

Yeah. You must touch the upstream Switch. Yep.

So once you do have that port channel, we do um, auto discover a way to connect to dashboard. You don't have to go in and manually configure a VLAN for it to go reach out. We'll use something called uh, uplink auto config.

So basically the MCG will look at all the VLANs that's available on like the trunk port that we have, see if that VLAN allows for a DT P address and for outside connectivity, once it evaluates all those VLANs, it'll choose one, get the IP address and reach out to dashboard. Don't worry about what VA it does choose because then you can change that in the onboarding flow where you can say which IP addresses you want to use for each MCG. Just make sure that when you do do the like MCG deployment, like I said, you have the port channel configured and make sure DHCP is active on at least one vlan uh, uh, with uh, outside connectivity to dashboard.

Yeah. So next we do have, um, the two interfaces that we need for MCG when you do configure this. So for those familiar with 9,800, we had that wireless management interface, which was used not only for management of the box itself, but also to terminate the cap web tunnels.

So with MCG, we're kind of splitting that up. There'll be two, uh, L three interfaces that will be configured on the box itself. The first one's gonna be that management interface.

That'll be the external network. How do we reach out to dashboard? All the management plane traffic will go through there.

And then we have the AP tunnel interface. This will be used in the internal side of the network where you have to, where the tunnels from the aps both quick and VXLAN will be terminated. And we'll also use this to source any network services like Radius DNS, et cetera.

That will be from that IP address. For management tunnel. This can be either DTP or static ip.

AP Tunnel has to be static because we're gonna be using that for tunnel termination of the aps. And if you do make the management interface static, you can use the same IP address for the AP tunnel interface. If you only wanna have a single IP deployment, otherwise you can split them up if you need to.

At FCS we won't have any other, uh, L three interfaces configurable. And then the rest of the VLANs of the client VLANs will just be L two definitions on the box. I have a clarifying question.

Yes. So you're saying we, there's ports on the customer gateway, we connect that to a switch on A-L-A-C-P, but then these two interfaces here are virtual interfaces in which we would configure after it comes online with DHCP. Yes.

And so with DHCP, is that initially coming up on the management interface? Yes, it will be. Okay.

And the customer gateway just has this logic that says, once I connect to the switch, if I'll do DHCP just assign it to this management interface? Correct. So if you kind of remember on, if you, on the nine 800 view, uh, you have like the SVI definition and then you have have like wireless management interface, VLAN pen for example.

Yeah, it's kind of like that where we have the SVI IP addresses and then we'll be in the code assigning which interface will be used for management versus AP tunnel interface. And then for the SSIDs, as Travis mentioned, um, all the SSIDs will use that single VX lan uh, tunnel from the AP to MCG. They'll share that as opposed to having per SSID.

And when you do connect to a tunneled SSID map to say VLAN four, you'll have to just make sure that's defined centrally at the MCG. That way once the client does join, let's say VLAN N four, it can be switched to the rest of the network. If you don't have a VLAN defined on the MCG, which is basically allowing the, that VAN be passed through the trunk ports to the upstream switch, that traffic will be dropped.

And then with the VLANs that we do have defined for the SSIDs, that will be turn, that should be terminated on the uplink switch to the MCG. So it only has to exist between campus gateway and MCG. Obviously you can kind of, depending on your network design have say intermediate switches before you get to your core, let's say.

But the main point here being is you want to kind of contain that large, that broadcast domain so that way you can make that wireless client, um, VLAN as big as you need to be without having to worry about having to span that to all your access switches and potentially overwhelming those switches during any of like the ARP updates. Is, is the VXLAN a configurable option for the operator or is that just something you guys handle? It'll be something that we do handle.

So when you do configure SSID tunneling and we'll automatically form those quick and VX VXLAN tunnels to the, um, from AP to the MCG uh, one, oh, sorry, go ahead. Is that, is that presented though in the dashboard? Like does the user, if I'm in the dashboard, do I have to even know that VXLAN is there?

Nope. So the only thing you'll see is gonna be in a tunneled AP tab. It'll just say which APS are tunneling to what MCG.

And then for SSID configuration to do tunneling, it's very simple, ex external. Um, in the external DTP server assigned in your client IP and VLAN settings here, we now have a new option and tunneled tunnel mode with Campus Gateway. From there you just select the cluster, which you want to, um, tunnel your SSID to at launch.

It's one cluster, so it's gonna be pre pre-filled out for you. So the VLAN set, um, if you wanna do say adaptive policy set, like the group policy you wanna put your clients on, and then once you do save that the APS will automatically form the tunnels and you can start tunneling traffic. I'll show that in the demo.

Then, uh, with Campus Gateway, as Travis mentioned, this is gonna be a cluster of two. So with 9,800 we had that n plus one, which was stateless, but it was active Active. So in the event of a failover, there was downtime H-A-S-S-O that was state full, but it was active standby.

So only one unit was kind of serving clients. With MCG, we have this, the best of both worlds. It's active, active plus stateful.

So in the event of a failover, we'll be able to have as little downtime as possible when failing clients and aps over to the other MCG. But both M CGS will be active in serving clients dashboard will determine how aps are gonna be assigned to the different MCs. So they'll give 'em a list of primary and secondary.

I'll go over how that assignment works in the next few slides. So the way we accomplish the state full switchover is gonna be using that same RP port that we have on the 9,800 H one chassis, both copper and fiber. We'll use that to sync the client and AP states.

So if for example, this the MCG on the left had failed, we would just reform the VXLAN tunnel from the AP aps connecting to the left MCG to go to the right MCG. In that time you might drop say one ping and that's because we have the client state already synced to the secondary M CG for those aps. Um, for the RP link it's gonna, we'll be using Fast keep alive, so a hundred milliseconds.

So that way we can do those really quick ke lives without kind of clogging up the rest of your network. How we use the data plane ports, we'll use that dedicated link. This can either be back to back or via a dedicated VA if you're using intermediate switches similar to what we have for the H-A-S-S-O today, But they do need L two adjacency.

Yes. And then for the latency, less than 80 milliseconds, um, and then a bandwidth of, of uh, at least 16 megabits per second. And then for the load balancing, this will be done, um, at FCS based off AP subnet.

So aps of the same subnet will go to the same MCG aps in different subnets will go to different cgs. Yes. So I know that on the current Cisco, uh, controller, 9,800 controller, you have to be careful with, you know, the site and how the aps are assigned mm-hmm.

In the contract. You, you guys don't have this with the the SCG right? It gets rid of all of these limitations.

Yeah. So we have it now automatically optimized, so you don't have to worry about site tag load balancing aps amongst the site tag. So with the new CW CD um, uh, kind of processes, we're able to kind of split that other client AP say it's up.

So when we can load bounce between those Okay. With this very little like performance penalty of of, of going across those instances. But there is, there is, we just don't see the configuration options for it.

There is still a penalty when you move from WIN CD to win cd, right? Um, not as big, but yes, those, they'll, they'll probably be a few penalties, but it's mainly between m going between MCs and not within different processes of the M cg. Okay.

So that's why we're kind of putting the same aps in the same subnets in the same MCG to minimize that inter MCG real. So, um, that'll happen at, um, when you first add them, when we do the initial load balance, it'll be based off of those subnets, but let's say at the maintenance window, if let's say you have more aps in certain subnets than others, so it might not be a 50 50 balance at the maintenance window, we will run another rebalancing task, which may move some aps that are in like the same subnet to a different, um, MCG. So breaking that subnet rule to sort of achieve, um, a more 50 50 balance.

But the way it does that is to help minimize the amount of, um, inter MCG roams. And That doesn't require reboot, just the maintenance window configured in the Meraki Dashboard? Correct.

So the same thing you used for the firmware upgrades, it'll be used the same, uh, that that same timeframe will be used for the rebalancing task. Cool. So it's been a while since I've played with this.

How often is that maintenance by default? How often is that maintenance period? I believe it's weekly, but it runs weekly.

The, this one will run weekly. Like, so if like Friday at 2:00 AM it would run every Friday at 2:00 AM Okay, Cool. So I, I've been showing, we've been showing lots of slides, so I kind of want to go through a few demos with you.

So first we'll go through how to onboard an MCG cluster and it really shows this how easy it is compared to my WLCI came from 9,800, uh, using the 98 hundreds. And you'll be hard pressed to kind of deploy a full wireless network in, uh, 9,800 with APS connecting to it in maybe less than 10 minutes. 10 20 minutes if you're really good at it.

Um, so let's go here with the gateway cluster onboarding. Um, so as I was saying, it's added to, uh, as any other Meraki device. So you can use, uh, if you have the cloud id, you can add it to network wide ad devices or the organization inventory page.

Once you do, I'm gonna be using the organization inventory page. You would select the different, um, mc the two MCs you want to use in your network. Click them.

The two of them hit add to network Here. This is gonna be, uh, bring us to the onboarding flow. This is a new flow for onboarding these devices where you can either add them to an existing network or to a new network.

If you add them to an existing network, this would be networks already defined. Um, if you had already created an MCG, there would be a cluster name already predefined, like here. Otherwise that field would be empty since you don't have MCG clusters defined.

So we'll skip ahead here 'cause uh, we are running slightly outta time. So the next part here is once we go to the which network you want to use, you can do the, uh, your management interface. So the one of the two interfaces that we do configure here, it can be either static or DCP, um, and then the management vlan, which you want to use.

So you can either select which one, but I want to use both management and AP tunnel interface to share the same IP address. So I'm gonna select static. So here we're just giving our cgs the same subnet, uh, same vlan and the same subnet and the same vlan.

We'll put the IP default gateway, DNS, et cetera, click next. And then you would have your AP tunnel interface. You can check the box to manually configure if you want to use different, uh, VLANs for your management or AP tunnel and AP tunnel, or you can uncheck the box to use the same IP address since I had done static.

We'll just uncheck that box, click next. Then we have our cluster settings. You can put the name the native vlan and then the client VLANs, the native vlan will be assigned to clients that don't get a VLAN assigned to them in their SSID config.

And then the client VLANs will be all the client VLANs you're gonna want to use for your, um, that they, for your SSIDs you don't, so, oh, sorry. Uh, so why am I having to configure the VLANs here when I already have them? The ones that I would use likely configured in my Meraki dashboard?

So essentially, uh, when you're for the port channel that you're confi that we configured on the M cg mm-hmm. It's gonna be in trunk. We're, we're gonna be pruning those VLANs that are allowed on the trunk port.

So these are gonna be the VLANs, which you allow on, um, that trunk port. So any VLAN you're gonna be assigning to those ssis will have to be put here. Um, so we, we why, Why that just seems like room for air and you're gonna create problems And it's, it's also mixing behavior between what happens right now in the Meraki dashboard and kinda what we're doing now with the campus gateway.

Uh, that it's, it's, you've got different workflows, uh, and different ways of doing things just based on the deployment methodology. If I'm building a link between two switches, it's a different interface. Why is it different when it's just a trunk with some VLANs?

Um, well for the, So, so the concern is basically if I'm setting my SI. Perfect. Thank You.

Thank you. So, so the question basically is, I've already set my SSID, we say VLAN 10 room for error here. If I mistype, it basically is the concern, not Just the SSID, but in the me rocky dashboard, I've got my, um, my switch VLANs already created.

Mm-hmm. Uh, all of that information is me, Rocky D dashboard already. Um, why am I having to configure that here and in a different style interface than the existing switch to switch connections that I have in Meraki or within the mx?

Yeah, yeah. Uh, links. Okay.

It's a good, it's a good point. Like do some better automation here so we can kind of infer Well, I've connected to the Yeah. These are my port channel, not Necessarily automation, but consistency in what I'm doing.

Yeah. Across everything within the Meraki dashboard. Yep.

Yep. I already have the information and you're asking me for it a second time, which if I'm half asleep or something, I'm, it depends. I would say it kind of depends, right?

Because if you're greenfield, you're setting this up net new and maybe you haven't configured your SSIDs, you don't have this information. If you're, if you've dropped this in nothing else is configured, you're adding campus gateway first. You don't have that.

But in a brownfield scenario, that's a good point. I know the SSIDs that I'm gonna tunnel automatically send those without an SID this doesn't do anything Until I create the SSID and I assign A VAN. There's no purpose in it being here or not.

Right. So, well I think that the point is just the client VLANs, right? Because you wanna just say, send this SS IDI don't care what VLANs pull that dynamically from whatever on the backend.

And Yeah. I, I want, I want to, while we're on this topic, and I'm sorry to be beating you up about this, but I wanna be certain I heard you correctly. Did you say the native VLAN is where any ss ID that hasn't been assigned in, uh, uh, a VLAN N will go to?

Correct. This is something that started way back when in the original Cisco controllers have been dealing with this garbage since the 44 hundreds. And it, I despise it.

The first thing I do on those stupid things is set up a black hole network because the default, putting, putting default SSIDs into a or or a new ss ID into a default VLAN creates a, a, a security problem, like from the word go. Because what you also end up doing is you end up having access points that end up in the wrong, uh, in, in, in the wrong config group or something else that, that where you ultimately end up with an open network, uh, available to any client that somehow ends up on your management network. Mm-hmm.

Mm-hmm. Like do away with this. There is no reason I should if, if I've configured this.

So just Drop, drop the traffic. Absolutely. 100% don't every Time, don't just drop it every time.

Because when you con, when you're configuring that network, that's, that's when you want the traffic to go nowhere. So, Brent No. Fair.

I appreciate it. Love it. It's, I I I do like his comment though.

This is good feedback. 'cause I think that was something we consider early on is like, well if I have the SSID configured, just plumb it up there, do it automatically. But in this case, you know, resource constraint, things we can and can't do, just set your trunk and here's your vlan.

That's bruney, but solid feedback. I really appreciate it. So I think we're getting cut.

I think we're getting cut off. So you got one minute to show. Do you wanna show they have one minute to finish up?

You have, do you wanna do one question? Yeah. Uh, So I guess I can just show real quick where the SSID config is.

So essentially it's gonna be in that access control page here, right? So, um, like every other SSID like say if you want to do bridge mode, it's in that client IP and vlan. You go to external, um, IP address here, go to Tunneled and there's that new option tunnel mode with campus gateway, oops, sorry, I'm in your way, my bad.

Um, and you can select that MCG cluster you configured. Uh, and then for the MDNS gateway, um, here, this is gonna be where you can select which services you want to kind of learn across VLANs. So for example, airplay, iTunes, et cetera.

You can select those there. Uh, and then once you're done, you click save. Once you click save and those configs are pushed to the aps, they'll start forming those quick and VXLAN tunnels to the MCG as well as getting that load balancing.

If you had configured a cluster of two and kind of with that, it's like within three, five minutes CGS deploy, uh, kind of configured and then your aps are able to tunnel. You have your full like, kind of tunneled wireless network done in that few, a few, few clicks, a bit, a bit less than the, than a traditional WLC network. Do you show which MCG the AP is?

Yes. So if we go, if we go back here, sorry. I will, this is the last thing I'll show.

Um, if you go to this tunneled AP tab there, that'll show you all the, um, MCs, which the aps are tunneling to as their primary. So with that, um, we'll, uh, hand over to our, uh, other teammates to kind of talk about assurance.