Thank you. We've reinstated the ASA for Anyconnect and we're going to look for a suitable solution. ... View more

I have tried setting the power manually but even then the dashboard keeps telling me the max output power is lower than expected. I haven't done any measurement tests to see if the measured output power increases when setting it manually higher. If so the dashboard is not reporting it right but considering the explanation that this is "working as designed" I doubt there will be any difference between the dashboard and the actual output power of the AP. ... View more

I'm trying to wrap my head around this how we should consider this in a design:   Let's say I design a VoWLAN network with every AP (MR46) at 14 dBm EIRP (@ 5Ghz). This means I set the AP in the dashboard at 8dBm (as far as I know that's always the AP output power without the antenna) and with the antenna gain I end up at 14dBm EIRP. Does the beam forming gain only add up when I allow more output power than 14 dBm?This could result in sticky clients.   When beam forming kicks in does the output power of the AP go back to 2 dBm to compensate the 6 dBm gain to keep the max at 14 dBm?   I'd like to hear Meraki explaining this because if the behavior is unclear you can end up with pretty wonky designs.   ... View more

Just checking my case notes : my test on channel 100 (20mhz) saw the output power max out at 13dBm. The 3F gain is almost 11 dBm so 13+11=24 dBm which is 6 dBm below the regulatory 30 dBm. This makes sense if beamforming takes 6 dBm... (why isn't this in the datasheet ?). ... View more

I have a customer with MR46E with MA-ANT-3F antennas and it's impossible to get the output power above 6dBm on UNII-1 and UNII-2e (max EIRP 17dBm instead of the expected max 23 dBm). It allows 12 dBm on UNII-2e channels.   On 2.4Ghz 3 dBm is the max output power.   Support could not give me an answer (like above) why the settings are lower than the MR42E (MR42Es do not have these limitations or uses the 3dBm margin, they are 3x3:3). All in all the dashboard is a bit confusing when it comes to output power and EIRP values.   Edit : customer is in ETSI region also. ... View more

I often use MA-ANT-3-E6 antennes to cover ground areas if the ceiling is above 8m (in designs). Below that I'd advise you to use a downtilt omni antenna. Main advantage of the 3-E is that you get a smaller coverage cell than with an omni so if roaming is required this will give you a more predictable wireless environment.   This is a MR42E with a 3-E antennes at approx 11m in a warehouse. 3-F antennes are used for getting the signal between the racks (also mounted at 11m) and standard APs at the docks (mounted at 3m).         ... View more

MX 16.16.2 promises fixes for some models:   Fixed an issue on MX67(C,W), MX68(W,CW), MX75, and MX85 appliances that could cause ports to occasionally disconnect and reconnect (“flap”) when connected to some devices.   ... View more

The Meraki example which I posted was during a MS Teams call from my iPhone 8 (started at 15:16 and took 6 minutes). The call was quite good (some glitches). The experience with the Gigaset smartphone was quite horrible but that's because it's crap hardware (sticking to APs up to -90+ dBm.......). But that aside when I look at the iPhone roaming the number do not make any sense to me. When I look at your example it seems to make sense. ... View more

Yesterday I did some testing with a Android smartphone from Gigaset. These phones are horrible when it comes to roaming. So I made a round with my iPhone 8. If I look at the timeline from a wireless troubleshooting perspective then this is a useless tool. The reporting is not consistent (sometimes the time to connect is missing) and the reported time values are nowhere near what you want to see when checking requirements. For example if you check Voice over WLAN requirements you want to see if the device roams within 150ms. Do not know who developed this but this is developed without any knowledge about wireless troubleshooting.     This is useful information (Cisco Wireless Debug Analyzer):       ... View more

Thanks for the update! This afternoon I'll be going on site and will try to collect some data about roaming (there are issues with a Gigaset android devices) with different devices and see if it corresponds with what the dashboard is telling me. ... View more

Any news on ths topic ? I still see 'time to connect' values between 2000-4500ms when roaming. Which is quite bad considering this is on a Voice SSID.I think I'll open a case as well. ... View more

Looking at the VRRP is certainly important because it tells you if the problems are caused on the WAN or the LAN side. Losing uplinks will give you another VRRP status then a losing the connection between the MXs on the LAN-side.   ... View more

Are these interfaces connected to the uplink ports or are these connected to the LAN-side of the MXs? If you're seeing a lot of VRRP events keep an eye on the priority status. If you see prio 75 (primary) or prio 55 (spare) then you have issues with your uplinks.   https://documentation.meraki.com/MX/Networks_and_Routing/Routed_HA_Failover_Behavior   ... View more

Thanks for adding the info. At this moment it is still hard to point out a specific situation or hardware type except that it happens with HA-pairs.   Update: changing to SFPs on our MX85s did nothing with the dropping uplinks. Advice from Meraki support was upgrading to 16.16.1 which includes a fix for the MX100 but they expect it to work for these as well.   In case of the MX450s I had a chat with the customer and they are using a Aruba switch as WAN-switch and I have yet to rule out any spanning-tree causes. The odd thing is that VRRP is using prio 105 when the uplink drops. I haven't found any reference to that status.   https://documentation.meraki.com/MX/Networks_and_Routing/Routed_HA_Failover_Behavior     For those interested. This is the kind of behavior we're seeing : Depending on the role the FW is dropping to the VRRP-prio associated with failing uplinks (75 on the primary and 55 on the spare MX). On the WAN-switch we only see the status of the ports change Designated -> Down -> Disabled -> Down -> Designated. This occurs repeatedly and coincides with the VRRP events.   I'll keep you updated.   ... View more

These access points are running MR28.5 ... View more

Cisco has some Excelsheets for range calculation. It is based on Cisco APs and antennas but it might give you an estimate:   See this thread on the Cisco Community forums https://community.cisco.com/t5/wireless/calculating-coverage-area-using-directional-antennae/m-p/2742050/highlight/true   ... View more

The story continues:   Have tested it with a MR33 and it fails to work with Microsoft NPS. I've also tried FreeRadius and that works. During the tests I made come captures:   This is FreeRadius capture (the only interesting part is the Access-Accept reply from the RADIUS server):     This is the NPS reply:     Assuming Meraki ignores the other attributes, one thing is different in the Tunnel-Password attribute; NPS is not adding a Tag field in the reply. From the RFC   Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains; otherwise, the Tag field SHOULD be ignored.   Don't know if this is the case but this might be the reason it is not working.   ... View more

Hi,   I got it working with a Cisco WLC (8.5) and NPS on Server 2012. The WLC part is pretty straight forward (PSK Based SSID with MAC filtering and AAA server configured). I know this is a Meraki forum but want to share the part of the NPS config. It might give others some leads:   NPS / Windows: Create a user with its MAC-address as username an password (format aabbccddeeff). This creates an issue with the default Password Policy because it rejects the password. For testing I disabled it but this is unacceptable in production. Add the user to a group (e.g. IOT) Create a network policy with the condiftion of the User Group (IOT) and other favourite conditions Do not select any Authentication Methods and add Vendor Specific RADIUS Attributes (Cisco-AVPair)       PSK configured on the WLC is 'Waarisdesleutel' just like the RADIUS attribute.   Caveats: Password Policy is configured at the domain level so changing it will affect the whole domain. If you want to use NPS for this setup, install an sperate DC server with an seperate domain. Install NPS on this server and use this one for IOT-authentication.    If you want to use only one front end RADIUS server you can use this server. For normal 802.1X users you can add a policy which proxies the requests to the internal NPS server.   Seperating the IOT-users from your normal domain solves another problem and that is access to other Windows resources.    Edit : it seems in Authentication methods you need to select PAP only. My client was suddenly offline and fiddling with PAP and the "Allow clients to connect without selecting...." option got it back online. Going to keep an eye on this.   ... View more

Having one 1 IP address is standard with Catalyst Stackwise because the switches share the same control plane. I guess they did not change that.   The boottimes are really bad. It's a bit embarassing that they slap themselves on the shoulder with having one hell of an ASIC on the inside while the switch itself takes ages to boot (resulting in unnecessary long downtime). The Catalyst version is also slow as hell (but that is already mentioned in this thread).  ... View more

>No Meraki stack from any model MS family allows an individual switch to be rebooted.  The same restriction applies with most of the Cisco Enterprise stacks as well.  Nexus is one exception, but it's not a stack like the others. Catalyst 3K and 9K have an extra reload option to reload a slot (aka a stackmember). And you can always use the power to shut down a member (not elegant I know).   IMHO the purpose of a stack is redundancy in case of a failure. Having MLAG support is a benefit.  VPC on NX-OS has one big benefit and that if one switch fails at the software level it won’t pull the other switch down the drain. VSS and StackWise Virtual still have that problem just like normal stacks. One drawback is that you have 2 separate switches with separate configs which you need to keep synced manually.  Putting the redundancy at the host level is also an option. It’s a matter of preference I guess.  ... View more

That beats the purpose of a stack. You would expect redundancy (to a certain level) when you connect servers with double connections to a stack. Splitting the stack will also disable any MLAG functionality.   Meraki should not have released this switch before a) the firmware was stable and b) it has at least the feature level of a MS355/MS425.   This thread is already too long and still the beta firmware (release notes) does not show much progress. since I opened this thread.   We're talking about a hardware platform which is already in production for about 2-3 years. It has a predecessor which is quite similar (Cat3600/3800). You'd say they had more than enough to play around with prototypes. I do not know what is keeping them from 'getting there'.    In the meantime we've made several designs based on the 'normal' MS400/MS300 switches where a proper functioning MS390 certainly would have made a difference.   I really love the idea of having a Cat9K switch with Meraki software don't get me wrong. ... View more