It would indeed be a product of interest to many.   All I would say, on this is:  beware the distance between camera and object and the quality you require of the resulting image.  Place a fisheye camera outside - which is already 'robbing Peter to pay Paul', in terms of quality : field of view - and you likely have an increased risk, particularly with the camera deployed at height, of simply being too far away from the objects/people you want to see. ... View more

Why can't you just use your two WAN ports on the MX, to link to the VLAN or VLANs which are Internet-facing, on the upstream switches?   Both of these WAN ports can be in the same subnet, if they really need to be - I have had this working on my MX, as shown below. ... View more

Hi Jake - you should really raise a case with Meraki Support, who will have the time and Dashboard visibility to dig into the detail with you. (Your licensing allows you 365-day 24x7 access to Meraki Support, remember!) Choose your preferred path to support via Help > get help, top right hand side of the Dashboard. Making a telephone call would probably be best. ... View more

Yes - I've come across similar, with store numbers, in retail chains.   I'm never a fan of doing your IP addressing based upon anything like that.  IP addressing wasn't designed for it and you often end up 'standardising' on something that then ends up with anything > 254 being non-standard.  A standard that works only some of the time is worse than knowing you have no standard - and using an IPAM tool - IMHO. ... View more

Correct, Blake - except you CAN stack MS210 <-> MS225:   https://documentation.meraki.com/MS/Installation_Guides/MS225_Series_Installation_Guide#Bringing_your_Stack_Online ... View more

I'm with kYutobi  on this one;   provided you're not going to readily run out of IP addresses, then use /24 subnets;   they can never be considered too big, as broadcast domains    and just because they're really easy to work with, with the third octet letting you see, very simply, whether two addresses are really in the same subnet. These days you'd probably get away with /23 or even /22, but as soon as you started getting some kind of intermittent performance type issues, there'd be that nagging doubt as to whether broadcast/L2 multicast levels might be coming into play, which take time to allay.   One exception to this, in a big network, would be if you ever need 'transit VLANs' or similar, in which case I'd go for /29.   /30 is always tempting, in those circumstances, but if you ever wanted to insert a device between - say for management, monitoring or traffic manipulation purposes - you'd be stuffed,  but /29 is still pretty address-efficient. ... View more

It sounds to me like it might be easier just to do all your inter-VLAN routing on your MX and have your switch(es) just switching at layer-2..?    If all the servers being accessed are remote anyway, then all the traffic must transit the MX, so there's no real performance gain from routing on your switch.  If this makes sense, then connect the MS and MX using a trunk, with just the VLANs that you want to be accessible from your switch(es) allowed, then add all the routable VLANs on the MX that you need (Security & SD-WAN > Configure > Addressing and VLANs).   Note that MX doesn't support LACP, nor does it participate in Spanning Tree, so if you create a physical loop, in order to create resilience, you'll be relying on the switch(es) to resolve it. ... View more

It's not possible to do this, in the same way as the new alerting for Web app health (configured within MI).   Uplink status change within Network-wide > Configure > Alerts is still the best tool in Dashboard itself. What I'd really recommend though, if you're looking for more granularity than simply Up/Down - and/or you're interested in WAN2 (and who isn't?)  is looking at this fairly recent additional API call:   'Return the uplink loss and latency for every MX in the organization from 2 - 7 minutes ago' Details are available under the Organizations heading within Help > API docs in Dashboard. ... View more

I haven't, but I'm not sure what customers of mine, if any, have this use-case. Can anyone here add anything further? Are you seeing specific issues Adoos, or are you in planning phase? ... View more

Note that, in Supervised mode, the MDM Admin has control over most of the managed devices' functions.   Most employees will be unhappy to give up this level of control over their own devices (I certainly wouldn't allow it, personally).   Do you have Meraki networking devices and, if so, which?  (MR Access Points?   MX Security Appliance?) ... View more

Hi Brenda - I just wanted to reinforce @PhilipDAth 's cautions;   BGP is only used to exchange routes in and out of Meraki AutoVPN (e.g. at a Data Centre) - you couldn't, for example, use it to peer with MPLS CPE routers, to push all your branch subnets into the MPLS cloud from each branch.   While we're on that subject, OSPF could also be used for the same use-case as BGP, but the exchange is one-way only (branch subnets into the DC).  OSPF has been available for ages, in Stable firmware.   Note too that, while it is indeed a Beta feature and you do have to call the Support team to enable it, I wouldn't myself describe BGP as closed, these days;  Support will happily enable it for you, once they've had a little look at your general setup and with appropriate cautions.  With the move of r14 firmware to Stable Release Candidate status, I would recommend that this version be used for any BGP setups.   Policy Routing relates only to traffic hitting MX WAN/Internet ports (it's part of the SD-WAN functionality).   You can't policy route traffic between different LAN ports. ... View more

A couple of other things to add to the good points made already:   Excepting LTE capabilities (via dongle or, in the case of relatively recently released MX67C and MX68CW models, direct SIM) MXs connect using Ethernet connections only - mainly 'RJ-45' copper, but fibre options on 'larger' models.   Many routers traditionally offer flexibility for different link connection types  (e.g. ADSL, serial, ATM etc.)   Currently, if you pass traffic out of an MX WAN interface OUTSIDE a VPN tunnel (unencrypted) the source IP address will be source NATed to the IP address assigned to that interface.  This would be expected behaviour of a security appliance.   A router, by default, would leave the IP addressing native.   NB - Meraki is working to make the router's 'no-NAT' approach an option for the future. ... View more

For sessions initiated from the one-armed Hub, initially the Concentrator MX chooses one of it's two available tunnels to the relevant spoke fairly arbitrarily  (it's actually round-robin).   The Spoke MX then chooses the tunnel for the reply packets relating to this session, based on its own configured performance and policy SD-WAN rules.   Once the Hub MX sees the tunnel preferred by the Spoke, it will flip subsequent traffic, for that session, to match the Spoke's preferred tunnel. ... View more

Indeed;   Chrome or Firefox tend to be far more reliable, with certain areas of the Dashboard. ... View more

I think you need to raise a Support case for this. ... View more