No, the VLAN should be set to the VLAN that the workstation should be on if it wasn't connected through the phone and the voice VLAN should be set to the voice VLAN.  The phone (or at least every VoIP phone I've ever dealt with) will pass through untagged traffic to the PC port on the phone.     If you want the phone and the workstation to be on the same VLAN, then you should leave the voice VLAN blank (which these phones don't seem to like) so all the traffic is untagged.  From your original post, it sounds like you already have separate voice and workstation VLANs, you just weren't using the voice VLAN feature. ... View more

Configuring a port for access with a voice VLAN essentially configures it as a trunk port with the access VLAN as the native VLAN and the voice VLAN as an allowed VLAN.  It also advertises the voice VLAN in LLDP.  Phones are supposed to listen for that, then do DHCP with tagged packets on the voice VLAN instead of untagged packets on the native VLAN.  That way you can have your workstations on the native VLAN and the phones on the voice VLAN without dedicated phone ports configured.  Here's the obligatory Meraki documentation:   https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Configuring_the_MS_Access_Switch_for_Standard_VoIP_Deployments   It sounds like the latest firmware of the phones isn't properly handling the case where LLDP doesn't give it a voice VLAN.  They should just use the native VLAN in that case.  Disabling LLDP causes them to not see any LLDP and not try whatever incorrect behavior they are doing when the see LLDP.  Hopefully, configuring the voice VLAN on the switch so LLDP has it defined will make them behave in a more reasonable way.  (And it's probably what you want in the long run anyway.)   If that does fix it, make sure you pass that on to their support people to help them find the bug in their firmware. ... View more

Do you have a voice VLAN set on those ports?  The voice VLAN is given out via LLDP, so the phone may be seeing it and trying (failing) to tag traffic on that VLAN.  Removing the voice VLAN from the port will remove it from the LLDP advertisement so the phones will use the untagged VLAN.  If it isn't there, maybe changing the untagged VLAN and putting the VLAN you want the phones to use in the voice VLAN field will make them properly tag the packets and it will work.  Either way, this will give you and their support team more data points. ... View more

Do the Network Policy Server logs show anything?  They are in an unwieldy XML format, but they will tell you 1) if the request made it to the server and 2) what the NPS server's response was.  The log files default to %systemroot%\System32\LogFiles but you can change the location from the Accounting tab in the NPS MMC snapin.  The files are rotated daily with the date in the filename, so make sure you grab the right one. ... View more

It is available now if you are on the latest MR GA firmware and the beta MS firmware. https://documentation.meraki.com/MS/Access_Control/SecureConnect ... View more

To add to the links Philip posted, the MR firmware required is the new GA version and the MS firmware required is in beta, so it should work now if you can run the beta MS firmware. ... View more

I have option 2 working.  Like you, I found it a better fit for the existing network design in situations where there is an existing robust MPLS WAN.  The key is corresponding conditional routes on the MX at both ends.    - MX A has a route to site B VLANS through MX B if it can ping MX B  - MX B has a route to site A VLANS (or 0.0.0.0) through MX A if it can ping MX A  - If the ping fails, the VPN also has that route, but with a lower priority, so the VPN takes over   Most of my sites already had OSPF in place, so most of these are actually "While host responds" not "While next hop responds" and they are pinging the OSPF gateway at the remote site.  The hub site injects the default route into OSPF and the remote sites have a high metric default route to the MX, so the OSPF default takes priority.  If the MPLS circuit fails, OSPF loses that route and the default goes to the MX, where the VPN takes over.  At one site, the backup is via cable modem, not cell, so it will also advertise the default route, but with a worse metric than the hub site.  Our MPLS is over a point-to-multipoint, so any sites that can get to that site can share that cable modem.   My preference is to have a Cradlepoint or other LTE gateway device (like the Meraki MG if you want to stay on brand) connected to the WAN, rather than the built-in USB LTE backup.  It works much better and the MX doesn't complain.  If I don't have that, I have the WAN also connected back through a separate VLAN on the MPLS circuit so the MX can get to the dashboard, but I don't route any traffic that way.    This let me add the MX for LTE/cable modem backup without disrupting my existing network. ... View more

This is now a drop-down option in the client search, with a new magic query: clientType:client-vpn ... View more

Source based routing is now in beta with the 15.23 firmware.  It will require a support ticket to turn on the UI in the dashboard. ... View more

@TimBisel wrote: That is actually what I was going to move to after thinking about it more. I think Meraki needs a "Experienced" mode that does less of this Apple style "We know what you want better than you" stuff and turn off some of these automatic things so we don't need to have work around for turning off some of the "simplicity" features. I think the desire for "Experienced" mode ranks right up there with IPv6 and NoNAT on the desired feature list. ... View more

@TimBisel wrote: Ok, you are right so far, but two things.   1.What am I missing on why the MX is still reachable?   I believe this is because the connections to the MX are handled by the "input" firewall rules and the traffic to devices in the other VLAN are handled by the "forward" firewall rules.  Many firewall devices have two separate sets of rules, one for traffic destined for the device (input) and one destined for devices on the other side (forward).  Because the pings that are destined for the MX itself, the packets never go through the "forward" rules, even if they are for a different interface than the one they come in on.       In the case of the Meraki, the "input" rules seem to be governed by the "Security appliance services" rules for the outside interface and things like the "Local device status page" for the inside interfaces.   ... View more

You might look at something like this: https://www.bhlpower.com/index.cfm?page=products&productid=1   It is similar to what others have suggested, but you can mount the patch panel in facing out and the switch facing up, plus it will hold a rack mount UPS. ... View more

I get the same behavior, it only allows 10 GbE SFP+ SR transceivers, but it allows more of the other 10 GbE SFP+ transceivers. It does allow me to type in 32 on the 10 GbE SFP+ SR transceiver line, just not use the arrows.   I didn't try submitting it with the typed in 32, so I don't know if form validation will stop it.  If you submit the form should end up with a sales rep, so you can have them adjust it as needed before you order.  Also, off brand optics work fine, so any pricing you find on the Internet for the optics is probably better. ... View more

And if i used Meraki switch as Access switch then they need to form ether channel with Cisco 3850.   Moreover can you recommend Meraki Model which can support more than 12 port  , 10 G SPF + capability.  You should have no problem connecting to the Cisco 3850.  The Meraki and Cisco both support LACP for port aggregation.  You may have to specify lacp on the Cisco, I can't remember if it defaults to that or the Cisco proprietary "Fast Etherchannel".  As @akan33 mentioned, you will need to make sure the Cisco is using RSTP, not PVST, for spanning tree.  Also, Cisco's default to native VLAN 1 for trunked interfaces, while the Meraki's are perfectly happy with no native VLAN, so make sure your trunk settings match.   For higher density, look at the MS425 switches for 16 or 32 SFP+ ports or the new MS355 X2 switches that @BrandonS linked to for mGig copper ports. ... View more

One of my networks has been scheduled by Meraki to get 14.35 but for another of my networks it isn't an option. Both networks show the changelog if I click 'Next version' from the 14.34 changelog.     It may have to do with tickets that were opened in that network.  The second changelog entry covers one of the tickets I had open for the network that is scheduled.   I also noticed in the Other section that they are removing the automatic four hour reboot with no uplink.  It would be nice if this were a configurable option.  For most of our devices this will be good, but we have some remote devices that will now have to be manually power cycled if the uplink changes. ... View more

We found a great rack mount shelf for the MX65 here: https://www.rackmount.it/products/cisrack/rm-ci-t5.html   Make sure you get the V2, it has a small fiber optic cable so you can see the status light from the "front".   ... View more