Meraki

CFStevens · ‎Mar 27 2024

Hey @TomasB , As @ww correctly pointed out, MG's now have a yellow status in the Organization > Overview section of the Dashboard. Please see the following for more details: https://community.meraki.com/t5/Cellular-Gateways/New-MG-3-102-stable-release-candidate-firmware-reboot-fix-and/m-p/227418

CFStevens · ‎Mar 25 2024

Hi @six , I am not sure if you ever resolved this issue, but in case you have not, I would advise reviewing the uplink loss on either end of the tunnel. You can check this by navigating to Security & SD-WAN > Monitor > Appliance Status > Uplink > Loss. Are you seeing packet loss on either side that could account for the spotty connection to your web servers? Are you running the latest MX firmware? Do other branch MX sites have troubles accessing these servers as well?

CFStevens · ‎Mar 25 2024

Hey @BSD54 , As others have stated, it would be best to know what your source IP address of the pings will be as well as the destination IP you are trying to ping. I agree with @ww in that it would be best to double check and confirm you have a return route from your upstream router to the downstream subnet you are pinging from.

CFStevens · ‎Mar 25 2024

Hey @BingBongNoise It would be worth reviewing and seeing if all your wireless clients are having DHCP issues, or only some are having DHCP issues. If only some are having DHCP issues, then it would next be good to determine if it's only the ones with those poor initial connection stats. If it does start to look like poor connection quality may be a contributing factor, then it would be worth it to review your RF Profile settings by navigating to Wireless > Configure > Radio Settings > RF Profiles > [Edit Profile]. I would advise giving the Meraki Support queue a call when you do this so we can help advise if the RF profiles look like they may be noticeably improved or not. RF Profile settings are generally site specific, but gross misconfiguration does occasionally happen.

CFStevens · ‎Mar 25 2024

Hi @JLHSolutions I am assuming the issue is only happening when users try to connect wirelessly, correct? If you navigate to Network-wide > Monitor > Clients, and review a client who has been seen getting these errors, are you seeing any other strange behaviors? Poor SNR or slow time-to-connect? Quickly roaming to other access points in a short period of time?

CFStevens · ‎Mar 22 2024

Hi @CFC-OZ, Judging by what you have said, your switch likely needs a quick check by a Meraki Network Support Engineer. Please give us a call when you have a free moment to troubleshoot and we would be happy to help. :]

CFStevens · ‎Mar 21 2024

Hi @Cid7 , As the previous posters have said, this would be an ideal situation to open a support case with the Meraki support team so we can review what is going on in the back-end and help. You can find your Meraki Support number by logging into your dashboard and going to: Help > Get help > Still need help? > Call the Meraki Support team. Alternatively, if you don’t have access to your Dashboard network now, you can always navigate to https://meraki.cisco.com/support to find a region-specific support number to call in to.

CFStevens · ‎Mar 20 2024

Hi @VanDerTuch, I hope you are having a wonderful week and that you have been able to resolve this issue! However, in the event that it is still a problem, I would highly recommend you give the Meraki Support team a call so we can review your configuration and attempt to recreate the issue. :]

CFStevens · ‎Mar 18 2024

Hi @ShankarKB, I would advise taking a packet capture on the upstream switch port that the AP is plugged into. Verify if you are getting any sort of RADIUS return traffic from the RADIUS server. If you are not, take a capture directly above the RADIUS server to see if it’s even getting the initial RADIUS responses and possibly investigate the RADIUS log messages and configuration to better understand why it’s not replying back.

CFStevens · ‎Mar 15 2024

Hey @jctech2025, Yes, please give us a call once it happens again and we would be happy to assist. As for the logging, we don't actually have the extensive logging either, but a Meraki NSE may be able to better interpret the logs they do have available in a more meaningful way.

CFStevens · ‎Mar 15 2024

Hi @Speedbird1, Is this issue still affecting you? If so, what model MR devices are you running and what firmware version?

CFStevens · ‎Mar 15 2024

Hi @Tigers, I would advise reviewing the client connectivity logs for a given client (Network-wide > Monitor > Clients) in case there are any obvious red flags that we can troubleshoot. After this, I would give the Meraki support team a call while you have someone on site who can reproduce the issue. I would budget 30-60 minutes to troubleshoot this issue. The Meraki NSE will need the MAC address, SSID, and a brief description of what is happening to the end clients. It would certainly be worth mentioning that this is only affecting Android devices. If you have a running history of when the issue happened (maybe after a specific update?) that would also be useful information. After that, working with them to reproduce the issue while we review will be best.

CFStevens · ‎Mar 15 2024

Hi @Keith_Li, We will need to do a bit of digging to determine why the problem is appearing on that one AP. You can start by ruling out a few common factors that often cause wireless latency. Distance from client to AP, channel utilization and SNR are all things that would be worth looking into. I would advise starting by selecting that AP and reviewing the connection logs. What SNR and Time-To-Connect values are you seeing? Is only one client having issues, are or all clients roaming to this AP having issues? How long ago was the site survey taken?

CFStevens · ‎Mar 14 2024

Hey @jctech2025 , I am indeed a Meraki person! It would likely be better to give us a call than to open a ticket. However, we could take down as many details about the event as possible and hide the case until you call in at a later time. In that instance, we would likely want to know the following at a minimum: Date issue happened: Time issue happened: MAC address or Hostname of client: SSID name: Network name: Brief description about the behavior as seen from the client's perspective: What seems to resolve the issue (if any): What changed around that time (regardless if it seems relevant at the present time): However, if I was in your shoes, I would advise whoever is on site to immediately call the Meraki Support team when the issue happens again. I would set aside 20 to 40 minutes out of their day to troubleshoot. We would want the same info as above, but we would also want to have the Meraki NSEs review logs, review configurations, and possibly pull packet captures while the test client on site tries to reproduce the issue.

CFStevens · ‎Mar 14 2024

Hey @jctech2025 I completely understand (the want for cost savings, as well as the issue never happening when you need it do 😛 ). Your firmware version unfortunately isn't going to show the logs we will need to better understand the client roaming behavior, however, Meraki NSE's will likely be able to review back-end logs to help piece together whatever is happening.

CFStevens · ‎Mar 14 2024

Hi @ccall678 , Have you tried taking a packet capture off the RADIUS server's uplink interface, or the switchport directly connected to the RADIUS server to confirm it is getting RADIUS messages? If so, are you seeing the RADIUS server then send RADIUS replies back towards the AP?

CFStevens · ‎Mar 14 2024

Hey @jctech2025 , As suggested, it would be worth opening a support case with Meraki while someone is on-site and can reproduce the issue. You can open a support case through the Dashboard by navigating to the top right "?" icon. Select it, then select Get help > Still need help? > Submit a case. It would be worth reviewing your client logs while we can reproduce the issue, and possibly reviewing your RF profiles considering the issue goes away on reboot. However, you are running an older firmware version which might be at play as well.

CFStevens · ‎Mar 14 2024

Hey @bkoch , User cmr is absolutely correct in regards to the reasoning behind why one would use L3 roaming or not. To expand on that, L3 roaming causes a bit of overhead and latency, but not nearly as much overhead and latency as if you were to not be using it in a situation where different SSIDs were mapped to different subnets. Without L3 roaming turned on, clients would be given new IP addresses whenever they roam, which will cause many disruptions on the client end (think dropped calls, packet loss, etc) in an environment where different APs are assigning IP addresses out of different pools for the same SSIDs. With L3 roaming, whatever AP your client initially connects to will be its designated “anchor AP”. All subsequent roams will tunnel traffic back to this anchor AP so the client device can keep it’s original IP address. This is less jarring than getting a brand-new IP, but it still introduces an additional layer of processing power and latency. If L3 roaming isn’t needed (which it doesn’t appear to be in your case), it is highly recommended that you disable this feature.

CFStevens · ‎Mar 12 2024

Hi @JonP, I believe 2292 and 2294 are the result of an unintended behavior and would encourage you to open a support ticket to get additional eyeballs on the situation.

CFStevens · ‎Mar 12 2024

Hi @amirnetop, In regards to the APs that are not displaying SNR and RSSI values, what model AP and firmware version are they running?

CFStevens · ‎Mar 12 2024

Hi @shassan, All the comments here are great places to start. If nothing is standing out as an obvious problem, then I would advise giving the Meraki Support team a call. That second set of eyeballs can often times lead to a quick resolution. :]

CFStevens · ‎Mar 12 2024

Hi @Agus, Yes! You can add your new APs to your existing dashboard networks. When it comes to network types, we have two that could fit your requirements. Type: Combined Network This network type lends itself well to topologies that are organized by location. As an example, say you have a firewall (MX), switch (MS), and three APs (MR) at one location. You could group all these devices in one logical Combined Network. If you decided to open a new location and wanted to follow the same logical organization scheme, you would create a new Combined Network for the second location and place all the network hardware into that new Combined Network. Type: Wireless Network This network type only allows wireless devices to be added to it. Customers will sometimes choose this network type to standardize their MR device management to be under one single pane of glass. If you navigate to Organization > Monitor > Overview, you will see the current network types that make up your organization. What type of licenses do you currently have? You can check this by going to Organization > Configure > License Info. You will want to look specifically at the license model being used.

CFStevens · ‎Mar 11 2024

Hi @SLR, As stated earlier, it would be advisable to confirm that your DHCP server is receiving the DHCP Discover messages, preferably via packet capture. Once that is confirmed, you could take a few additional captures from the DHCP server back down to the AP to determine if the DHCP messages are getting back to your client, and if not, where they are being dropped. You can then focus your troubleshooting efforts at the last hop the DHCP communications are seen.

CFStevens · ‎Mar 11 2024

Hi @N-infoMeraki, I would advise giving the Meraki Support team a call so they can review your configurations and look for any potential issues on your Dashboard. After that, having someone onsite to recreate the issue will we review would be preferable. You can use tools such as iPerf to verify network throughput. If that checks out, recreating the issue while taking packet captures at either end of the connection will help us understand where the slow down is happening.

CFStevens · ‎Mar 8 2024

Hi @nipun_m, As stated previously, APs will failover into repeater mode when they lose connection to their gateway. If this is happening to you now and this is not your intended behavior, we will likely need to troubleshoot the issue. I would advise starting with the following 4 troubleshooting steps. This isn’t an exhaustive list, but may either resolve the issue, or put you very close. 1. Bad cable: Sometimes a wire, or pair of wires within the cable will fail, allowing PoE to function, but data transmissions will be corrupted or incomplete. Bring the AP back to your server room and plug it directly into the same port you were using prior. If the AP doesn’t go back into repeater mode, you may have a bad cable. 2. Bad port (on switch): It’s possible some of the pins on the switch are dirty, corroded, or have failed. Test this by moving the ethernet cable connecting your AP to a different switch port, ideally with a known working port configuration. If the AP doesn’t go back into repeater mode, you may have a bad port. I’d advise then following up with this issue by moving the AP back to the port and observing its behavior and factory resetting the switch. If it indeed a confirmed issue, then you will want to reach out to Meraki Support. 3. Bad port (on AP): You may have a bad port on the AP, and the easiest way to verify this will be to take a known working AP, and plug it into the cable run that is currently supporting your repeater mode AP. Does the issue go away? Does moving the repeater mode AP to a known working cable run exhibit the issue as well? If so, factory reset the AP and observe. If the behavior doesn’t change, contact the Meraki Support team. 4. Misconfiguration issue: Check the port configuration upstream for possible misconfiguration issues that may stop the AP from talking to, or getting return traffic from the gateway. If using a static IP on the AP, double check the IP, gateway, and subnet configuration for issues. Look for missing VLANs on the uplink port that the AP hangs off, as well as on all other ports leading back to your gateway Ensure there are no ACLs that may impede traffic from your AP to your gateway. If after running through these steps you still find that you have issues getting this AP out of repeater mode, give the Meraki Support team a call and we would be happy to help. :]

Meraki

Community

About CFStevens

CFStevens

Community Record

Badges

Re: MG21E showing with wrong status on Meraki Organization Overview screen

Re: 2 ISP connected in WAN Branch-Meraki MX and unable to access the web se...

Re: Can't ping gateway from test VLAN

Re: Geeting tons of DHCP server rejection error messages

Re: Geeting tons of DHCP server rejection error messages

Re: Meraki Switch MS120-8FP keeps updating it's firmware

Re: MS390-24UX Current version: Not running configured version, it is opera...

Re: IPSK without Radius problems

Re: Recent 802.1X failure on Meraki Access point

Re: Devices not authenticating to SSID

Re: Latency Graph on MR's missing

Re: Android authentication errors

Re: Meraki MR76 with avg wireless latency warning

Re: Devices not authenticating to SSID

Re: Devices not authenticating to SSID

Re: MR 33 AP's will not connect to raduis server (TACACS)

Re: Devices not authenticating to SSID

Re: Bridge mode vs L3 roaming

Re: Top applications by usage - Weird applications

Re: Empty historical data for wireless AP

Re: AP flapping but internet service is working

Re: Combine new access point to one dashboard

Re: Meraki AP & Radius Integration

Re: RJ45 - Network slowless

Re: AP going to Repeater mode

Re: AP going to Repeater mode

Re: MR 33 AP's will not connect to raduis server (TACACS)

Re: RJ45 - Network slowless

Re: AP going to Repeater mode

Re: MS390-24UX Current version: Not running configured version, it is opera...