I think I might understand, you're asking for 10G copper (electrical) modules as opposed to fiber (optical) modules. For 10G copper/electrical, also called TwinAx, your options are the 1 meter and 3 meter "direct attach" cables to attach to servers. Those would be MA-CBL-TA-1M and MA-CBL-TA-3M. See "Direct Attach" in this data sheet: https://meraki.cisco.com/lib/pdf/meraki_datasheet_sfp.pdf ... View more

Yes, it should be a firmware limitation of 128 clients per radio, so 256 clients per AP.  Note that is far beyond the number of clients that SHOULD be simultaneously connected to have anything resembling an acceptable user experience, because none of the wireless users will be happy when there's 200+ clients on a single AP.  It's not really a hardware limitation so much, it's really just physics.  So while 128 clients per radio may be an arbitrary firmware limit, that's beyond the practical / usable limit anyway.   ... View more

The only answer is "it depends" and it could be 50, 100, 200 or more.  It varies greatly based on client capabilities and what applications are in use, and what the RF conditions look like.  No two deployments will ever be exactly the same.  One of the critical figures of merit in wifi is "duty cycle" (channel utilization), and what drives the channel utilization is directly related to what apps the clients are using (data vs voice vs video vs mix, etc) and what are the capabilities of those clients (a/b/g/n/ac technology, channel width, supported data rates, etc) and also the RF conditions, because if there's a higher noise floor in the environment then clients will have a worse signal to noise ratio and have to use slower data rates.  Lots of variables.   The real first step is always a site survey, but when it comes to estimating clients per AP, as a first step, figure out the types of client devices and the primary applications, and determine what the airtime consumption should be on a per-client basis, and from that you can do a back-of-the-napkin estimate on # of clients per AP.  For example, just hypothetical, a 1x1 smartphone on a 20MHz channel might end up with a sustained max TCP throughput of 50Mbps, but a 2x2 tablet on a 40MHz channel might get 250Mbps.  Just hypothetical, but the point is, that 1x1 smartphone could have 5X the amount of airtime consumption.  Figure this out for the different types of devices and their capabilities and what application is in use (like 2Mbps video streaming or whatever) and for a mix of devices, your answer will be somewhere in between.   If you can estimate the amount of airtime consumption per device, then look at the bandwidth requirement and divide.  Using the 2Mbps application requirement above, and say we're talking 50Mbps per device, 2/50 = 4% airtime consumption.  Since we would consider an AP "maxed out" at, say, 80%, we divide 80 by 4 = 20 smartphones.  But for those tablets at 250Mbps, we're talking 0.8% airtime consumption and 80/0.8 = 100 tablets on an AP.     Note, this is on a single radio, with a completely consistent mix of clients.  Your mileage WILL vary.  And there will always be a mix of clients, and your answer will lie in the middle ground.  There's more to it, but there's a quick & dirty type of estimate.   ... View more

Thanks for this suggestion, and you'll be pleased to know there is a feature request in the system already for this ability.  It is a good/valid request and you can expect it to come in time, but ETA is unknown.  The best suggestion is to keep making the wishes (best to make the wish while you're actually on the packet capture page in Dashboard so it gets properly categorized) and keep the feedback coming through your Meraki or Meraki Partner sales teams so they can also help prioritize.   ... View more

Understand the objections and agree with some of the comments about why Meraki is not offering a PTZ.  Industry reports show decreasing PTZ camera use, and Meraki is not likely to add a PTZ camera to the portfolio anytime soon.  Less than 10% of cameras are PTZ, and PTZ cameras can be 2x to 3x as expensive, they are physically larger, and heavier (motors/servos) and these moving parts wear out and break down more frequently, and the more you use it, the shorter its lifespan becomes, as indicated by the shorter warranty typically offered on PTZs.  PTZs do have their place in the industry.  But perhaps the biggest drawback is that if you PTZ into a specific area, the camera cannot record what it isn't looking at.    Most PTZ use cases can be addressed with proper planning and multiple non-PTZ cameras today, and in the future with other models that might offer a wider field of view for example.  There are many cases where PTZ cameras have been deployed and then the pan and tilt functions are rarely used, and only the zoom gets used, to zoom in for identity or zoom out for overall scene context, and MV does offer a varifocal lens remotely adjustable via Dashboard for that purpose.     All that said, MV cannot address every use case.  If you're in retail and want to follow an active shoplifter around a store, the MV cannot be used for that purpose.  But I'd make the argument that with well-placed cameras and Dashboard's video wall, you could get very close, as well as meet all other retail requirements.   MV21/71 are the first two products in a new and exciting product family.  Help Meraki help you, keep making wishes in Dashboard, and keep the feedback coming through your Meraki sales team or Meraki Partner so all of the use cases and feature requests can be collected, categorized and prioritized.   ... View more

Generally speaking, the #1 best and common practice is WPA2-Enterprise which leverages 802.1X/EAP with a RADIUS server which in turn queries an external LDAP database (very commonly AD).  This covers everything you need with respect to AAA, mutual tunneled authentication, RBAC, and a variety of EAP types to fit various requirements, and to handle both wired and wireless use cases.  You mentioned DEP and iOS 11 so if you have it, RADIUS can also query Open Directory.  And if you're using Meraki Systems Manager you can also leverage that for things like client certificate distribution to implement EAP-TLS, without the need to stand up your own PKI or do all the cumbersome certificate management.  Anyway, definitely read up on 802.1X/EAP and RADIUS to plan out your AAA services on your network.  ... View more

Thank @barryf2031 for noting this, Meraki does value all feedback both positive and negative and your objection is noted.  A great deal of thought is poured into all Meraki hardware design, and Meraki is fully aware the MV physical installation is a critical element to both a customer's overall experience and the capabilities of the video surveillance solution.  For example, bonding the MV21 dome and camera mounting plate into a single unit along with a hand-removable bubble for optical adjustments, right down to the way the foam tray holds the tools and screws and even optimizing the size/shape of the installation guide for use on a ladder.  With additional feedback and Dashboard wishes, Meraki can take that many more data points into consideration for future iterations of the hardware, so thanks for sharing and thanks for joining the Meraki Community.   ... View more

Here's one of my own "before and after" stories.   Ok, just kidding, stretched the truth a little, but you get the idea. 🙂  ... View more

Lot of work.  Thanks for sharing, very nicely done!! ... View more

One other best-practice that comes to mind if it might help with your fine tuning...  As a rule of thumb you want to at least disable the lowest two data rates in each band.  Selecting 12 or 18Mbps is a common practice.  You can do this SSID-by-SSID on the Access Control page.  This also has the (usually desirable) effect of disallowing very old legacy 802.11b devices from associating and avoids the protection mechanisms (and associated performance impacts) for backward compatibility.     The default setting of 1Mbps creates the largest possible coverage circle, allowing clients to stay associated to APs very far away (despite other APs being closer) and staying connected with lower signal-to-noise ratios, therefore at lower data rates.  Lower data rates will impact channel utilization since the data will be modulated onto the RF carrier that much slower.  This causes a very high duty cycle (slower clients take longer to transmit the same amount of information) and impacts performance for every other nearby client.   It's a half-duplex shared medium, channel utilization is a critical factor, and there is a large impact on the time it takes to modulate a signal into the air at 1Mbps versus 12 or 18Mbps.  The faster a client can get on and off the air, the better.  Using 12Mbps as a minimum bit rate improves channel utilization and encourages better roaming behavior.   What we do NOT want to do is try to artificially force all clients to the higher data rates (like 48 or 54Mbps), as this can also create client problems.  Remember, the CLIENTS, not the APs, ultimately make the roaming decisions, and we cannot control the clients, but we want to get them behaving well, by making it as easy as possible for devices to access the medium on a reasonable data rate with a good SNR.  Thus the best practice is to size your coverage cells (resulting from a site survey) to allow the proper cell overlap (for example 15 to 20% overlap with -67dBm edges) to allow the elimination of lower data rates <12Mbps.   If you find that you MUST support 802.11b data rates (those use cases still exist), consider using AP tags and SSID availability to only broadcast a legacy SSID at the 11Mbps rate from specific access points for example.   Also, to reiterate what @Adam said, use automatic power reduction and don't run all APs at 100% transmit power.  Since many of the APs will “hear” one another, especially in relatively open spaces, and in many designs you might plan for roughly 20% cell overlap, you can end up with lots of APs within range of one another.  If all APs are set to use maximum transmit power, all the APs are just screaming at one another and you end up with far too much cell overlap, far too many APs within range of one another, and too much co-channel interference.  Needless to say that will contribute to wacky roaming behavior.  And remember that while APs might top out at 30dBm (1 full watt of Tx power, that's a lot) many client devices, especially handhelds, might only top out at 15dBm, because for them it's all about battery life.  And those are dBm's so that 15dBm isn't half the power, it's more like 30 milliwatts for the client versus 1000 milliwatts for the AP.   Using Automatic Power Reduction will allow all of the APs to not only properly balance their channel settings, but more importantly their transmit power settings.  After Automatic Power Reduction has been running for some time, and perhaps after running an Update Auto Channels overnight, look back at the Transmit Power column on the Radio Settings page to make sure the way everything "settled" makes sense. ... View more

If you haven't already, do open a Support case on this.  There have been some known issues with DFS over-sensitivity and while most newer AP models had this fixed/addressed in the MR 25.X releases, the same fixes should be coming to MR26/32 so keep an eye on the firmware change logs, and consult with Support to confirm, and they can also attach your case to the existing issue for better tracking, correlation and prioritization.   ... View more

As a temporary test, try setting your default channel width to 20MHz channels under Wireless > Radio Settings, then go back to my.meraki.com and refresh the page and see if those plus and minus signs go away.  Then go back to 40MHz and they should return.    This should be indicating multiple bonded channels when you're running 40 or 80MHz channel widths, so 161- indicates a 40MHz channel bonding of 157+161, while 149+ indicates channels 149 and 153 bonded to be a 40MHz channel.  Try it both ways and check the results.    I think you'll find that the channel reported is the primary channel (like 149 and 161 in your case) while the positive or negative offset indicates the direction up or down the spectrum for the secondary channel (which would be 153 and 157 respectively in your case). ... View more

Are you using an actual wireless client/supplicant or the "Test" button on the Access Control page in Dashboard?  You already ran packet captures and/or ran it by Support to assist with some pcaps?  Let's see what is or isn't traversing the AP.   ... View more

@PhilipDAth is likely correct, the most common issue is a mismatched shared secret between the AP and RADIUS server, but it could sometimes be fat-fingered IP address settings and a UDP port mismatch (make sure it's using 1812 and not some other port like 1645).  Any of those things would likely cause radio silence from the RADIUS server. ... View more

Cool, great timing then, good luck! ... View more

Yes, do call this into Support, at least to review your aperture setting and night mode lux settings, as well as your firmware version (latest is 3.2) to see if any of those "general stability/performance improvements" might apply.  I've also seen a case where the lens was tilted beyond (forced slightly past) the gimble lock and obstructed the IR sensor, but if that was the case here, you'd likely be stuck in night mode, and that image you posted still has some color and isn't B&W.  Have you messed with the aperture setting?  Try setting it to maximum, then minimum, then back to your regular setting and turn the lights on and off with each of those settings.  Share any interesting results with Support. ... View more

Hi Team, just an FYI since it's relevant to this thread, that MS 9.32 has just been promoted today to the latest stable.  Another quick turnaround for the MS releases, in this case it was mostly to address dnsmasq buffer overflow vulnerabilities CVE 2017-14491 to 2017-14496.  Check out the release notes for more info. ... View more

Agree with earlier posts this is a good ask, and unfortunately is not visible in Dashboard, at least not yet.  It is also not available (again at least not yet) via Dashboard API calls.  Confirmed that Meraki Support can see uptime info and past reboot history and share with you.  In the meantime, leverage what you can from the configurable alerts, the Event Log (for example Primary Uplink Status Change on the MX or Power Supply Inserted on the MS), keep the wishes coming, and work with your respective Meraki or Partner sales teams to echo this feature request to the Dashboard team.   ... View more

Daniel, depending on your deployment architecture/scenario, there are a couple of things to consider.  Check out some of the deployment guides https://documentation.meraki.com/MX-Z/Deployment_Guides such as Warm Spare, DC-DC Redundancy, and SD-WAN solutions if that applies to your specific architecture.  If you're simply referring to mitigating an MX failure in a single site, that's simply the Warm Spare (NAT HA) scenario for an active/passive design.  Along with other obvious things like having both MX units on separate and redundant UPS power, dual power supplies in the higher-end models, physical separation between the units as appropriate (like in different racks or rooms or buildings), and then you'd consider redundant ISP connections, cellular WAN backup, and SD-WAN scenarios, etc.  And if for whatever reason a 2nd MX for Warm Spare functionality isn't in the budget, consider a Z1 or Z3 along with a 4G cellular dongle, you could drop the Z appliance in place of a failed MX for emergency connectivity, and/or use the 4G USB dongle for ISP outages.  Neither might not be close to the same bandwidth/performance, but then again it's for emergency backup use.  I've used my own Z1 and 4G USB dongle together multiple times for on-the-fly connectivity, works great.  ... View more

No, you are not forced to use Ekahau or Stanley/Aeroscout (I have also done some successful testing with Estimote) however the best integration story is likely to be with the first two as described in the RTLS Support doc https://documentation.meraki.com/MR/Monitoring_and_Reporting/Real-Time_Location_Services_(RTLS)   Also take a peek at the Asset Tracking solutions page on the Meraki Developers site: http://developers.meraki.com/tagged/Asset%20Tracking/ and here's a good reference on general RFID tag selection http://rfid4u.com/rfid-basics-resources/how-to-select-a-correct-rfid-tag-criteria/ ... View more

@blakekrone is correct that Meraki devices will attempt a combination such as OUI lookup, DHCP fingerprinting via option 55 in the DHCP request, HTTP snooping for the User-Agent string, LLDP if available, and of course NONE of those methods are close to perfect.  I've also seen "amusing" results (like my Honeywell thermostat is reported as an XBOX 360) and I have often flagged incorrect device types.  I'll ask around too and report back with any updates.   ... View more