Thanks!  🙂 ... View more

Any chance you could link the other thread - for others arriving here?   TIA! ... View more

The concern I'd have here is that you'd end up with two totally different APs;   a 2.4 GHz AP, on one side of the wall and a 5 GHz AP on the other.  If your client mix is OK with this, that's fine. I'm thinking maybe you planned on splitting the pigtails from, say, an MA-ANT-25 across the two radios?   On the face of it, that would give you one antenna for each radio, both inside and outside..?   That really should be avoided;  the recommended dual antenna chains connected to the same radio is what provides multiple spatial streams (for newer clients) and/or antenna diversity [to mitigate multi-path fade] (for older clients).  These rely on both antennas having the same coverage area and the radio assumes that, in its operation.  This is mentioned in the antenna installation guide. ... View more

The MS355 and MS450 have been built for just that use-case;   with 40G uplinks between the two layers. ... View more

I stumbled on this post, looking for something else... Keen to understand how you got on: A)  Because I wasn't sure what you meant by horizontal and vertical ports  (MR74 has a pair of antenna ports on the top (one radio) and a pair on the bottom (other radio). B)  It sounded like what you might be doing was the opposite of ideal...   If you have an antenna, such as an MA-ANT-25, then its two pigtails should be connected to the same radio (both plugged into the same side of the MR74).   A second one would plug into the two ports on the opposite side of the AP.   If this is what you've done and I've misinterpreted, my apologies... ... View more

You might also find it more cost-effective (depending on the kind of port density of 1/10G you need) to aggregate those lower-capacity links first - maybe with an MS425, which supports both 1G and 10G SFP/SFP+ - uplinked to the MS450 using 40G..?   Apart from anything, using up a port on a 1.36 Tbps switch for a 1 Gbps link offends something deep inside my soul...   🙂 ... View more

I reckon that the best way of selling anything to any business or organization is to fundamentally understand what they exist to deliver and how technology and information can help them do that more quickly, more efficiently and with better outcomes for their customers, their staff and their owners / stakeholders.  In other words - give them what they really need, by way of wireless connectivity, don't be a slave to anybody or organization who tries to suggest that one size fits all.  Your latest car magazine might tell you 'this Ferrari is the best car in the world', but if what you need to do is carry eight kids to the supermarket, it wouldn't be your choice.   New customers keep buying Meraki.   Existing Meraki customers keep renewing their licences... ... View more

You need to process your trial through to completion.   The best approach would be to contact the Meraki sales team, through which you initiated the trial and they will guide you through your choices.   These are generally to either purchase the components trialled (usually through bill-only purchase order) or 'return' them.  Often this is via the returns web-page where you initiated the trial (the link to this will be in an email, you will have received).  Obviously, if it's just a license, then you wouldn't actually 'return' it - but it would be unusual just to have a license, for a trial, so your account team is definitely the best route. ... View more

While I do work for Meraki, I have no specific answer to this, at this time - but I would take a look at the kind of performance available from the likes of MX67/68, within the MX Sizing Guide - and wonder whether you could actually gain anything from the extra bandwidth that WiFi6 might offer..?   If it were me, I'd be choosing my MX and my preferred MR access point separately.  This also allows you to put the AP in the best place for coverage, leaving your MX safely in a rack or similar - plus you could deploy more than one AP, to have a fully roaming WLAN, should you need to extend your coverage. ... View more

Why would you set email (a non-real-time application, in the vast majority of environments) to high priority?    It might be a very important application, but if an email is delayed in delivery, by just a few seconds, it makes no difference.   Emails with significant attachments will slow down your real-time applications significantly.   Maybe make it low priority and apply a bandwidth limit? ... View more

The Umbrella integration for MX is available, in Beta, now - with all the cautions that entails.   You will need to be running MX r15 to access it, will need Advanced Security license in your Organization and will need Support to enable it for you.    You will, of course, require an appropriate Umbrella subscription too.   More information available here:  https://documentation.meraki.com/MR/Other_Topics/Integrating_Cisco_Umbrella_with_Meraki_Networks I don't have a date at which this would become a 'generally available' feature, but I would not expect it to be imminent. ... View more

I think you have your MX Cellular models mixed up.    MX67C has no built-in WiFi capability (either 2.4 or 5 GHz).   MX67W has Wi-Fi, but no Cellular.   Both Wi-Fi and Cellular are available from the MX68CW   (C for Cellular, W for Wi-Fi)   Note:  on MX68CW the two antennas attached to the unit are used for both Cellular and WiFi.  Because of rules around W-Fi, these are not inter-changeable - you can't unscrew and replace them, like you can the Cellular-only antennas on the MX67C ... View more

I believe that 'Alert when a switch port is connected / disconnected' is part of the Meraki cloud controller poprietary MIB.    See Traps in here:  https://documentation.meraki.com/zGeneral_Administration/Monitoring_and_Reporting/SNMP_Overview_and_Configuration#SNMP_Traps   The MIB itself is available within Dashboard:  Organization > Configure > Settings, under SNMP   Does your alert have to be via SNMP?   Can you not use Network-wide > Configure > Alerts?    Under switch, when a port type goes down for selected period - this generates alert emails - or alerts via Webhooks, if you can use that. ... View more

This was highlighted previously as being a result of enabling the capability - and I believe other vendors show a similar impact on performance, when performing SSL decrypt. ... View more

Try rebooting the MX.  My guess is that what you're seeing would be expected behaviour. ... View more

Can I suggest you raise a case with Support for this? ... View more

As far as I'm aware all currently shipping switches adhere to the QoS features detailed here:   https://documentation.meraki.com/MS/Other_Topics/MS_Switch_Quality_of_Service_Defined   MS120 switches (current entry-level) have less granular L4 classification capabilities, but this is described in that document.   Can you be more precise on your 'looks like' comment..? ... View more

OK - it would probably have helped if you included some information on your diagram, as to how VLANs are being used on the switches, to interconnect different components and ports (I'm still not sure why you have MX LAN ports linking to the upstream switches), but I think I understand your latest question:   basically the upstream PA firewall is changing the public IP address which the MX would be using over WAN1, as part of its own failover mechanism.    This should work ultimately, I imagine, provided you have appropriate rules in the upstream firewall to allow the comunications from the MX to Dashboard and other Meraki cloud resources, via each public IP, but it will take time - and might even require an MX reboot.   By default, even discovering that the upstream primary path isn't providing Internet connectivity will take five minutes:   https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Connection_Monitoring_for_WAN_Failover   The MX then has to re-register with Dashboard, using the new public IP address.   How long did you leave it - and did you try rebooting the MX(s), as part of the diagnostics?   Basically - MX failover isn't designed to be based upon the MX having the public IP of a WAN port changed;  it's designed to make use of the fact that it has two ISP links, each with its own public IP (MX then checks in with Dashbord using both). ... View more

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