Meraki Community

Matt_Carroll

Thank you @PhilipDAth, I had half-expected this to be the case, as I made the same argument to myself on why it's unlikely. Still, wanted to put out a feeler to see if maybe this was of interest to others in a similar situation. We do currently use Catalyst Center for an Assurance-only deployment. For all the great things that DNAC/CC is, a great user experience it is not. Meraki has just nailed the GUI and it's a much more approachable tool that some of our non network-focused team members can use to get visibility into the network and simplify some of their workflows. Cloud-monitoring for Catalyst was something that had re-sparked my hope for a single pane of glass, but in the current state, it's not going to work for our campus fabric designs. Interested to see how this ultimately pans out with the plans for Meraki-managed BGP-EVPN fabrics; the current issues might be solved by then Thanks again for your response.

Matt_Carroll

Hi Jenn, The ask would be to remap any discovered site tags to existing Meraki networks, not just to the networks it auto creates. Example: We have site tags building01 and building02, upon sync of the WLC, if the cloud monitor integration has not seen these site tags before it will create a new networks for each with the naming convention [wlc_network_name]-[site_tag], e.g. campuswlc-building01 and campuswlc-building02 We may already have Meraki networks for these buildings with other devices populated (perhaps containing cameras and switches as an example, things that are not as easily moved as APs) and would like to have the WLC APs synced into those networks instead. It would be (really) nice to instead have a third option for WLC AP network placement. I see this as where we can learn the site tags from the WLC, but not create new networks automatically, i.e. just have newly discovered APs sit in org inventory upon discovery from WLC. Then admins will need to go to a page under the WLC network which shows all the discovered site tags for the WLC and then can manually choose to either A) map the site tag an existing network from drop down, or B) create a new network on the fly and map the site tag to that, then APs are moved to the target networks.

Matt_Carroll

As someone who primarily uses the out of band management interfaces for our switch management, especially for our fabric deployments, we would like the ability to utilize the Mgmt-vrf interface for Cloud Monitoring. The limitation with this as I understand is that a secure tunnel must be built for Meraki management and obviously we cannot have more than one interface in the Mgmt-vrf (so no room for the Loopback and Tunnel interfaces), and you are not currently supporting any non-default / Global VRFs. The issue for some of our devices, like fabric-deployed leaf switches, is that even if we do allow communication via the underlay / Global VRF to the Meraki cloud (which we don't really want to do), the TLS tunnel and the provisioning script doesn't seem to play well with ECMP, which is heavily used for leaf-to-spine; so the tunnel is always tied to just one upstream interface (can't just rely on current routing table) and the tunnel fails to establish correctly at all when ECMP is happening anyways. With the planned changes to the monitoring architecture and move to native NETCONF interaction with IOS-XE, could we instead get an VM/container based solution that is deployed on-prem and can communicate with the managed devices directly over any interface via NETCONF, while the VM acts as a satellite for proxying communication between the devices and the Cloud via secure tunnel terminated on the VM instead? I've seen that Meraki-managed BGP-EVPN fabrics are planned / on the roadmap, but not sure how we plan to architect the solution if still relying on the TLS tunnel with the same limitations for Cloud connectivity establishment.

Matt_Carroll

Initial testing looks promising and onboarding was easy enough thanks to great documentation. A couple major pain points we've noticed so far: - The limitation of 15 SSIDs per Meraki wireless network is impacting the client visibility. If we have more than 15 SSIDs detected for clients in a single monitored Meraki network, the clients for any additional SSIDs are effectively truncated, so we only get a partial view. This makes the single network for APs and WLC not even an option. We are using the site tag to network mappings instead, but for our campus deployment, one of our larger buildings actually has more than 15 SSIDs active throughout the building (only a subset active in each area), so client data is incomplete. - The site tag to network mappings work as expected, however it would be nice to have control over these so we can import APs into existing Meraki networks vs only having a new network created per site tag. I understand that this is still early access and we are testing something still actively being worked on, but just wanted to provide the feedback that these are two major issues that would keep us from ever utilizing cloud monitoring in production and would feel that the first issue with the SSID limitation would be a big oversight if not addressed by GA. Thank you and the product and development teams for the continued efforts on bringing us additional value and I'm very excited to see where it goes from here.

Meraki Community

About Matt_Carroll

Matt_Carroll

Community Record

Badges

Re: Cloud Monitoring - Satellite Option

Re: Cloud monitoring for Catalyst wireless is here!

Cloud Monitoring - Satellite Option

Re: Cloud monitoring for Catalyst wireless is here!

Re: Cloud Monitoring - Satellite Option

Re: Cloud monitoring for Catalyst wireless is here!

Re: Cloud monitoring for Catalyst wireless is here!