About NolanHerring

DavidStabik

@Decker19797, I know that the training courses are difficult to get into due to the high demand for both the content and the take home equipment. There were over 140 registrations for the courses offered near me and only 15 spaces available. Good luck in getting in to one near you!

BlakeRichardson

We ditched 2.4Ghz last year as there is just fair to much interference on that frequency from neighbouring properties. Since we stopped using it most of our problems have gone.

bk10233

Thank you !

BlakeRichardson

This is from the Meraki SFP Overview article. JUst thought I would post this in case anyone was interested. Are other Cisco SFP/SFP+ parts certified to work with Cisco Meraki products? Not at this time. If I have a technical problem and am using non-certified optics, will Cisco Meraki Support provide assistance? Cisco Meraki will still provide technical support and help troubleshoot the issue. However, if the problem is isolated or related to a link that is using non-certified optics, you may be asked to test using a certified part.

RB___

As others have mentioned, connecting to the local configuration page will provide you the ability to confirm whether or not that WAN 1 is statically configured. Ensure that interface is configured for DHCP addressing and then reboot the device.

NolanHerring

This might be what your looking for. https://meraki.cisco.com/blog/2019/03/introducing-the-mv-snapshot-api/

jscott

Another note, this particular AP is not mounted on a ceiling. It is sitting on a shelf.

HodyCrouch

You probably already know... Meraki supports both "Click-thru Splash" and "Login Splash" for captive portal. The click-thru doesn't include mauth and doesn't use RADIUS to verify the credentials. Login splash provides a destination URL to authorize the client. With your mobile app and proper walled garden, you don't need to show the captive portal page at all. Instead, have your back-end server call the appropriate Meraki Dashboard API. PUT /networks/[id]/clients/[mac]/splashAuthorizationStatus or PUT /networks/[networkId]/clients/[mac]/policy To use the second option, you would create a group policy that allows the client device to skip the captive portal page. With the first option, the authorization automatically expires. Group policies remain until you remove or change them.

Nash

@PhilipDAth's got the same logic my company uses. If there's not a lot of inter-VLAN talk, MX is fine. If there's a significant amount of traffic, L3 goes into the core switches.

BlakeRichardson

Pretty sure Meraki only allows you to stack switches that are the same model family as there are different stacking types.

ww

Thats normal because al traffic tunnels to you wlc/appliance. The switch does not know whats inside the tunnel packets. https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/SSID_Modes_for_Client_IP_Assignment

NolanHerring

Thanks guys. This doesn't really seem like something I want to collect and never look at lol. Also seems like it would be a lot of syslog traffic.

aedm87

Thank you PhilipDAth, I hope to release soon this version....

Dudleydogg

This also started affecting me today. Some of my SSID's work for ATTWIFI some do not. all are bridged. I did not make any changes to the SSID but something else in MDM might have kicked . we can no longer make wifi calls Any one have and resolve this problem Thanks

LouisR

Yea I looked over that documentation so I think my take away looks to be correct. Thank you everyone.

NolanHerring

To quote a friend, it depends. =) Some are 100% against it and prefer to use proper design to 'persuade' clients to connect to 5GHz. By that I mean by using a 6dB difference in power between 2.4 and 5Ghz, which tends to be the magic spot so that cell sizes match and the end-user doesn't hear the 2.4GHz much louder. Client devices have a tendency to be stupid, and the louder the RSSI is, they cling to it. The theoretical 'pros' are that it will get more clients onto 5GHz and that is usually what you want since 5GHz usually is much cleaner, less noise, faster throughput etc. The 'con' however is that it is an imperfect solution to an imperfect world. Clients send out Probe Requests on 2.4 and 5GHz at the same time. The method it uses to accomplish this is by ignoring the probe requests the client sends on 2.4GHz (usually around 3 times) and by doing this, it hopes that the client will see the Probe Responses on the 5GHz side and end up connecting to that. https://documentation.meraki.com/MR/Radio_Settings/Band_Steering_Overview Doesn't always work, and so sometimes it might cause some 'thrashing' and and the end of the day you want your wireless to be as seamless and as stable as possible. My solution, in case you noticed by my screenshot above, is to use dedicated SSID's per-band. My corporate networks are 5GHz only. The guest network we have, is dual-band with the band-steering enabled and for the most part it works, have not noticed any 'obvious' issues. I would prefer to use seperate SSID's for guest, the problem though is that it just doesn't look 'clean' and now your relying on end-users to make the right choice. Random Example: Starbucks <---- one SSID, clean, simple, with band-steering vs Starbucks <---- 5GHz only Starbucks Legacy <---- 2.4GHz only (Legacy being the word I"m using to reflect 'slower' or 'less optimized'.) It achieves the goal, but you might run into users choosing Starbucks Legacy even though they have a 5GHz capable device. So for non-critical SSID's like guest, I will use it. For business SSID's though, I will use a 5GHz only SSID and it takes all concern out the window.

PhilipDAth

With switches all the packet forwarding is done by the silicon. The CPU and memory are used by things like dynamic routing protocol updates, spanning tree calculations, and the like. Unless you have at least 10,000 layer 3 routes in your network you probably don't have to worry about CPU or memory. Throughput can be gauaged from the Network-Wide/Clients view. If you are only using the Gigabit ports, then your maximum throughout would be 2 x 24 Gb/s, or 48Gb/s. So if you don't see the graph getting close to this you don't have an issue. And even then, you could then consider using the 10Gbe ports for high traffic generators/sinks.

BrechtSchamp

I guess the news is out then :P. I thought it was supposed to be a secret until April 29th...

MerakiDave

Good idea @NolanHerring but that's not there (or hidden) today, perhaps a good wish. For now, you would need to leverage the update-a-switch-port PUT command twice, with a sleep timer in between, to toggle the poeEnabled parameter off and on. https://api.meraki.com/api_docs#update-a-switch-port

Nick

Nice - thats the sort we want I will do some searching thanks Philip

RobertDitusa

What are you getting how slow? You have one device only plugged into the MX65?

AndreasE

how? example?

jdsilva

Just the one time. It's been good again trying twice more. Maybe just residual?

NolanHerring

It is stable candidate and based on the 'vibes' I've felt in the ether on these forums, it seems to be the go-to-firmware for MX67/68 models specifically. I have not seen any specific issues on my end, but I"m also not doing anything fancy pants.

BrandonS

There is a KB article and guide that should help too: https://documentation.meraki.com/zGeneral_Administration/Tools_and_Troubleshooting/VoIP_on_Cisco_Meraki%3A_F.A.Q._and_Troubleshooting_Tips Cisco Meraki VoIP Deployment Guide

NolanHerring

Nolan Herring

Community Record

Badges