About GreenMan

GreenMan · ‎10-24-2019

Yes - the Alerts function in Dashboard is a one-time event

GreenMan · ‎10-23-2019

You could poll for status information periodically (e.g. every 10 minutes) using the Dashboard API, to give you ongoing information. Or (more old school) use SNMP monitoring.

GreenMan · ‎10-02-2019

Would you be using the Legacy version of Systems Manager, @ElderPhllaps ? That only allows for the creation of a single security policy, as per https://documentation.meraki.com/SM/Tags_and_Policies/Security_Policies_in_Systems_Manager#Creating_Security_Policies

GreenMan · ‎09-20-2019

Basically I think you need to follow this one through with the case on our Support team...

GreenMan · ‎09-19-2019

'Device type' is an Auto tag and covers the following; Android devices AppleTV devices Chrome devices iOS devices Mac devices Windows devices Take a look at this KB article

GreenMan · ‎09-18-2019

Adding to NolanHerring's thoughts; as we've seen with previous generations of new WiFi technology, the gains will be accrued, over time, as client devices are replaced: new WiFi6 compatible devices will directly see the benefits themselves - and non-WiF6 devices will be rewarded with extra airtime, freed up by the newer devices transferring their data more quickly. It's also likely that WiFi6 will offer greater capacity. Given that many WiFi solutions are replaced simply to support greater numbers of clients and/or more intensive applications, MR55 should be more scaleable, long-term. Also remember that buying newer tech always has another potential longevity advantage. MR55 will, almost inevitably, be fully supported, beyond the End of Life of MR52/3. (having said that - remember Meraki supports products for 7 years beyond End of Sale anywau - longer than anyone else in the industry, AFAIK)

GreenMan · ‎09-18-2019

Thanks! 🙂

GreenMan · ‎09-18-2019

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

GreenMan · ‎09-16-2019

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.

GreenMan · ‎09-16-2019

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

GreenMan · ‎09-16-2019

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...

GreenMan · ‎09-13-2019

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... 🙂

GreenMan · ‎09-13-2019

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...

GreenMan · ‎09-13-2019

The MS450 is equipped with QSFP+ and QSFP28 ports. These are physically incompatible with 1G SFPs and 10G SFP+ modules (the holes are different shapes and sizes...)

GreenMan · ‎09-10-2019

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.

GreenMan · ‎09-10-2019

Keeping up with our pace of development, in API space, can be difficult. Try keeping an eye out, here: https://developer.cisco.com/meraki/whats-new/

GreenMan · ‎07-23-2019

I'd include UDP in your flow preference rule, too

GreenMan · ‎07-23-2019

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.

GreenMan · ‎07-15-2019

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?

GreenMan · ‎07-12-2019

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.

GreenMan · ‎07-04-2019

Agree with other commenters on this. Have a look here: https://documentation.meraki.com/MX/NAT_and_Port_Forwarding/Port_Forwarding_and_NAT_Rules_on_the_MX

GreenMan · ‎07-04-2019

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

GreenMan · ‎07-04-2019

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.

GreenMan · ‎05-17-2019

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.

GreenMan · ‎05-03-2019

If this is not a new Organization, and for which this Summary Report has previously provided useful information, I would suggest you contact Support about what you are seeing.

GreenMan

Community Record

Badges