About GreenMan

GreenMan

No - @PhilipDAth describes the capabilities accurately; connectivity via one SIM or the other, not both. I believe 5CA is more like the cellular version of using multiple 20 MHz-wide channels in WiFI (40 MHZ, 80 MHz etc.) to achieve higher throughput. https://www.4gmobiletech.com/carrier-aggregation

GreenMan

If you configure a switch port as access, rather than trunk, it automatically sets the equivalent of portfast: https://documentation.meraki.com/MS/Deployment_Guides/Advanced_MS_Setup_Guide#Automatic_edge_port I would concur with running DHCP on your MX, if you have one. If your chosen MX is sized appropriately, as per the Sizing Guide, DHCP performance should be very good: https://meraki.cisco.com/product-collateral/mx-sizing-guide/

GreenMan

@antonis_sp is right - this is absolutely not the way to do it. The ANT-27 is fine, in general, but you'd need two of them and you need to point them in the same direction.

GreenMan

As you have to purchase Meraki licensing, to work with Meraki devices at all - and the licensing, provides you with the Dashboard and all the infrastructure that hosts it - and Dashboard has a built-in 'API Gateway', with which all your Meraki devices interact by default... I'm not sure why you'd want to build you own, even if you could? (Note; Meraki devices are essentially managed solely via our cloud infrastructure, in order to keep the platform secure) The Dashboard natively provides (Organization > Summary) reports via the GUI, which can be modified, to a certain degree and scheduled. If you want ultimate flexibility with data reporting, such information can virtually all be accessed by combining different combinations of endpoints pulled via the Dashboard API, which you can then manipulate freely at your end.

GreenMan

Personally I would aggregate access switches into a pair of 'core' switches, built as a stack, first. The downlinks can then be set up as LAGs. You then designate the Core stack as STP root and link each MX directly to both switches in the stack and allow the Core stack to block one uplink to each MX. No link directly between the MXs.

GreenMan

If, by this enquiry, you mean: "Can my Meraki devices interact, via (NB) API, directly with a controller other than the Meraki Dashboard?" No - Meraki devices work via the Dashboard. Given that the Dashboard itself has a wide range of API inputs and outputs however, it it possible to understand dynamically what's going on with a device (via Dashboard and the REST API) and then implement a related change to that device (via Dashboard and the REST API). Does that help?

GreenMan

It's important to understand who owns the licensing here, currently - licences are not transferrable ( see the End User Agreement linked here: https://meraki.cisco.com/support/#policies:eca ) If the customer already owns the licensing then either pass on Admin control of the existing Organization - as per @BrandonS ' suggestion, or have Meraki Support 'move' licences from the existing to a target destination, by raising a Support case. Bear in mind that the latter option requires that the Admin raising the case with support have full permissions in both Organizations: https://documentation.meraki.com/General_Administration/Licensing/How_to_Request_a_License_Transfer

GreenMan

Devices enrolled into Systems Manager appear (for MDM purposes) primarily under Systems Manager > Monitor > Devices, within the relevant SM network in your Dashboard. Your device would only appear under Network-wide > Clients if it's a Combined network and it is physically plugged into a Meraki switch managed in the same Network. The latter functionality would essentially have no relationhip to SM specifically.

GreenMan

I don't know of a way to do precisely what you're asking, by way of tagging in SM. About the most effective method I've found for encouraging staff to use the right SSID is simply to make the recommended SSID better suited to their needs, e.g: Set the Guest SSID to require them to login and re-login every few hours Apply more rigorous traffic shaping / firewall rules to guest clients Make the recommended SSID as seamless a signon experience as possible (use Trusted Access, for example?) - and loosen traffic shaping constraints.

GreenMan

It sounds like they are probably referring to the processing power of your firewall, rather than any specific compatibility. Your new APs are very likely capable of carrying significantly more traffic than any they are replacing. How much of that extra capacity your wifi client base can realistically make use of will depend on your device mix and how they are used (what apps etc). You have to think that those devices will become more capable, over the years though, as they're replaced. Moreover, you may well be (more) constrained by your available Internet uplink, beyond your firewall. If your link is just 100 Mbps or so, how will a Gig-capable firewall help? That having been said, your Internet pipe will probably be upgraded, within the lifespan of your APs and a replacement firewall anyway. I try to think about your whole traffi-flows and any bottlenecks along the way. Bear in mind too that you needn't necessarily upgrade the existing Fortigate with a new Fortigate; what about an MX? 😏

GreenMan

Yeah - I don't believe that combination is possible. You would like to use source-based default routes, but they can only be defined via another MX (an AutoVPN tunnel) or a LAN port, not a non-Meraki VPN tunnel, as here. Is there a reason why you can't run the DHCP on the MX, as I suggested? It's the closest you will get to the traffic pattern you want, right now, I think.

GreenMan

My experience is within Europe, but I'm pretty sure that the US mandates the implementation of DFS on a range of 5 GHz channels, too. If compliant APs (including Meraki MR) hear radar - or something 'in the air' that looks like radar, while running on one of those channels - they have to immediately change channels and will add a DFS event to the event log. I'd be very surprised if you are being impacted by airport radar, without this manifesting as many DFS events and the majority of your APs ending up on non-DFS channels. Your experience if configuring your APs to non-DFS only is likely to depend heavily on how busy your RF environment is, generally.

GreenMan

Where is the DHCP server, that is serving VLAN 30? I'm guesssing that's at the far end of the non-Meraki tunnel? It sounds like you have a default route 0.0.0.0/0 configured as the Private subnet in your non-Meraki VPN. (for VLAN 10) and that you have VLAN 20 = VPN mode disabled. I think you will need to also configure VLAN 30 = VPN mode disabled, but provide DHCP for that VLAN locally on the MX.

GreenMan

There's one exception to this rule, that I'm aware of and it relates just to the original virtual MX 'devices' (VMX100 in Azure, AWS etc.) The licences for these are, in effect, also the devices - and you can no longer buy them (they are End of Sale, replaced by more capable and flexible VMX-S/M/L). When your co-termination date arrives, therefore, you cannot include them in a Dashboard renewal. If you do just renew - even if you include (say) a VMX-M (functionally equivalent, scale-wise, to VMX100) - your Dashboard will show: VMX100 License limit 0 Current device count 1 (or more) and you will be non-compliant, licensing-wise - and thus, into your 30-day grace period. If you have VMX100s, you need to plan to deploy new VMXs (small, medium or large, cloud-platform dependent) and a migration of remote peers from one to the other, in advance of your co-term renewal.

GreenMan

As Connor suggested - use packet capture to understand what's going on, first. My experience is that, in many CG-NAT cases, you can work around by reconfiguring your VPN Hubs to use Manual NAT traversal. Security & SD-WAN > Configure > Site-to-site VPN change from NAT traversal = Automatic to Manual : port forwarding, Specify a particular public IP and associated UDP port number for the VPN service to reside on. The upstream firewall, behind which the Hub NATs, will need to be configured to match (to forward this traffic to the MX by its real IP, port unchanged). I’d recommend choosing a port between 1025 and 32768, but avoiding 4500.

GreenMan

Depending on the specific MX model and depending on where the device was originally shipped to, you may get into challenges with RF-related regulatory stuff. Cellular-equipped devices, such as MX--C have specific SKUs for US, versus rest of the world. My understanding is you shouldn't use the wrong SKU in the wrong place. At a practical level I suspect it is most likely to manifest as APs ending up in Worldwide Safe Mode, so you'll want to read this documentation carefully https://documentation.meraki.com/MR/Radio_Settings/MR_Wireless_Regulatory_Domains Transferring devices between Organizations is fairly straightforward and you can do it yourself. Licences, on the other hand, generally need moving by Meraki Support: https://documentation.meraki.com/General_Administration/Inventory_and_Devices/Moving_Devices_between_Organizations

GreenMan

I find customers with a lot of sites (the sort of scale you describe for yourself) find the power of Templates a bit scary; yes, it's great that you can update a setting on that many sites, very, very quickly - but, as Spiderman rightly said; with great power comes great responsibility. 😁 Remember though that all changes are visible in the Organization > Change log - so could be just as quick to back out at the same scale/rate (maybe not so nice for firmware updates). In such instances, maybe consider having 'a few' Templates, each of a scale that makes sense to you. Template 1 - maybe with just my Lab Network bound - for initial testing Template 2 - Ten guinea pig sites, I roll change out to second Template 3 - 50 sites for further reassurance Templates 4, 5, 6, 7, 8, 9 - each with max 100 bound sites, which I can phase the change through A change in 10 GUIs still takes time, but a lot less than doing the same to 700 sites individually! It's also maybe simpler than API if you don't have in-house skills for that (or can't readily get them in from a Cisco partner). You can have as many Templates as you like, so cut this to suit your needs (and bearing in mind Ryan's excellent advice - in particular that the Dashboard API is there to provide ultimate flexibility, if you need it.

GreenMan

A high level view of licensing status is available for multiple Organizations, from the MSP Portal, which becomes available to you (under Organizations, top left of the Dashboard) when your Admin profile has permissions in multiple Organizations. If you click on the Organizations tab in the mai table (the right-most of the three), you will see each Org listed and the License Status and License Expiration (for co-term Orgs) are available columns in the table. If they don't show up immediately, you can add them by clicking the + sign, top right of the table.

GreenMan

When new hardware products are released, it's usual for them to only support the newest releases of firmware - and this is the case with the MX75 (and the MX85, 95, 105, released at the same time). Release 16 of firmware is therefore considered Stable specifically for those platforms. You may see upgrades automatically scheduled for your MX75 to newer versions of 16.x as they become available (these would also be Stable, for your MX75) but should not see similar for 17.x until it at least becomes available as a Release Candidate, in a future iteration. MX75 will not run 15.xx firmware More info on such dependencies is available here: https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Product_Firmware_Version_Restrictions

GreenMan · ‎11-02-2021

Most customers really don't need spatial re-use of links, for the extra bandwidth - or can achieve spacial reuse through LACP between stacks. So if customers don't really need something, why make a product more complex by including it? While MX may not participate in (R)STP, it happily passes BPDUs, allowing you to build topologie with loops, for resilience. The control of the loops is based upon your STP root bridge, in the usual way. If Cisco customers do need these extra facilities, Catalyst will work well for them.

GreenMan · ‎11-02-2021

For individual users, the hardware equivalent would be the Z3 or Z3C - or possibly a small MX (MX64?) https://meraki.cisco.com/en-uk/product/security-sd-wan/teleworker/z3/ https://meraki.cisco.com/en-uk/product/security-sd-wan/teleworker/z3c/ These are also small enough to put in a bag and take with you, if you're a frequent traveller. You'd choose an MX if you want the extra protections offered by the Advanced Security license: https://meraki.cisco.com/en-uk/product/security-sd-wan/licences/advanced-security-license/

GreenMan · ‎10-12-2021

Note that the current crop of APs support multi-Gig (mGig) on their single LAN interface for the most part, so; 100/1000/2.5 - or even 5 Gbps, in the case of MR56. Uplink support reflects the capabilities of the installed radios and cumulative wireless data rate. Review the specific datasheets for full details. Of course, you need mGig capable switching too, of which there are a number of choices, within our MS switch ranges.

GreenMan · ‎09-14-2021

Bear in mind, you should only really use Layer-3 roming when your deploying a large network, with contiguous wifi coverage, where the clients would normally need to be dropped into different VLANs in different places, to aid with scaling. In my experience there are very few sites that necessitate this. Most wifi networks work just fine (actually better, as it's simpler) using Layer-2 roaming; you ensure that the client is always dropped into the same VLAN, when moving between APs.

GreenMan · ‎09-13-2021

You can move one switch to a different Network and upgrade it there.

GreenMan · ‎09-10-2021

A few initial thoughts, from reading your post: 1) Average utilisation over (say) a day can often be misleading. It's no good your infrastructure carrying next to nothing between 4PM and 8AM, if it's totally swamped for the rest of the time - but if the stats you look at are only averaged over the day, you very likely won't see the problem. You need to look at more granular stats during the periods that people are having the issue. 2) 90 - 100% utilisation of an MX for any length of time is likely to cause problems for many of the applications flowing through that MX. Maybe look at waht traffic is required to run through the MX - asssuming your inter-VLAN traffic is all L3 routed on the MX, what are the major traffic contributors, application and client-wise? Could they, for instance, be located in the same VLAN, without overly damaging your security? 3) In regard to 3, I would certainly look at what your cameras & NVR etc. are communicating with, and how that would be handled by your LAN setup If you haven't already, don't be afraid to ask for help & advice from Meraki Support with this

GreenMan

Community Record

Badges