Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About craddockc
craddockc
Here to help
Member since Mar 7, 2019
Sep 18 2019
Community Record
14
Posts
1
Kudos
0
Solutions
Badges
Sep 18 2019
7:15 AM
I upgraded to 25.14 and have not seen the issue occur again in the 2 weeks since I have upgraded. However, 25.14 has introduced another host of issues that I am contending with. Band steering is broke, the DCA and DPA functions dont seem to be working correctly. The client balancing feature also seems to be impaired due to the upgrade. Pretty frustrating.
... View more
Sep 17 2019
2:07 PM
@NolanHerring , I just upgraded to this version from 25.13 to clear another issue where the AP would randomly stop passing traffic for clients. That issue seems to have been rectified with this code but now it has introduced others. For instance it is reducing some AP's xmit power to 0 (apparently) without logging it causing the AP to stop servicing clients altogether. See below where it says "old Power 0" "New power 23". No log telling me it even reduced the power. Also notice when the power change was made, the AP stopped servicing clients: For whatever reason the times in the log and the RF tab under the AP aren't lining up but I have no doubt it was the same event. I am also seeing ALOT of dynamic channel changes in the 5Ghz range which makes no sense considering how low the channel utilization is. And even sometimes it says its changing it to the same exact channel and band it was already on: All I can say is that these issues did not exist until I upgraded.
... View more
Sep 17 2019
1:43 PM
Thanks everyone. After doing some investigation it appears the MR25.14 code is doing some really buggy stuff with the power and channel assignments on certain AP's. I will see about setting a manual power/channel plan in the near future. Do you guys have any recommendations as far as what power settings are good for setting my AP's? My AP's are roughly 30 feet apart on average. Thanks.
... View more
Sep 17 2019
11:09 AM
1 Kudo
Dear Community, I have been battling some intermittent connectivity issues in our 5Ghz range lately and wanted your opinion. I am currently using the Default Indoor Profile for my deployment but am noticing some strange things. My deployment is in an office building on the very top floor that has a few other 5Ghz range SSID's but very low channel interference from the environment. Here is a snapshot of what I am seeing: If you notice above how AP's 1704 and 1705 who are adjacent to eachother are using the same channel (60) and again 1707 and 1708 (56). Wouldn't this cause co-channel interference? Why did Meraki dynamically select the same channel on 2 AP's that overlap? Also, if you notice the channel #s being used in the 80Mhz width, why is Meraki not referencing the center channel as per the 802.11ac guideline? For instance AP1703 is using channel 108 in the 80Mhz width, But 106 is the center channel for that width. Same with Channels 56 (58 is the center channel) and 104 (106 is the center channel). Some things just arent adding up here: Would you recommend I statically assign the 40Mhz channel to this 5Ghz range in my deployment? I really don't see the need to have 80Mhz channel widths as we have a semi-dense deployment where interference could be a factor here. And since Meraki doesnt seem to provide away to just exclude the 80Mhz widths from its dynamic assignment, I don't see any other choice but to statically assign it. Please let me know your thoughts. Thanks!
... View more
Sep 3 2019
12:33 PM
Community, This issue occurred again today. After troubleshooting I found that the AP's were not processing/forwarding the ARP packets correctly for the affected clients. Long story short, ARP was failing for the affected clients. I still cant explain exactly why this is happening but my suspicion is that its the AP Firmware. I am going to upgrade the firmware from MR 25.13 to MR 25.14 and see if that "corrects" the issue.
... View more
Aug 30 2019
11:49 AM
Community, I have moved the corporate WiFi that was having an issue to the 5Ghz band only. This seemed to help for awhile but just recently we had users once again complain of their traffic no longer being passed. One user it turns out was a driver issue. The other users we still have not yet figured it out. The issue only happens intermittently. The RF Spectrum in the 5Ghz band on all of our AP's shows low to very low channel utilization and almost no interference on the 5Ghz band, so I am not convinced it is channel utilization or interference at this point.
... View more
Jul 12 2019
6:39 AM
@PhilipDAth , Thanks for the feedback. I will check out what chipsets we are using. Thanks!
... View more
Jul 10 2019
11:16 AM
Thank you everyone for your valuable input. I am goign to move our BYOD WLAN to 2.4Ghz only and see if that help alleviate the situation. Your suggestions have me thinking that its possible that the BYOD SSID is occasionally interfering with the Corp SSID, causing Corp clients to be affected. I will make this change and follow up in a few weeks with results! Thanks.
... View more
Jul 10 2019
9:59 AM
The client appears to still be connected (associated) to the AP, it just loses its network connectivity even to the point to where it cannot even ping the DG which is the switch directly connected to the AP. Its like the AP just stops passing traffic for the affected client. I considered channel utilization as a possible cause but to me that would make more sense if it was just one AP. The issue has occurred to multiple clients across multiple different APs (on different floors of the building) all at the same time. We utilize the band steering option so most clients use the 5Ghz range where the Dashboard shows "Low" and "very low" channel utilization. You mentioned interference, how can I find out if that is whats contributing to the issue? We have 2 separate SSID's one for corp devices that use 802.1x and another for BYOD devices that use WPA2 PSK. I am noticing that on each AP, both of the SSID's are using the same 5Ghz channel. I wonder if the BYOD SSID is interfering with the Corp SSID as it is the corp devices that we are noticing the issue with. Thanks!
... View more
Jul 10 2019
8:34 AM
Dear Community, We have a new deployment of Meraki switches (MS350) and APs (MR33). For the most part things are working very well. However, we have had instances where the AP's will stop passing traffic for one or more clients. Sometimes this issue is isolated where only one client will experience it but we have also had instances where the issue was widespread where a dozen or so clients across multiple AP's (on different floors) will all at the same time lose network connectivity. When this happens the client cant even ping the DG (which is on the meraki switch). The client will usually have to disconnect and the reconnect to the WLAN to get traffic going again, otherwise the cklient will usually correct itself after a minute or 2 and be able to pass traffic again. When the issue occurs the logs only state that the client "disassociated" for "Unspecified reason" but doesnt offer any more granular detail as to why this is happening. Has anyone ever seen this before? Thanks!
... View more
Mar 7 2019
8:13 AM
thank you for your very helpful replies!
... View more
Mar 7 2019
7:32 AM
Dear Community, I am new to Meraki and had some questions about how the gear connects to the cloud and how it gets its configs. 1) How exactly do the Meraki switches and AP's contact the cloud? Are they pre-programmed at the factory to reach out to a certain URL once they have DNS and internet access? If so, what URL do they use? What ports do they use? Im assuming 443 for TLS connectivity? 2) When config changes are made in the portal, does the equipment "pull" the configs down or are they "pushed"? I ask for firewall reasons. If the configs are "pulled" from the gear then I dont need to allow inbound traffic from the Meraki Cloud into my network. Any answers or links to technical documentation would be very helpful! Thanks.
... View more
© 2024 Cisco Systems, Inc.
