Hey @Vishal07, This might answer your question: https://documentation.meraki.com/MS/Layer_3_Switching/MS_Layer_3_Switching_and_Routing#Pings_Destined_for_a_Layer_3_Interface   "Note: Meraki MS classic switches (excluding MS390) are unable to ping their own Layer 3 Interface." ... View more

Hi @redsector, Please let's try to be respectful here. I'm not trying to accuse you of anything, just trying to help since I saw noone replying to your request. Based on my experience, packet capture is the step that helps in most cases to understand whether there is some traffic on the link or not, and mostly people forget about this step. You can collect them on the upstream device, not the AP which is offline, as I mentioned in my comment: "If your AP is connected to Meraki device upstream, you can leverage Dashboard Packet Capture utility to collect pcaps.". Obviously this applies to any other devices upstream that are capable of collecting pcaps. ... View more

Hey @Jobsp,   This KB gives some brief overview on what DFS is and how APs behave when the DFS event is detected. To mitigate negative impact on the network, you can deselect DFS channels from AutoChannel selection as mentioned in that KB. Note, however, that this will leave you with fewer channels and may be challenging in dense environments.   Based on my experience, DFS events can be detected pretty much everywhere. Usually, they can be caused by Radars, but sometimes there can be some device in the environment that is generating signals that are legitimately detected by the AP as DFS event, so hitting DFS event from time to time is normal. ... View more

Hi @Messy,   Unfortunately, it indeed is correct and when using sing-on splash page you will need to specify publicly-available RADIUS server. This, however, applies also to MR, so there's no difference in this case between MX and APs.   This is simply caused by the traffic flow. When Sign-On splash is used for authentication, the authentication will be happening between Client <-> Cloud <-> RADIUS server, so Meraki Cloud needs to communicate to the cloud in this scenario, hence public IP is needed. The flow is described quite well here. When you think of that, it makes sense, but introduces some challenges. Me personally can't think of a better way to implement this without this limitation.   Good news though! You don't need to expose your RADIUS server to the whole Internet, only a couple public dashboard IPs will be enough. You can find them in the "?" > Firewall Info page when you configured the Sign-On splash. In my case it was 3 IP ranges from where RADIUS server can expect connections.   Here is also a KB for MR configuration, but it should be pretty similar on MX side as well.   I hope that helps, or at least gives you some more understanding on why it was implemented this way 🙂 ... View more

Hi @mrpackethead_, Unfortunately, it's not possible to configure the MX WAN interface to use DNS server which is reachable over the Site to Site VPN from the MX. This is because the MX WAN interface doesn't participate in VPN, and all traffic from the MX management interface will be sent directly to WAN link, so you need to make sure that the server is reachable from WAN interface. It doesn't necessarily mean that it should be a public IP though. If your MX is behind NAT and using an IP in a private range, you can use the DNS server that will be in the private subnet as well.  ... View more

Hi @tcanty, @ITINABOX, I was able to access dashboard on both servers you mentioned (n568 and n176), and I also have an organization on n166, which also seems fine. Have you tried standard troubleshooting? Clearing cache, cookies, trying from different browsers/networks? (I can see @ITINABOX, so these questions are more for @tcanty). Does it also happen for all administrators in your organization, or is it limited to you only? ... View more

Hi @Ahmed900, I agree with @PhilipDAth, at first its important to understand what you're trying to achieve. With this said, I think you can use the setup with PSK and Sign-on splash page, and in the dashboard settings you can put the laptops into a white list manually, and in this case these clients won't need to go through splash authentication. And if users try to enter connect to the SSID from their phone knowing the PSK, they will be met with the splash page. This method, however, don't prevent them from connecting if they know the password for the splash page. Something similar is outlined in this KB. I believe the best way to go here if you want to restrict access from phones would be some sort of MAC address-based, or cert-based authentication. ... View more

Hi @soypablocra, On top of the upgrade suggested earlier, I would recommend to also collect packet captures on the ports where your pin pads are connected when the issue is happening, and/or call Meraki Support when the issue is happening so that they could do the necessary troubleshooting. But yeah, based on the known issues you found, this could definitely be a firmware issue. ... View more

Hi @piasterloo, I +1 @ww here, having these switches in a separate network will help not to break reporting 😀 ... View more

Hi @Network_ICT, That's an interesting issue, I haven't seen it myself to be honest, however, I have a few suggestions on how to approach the troubleshooting. 1. In the wireless packet captures, make sure that you're checking the correct BSSID in the beacon frames, just to double-check that you're seeing beacons from the correct AP. 2. Create a test SSID that will be broadcasted on 5 Ghz only. You can enable it on the AP when it is affected and see if your clients can connect to it. This will allow you to see if the issue is limited to specific SSIDs, or it's AP-wide. Also, if you don't see it from the clients, it may mean that the AP is not beaconing for this SSID, which is a problem. 3. In the wireless packet captures, try to identify on what step the connection is failing over the air. 4. Call Meraki Support when the issue is happening. They should be able to verify if the SSID is beaconing, and also collect some backend wireless connection logs to see the step where the issue is failing. If you have a way to reproduce the issue on-demand, this will also help with troubleshooting! ... View more

Hi @Jay13, I did some digging, and here is what I found: reason code 77 (UNSUPPORTED_FINITE_CYCLIC_GROUP) - Authentication is rejected because the offered finite cyclic group is not supported; check the RSN Information Element in the Association Request/Response frames. I would suggest to try and scope the issue to see what SSIDs are affected. I'm not sure what authentication you're using, but I'd recommend to try different (including open SSID) to see which are affected. Monitor Mode (or Over the Air) captures would also help here - you would need to look at the beacon and association request frames to see and compare "RSN Capabilities" header. I think on MR44 you can also collect bidirectional over the air captures from the Wireless interface of the AP in the Dashboard from the Network-Wide > Packet Capture page. ... View more

Hi @AxL1971, @Networking101, There was a bug in MR 30.7 where client balancing was rejecting clients from connecting to particular SSIDs. This is resolved in MR 30.7.1+ firmware versions, and we didn't have reiterations of this bug. With this said, it is still recommended to keep Client Balancing disabled due to often client compatibility issues. If client doesn't support 802.11k, you can see something like "client was rejected by the AP" or "reason.code == 17" in the logs, which doesn't necessarily mean that that the AP is malfunctioning, but can just be compatibility issue. This behavior is explained quite well in this KB. ... View more

Hi @SeanGr, Normally, you would like to reset the device using the reset button and a paper clip, however, power cycling the device multiple times will also reset the device. This is an additional reset mechanism that is sometimes recommended by support (for example, when Local Status Page is not available or a standard factory reset isn't working). I suspect that your unexpected reset could have happened as a result of multiple power cycles. Were you actively power cycling the device close to the time you noticed a reset? Did you maybe have some issues with the power?   Also, I will +1 @Mloraditch here and recommend opening a support case. The agents may have more insights from the backend to see what happened at that time.  ... View more

Hi @Indian1,   Root Cause Analysis was recently introduced for the Ethernet uplink speed degraded alert. If you click on the link in the alert, you will see alert details, as well as the suggested actions that may help to resolve this issue. I would start with these actions first.   Additionally, see details about this alert and suggested steps in this KB. ... View more

Hi @GoOn, You can configure VLAN tagging on Internet ports either from the Local Status Page, or from the dashboard Security & SD-WAN > Monitor > Appliance status > Uplink > VLAN ID. It is not a requirement to use PPPoE to be able to configure VLAN tagging on uplink. On Addressing & VLANs you can only configure VLAN IDs for LAN ports. ... View more

Hi @thomasthomsen, I just made a quick test with my MR52 AP by collecting pcaps on the upstream switch port and can see system description in the LLDP packets from the AP, so it appears that what you're observing may be a bug in the new CW917x AP.  I would suggest you to open a case with Meraki Support so that we could take a look into it. I would recommend attaching the pcaps of non-working scenario (with CW917x AP not sending System Description in LLDP), and working scenario (with other AP sending System Description in LLDP). This will speed up the process and help support in their investigation. ... View more

Hi @redsector, Firstly it is important to understand whether an issue is only with cloud connectivity, or clients are also affected. If when the AP is offline clients can still connect to it, then the issue would be related only to the management traffic. In both cases, once you identified the scope, I would recommend collecting packet captures on the switch port where the problematic AP is connected and filter by the AP MAC address with "eth.addr == {AP_mac}" filter. In the pcaps pay attention to any DHCP, ARP and/or DNS messages. If any of the above is not replied, investigate in this direction. Based on my experience, this is usually caused by DHCP issues, but pcaps will definitely be useful here. If your AP is connected to Meraki device upstream, you can leverage Dashboard Packet Capture utility to collect pcaps. ... View more

Hi @James2050 , @cavementech1,   Process of converting C9300 from Meraki to DNA/CLI managed mode is pretty quick and should take no longer than 15 minutes on call, but it can only be done with the help of Support.   Once you created the case and called Meraki Support, the agent will verify your support passcode and initiate the migration, which will then take up to 300 seconds for selected switches to start migrating. Once initiated, the migration process cannot be stopped via Dashboard or SSH, and should not be interrupted.   Also be cautious of the fact that migration will factory default the switch and all configuration.    ... View more

Hi @jsmith722, As it was mentioned by folks above, there is no native solution in Meraki to limit the amount of clients per AP, so in this case it will be always the client decision to which AP to connect. With this in mind, key to the correct client distribution between APs is wireless design.   Here are a couple of KBs that can help you understand what settings can be used to control RF environment: https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MR_Wireless/High_Density_Wi-Fi_Deployments https://documentation.meraki.com/Architectures_and_Best_Practices/Meraki_Wireless_for_Enterprise_Best_Practices   If you have a high density deployment, make sure to conduct post-deployment site survey to validate the RF environment. ... View more

Hi @Rafael_Cabrera,   Regarding "Consistency Across All Existing and New Sites", although I'm not fully aware of your deployment goals, I believe you can use templates to achieve this. It will allow you to have consistent wireless settings across multiple sites, with some level of flexibility per each site. You can see "Local Overrides" section in the linked KB to see what settings can be overriden in networks bound to the template.   When it comes to the feature itself, you can submit a feature request. This KB outlines the process of making a with.​​​​​​​ Any wish that is made, will be brought to the attention of Product Managers and Development Teams. These wishes are taken into consideration and are used to help shape our product roadmaps. The most wished-for items are incorporated into product development.   In the meantime, you can consider writing up a script using API to try and automate SSID configuration. I believe this API call may be helpful. ... View more

Hi @B_97, I agree with @Mloraditch here, Event Log will be helpful here. In addition to that, I would recommend reviewing the Wireless > Monitor > Health > Connection log page since it includes more detailed information about the failure and can provide you with the most likely root cause of the issue.   You can also use a new Assurance tab to view Client Impact in your wireless network to see if this is possibly more wide-spread issue.   Once you reviewed the Connection log and assurance tab, I would recommend to scope the issue and see if this is related to a specific client device/SSID/AP etc. Also see if you can reproduce it on-demand, or the issue is intermittent - this will be helpful information to understand the root cause. ... View more