Meraki

alemabrahao

A roam does not necessarily trigger a full RADIUS (802.1X/EAP) authentication just because 802.11r is disabled. If 802.11r is disabled and clients do not support OKC/PMKID, then roams may require full 802.1X/EAP reauthentication. But in most enterprise WLANs, roaming still uses cached keys, so disabling FT does not automatically cause full RADIUS load or slow roaming.

alemabrahao

Only using certificate-based authentication. Sentry AnyConnect VPN is a special Cisco Meraki integration between MX and Systems Manager (SM) enrolled devices. This allows secure and automatic certificate-based Always-On AnyConnect VPN for SM managed devices. SM managed devices will be sent all the necessary configurations, certificates, and app settings for an Always-On VPN tunnel back to the MX. For SM enrolled devices, the end users are not interrupted with any authentication/setup steps and the VPN tunnel will open automatically. https://documentation.meraki.com/SASE_and_SD-WAN/MX/Design_and_Configure/Configuration_Guides/Client_VPN/AnyConnect_on_the_MX_Appliance/Authentication#:~:text=1%20%2D%20300%20seconds.-,Systems%20Manager%20Sentry%20Authentication,await%20the%20general%20availability%20release.

alemabrahao

Yes I do.

alemabrahao

If you have 802.11r enabled in the SSID, some devices don't support this feature and may exhibit the behavior you're describing. So try disabling 802.11r from the SSID.

alemabrahao

Layer 3 Interface (SVI) Caveats Switch Management IP and Layer 3 Interfaces (SVIs) The management IP is treated entirely different from the SVIs and must be a different IP address. It can be placed on a routed or non-routed VLAN (e.g.: a management VLAN independent from client traffic). Traffic from the management IP address to the Cisco Meraki Cloud Controller will not use the layer 3 routing settings; instead, it will be using its configured default gateway. Therefore, it is important that the IP address, VLAN, and default gateway configured in your switch management IP can still provide connectivity to the internet independently from the switch's own L3 routing settings. The Switch (or Stack) management IP configuration cannot have Gateway address defined as one of its own SVI address when it is performing Layer 3 routing. It will not be able to check in using the assigned management IP when the gateway is pointed to itself. For example, if 192.168.1.1 is one of the L3 interfaces (SVI) on a switch (or stack), you cannot have 192.168.1.1 as the gateway for its management IP (Switching > Switches > LAN IP).

alemabrahao

Well, the most logical explanation is that, given this behavior, it seems you don't have the VLAN added to the trunk on the core switch and the access switch. What is your topology? Can you see the server in the ARP table when it's connected to the other switch? The problem is probably a small detail you're forgetting. Please provide more information than you've already verified.

alemabrahao

This is an expect behavior.

alemabrahao

You can get those IPs into OpsRamp using a different method, API‑based discovery or OpsRamp’s Meraki integration. Introduction - Meraki Dashboard API v1 - Cisco Meraki Developer Hub Meraki | OpsRamp Documentation

alemabrahao

Yes, that behavior is expected on a Meraki MX when you perform an SNMP walk directly against the appliance. SNMP Overview and Configuration - Cisco Meraki Documentation

alemabrahao

I suggest you open a support case.

alemabrahao

Yes, you can onboard a new C9300‑M directly with IOS XE 17.18.2. Cisco’s current minimum required software for onboarding Catalyst 9300 family switches into cloud management is IOS XE 17.15.3.

alemabrahao

Honestly, it doesn't seem to be an MX problem to me. A simple test you can do is plug the Starlink into your laptop in bypass mode and see if the problem persists. Also check if it might be related to the MTU.

alemabrahao

You don't need to install an expensive switch. A non-managed PoE switch is much cheaper.

alemabrahao

Wouldn't it be easier to install a POE switch, connect the fiber to the switch, and then connect the access point to the switch?

alemabrahao

To be honest, this doesn't make sense, because it's describing the ready-only role. This document seem to be wrong.

alemabrahao

As far as I remember, Observe has always been view-only in areas classified as Monitor. And Read-only can view the settings. I think you're confusing things.

alemabrahao

Try upgrading your wifi nic drive.

alemabrahao

Could you share a screenshot of your SSID settings? https://documentation.meraki.com/Wireless/Design_and_Configure/Configuration_Guides/Encryption_and_Authentication/WPA3_Encryption_and_Configuration_Guide

alemabrahao

It definitely is, but you would have to apply the Group Policy manually to each client. https://documentation.meraki.com/Platform_Management/Dashboard_Administration/Operate_and_Maintain/How-Tos/Creating_and_Applying_Group_Policies#By_Client

alemabrahao

I believe you can do this via Group Policy. https://documentation.meraki.com/SASE_and_SD-WAN/MX/Design_and_Configure/Configuration_Guides/Client_VPN/AnyConnect_on_the_MX_Appliance#Group_Policies

alemabrahao

I suggest you contact Meraki support.

alemabrahao

But now comes the question: the documentation makes it clear that all C9000 cloud management models with iOS XE 17.18.2+ are compatible with the functionality, so in theory the requirements are okay. So it seems to me there's a discrepancy in the documentation, don't you think?

alemabrahao

But as far as I remember, in the suggested scenarios, it's recommended as good practice to have STP enabled, isn't it?

alemabrahao

Counted as a single camera. Meraki sells a specific single license SKU for the MV84X, such as LIC‑MV‑MULTCAM‑1Y / 3Y / 5Y, which is tied to the entire device rather than to each sensor.

alemabrahao

I've also heard some say that disabling DHCP on a network is a security measure. A poorly trained user makes the network more insecure than anything else. 😅

About alemabrahao

alemabrahao

Alessandro Abrahao

Community Record

Badges