Hey team sorry I was offline for a few weeks and just checking back, I had to get through the 350-401 Cisco exam, failed it (by just a few points) 2 weeks ago and then got a solid pass 2nd time around yesterday, so I was neglecting the Community for a few weeks. 😁      @Thygesen the other answers are correct, technically speaking, you can certainly spray paint an AP with the non-metallic paint as you mentioned and it would likely work fine, but the warranty is void.  I mentioned in another reply above about vinyl wraps, and yes they'll work great, and to my knowledge they do NOT void the warranty like paint does.  That'll be your best bet to have the APs blend into the environment, vinyl wraps are effective, safe, and cheap.   ... View more

@UmutYasar there actually is a way to run BGP out of the MX VPN Concentrator when it's running in NAT/Routed mode, however it would need to be enabled via Meraki Support and would be considered an exception, as the MX would essentially be acting as a 2-armed VPN Concentrator then.  There isn't anything in the Dashboard UI to be able to configure it.  I would suggest going over the design options with your Meraki SE to come up with the plan forward for this one.  Perhaps this is the config you'll end up with but it might be considered beta, may or may not ever be more than beta, so best to work with your local Meraki team to engage with the product team for input.  ... View more

Hi @trunolimit also check your firewall settings on the MX under Security & SD-WAN > Configure > Firewall and there is a section for "Security Appliance Services" where you should be able to specify the remote IPs allowed for ICMP.  ... View more

Hi @Kevin31 your settings all look correct, I would suggest opening a case with Meraki Support and get a plan in place to try tweaking certain settings, in a certain order, to gather some additional data points.  I'd also suggest getting on the 27.5 firmware and confirm you get those same results with your roaming tests.  Also note there is not necessarily anything wrong, as the roaming behavior is completely dependent on the client, the OS, the driver version, etc.  Here's another related thread if it helps.  https://community.meraki.com/t5/Wireless-LAN/Wireless-roaming-for-client-to-AP-s-not-connecting-to-closest/m-p/100465#M14846  ... View more

Hi @UmutYasar the official documentation is here https://documentation.meraki.com/MX/Deployment_Guides/VPN_Concentrator_Deployment_Guide and note that you can actually run OSPF route advertisement out of the MX VPN concentrator when it's running in NAT/Routed mode.  Note that it will only advertise the routes (as external type 2) and will not learn routes.  It's basically to take all of the remote site routes in the AutoVPN domain and advertise them into an OSPF area.  Note that if you are doing OSPF route advertisement out of the NAT mode concentrator you do need to have VLANs disabled, in NAT/Routed mode it's either VLANs or OSPF.  ... View more

Hi @DBlum, remember that it's ALWAYS the client's (not the AP's) that ultimately make the roaming decisions, and it varies wildly by device vendor, by operating system, and by device driver versions. I've seen devices cling for dear life to an AP 50 feet away when it's right underneath another AP. It's very device-dependent.   So we cannot control the clients, but we try to get them behaving well via best practice settings. And even then, they don't always behave well, and still varies by device type, OS and driver version.  And don't forget that every RF environment is going to be different, and in a given RF environment, every client is going to have a different perception of it.  Different vendors and different operating systems will use different methods, often based on RSSI, which is typically proprietary and different phone/laptop/tablet manufacturers implement in different ways.   So it's entirely possible that client devices can stay "sticky" to an AP even on a floor above or below (through a ceiling or floor) even with another AP in the same room. Obviously there's going to be signal attenuation through a ceiling/floor, but there could still be enough signal strength to keep the client happily associated at a reasonable data rate.   Newer clients that support 802.11k, 11v, 11r (all of which are there since r25 firmware) can leverage neighbor reports to interact with APs to make optimal roaming decisions, and APs can assist with client balancing, but still, it's the client who makes the decision and initiates the roam. And that decision process is a dynamic one with constantly changing variables, such as people (attenuators) moving around.  Furthermore, different client devices from different manufactures running different OS and drivers may exhibit different behaviors.   I've observed similar behavior in my own home, where I have an AP in my basement office and an AP in a 2nd floor bedroom. Some devices will consistently roam from AP1 to AP2 when I get within 15 feet of the AP, while other devices will stay associated to AP1 no matter how close I get to AP2. The behavior isn't perfect but improved with newer firmware.   And implement standard best practices, like setting minimum bit rates to 12Mbps (for example), using automatic power reduction, band steering to favor 5GHz, minimizing the number of SSIDs, using an appropriate channel width, including DFS channels if appropriate, etc.    And of course you can always get with Meraki Support to take a closer look at your specific APs and clients where you’re seeing roaming issues.  Many "roaming issues" can actually be normal behavior given client dependencies and so many variables.  Still, Support has additional tools on the back-end to get some insight on how the APs are behaving and communicating regarding client roaming and steering.     One way to really get to the bottom of it would be to get with Meraki Support and they can assist with analyzing the output from monitor-mode packet captures.    More info https://documentation.meraki.com/MR/Other_Topics/Client_Balancing https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/802.11k_and_802.11r_Overview https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Roaming_Technologies   Hope that helps!   ... View more

There is a pretty good documentation article on this, is/was this helpful? https://documentation.meraki.com/zGeneral_Administration/Support/Information_for_Users_in_China I don't know your exact connectivity or if this is behind the GFWC but it sounds like you might just be able to add them to your Germany Dashboard and have it work, but reading the fine print, you might be required to have these APs on the dashboard.meraki.cn dashboard.  I'd connect with your local Cisco Meraki account team to get a definitive answer.    ... View more

@Manucha is it possible you are administering a wireless network that is bound to a template?  If so, when you are in the "network" that would explain why you're not seeing all of the menu options, but you would have to drop down your network selector in the upper left and drop into the configuration template to see all of the configuration options.  ... View more

@route_map you certainly can and I have this working in my home lab just fine, the MV detects human motion, triggers an alert and sends a snapshot from the camera via a Webex Teams chatbot.  Here's a self-paced guided lab to get it going!  cs.co/adventure   ... View more

@RumorConsumer maybe I misunderstood, but if you simply want to get SMS messages for any/all of your Dashboard alerts, you can simply send them via email to the appropriate carrier's email to convert to a text message.  I haven't tested all of these, I've used it with Verizon and AT&T, but this is the list I have.  Simply include these as an additional (or default) recipient along with any other email addresses.    Alltel: phonenumber@message.alltel.com  AT&T: phonenumber@txt.att.net  Nextel: phonenumber@messaging.nextel.com  Sprint: phonenumber@messaging.sprintpcs.com  T-Mobile: phonenumber@tmomail.net  US Cellular: phonenumber@mms.uscc.net Verizon: phonenumber@vtext.com  Virgin Mobile: phonenumber@vmobl.com  ... View more

Hi @Tirop You can install a 0.0.0.0/0 as a static route and make the next hop the other gateway you want to use on the LAN side of the MX and that should work fine. The "default WAN route" of 0.0.0.0/0 will always be there in the routing table by design and as the last resort, but your static will take precedence. ... View more

Hi @mikyle you can accomplish this using the MV snapshot API, it would just be a matter of configuring an MV Sense license (you already have 10 for free automatically to get started), generating an API key under your profile, and following some of the self-paced learning labs on Cisco/Meraki DevNet.  Sounds like you would end up with a script that sent a snapshot API call to the camera(s) perhaps once per minute, to play back an entire day over the course of a minute or two at 15 or 30fps.  Check these links to get started. https://meraki.cisco.com/blog/2019/03/introducing-the-mv-snapshot-api/ and https://developer.cisco.com/meraki/mv-sense/#!overview/introduction and you could find more pre-canned options in the app store https://apps.meraki.io and elsewhere on Cisco DevNet.  Hope that helps!    ... View more

Hi @NickSpeechley agree with @DarrenOC that I'd go right to the MX84 in this case for 100M/40M with 100 clients.  No, client count is not a hard limit, but a guideline on what was methodically stress tested with all features enabled and still had solid performance.  Depending on what features you'll be running, you might be fine running more clients than what is specified in the data sheet, but we'd never recommend undersizing an appliance for an initial deployment, since some of the key factors for MX sizing are bandwidth, client count, and tunnel count if doing VPN.   ... View more

Your interpretation is correct, the items in that allow list on the Threat Protection page are related to the AMP engine, so any sites you explicitly allow there get excluded from malware scanning.  But agreed, the items you listed certainly look like you would want them blocked, not allowed.  Look up whatever the URLs happen to be.  That's for the AMP piece, and the same concept for the IPS basically applies, but it's possible there was something legitimate being blocked which prompted them to put something in the allowed list.    Also, just a thought, see if you can go back in the change log, see if or what else was changed around the same time, and also see if you can correlate the changes with anything you might see in a Security Center report if it was within the last couple weeks.  You might be able to go back further if there were Security Center email reports configured, as long as you can retrieve those emails.   ... View more

Hi @Quattro_Vageena the MG does act as a NAT gateway and as such it has a subnetting capability, you can easily define the subnet pool that will exist behind the MG on the Ethernet side.  The MG also provides you control over the DHCP configuration as well as fixed IP assignments for devices behind it if desired.  There is also a port forwarding configuration on MG which looks very familiar to MX port forwarding.  But note that the MG is not a true router/firewall in the sense I think you're asking.  Perhaps consider a Z3C appliance for this, which is less expensive than the MG21 anyway, and the Z3C (or the less expensie Z3 but with an external USB cellular dongle) provides you the firewalling and/or AutoVPN capabilities if needed.   ... View more

Oh, and I realized I never answered the actual question in the title of your post, as far as how many clients. That is always an "it depends" answer, many variables there too, one of which is the applications in use and what's going to drive the duty cycle.  Depending on the client capabilities, the applications in use, the RF environment and airtime utilization, the client density and spread, etc, you could find this to be 60 clients, 100 clients, or more.  The theoretical max on the acW2 MR52 AP is 256 clients per radio, but please do not ever design for that or attempt to achieve that 😁  ... View more

Hi @AldoCar there are many variables that will determine if and when a client roams from one AP to another and/or which one they will connect to in the first place.  And those variables are constantly changing, possibly from second to second, for example as people (attenuators) move around the environment, doors open and close, etc.  It is always the clients decision.  We can configure the network and try to fine tune the RF environment and leverage 802.11k and 802.11v to try to influence client decisions and get them behaving as expected, but even still, the decision ultimately rests with the client.    Generally speaking, yes, most of the clients should get the best RSSI from the AP in the same room, but again, the RF environment can change second by second in time, and foot by foot in distance.  In addition, different client devices will have different roaming behaviors, and sometimes even the same brand of client devices, like you mentioned Dell laptops, can have different behaviors based on operating system, wireless NIC and even driver versions.    So lots of variables and every deployment is going to be unique from an RF perspective.  Still, if something just seems plain wrong with the client/AP balance, definitely open a case with Meraki Support for a deeper look and to scrub through your config settings.     Also, I'm assuming the APs in the 3 rooms are the same model, with the same capabilities?  Because if you had an 8x8 AP in one room and a 2x2 or 3x3 in another, that could also explain more clients sticking with the 8x8 AP, even from another room, because that's where they perceive the best SNR, that's just one of a few variables.  Have a look at your radio settings page for example, see if the transmit powers are relatively balanced, or perhaps not, and perhaps adjust them.  Also look at your minimum bit rates, which should typically be 12 or 18Mbps, but make sure it's not much lower, which would create much larger coverage cells and leave clients happily connected to an AP in another room and be stubborn about roaming.  Also look over your Wireless Health page and see if anything jumps out, like if one AP is having many more issues than another.  You could also try toggling Client Balancing on and off, and allow that time to settle and re-check and that result could be another data point to open a case with.     Hope that helps!   ... View more

@TimothyS also get your design and use case to your local Meraki team so it can be added to the request.  I'm not hinting Meraki is developing a ruggedized switch, but I've been in those discussions and want to make a strong case even stronger to expand the MS product line in that IE direction as well. Please have your Meraki SE relay the project info to MS PM.  ... View more

@AndrewTergis I'm not sure which makes & models you might have already tried, but if it's just a single AP to be able to prove this out, I'd suggest getting an MR46 or MR56 trial unit and deploying it with the recommendations @PhilipDAth mentioned as well.  Meraki trials are completely no cost, no obligation, and it's new equipment so should you keep it, no need to return and replace the trial unit, it just gets converted to a purchase.      [updated] In the newer firmware releases and in newer chipsets since acW2 APs, there is no longer a software limitation of 128 clients per radio (which you would normally never want if those clients were actual end users).  But with IoT deployments much more mainstream now, you can support up to 256 clients maximum per radio on acW2 APs and up to 512 clients per radio on ax APs.  So you might be ok in that regard given it's an IoT environment with really lightweight requirements. But there are many other factors to consider, and just because an AP might support that many clients per radio, doesn't mean it's a good idea, 😁      You'll need to carefully consider the IoT application itself and understand it's network traffic footprints, and really understand what's going to drive the duty cycle in that airspace, and consider the RF environment, noise floor, etc and the various considerations that come up during a site survey.   ... View more

Correct @Dave_ the gateway of last resort so to speak is always out of any active WAN interface for any MX or Z appliance.  And that's also correct, you can certainly add your own 0.0.0.0/0 route and that should be reflected in the same route table, for example if you want to have a 0/0 route pointing out via a LAN interface and/or shared over an AutoVPN.   ... View more

@WayneC If it's mission critical or there's a good business case to deploy a potentially expensive wifi solution for a single scanning gun, and they are willing to make the investment, I'd say this is screaming for a site survey, as warehouses can be tricky.  😁  I would also imagine the wifi would be leveraged for more use cases in the future than the single scanning gun, either more scanning guns, or perhaps iPads, mobile phones, etc.  Or you might also want to deploy wifi-capable cameras or environmental sensors that could also leverage the solution?    There are many ways to approach a warehouse design and a lot of "it depends" type answers to many of the questions.  It sounds like all you need is coverage, not concerned with performance or density, but even still, depending on the RF environment and the layout of the shelving (and what's in or on them) you could end up with a couple of different design approaches, thus I'd suggest at minimum get a floorplan to do a predictive site survey.  But be careful there too, nothing simulates a fully stocked warehouse like a fully stocked warehouse.     Sounds like you may have already done that, and came up with 33 APs?  Which might be excessive, that's <500 square feet per AP, but depending on the layout and RF environment, might be appropriate.  What model AP, are those 33 APs with internal omni antennas, wall mounted (hopefully not up on the high ceilings which wouldn't be good)?  Many designs end up with wall-mounted APs and sector antennas aimed down every-other row for example.  But lots of variations, every deployment will be different.   ... View more