Hey,   You should use a high 5 GHz channel to base your max distance on. So I choose channel 140 or 5700 MHz. You should transmit at no more than 14 dBm. The antenna gain on 5 GHz is 6 dB, however the half power beamwitdth is 60 degrees so if you want to calculate for the entire 60 degrees you should subtract 3dB from the gain. So you have 14 dBm transmit power and 3 dB gain on 5GHz for the entire 60 degrees. This gives you an EIRP of 17 and you want to target no lower than -67 dBm receive power at the edge. So you want your free space path loss to be no higher than 84 dB. So 93 meters is your maximum for a very decent coverage. ... View more

That does not appear to be a best practices campus design model you are using. If you are truly using a CORE stack and distribution stacks then those distribution stacks would connect to the CORE and not to the MX'es.   For a distribution or core block it only makes sense to use more than 2 switches if you are out of ports but then you would need all your stackmembers to be in close proximity to each other for the stacking cables unless you are using MR425 models which do flexible stacking.   It's also non-sensical to connect MX appliances directly to distri/core switches because those are some expensive ports.  You normally connect those to an access layer stack in your Internet/WAN edge.  Only if you are in a small company and use access switches as distribution like MS250 then you could collapse both functions in that one stack. If however you would continue with your design as is shown in your post: Question 1: You could use a single subnet or separate subnets.  The thing is that MX'es won't fully participate in OSPF so you would need static routing everywhere to reach all the subnets behind each distribution stack.   Question 2: The ports will behave spanning-tree wise as belonging to the same 'switch' so you will have 2 links in blocking state.  But this could differ at every boot of the stack since the switch numbering will not always be consistent.  It is however important to split each mx over at least 2 switches so that downlink survives a single switch outage. ... View more

Philip he said in his post that channel util on 2.4 GHz is bad everywhere so yeah that's not optimal 😜 Cisco and Meraki both only use multi channel architectures.  No support for single channel architecture. ... View more

Hey there. Each MS switch (except MS390) even in a stack has it's own management IP which is configured on the switch status page on the left hand side.  When you click on the pencil button you have the ability to configure DHCP or Fixed IP for management of the switch.  In there you will find a VLAN field.  If you leave that field empty, the switch will default to the management VLAN that is configured in the switch -> switch settings page. So depending on your upstream trunk configuration you can have success or failure to get the switch online to the meraki dashboard. This management IP has NOTHING to do with the local IP the switch has for the local status page when you connect to the out of band management port. ... View more

Any inside info when this will be expanded to group policies? Or perhaps some Auto-objects/groups like "internet', "meraki-net1" through "meraki-net7" And of course service-objects, however I fear these will be deemed to much for complexity to implement. ... View more

Correct. Adaptive means that 802.11r is not announced via the RSN IE so non supporting clients will not trip over it. But clients that support adaptive will get the clue via an aironet IE and will negotiate 802.11r at association.   802.11k is always on. ... View more

I would limit the power output of your AP's to about 14 dBm.   About 802.11r it does not really provide much of an edge when using WPA2-PSK. Usually a full roam using PSK and the 4 way handshake takes around 50 to 80msec. The 802.11r part will take it down further but at the expense of the security issue and the potential for devices not supporting 802.11r and just refusing to join the SSID. However on a WPA2-Enterprise SSID a full authentication can take up more than a second depending on network situation and proximity of the radius server.  There 802.11r can be a true blessing. Enabling 802.11k is a no brainer.  All devices that support it will be able to receive the neighborlist and take advantage of that list to do less scanning and thus roaming faster. ... View more

Think of Meraki AP's as being Flexconnect Local switch. ... View more

I have an update on this matter.   Today I had to further check the QoS handling for a customer that does AutoVPN from different offices to a datacenter concentrator mode MX. These branches have both an internet connection and a MPLS connection that is able to accept pre-marked packets and stick them in four different queues. At the branch there is an MX84 running 14.40 in NAT mode and in the DC there is also an MX84 running 14.40 in concentrator mode. After some testing and using different DSCP values than normal for voice I could more easily make out the tagged and non tagged packets by my design in the packet captures. I made sure the traffic was tagged by the windows pc via GPO and tested it using jabber towards external phone.  That traffic passed through the datacenter. I first captured on the MS switching using a mirror port. And then I both captures on the LAN and WAN of the MX both via dashboard and by looping the WAN port of the MX through two external VLAN ports on the switch.  Because I had the feeling the dashboard capture does not always show the same results.   So the NAT mode MX does in fact copy the existing DSCP value of the packet to the outer IP header between both MX'es.  And QoS can be applied.  Even if there is no explicit rule for that traffic.  Default QoS markings is on though. The MX in the datacenter however does receive the downstream packets from the voice server tagged but it does NOT carry the DSCP value over to the outer IP header.  So this should be categorized as a bug.  The whole idea of doing SD-WAN over MPLS is so you could differentiate between flows even if they are tunneled and put them through the correct queues. ... View more

Oh I forgot one challenge!  These new Wi-Fi 6 AP's are so wide they don't fit inside the bracket anymore 🙂 ... View more

In a scenario like that be sure to always allow DHCP traffic towards the DHCP server as client asking for DHCP informs or simply renewing their lease will send using unicast directly to the DHCP server. Of course if this fails they will ultimately retry using broadcast DHCP discover but that's at the very end of the lease and not recommended to let it come that far. ... View more

I'm not familiar with those exact sku's. Normally the VMX licenses are LIC-VMX100#YR. ... View more

After the initial EAP packets the client will probably build a TLS tunnel between itself and NPS and that traffic starting from the change cipher spec should be opaque in your capture of the inside communication.   However after that exchange is completed you should see an access-accept packet from NPS destined to the AP with all needed AV pairs.  Can you verify the AP receives that packet? Wirelesslywired has a few captures as example but it's EAP-PEAP. https://drive.google.com/drive/folders/0B4-AWwD5siI1VFVTU01aV3QxWHc ... View more

Good to know. Btw this behavior is different from AP's.  There having no VLAN in the box is the norm since you usually leave the AP mgmt untagged on the switchport. ... View more

When you leave it as blank It will use the management VLAN under switch settings. Maybe that value is missing. And don’t worry about double tagging. If you do fill in a VLAN number and that VLAN number is the native VLAN on the uplink Port. It will send mgmt traffic untagged. ... View more

I also first learned Cisco through netacad. So I do know it’s hard to miss features which are common.  However you need to wrap your head around the whole cloudmgmt. Think of the management ip of a meraki switch as being purely out of band like a management Port of a switch living on it’s own VRF. And you can’t plug that mgmt Port into the switch itself. And that is why each stackmember has it’s own mgmt Ip which has nothing to do with the upstream transit VLAN.   I prefer using a separate VLAN directly terminated upstream.  But in your case you could change your /30 into a /29 and put both stackmembers mgmt in the same subnet as the stack IP. ... View more

Hey, I haven't read your explanation entirely but I get the main point.   You basically have two options in this kind of design. 1) You have a totally separate VLAN on the upstream router that only serves for the management of all your Meraki devices lan devices like switches and access points.  And then you have your transit VLAN between the router and your core switch.  In this case you will have a default gateway on the management of all your devices which is the router.  And you will also have a 0.0.0.0 route defined on your coreswitch pointing to the transit VLAN router IP as next hop. 2) You can have only 1 interface on the router which is the transit VLAN.  In this case your subnet used in the transit VLAN must be large enough to accomodate the routers IP, the core stack IP and all the management IP's of the core stack members.  Then all switches and access points downstream of the CORE will have another management VLAN where they are in and they point to the CORE as default gateway. ... View more

Hi, For the switching part you need to consider the kind of MS switches you have. The MS120/125 switches cannot classify traffic for QoS purposes and the higher end switches only can use L4 ports. So the first consideration is the App and how it behaves.  What ports it uses. An alternative is when you use dot1X to get trusted pc's into a certain VLAN you could trust incoming DSCP markings on that VLAN.  And then have a group policy that allows DSCP tagging on packets from the voice App. ... View more

Yeah but I mean downwards pointing antenna. Normally we do staggered when it's open so there is some distance between the AP's.  But if the aisles diminish the signal enough it's not a real requirement. But as said before, try simulating the AP at the correct height with the antenna pointing down and see if the signal reaches all the way to the end of the aisle. If that doesn't work but the aisles weaken the signal enough, you could try in the middle pointing down and if that is not enough try 1/3 closer to the wall and then use the AP's in the open area for roaming. That's one of the big plusses of having software like ekahau, you can try all 3 scenario's and see which is best. ... View more

I see you have Ekahau and that the ceiling height is much higher than the 5 meter originally given. I'd encourage you to first experiment with the MA-ANT-25 pointing straight down at 1/3rd of an aisle and see if it covers the entire aisle or not.  I do recommend using the offset feature to subtract some 5 dB from your "measured" value. Then you could do a staggered pattern in your aisles 1/3rd, 2/3rds. ... View more

Hehe,  when you say campground in a WiFi forum, for some reason I seem to think about this: If you get it.. please say so 🙂   ... View more

@PhilipDAth , the MX should one thing extra than mark DSCP tags and that is putting it in the correct outbound queue (high/med/low) but it would essentially be tail drop in that queue if it is full. At least the configuration/documentation says so.   And about the policing, you can limit the bandwidth for a traffic type but I'm not sure if for the MX this is also a per flow limit or a total policing limit like you would do on a Cisco ISR.   I also assumed the DSCP tag would be copied to the outer IP header.  Hmm, I'll have to do a test setup with a switch in front of it to verify this.   If it doesn't then I'd be really disappointed.   @whistleblower the reason for the 7'ths is simply because they wanted each queue to be double the previous one.  So low queue = 1, mid = 2 and high = 4.  Add them up and you arrive at 7. ... View more