Getting started with Cisco Wireless and Meraki Dashboard Using the cloud for your wireless deployments

So hello everyone and thank you for joining our event on the Getting Started with Cisco Wireless and Meraki dashboard using the cloud for your wireless deployments.00:10I'm Abby from the customer success team at Cisco and will be your host for today's call. Your phone lines have been muted upon joining the call and if you have any questions, please direct them to the Q and A panel. Depending on timing, we will open the floor for a live Q and A at the end of today's webinar.00:20Lastly, if you have any feedback after attending today's event, please fill out the survey at the end and please note we will share the slides and recording with everyone that registered for the event within the next one to two weeks. Today we have Justin Liu, a senior technical marketing engineer from Cisco wireless. Justin has been with Cisco for six years.00:37Was all on the wireless team. He covers all things wireless architecture ranging from the 9800 wireless LAN controller to the new Cisco campus gateway.00:56With that, I will now pass it over to Justin to get things started. Awesome. Thank you for the introduction. Again, I'm Justin Liu and today we'll be going over how we can use Meraki dashboard with Cisco wireless. So, our agenda for today will 1st cover our strategy for cloud, and then going into our cloud monitoring.01:07The Wireless solution followed by the cloud managed large campus with campus gateway.01:27So I wanted to touch on the strategy just a bit because it seemed I wanted to make it clear that we're not forcing you to go to cloud. It's just another option in how you want to deploy. You want to stay on prem, do 9800 catalyst center, that's perfectly fine. You want to go full cloud with Meraki dashboard, that's also great. If you want to be somewhere in the middle where you want to.01:31Have some on prem control and be cloud assisted.01:51We got you there as well. Because our goal with Cisco wireless is to have that network architecture flexibility and meet our customers where they are. You can think of this as a matrix if I wanted to play a centralized or distributed architecture or then how do I want to manage it? Now with this campus gateway, we can now do that centralized cloud managed, so our portfolio is now.01:54Full for any way you want to manage and deploy your network. So let's go on to cloud monitoring for wireless. Why would you use this? This is gonna be that middle ground between on prem and cloud, where you can retain control on prem, but still be cloud assisted. So you can use Meraki dashboard for the tools to help you monitor and run your networks.02:14And you with the the 9800 being cloud connected, you'll be able to deploy either a centralized architecture with your local mode or addition to flex connect as well. Either way, you can use cloud monitoring. So with Meraki dashboard, our goal is to simplify the catalyst network operations and it boils down to six main.02:34Aspects. The 1st being event monitoring will allow you to get events from your catalyst devices to your APs and wlcs, did my WLC go down? If so, why? Did my AP disconnect from the WLC? With these events, it'll help with our problem analysis to find any causes for our network incidents.02:54Then we'll also be able to monitor the performance of our clients, our APs, and our wlcs, so we can be more proactive with our network monitoring. So if an incident does occur, we can do reduce the incident resolution time or maybe stop those incidents before they happen.03:12And then they'll also bring change tracking image management, but those are for wireless are still on the roadmap. So with cloud monitoring for wireless, this will use a native tunnel from the 9800 to dashboard. It's built directly into is iOS XE.03:28So you don't need to have a little another container or anything else. You just do a few simple commands and you'll be able to establish that connection to dashboard. So the nice part here is you get to keep your existing WLC and AP hardware as well as your existing licenses and still get to take advantage of cloud.03:44With dashboard it's gonna be an always on solution, so you don't have to worry about making sure keeping it updated et cetera. It's all in the cloud. We will handle it for you. You just have to log in and point your devices to it. It's highly scalable. We can scale up the thousands of access points for monitoring.04:01And like I said before, you can use your existing licenses. There's NO extra license needed to use cloud monitoring. All you need is a valid DNA or UNX license, essential essentials or advantage. Just note that some features like AVC will need the advantage to your license.04:19And then if you do have some Meraki devices already, like say switches or MX or other devices like the MVs, you can use dashboard as a single pane of glass to monitor your catalyst devices as well, not having multiple dashboards. And since it's cloud, you can access it from anywhere. You don't need to VPN into your network or be on your.04:38Network in order to access your device. You can access it even on your phone if need be.04:58And low barrier to entry, all you have to do is create a dashboard org, and you'll be able to start using cloud monitoring. So we support most of the physical hardware wlcs, so the AD, the H one, the H24 DM, and then the C 98 hundred-L both fiber and copper variants.05:04The new CW 9800 L which was announced late last year, that support will be coming the 1st half of this calendar year. And then we also support the virtual 9800 as well, the 9800 CL, and we support all the throughput models, so the normal and high throughput as well as the scale, so large medium, small, and ultra low.05:25Just note though that the scale numbers for monitoring mode are different. So if you, you might notice that it is not the same scale as the hardware. So if you do go above, let's say for the H one, if you go above 2000 APs, we'll send an alert to you and also dashboard will stop collecting telemetry data until the.05:43AP joint time is lowered to under that 2000 AP limit.06:03And then for the APs, we support all the way from wave two, all the way to Wi Fi seven. So for like the we support for wave two it's the 4800 2830 800. We support all the Wi Fi six and six EAPs, and then for wi Fi seven we support most of the new APs, the support for 901-70-9704, and 71.06:09Will be coming soon.06:29So to enable, cloud monitoring on your 9800, it's super easy. All you have to do is go to configuration services, Cloud services. And now there's a Meraki tab. From there you just enable Meraki Connect and then we'll form the tunnels from our 9800 to dashboard, so that way you can register and claim your device.06:33And add it to dashboard.06:53There are a few prereq prerequisites to establish a tunnel to Meraki dashboard. The 1st one being is you need IP routing to be enabled, and then the Meraki tunnel only supports the global VRF, and then you make need to make sure you have DNS and NTP configured on your device as well.06:56Otherwise if we don't have DNS, e.g., on my network, the tunnel doesn't come up because we can't reach our registration host. And in terms of features, we are working to bring a lot of the cloud managed AP features to cloud monitoring and we have done that already.07:13So from an organization level, you're able to view all your wlcs, you're able to see the cloud monitoring info, and if you drill down to network level, you can see all the wireless clients that connect to your network, maps and floor plans, topology, all the access points that have been added, same with the wlcs.07:32And then from a client specific view, you'll get the same information you get with cloud managed APs, so you'll be able to see the overview, connections performance, and the big one, client roaming health. You can see what APs the client had roamed to at specific points in time. And then for the WLC, you'll be able to see the ports, the redundancy if you have HA SSO configured.07:47The APs as well as the cloud CLI. Then with the APs you get the location and summary. Some of the new features we brought out in which I'll be demoing today is gonna be the AP live tool support, so you can do the ping, you can do the dashboard throughput, et cetera. I'll show you more in that in the demo.08:08The cloud CLI for wlcs and then the packet capture. Coming soon, we'll also be bringing config history and versioning as well as software image upgrade. So to connect our 9800 to Meraki dashboard, all you have to do, like I showed in the previous screen.08:25Is either go to that configuration services cloud services, Meraki, and then enable Meraki Connect. Otherwise, if you're a CLI person, you can go to the global config mode and with a single line, service Meraki Connect will establish that tunnel to dashboard.08:42Once we establish that tunnel, we'll register to catalyst.meraki.com in order to get a cloud ID. This cloud ID will be used to claim and add the devices to the network. If you have HASSO configured, we'll also automatically register and get a cloud ID for our standby chassis.08:57Then we'll also register the APs as well. So APs that weren't born to be cloud managed so the non CW APs, they'll have to register to register to get a cloud ID. And because of that, you need to allow port 443 to dashboard to allow registration.09:16Then to claim the device to dashboard, all you'll just have to do is paste the cloud ID of your active chassis. We will automatically, when you do add the network, the WLC to the network, we will automatically claim and onboard the standby chassis if there is one as well as all the APs. So that way you don't have to add, let's say, thousands of devices.09:36This is all in one go.09:56Once you do add the device to, your claim the device, you can add it to the network. So when you add it to the network, there'll be two options here. Create an existing network, select an existing network or create a new network. If you do choose an existing network, we do have the caveat being that.09:57Cloud monitored WLC and APs cannot be added to the same network as cloud managed APs. So just keep that in mind. Then once you select the network, you'll just use the WLC credentials which you use to SSH into the box, and then you can review and add to network.10:17From there, we'll dashboard will use that credentials to to to go into the box and then configure the necessary telemetry subscriptions so that way we can get all that information to dashboard. So like I said, we did do support the 90 hundred CL, but there are just a slight few caveats.10:32Compared to the physical, just because since it's.10:52Since it is virtual, it doesn't have all the necessary hardware security chips which we have on the physical boxes. Those hardware security chips are used for us to securely onboard and register devices to dashboard. So to get around that, when you 1st establish that Meraki Connect tunnel.10:559800 CL will register the dashboard and get a temporary cloud ID. We'll use this temporary cloud ID in order to prove that I am a valid 9800 CL and I can be claimed. It'll be in the same format as a typical cloud ID, but now the 1st character will start with a V.11:13Once you claim it, we'll then change that temporary cloud ID to a permanent cloud ID which you can use to add to your networks. The one also if you do have HASSO configured, you would need to claim both active and standby wlcs just so we can change their temporary cloud ID to permanent.11:28But when you do add it to the network, you only need to add the active. Then there is a limit of ten CL that you can be added to an organization, but that's not gonna be a hard limit. If you do need to add additional 90 hundred CLs, just contact support and we can allow that for you.11:46So with that, I'd like to go over into a demos just to show off what we have for cloud monitoring. So if we go into our wireless line controllers, this is gonna be an example of our 90 hundred M which is cloud monitored. So if you go here, we have a field wireless wireless line controller list, and then this is gonna list all.12:04The wireless controllers in our.12:24Network. We click here, this will bring us to the 9800 device page. And if you're if you have seen dashboard before, this should look pretty familiar to you. So we do have our front panel ports which you can see that are up and running, and then we can also see the number of APs and clients which are connected to.12:26The WLC and since it's a live demo, the demo's not loading, but that's ok. And then we can go into the number of clients and APs over time that are connected. So here since it finally loaded, we have 15 APs that are connected to our WLC.12:46And we'll also get information such as the former that we're running as well as both the Catalyst and Meraki serial numbers. Then if you want more port information, you'll be able to see the layer two interface that you have. So in this case I have my 02:25 gig ports connected.13:02And a port channel, and then my svis that have been configured. So in this case, VLAN 99 is my WMI, and this TLS VI VIF, that's gonna be the interface we use for the next tunnel or Meraki tunnel. And then if you do have HA SSO configured, it'll show here.13:19You'll see the chassis one is active and then chassis two is standby hot, so you can tell which one is the current active at the time. We'll give you the RMI of that, of each chassis as well as the cloud ID.13:39And a big one here is gonna be the redundancy details, so it'll show you if SSO mode is enabled as well as if there's been a failover, because sometimes since there's a SSO, you might not notice there's a failover till afterwards. So in this case, we'll give you the total list of failovers have happened.13:51As well as when was the last failover that happened and then the reason for it. So in this case, the active RMI port was down. And then we get a list of all the APs which, have been added, which are being managed by the WLC and you can be redirected to their specific page.14:08And one thing I forgot to mention is that for the APs that are gonna be, when they onboard initially to dashboard, they'll be all, they'll be by default added to the same network that the WLC was added to. So in this case, I my WLC has added to cloud monitoring WLC and AP demo. So all the APs.14:27By default will be joining that network, but that that's ok. We can change it afterwards and then future APs will also be assigned to that this this method. So for the assignment options, we have existing networks so you can choose any, any existing Rocky network you have. Just note that you can't have.14:47Cloud managed APs in that same network, you can create a new network or you can do based off of AP site tag. So if you're using say site tag per building, you could create a Meraki network per building. Or if I had let's say five site tags, I would have five different Meraki networks with the APs added to the respective network.15:07In this case, I'm just gonna keep it as is and the WLC default network. And the last thing I want to show on the WLC side is the cloud CLI. So, like the cloud managed config source device switches, you'll be able to configure your WLC via the CLI terminal here.15:26So not only do we support all the, most of the show commands minus few heavy ones like show tech wireless, those ones we recommend you run on the box since they are really resource intensive, but for the rest of them, you can run most of your show commands, but you can also access global configuration mode.15:45So e.g., if I want to, I could change the host name. I'm doing that since that's not a non non disruptive change. So like the cloud mon 9800 M one demo. So it would change initial initially on the box, and then once the box does sync back to dashboard, this will update with the new name.16:00Cloudmon 9800 M one demo. So now let's go to the APs. So this is gonna be one of the APs that has that that is being managed by that same 9800. And it, again, it will look very familiar to you if you have seen a cloud managed AP page.16:19But the big difference here is the operating mode will be listed as hybrid for cloud monitored APs as opposed to operating mode cloud for cloud managed. And then the information will be a little different on the left hand side, so you'll see the wireless line controller as well as the respective policy site and RF tags.16:36You'll also see the access mode point access point mode, so either local or flex, and you'll be able to also see the catalyst serial and Meraki serial. We'll give you a lot of the same information like we do on the cloud managed side, so you get the port information, the connected clients, as well as the channel utilization for the current.16:53Channel the AP is on, as well as all the channels that the AP sees.17:13Then you'll see the historical connectivity and usage as well as historical clients. And now I want to go into the tools because this is a cool new feature we just added in 1718, where you're able to access the live tools for the client, for the APs just to validate that the AP performance is as expected.17:17With this we build native next tunnel from the AP to dashboard. So this means that the APs will need port 443 open for them indefinitely, so that way dashboard can directly talk to the AP. So we support all the same tools, so ping, reboot, blank, dashboard, throughput, trace route, and.17:37Arp cable.17:57So I'll show a few of them, so with ping we can do, I'll ping Cisco.com and we can see once that we get information back from the AP that IPV four is working but IPV six is not. So that's something I would want to take a look at. And then let's say I want to run dashboard throughput, so we can run the dashboard throughput just to make sure we are.17:57Any adequate.18:18Throughput to dashboard. I won't be doing the reboot or blink LEDs because I don't want to reboot my AP, but for the dashboard throughput, we're getting, expected 01:30 9 mbps, and then let's say I want to run my ARP table, I could also do that as well. So with that, we're bringing a lot of parity to what we have with the cloud managed.18:19It's aside to cloud monitoring.18:39And then the last new feature I want to show up that we have is gonna be our intelligent capture support. So now with a dashboard, you're able to take up an over the air packet capture from the APs directly from dashboard. It used to be a pretty cumbersome process if you had to go directly on the box itself.18:41Right, you had to start the packet capture, then find a way to copy it, et cetera. But with dashboard you're able to quickly select which APs you want to do a packet capture of. You can do multiple, you can do single. You can choose if you want to do an over the air or a wired packet capture on the APs on the ap's port.19:00And then you can save it to Meraki cloud. So that way you can easily view on dashboard. And this is all included in this in essentials and advantage tier license. Just note that if you want to have more than ten of the files stored in dashboard, you will need an advantage tier license. You can then do the duration of the pack.19:19To Capture any filters and then you can name it.19:39I have a few stored packet captures here. So e.g., I had done a packet capture on my 9130, so what I can do is quickly view it and you're able to view within dashboard over the air packet capture for your AP. No more having to VPN in.19:42Go to the box, initiate the packet capture, copy it back to the TFTP server, and then download it, right? You can just do it all through dashboard in a very simple clicks, very easy to do. So with that I'd like to hop back into our slide.19:59Slides and hop onto cloud management because some customers once they move to cloud monitoring, will be like, oh, I really like cloud. I want to go full cloud. I wanna do all the the cloud managed devices.20:19But other customers might be like, ok, cloud monitoring, I really like that. I wanna stay there and that's perfectly fine too. But if you did want to go full cloud managed, we have solution, we have solutions for you. And that's gonna be with campus gateway, if you want centralized.20:31And then with this we have the traditional bridge mode APs as well. So with the cloud managed and on prem and cloud monitoring, we do have Wi Fi seven APs for every operational scale. So we have filled out our indoor portfolio now from the low end all the way to the ultra high end.20:46These APs will work with on prem, cloud mon, and cloud managed. And then new with cloud managed is gonna be that campus gateway. So this will be our design from the ground up for cloud centralized deployment. So this will allow us to deploy cloud without little to NO, with little to NO.21:05To Redesign for your switching network. If you're already using a WLC, let's say with local mode, just slotten the campus gateway where the WLC is. And then as long as your APs have connectivity to the campus gateway, they'll be able to form their control and data plane tunnels. You wouldn't have to.21:25Change the switch ports from access to trunk since you're not gonna be doing a distribute design. And this can scale up to 5000 APs and 50000 clients. So, just so you haven't just in case you haven't heard previous guidance used to be a thousand.21:43Nodes or devices per network and 25000 nodes per org. And you might be thinking, ok, you just said campus Gateway supports 5000 APs. So because of that, we had dashboards scale up to meet that 5000 node requirement for each network.22:01And then in our documentation as well as in the slide itself, you might see a different abbreviations that we have for campus gateway, because you all know we love our acronyms and our abbreviations. So the preferred for campus gateway is gonna be CG or CCG.22:19Acceptable would be MCG as you'll see in the SKUs for the box. So e.g., with our campus gateway large scale platform, the 9800 h1-MCG, this is gonna be our, the, for that large campus deployments. So this will be that 5000 APs 50000 clients.22:37And it does support, this is gonna be the same hardware platform as our WLC. So it has the same four by 25 gig ports as well as the eight by ten gig ports. And then we also announced this at Cisco Live EMEA last month.22:56A smaller scale campus gateway as well. So this will be based off of the 90 hundred L chassis that was announced late last year, and this can go up to ten gigs of throughput with 500 APs and 10000 clients. This will have two by ten gig up links.23:11For for your use case as well and these will all be allowed for redundancy and port channeling. And then for the APs, we'll support all the Wi-Fi 66E and Wi-Fi seven APs to go to campus gateway.23:28Just make sure they are running a release 30 one.two or later. And then in terms of licensing for campus gateway, the campus Gateway will not need its own specific device license. All you'll need is a valid AP license. This can be either enterprise or advanced tier.23:48Co term subs unex, or EA. As long as you have an AP license, you can use campus gateway. Just note that certain advanced tier features that were like adaptive policy would still require advanced licensing for campus gateway, with campus gateway.24:06And then the hardware skew will be the same as the wireless controller SKU, but if you do have 303 year advanced licenses when you purchase, we'll give you two campus gateway units. So with campus gateway, you might be thinking, do I always need a CG?24:22So that's gonna be up to you. You don't need a CG if you want to distribute. The CG is only for centralization. And if you want to decide between distribute or centralize, you have to consider your use case, some services that you're gonna be using, your wired network design.24:40Your scale performance policy and redundancy. So those who should consider a campus gateway should be those who have want to roam across L three boundaries without having to span their client VLANs to each specific roaming domain. If you want fast roaming across a large domain of more than two to 300 APs, you want MDNS gateway or you don't want to touch your wired.24:55Underlay wire design so I don't want to have to change my AP switch ports from access to trunk.25:15Or I want a single point of entry for my wireless traffic for easier QoS, ACL, et cetera enforcement. Or if I know that centralized aggregate is not gonna be a bottleneck and I want that performance of a campus gateway. So this little cheat sheet here gives a good example of how how and when you should use a campus gateway.25:20So our recommendation is if you have less than 300 APs and up to ten K clients, you can go a distribute Meraki network if you don't need campus gateway. And if you want to go, if you have more than 300 APs in a single roaming domain, you should, you should start bringing in and thinking about campus gateway for that L three roaming and client scale.25:40Again, this is just gonna be a recommendation. If you want to go, if you have less than 300 APs and you want to use campus gateway, go right ahead. If you want to have more than 300 APs and NO campus gateway, go right ahead. This is just a guideline, again, we're not forcing you to use one or the other.26:00So with campus Gateway and the APs, unlike a WLC, campus Gateway and APs are gonna be directly managed by Meraki dashboard like any other Meraki node. What I mean by that is the APs will go straight to dashboard. Campus Gateway will go straight to dashboard for management.26:21It won't go AP to campus Gateway to dashboard. It'll go AP to dashboard campus gateway to dashboard. The control plane and data plane tunnels will be quick and respectively. I'll go over more on that later.26:38And then today we have some limitations applied for the architecture. So 1st being that campus gateway and APs need to be part of the same Meraki network, and they need to be part of the same geolocation such that there's a round trip time of less than 20 milliseconds from AP to campus gateway.26:54And then you can only have one campus gateway clustered per Meraki network, and that cluster consists of two campus gateways. So with campus gateway, we do not recommend distributed layer three roaming.27:11Nor L three mobility with MX concentrator as four large scale deployments. These are not gonna be recommended if you have a large scale deployment, we recommend using campus gateway. That should be your solution going forward. And this.27:27All sort of sounds right of WLC managed the cloud, right? It really does, but just let me explain. So with the WLC architecture, you had your management control plane and data plane, both non real time control plane and real time control plane.27:43These all exist on the WLC because the WLC has to be able to operate with or without a management layer and with or without connectivity to the internet. E.g., in an air gap mode. For all intents and purposes, your the WLC needs to be your one stop shop for your wireless network.27:59But that's not the case with campus gateway. We already have Meraki dashboard for the management plane and non real time control plane, and we have the access point which already serves as the applying the QoS policy, rate limiting adaptive policy tagging, as well as handling all the client authentication and client state machine.28:17With campus gateway, we only needed to decentralize what we must and keep on cloud what we could. So what we had to centralize was gonna be that central data plane termination, as well as an MDNS gateway for better scale MDNS performance. And in terms of control plane, this will act as a triple AAA proxy.28:35So all the APs would send their radius requests to the campus gateway, and then the campus gateway would then proxy that over to your radius server. The benefit here is now you only need to add your campus gateways as NAS in your radius server as opposed to all your APs.28:53It'll also handle the key, the key management for roaming as well as the D store client database. So with the control plane for campus gateway, we'll be leveraging quick. It's not an acronym, it's just the name pronounced quick.29:09So in this case, the AP would establish two of these quick tunnels, one to the primary and one to the backup campus gateway. And then this is gonna be a UDP based tunnel, but it'll be reliable. This is because we will get TCP like reliability with UDP based performance since.29:27With UDP, we don't have to wait for the head of the line to to finish or our stream to continue, but we'll also multiplex the stream. So that way, even if one of the streams that gets lost and the other ones make it, we just have to send the misstream to the destination before it gets reassembled.29:44We'll be using keep alives to also check the reachability of each tunnel to make sure that we, that the peers up. The quick tunnel will use a TL will always be encrypted TLS one.three using our dashboard provisioning keys or certificates. And we'll use this for things like AP registration and client anchoring as well as between the campus gateways for H.30:01Messages and any other inter CG control messages.30:21So for the quick li for the keep alives, we'll be doing a 10 s keep alive timeout with a 16 s max idle timeout. So how that works is we don't hear anything from the peer, so NO packets received after 10 s, we'll send a probe.30:26Now if there's NO, if there's not a response, we'll send another 01:30 milliseconds later and then another 60 milliseconds, then another 01:20 and going exponentially until we miss eight consecutive probes. This results in a 16 s max timeout. And then if we don't hear back after that 16 s, we'll declare that connection.30:41Is down and the AP will start sending backup traffic to the campus or to the backup campus gateway. And then for the data plane tunnel, this will be using VXLAN. So we'll carry all the client data packets as well as the VLAN information within the tunnel.31:01And then send that to campus gateway. Once it gets de encapsulated, the campus gateway would then bridge the client traffic onto the respective VLANs. We'll leverage all the standard VXLAN encapsulations and then our QoS and policy information such as DSCP and SGT are carried in the tunnel header.31:20As well as radius messages as well. Technically you could do VRF, but just note that at launch we only support segmentation by SGT with adaptive policy. And then for the keep alives with the date with the VXLAN tunnel, we'll be using bi directional forwarding detection or VF.31:36D.31:56To check the reachability of our peer. So what we'll be doing is we'll send an echo every 5 s to the peer. And if we miss one of the echoes, we'll send four consecutive echoes at 1 s intervals before consuming the tunnel down. So 1st wait 5 s before we, after missed ech, well, before we hear back, and then we'll send four more.31:561 s after that. So that'll be about 9 s before we detect that tunnel is down.32:16If the VXLAN tunnel goes down, the quick tunnel will be brought down as well and vice versa. Both quick and VXLAN need to be up for that connection to stay up. And then for the VXLAN tunnel, as I said, we're using the same standard vxlan encapsulation.32:21So in the header, the ibit will be set to one to indicate VNI is valid and clear text, otherwise it's zero to indicate that we're encrypting the packet. And then if you are using adaptive policy, we'll set the G bit to one, and then the group policy ID will will carry the client's SGT value.32:39And then in terms of a QoS, the DSCP value will match whatever is in the inner packet for client traffic. Otherwise, if it's management traffic, we'll set it to 48, and we'll always have the do not fragment bit set to one because you don't want to fragment your VXLAN tunnel.32:57And then for the ports that we're using, we'll be using port 16675 for both source and destination port. And you might be wondering why not use the standard port of 4789. That's because with 30 two.two we'll be bringing in.33:13VXLAN encryption and VXLAN does not have a standard port for the encrypted tunnel, and we don't want to encrypt VXLAN using a s using the standard port. So that's why we chose 16675. This encryption will be available again with 30 two.two.33:31And we'll use DL DTLS and using TLS one.two and eventually moving to one.three when available. And then I did mention that we're not gonna fragment the outer VXLAN tunnel.33:48So that means that in order to maintain, be under the specific MTU, we will need to fragment the inter client traffic. And that MTU, that max MTU that can be sent on the link will be determined using path MTU calculations using the quick tunnel. Whatever we calculate using the quick tunnel will also use for the VXLAN tunnel.34:03So if the client IP I mean IP packet is too big after adding in the encapsulation headers, we'll have to fragment the client traffic. Now, if the client traffic also has the DF bit set to one.34:22And it's too big. The APN campus Gateways will send an ICMP too big message back to the center. So the max packet size that we can send without fragmentation, so the max packet size we support on campus gateway is 1500 bytes.34:38So considering the vxlanning headers, that'll be 50 bytes. So the max IP packet that can be transmitted would be 1450 bytes. Now if you are using TCP, the APs will implement TCP MSS, so you'll, it'll be 1410 bytes.34:55For IPv four or 1390 for IPV six. We aren't supporting jumbo frames on the APs at FCS. Now I wanna move on now to AJ because with the benefit of having a centralized architecture is you have that additional redundancy.35:10So with campus gateway, we're gonna do a cluster. So like I said, a cluster is a set of two, campus gateways, and they'll be acting in active active redundancy. So that means that the APs would be load balanced across the CGs and the cluster.35:26And when the AP gets its configuration from dashboard, it'll be set, it'll be configured with a primary and preferred campus gateway. Now if that primary campus gateway node fails, the backup campus gateway would take over so the APs would automatically fail over to that backup campus gateway.35:42So this failover will be stateful and will be zero downtime for a single node failure, and we do this by using the RP link on the chassis of the campus gateways, so that way we can sync the states of the APs between the campus gateways.36:02With this link, this will be either aL2 link and this can be either a direct back to back, so just going from one RP link to the other on the other campus gateway or if you have intermediate switches, make sure you have a dedicated L two VLAN for that communication.36:18This RP link is gonna be used for cat fast keep alives of a hundred milliseconds. That's why we want to have on a dedicated L two link, so that way we're not clogging up the rest of your network with keep alive sent every hundred milliseconds. This link should have a latency of less than 80 milliseconds bandwidth of more than 60 mbps and an MTU.36:341500 bytes or more. And the way we're load balancing the APs between the campus gateway is gonna be using the subnet of the APs. Aps that are in the same subnet would go to the same campus gateway and APs in a different subnet would go to a different campus gateway.36:54The reason being is we want to, we want to make sure that APs that are in the same subnet, they're typically gonna be in the same general area, so that way they'd roam within the same campus gateway. We want to minimize the amount of injured campus gateway roaming because that's a lot more compute and you'll have worse performance as if you roamed within the same campus gateway.37:13And again, we, we figure that if you're in the same subnet, you're in the same area. Other load balancing mechanisms would be provi might be provided post FCS, but today it's just that subnet rule. But we'll try to make sure that we have a 5050 split between the campus gateways. So in the event that the number of APs in the subnets and the number of subnets.37:32Are not even will run a rebalancing task during the network maintenance time. So this will be the time you normally set in your network wide general settings for when you want to have the software updates happen. And then we'll move APs from the busier campus gateway, from the busier campus gateway to the less busier campus gateway.37:52Breaking the subnet rule only as much as necessary to achieve an even balance. Now with our clusters, how are we gonna know though when to go back, what's the the detection times, right? Like from when the APs gonna fail over to the backup? So if the APs can't reach the campus gateway.38:09Due to a network failure, if you, for VXLAN this would be 9 s detection time while quick is gonna be 16 s. So in either case, the tunnels are brought down, but best case would be if the VXLAN tunnel failed, you'd have 9 s of detect of downtime.38:26Now if the campus gateway box failed, say a crash or power down, as long as the RP links are connected, we exchange the past keep alives, and then you'd have to miss five keep alives followed by one ping via the AP tunnel interface.38:43I'll go on more on that later. So by missing five RP keep alives that are sent every hundred milliseconds, you'll have a failover of less than 1 s. So you might miss one or two pings, but your clients stay connected and your APs would quickly fail over. Now if you did have a full network failure, so the campus gateway can't reach its gateway.38:57This would be about this would be a downtime about 8 s because we would have to miss four consecutive arps and then four consecutive ICMP echoes before the active campus gateway would consider itself down. So in general network failures would have slower failover time and longer downtime compared to CG box failures.39:15And then when deploying the campus gateway, the campus gateway will be deployed in a one armed concentrator. So you have a single logical link to the upstream network. So all the ports by default will come up in a port channel with LACP mode active. So just keep that in mind, so when you power it on, you have to make sure your switch port's already in a port channel.39:37So that means that the port channel would have to, would be in trunk because the management, control, client traffic et cetera, they would all be separated using different VLANs that would be switched upstream to the campus core or upstream switch. And our recommendation would be to concentrate the client VLANs at the campus gateway at its 1st top switch.39:57That way you can make the client VLAN as big as possible without increasing the whole broadcast domain for all your switches.40:17We are looking into bringing support for multiple logical links or multiple port channels to help separate the client tunnel et cetera data, but as of today, it's still a one armed concentrator. And then when you do onboard it to a, the campus gateway to dashboard.40:25The campus gateway only needs to have two layer three or SVI interfaces configured. This is gonna be the management interface, so this is gonna be the interface to the external network, so this will be used to talk to dashboard and build next tunnel. This can be assigned by a DHCP or static.40:41And then the AP tunnel interface, this will be the interface used for internal traffic. So we'll use this to terminate the quick and tunnels, source any network traffic to say radius or syslog, and because this is gonna be the tunnel termination point for the APs, you have to make sure you set this up, this is gonna be required to be set as static for the IP address.40:58Last thing you want is the device to read DHCP and all your AP tunnels go down. So these will be the only L three interface that need to be configured. Everything else so the client traffic would be segmented by aL2 VLANs.41:17Now when you do deploy the campus gateway, you can choose two types of deployments. The 1st one being a single L three or SVI interface, so that means that you can have the management and AP tunnel interface share the same SVI. The benefit here is it's quick and easy, you only have to handle one IP, but you will have to make sure that that IP address is gonna be static.41:34Now if you do want to segment your traffic such that you have your external internal traffic being on separate VLANs, that's ok. You can configure the management and AP tunnel on separate svis. In this case, management can be a static while DHCP or static while AP tunnel interface has to be static.41:55So let me hop into dashboard and I'll show you a quick onboarding of campus gateway, as well as, as well as, how to configure ssids. So let me refresh the page. So here we are in our campus gateway clusters page. So this.42:13This will be on a new page under wireless and this will give us all the campus gateways that are added to our current cluster.42:32So just for the purposes of this demo, I've already added a campus gateway, but let me add another one. The onboarding flow will be the same regardless if you're adding a standalone or adding in an HA or adding them both at once. So you can add it by add campus gateway. You can add it in the network wide, add devices.42:38Or you can go into the organization inventory page. So all we have to do is find our campus gateway. I already claimed mine, but if you need to claim, if you need to claim it, you can claim it in the claim devices section. Select the campus gateway which you want to add and then add to network.42:55This will bring up this new campus gateway onboarding flow. So in this flow, you can choose an existing network or a new network. Now if you already created a campus gateway cluster, that network would have clusters shown. Otherwise it would just show that network. After that, we'll go into the management interface, so you can choose DHCP or static.43:12But because I want to have my AP tunnel interface share the same SVI as my management.43:32I'm gonna choose static, and then here I can put in my IP that I want to use and what and then you would put in your subnet gateway DNS and then your primary and second DNS, click next. Now if you did configure static on the management interface, you will have an option to choose the AP tunnel if you want to manually configure.43:37Here or have it shared. If you want to manually configure you would just set the VLAN, IP address, subnet and gateway. Followed by this, you can do the cluster name and the uplink port needed VLAN, so if your client traffic is assigned without a VLAN.43:57We would automatically put those clients onto this VLAN. And then you'll put the port, the client VLANs which you want to use. This is an important section because if you don't put all the VLANs you're gonna use and you assign the clients to a VLAN that's not on this list, it won't be allowed on the campus gateway trunk ports.44:13So that means that that traffic would be dropped. But don't worry if you forget to do it, we can change that later on. Once that's done, you can do, they'll give you a summary to view the settings you can configured and then you can click finish, and then it would push the settings to the campus gateway.44:31It'll take a couple of minutes for the campus Gateway to download the the configs from dashboard and reach out and form the tunnel, but that's ok. I will continue on. So now let's say I forgot to add in a specific setting. No worries, you can go to edit, and then you'll get the same settings which you configured previously.44:47Now in this edit cluster attributes page. So e.g., let's say that I forgot to add a VLAN, let me add another one. So I'm gonna add in the range of two oh four to 210I can just add that in, save, and then my campus gateways would get the correct.45:06But we now have the correct VLANs allowed on their chunk port. But notice now that there's NO APs that are tunneling to campus gateway, that's because we don't have any ssids tunneling to campus gateway. So if NO ssids are tunneling, NO APs would form their quick and VXLAN tunnels.45:25But it's really easy to set a piece of tunnel. It'll be in the access control page for your ssids. And then here, if we go to this SSID, you go all the way down to the client and IP VLAN section. So typically before you would go bridged if you wanted to do the bridge mode.45:42But now if you go to tunneled, there's a new option called tunnel mode with campus gateway. You'd, you'd have that cluster that you configured, and then if you want to do MDNS gateway, so if you wanna have MDNS traffic spread across VLANs, you can choose which services you want to enable.45:58So e.g., I just want to have airplay, screen sharing Chromecast enabled, and then you would set your VLAN and then you can save. Once that's done, the APs would be like, ok, now I have a tunnel SSID, I need to form my tunnel to campus gateway.46:14And then they would slowly start adding in their, forming their tunnels to campus gateway, and then your ssids would be broadcasted. Please note, though, as your, if your tunnel connection to campus Gateway goes down, the tunneled SSID would NO longer cease to broadcast.46:32Now if you had a bridged mode SSID as well, that would continue broadcasting since it doesn't rely upon campus gateway. So it does take a few minutes before the tunnels do form. So in this case, I want to show you what it would look like in another network where the APs have been tunneled and are being.46:50And are being a load balanced. So in this case here, our APs are load balanced since we do have some ssids tunneled, it'll be current APs five and six since we are doing as as much of a 5050 load balance as possible.47:09So with that, I'd like to end off this session with a single slide showing that with Cisco wireless, you're able to do your on prem, your cloud monitoring, your cloud managed in any architecture you would like to deploy. We, whatever way you want to fit, we got you. Thank you. So I think we now have some time for live Q and A So, this hasn'.47:31Get any questions answered in the Q and A I'm more than happy to answer them live.47:51Yes, there's a couple that I wanted to get to your point of view honor that was shared from some of the attendees. The 1st one is, is there a cost of the campus gateway or is it included? I think you may have covered this, but if you could maybe reiterate the maybe the cost or licensing requirements there.47:56Yeah, so campus Gateway will be the same price as the WLC skus. And then if you, and then we do have a promotion going on where if you do buy 300 or more three year advanced tier licensing, you'll be able to we'll give you two pairs of campus gateway for free.48:15And campus gateway itself does not need a license, only the APs need a license. Perfect, and then someone was sharing a situation where they have 30 campuses. Each site has around a hundred APs.48:33Is the recommendation to then have a campus gateway? And if they do, then what's the difference between having a WLC versus a campus gateway? So for if those sites are already in centralized and they want to keep it as centralized.48:48They could go with a campus gateway in that deployment. Otherwise, if they are open to going distributed since it is under that 300 recommendation, they can go, they don't need the campus gateway either. They can go full distributed. And then the difference between a campus gateway and a WLC.49:05Does the campus gateway only does data plane termination and some real time control plane like key management and radius proxy? Whereas the WLC does everything, right? It does the management plane, so the config, the software management, it does.49:22A lot of the data plane termination does all the control plane traffic. So campus gateway really is just for allowing us to centralize our data traffic as well as get a better performance with some real time control plane. Awesome, thanks for that one. And then there's a couple more and then we can open it up for live Q and A.49:37Just want to get through these ones since we have them documented. So the next one is, are there any virtual deployment options for campus gateways?49:57No, so the only options are gonna be the 9800 H one MCG for large scale, and then the 9800 LMCG for the smaller scale campuses. Perfect. And then the last one that I see documented here is with the cloud managed solution, is there any.50:06Integration with ICE for client authentication and sponsored guest portals.50:26Yeah, so we do have integrations with ICE, so I can, when we do share out the deck I'll also include some helpful links for you to take a look for those to look up, take a look at afterwards as well. Awesome, thanks for that. And that's all the questions that I see written down. So now we could move to see if there's any.50:31Interest in live Q and A so if anyone would like to ask a question live, please raise your hand and I will request to unmute your line. I actually see already a hand raised from Tony, so I'm requesting to unmute you, and then please go ahead.50:51Options to go directly to Microsoft intra or Intune or whatever they're calling it today. Sorry, can you repeat the question? I think the 1st half got a little cut off. Oh, sorry about that. Yeah, looking at, authentication options for Microsoft intra or Intune.51:11Gotcha. So we do have integrations with entry ID. I can also share the documentation for you as well. I'm not entirely an expert on the entry integration, so I'd i'd rather share the docs rather than give you the incorrect information.51:32Perfect, they Tony gave a thumbs up to that. Alright, any other requests for live questions from anyone? Again, if you could read raise your hand, I can request to unmute you. I did see something just come through the Q and A panel.51:52From Nelson, it says speaking of portals, if a WLC is just cloud managed, can I use the Meraki captive portal for guest wireless? So if the WLC is cloud monitored, you won't be able to use the dashboard for captive portals.52:09Since any dashboard configuration UI outside of cloud CLI will not be supported with cloud monitor wlcs.52:29Now if you are doing campus gateway, yes, you'll be able to use the dashboard, provided captive portals. Perfect. I don't see any other questions in the chat or hands raised.52:36Oh Mike said so WLC versus CG, what is the main difference? Yeah, so, NO worries. So the the main difference is gonna be that with WLC, everything is handled on the box itself. So it will handle all the con.52:57Big management, software, it will handle, let's say road detection, key management, it will handle even the QoS applications et cetera. Campus gateway, because we already have dashboard and APs will not have to handle all those functions. It'll only have to handle data plane termination.53:16As well as some real time control plane like radius proxy and key management because dashboard already serves that purpose of management and the APs can already serve the function of like say qs enforcement et cetera. The big difference and then the last thing is.53:36The WLC needed to act like without any management platform, whereas campus Gateway does require Meraki dashboard. It's a ten four. Perfect.53:52Okay, I think that that's all I'm seeing so far and I don't see any other hands being raised. Maybe I can ask just a quick question as, can I onboard a WLC into the Meraki dashboard and Catalyst Center if I have both platforms in use?54:09So you are not able to, so we only support going to one or the others. So if you want Catalyst Center, you have to go with Catalyst Center. If you want cloud monitoring, you have to go with cloud monitoring. There's NO coexistence for cloud monitoring today. Perfect, and then what is the best way to prepare my network for.54:24For onboarding cloud managed for wireless.54:44The best way would, be 1st consider which architecture you want to go with because that will determine how you have to go proceed. So if you want to go, if you're already with WLC today, I'm assuming it's gonna be a local mode, so you would if you would you would want to probably keep centralized so you can just slot in the campus gateway, so you just have to allow the.54:49The ports.55:09Or dashboard to connect, and then if you have converged APs, so the CW series making sure that they get migrated to cloud. Otherwise, you would have to refresh with a AP that can be cloud managed. Perfect and lastly from my side, what are the.55:11Typical steps involved in onboarding A 9800 WLC into the Meraki dashboard.55:31It's All you have to do, it's pretty it's we wanted to make sure it was still Meraki simple. All you have to do is do a few clicks on the UI or single CLI command service Meraki Connect. This will allow us to get a cloud ID for the WLC and then you would claim and add it to a network like any other.55:37Meraki device.55:56Wonderful. Oh, one more question just popped in. Does campus Gateway work with flex connect? No, so flex connect well so the idea of flexconnect is gonna be with a WLC, but if you did want a similar solution like flexconnect, you don't need a campus gateway.56:00You can just set the APs to do bridge mode ssids. So in this case the APs would switch the traffic locally at the AP level and then go to the switch port. There'd be NO centralization. Perfect.56:19And I think that's it. So do you have any, oh, there I say that's it and then there's one more that keeps coming in. Is the WLC proxy aware to connect to Meraki dashboard as the next question. I know that we were working on that, but I have to double check to see if that's supported out there. Otherwise I see Yasharia is on.56:37So he might have the answer for you.56:57Could you repeat the question once, sorry Abby. No worries, it's is the WLC proxy aware to connect to Meraki dashboard? So when you say WLC proxy, could you just clarify the question? Do you mean web UI proxy or what exactly is the question?57:02So I'm I'm assuming the question's gonna be if they use a pro like a proxy to get out to the internet, do we support that with cloud monitoring? No, not as of now. That's, that's something that we don't support now, but maybe it is something that we can think about in the future.57:21But not as of now. Thanks for that and then and we're getting to time here so this will be the last question. What's the minimum iOS version for the WLC to onboard into cloud monitoring dashboard?57:38It'll be 1712 three and 1715 one. Those will be the, the minimum releases that you have to have to use. Perfect, and now we are right at time so thanks for the rapid fire of answering all of those questions Justin, and thank you to Yousharia as well as Travis for pitching in to answer the.57:56Questions in the chat and the Q and A panel. As mentioned at the beginning of the call, we will be sharing the materials from today's event within the next one to two weeks via email and we will post the recording to a Cisco community page and all of those relevant links will be again shared with you via the email address that you used to register for the.58:16This event. So again a major thank you to Justin for the amazing presentation and demo and a major things again to our panelists for helping to answer the questions and we'll be in touch soon and hope you have a great rest of your day.58:36I'm a gentle reminder to please answer the questions in the surveys. We would love to collect your feedback. Alrighty, thanks again and take care.58:48