About GreenMan

GreenMan

Most WiFi users will find that the 2.4 GHz band is much busier than 5 GHz. If this is the case, it will be better all around, for those clients which can use either 5 GHz or 2.4 GHz to use the former, instead of the latter. Dual band leaves the decision up to the client, as to what it prefers. Sometimes clients left entirely to their own devices make 'selfish' choices to join 2.4 GHz, perhaps because it has slightly higher signal strength (the frequency generally allows it to penetrate better). The problem is they often take no account of the fact that that band might be overloaded. Hence band steering encourages dual-band clients to go for 5 GHz more often, so would generally be preferred. https://documentation.meraki.com/MR/Radio_Settings/Band_Steering_Overview Note this, from that doc: " If certain wireless clients are unable to detect the wireless network they may be using passive scanning. In these cases configure the network to use Dual band operation, not Dual band operation with Band Steering ."

GreenMan

Both tunnels will be created - and could actively carry traffic concurrently, depending on what resources are accessed and how they are advertised by the Hubs. Failover between the tunnels will be automatic, should one drop; the failover time will be dependent on the nature of the failure. Whether this is disruptive to your applications will also likely depend, to a decent degree, on how sensitive the applications are to brief loss of comms. A trial / Proof of Concept is usually recommended, with your specific blend of factors.

GreenMan

Z3 does indeed support just a single uplink, but can form multiple tunnels over that single link - usually to different destinations (typically MX Hubs, in some form of Data Centre). As Z3 is designed for home office use cases, I would suggest keeping this count very small - maybe 2 or 3 tunnels, but no more. The documentation you quote around concurrently active tunnels across both uplinks relates specifically to MX (all models of which can support dual uplinks) Note that the warm spare device option referred to in @olvs earlier reply, could apply to the MXs in your Data Centre, but not to Z3 (no warm spare option for Z3). Such a setup would involve a single tunnel per remote Z3, to the active MX. If the active MX failed, a new tunnel would be automatically built, to the standby - but traffic would be interrupted, while this happens. It is possible to have active - active DC AutoVPN / SD-WAN designs, but that wouldn't rely solely on the Warm spare function - more on this here: https://documentation.meraki.com/MX/Deployment_Guides/Datacenter_Redundancy_(DC-DC_Failover)_Deployment_Guide

GreenMan · ‎01-25-2021

https://documentation.meraki.com/MR/Encryption_and_Authentication/Meraki_Local_Authentication_-_MR_802.1X

GreenMan · ‎01-22-2021

I would try to think of your traffic flows, in such cases. You normally look to route in a Layer-3 switch when the routing process is the potential bottleneck for your applications, because a layer-3 switch generally does this at wire speed in silicon . Do you have any servers, hosted on the site in question? If not and you're going to access all your applications across the WAN, probably with much lower bandwidth and routed through the MX anyway - then I don't see that routing on your switching buys you very much (the latency for one ethernet patch cord???). If you do have local stuff you access, is that definitely inter-VLAN traffic? If not, then again you don't lose anything. If it is inter-VLAN, is the application latency / throughput sensitive? Hopefully you see where I'm going with that... The Meraki approach is about simplicity and generally I think keeping Layer-3 to the MX is simpler, so stick with it, if there's no unacceptable downside to doing so.

GreenMan · ‎01-21-2021

That sounds like a good plan, in principle, but sub MR86 instead of MR84, for currency. Either way, you will need antennas with them. How would you uplink them to the network? Wired connection is definitely preferable. You could mesh them though, if cabling is not possible and if an existing gateway (wired) MR is near enough. Your choice of antennas may well have an effect on that - MR84/6 is dual-band, with the 4 antenna posts serving both 2.4 GHz and 5 GHz, so you can't have one antenna optimised for mesh uplink and one serving the clients. (You could do that with MR74/6 where each radio has its own pair of antenna posts, but those AP models arent so powerful, for the qty of users here) I would look at the ANT-20 first (qty 2 = 4 antennas) and check you'll get good mesh uplink, without the need for directional antennas. If you have to go directional, your coverage within the tent will likely suffer - unless your directional antenna is placed to have both the clients and the gateway AP in the direction of signal travel. The APs would be mounted with the antennas pointing straight up and straight down - probably pole mounted, out of reach of people in the tent itself.

GreenMan · ‎01-21-2021

And don't forget - you can use packet captures; https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Packet_Capture_Overview#MS_-_Switches

GreenMan · ‎01-20-2021

You should know which version of the API output is being generated - It's a while since I set mine up but, when you create a post URL (destination for the output) the API version is selectable, via a dropdown. If you see only v1 or v2, I suspect you don't meet the pre-requisites for the Beta. Beyond just having MR Access Points, this is down to firmware: Firmware R26 for WiFi observations Firmware R27.5 for BLE observations One of the major advances with v3 is that it consolidates observations to a single POST (and location) per network, rather then getting different values, at slightly different times, from different APs. This info and more is available here: https://developer.cisco.com/meraki/scanning-api/#!overview/requirements Note that for AP models which pre-date 11AC Wave 2, r27 and subsequent firmware verions are not supported. Some more info in this area here: https://documentation.meraki.com/General_Administration/Firmware_Upgrades/MR_Mixed_Firmware_Networks

GreenMan · ‎01-20-2021

While you cannot download any raw configuration file, as others have already said - you can access details of your Dashboard configuration via API and use the API to reconfigure your Dashboard setup, hence providing an avenue for a kind of backup and restore. Appropriate scripts can be created, customised to what you need. Such a script and others are available online and GitHub is a great place to start. Maybe have a look at this one first: https://github.com/meraki/automation-scripts/tree/master/backup_configs Loads more resources around Meraki APIs are available here: https://developer.cisco.com/meraki/

GreenMan · ‎01-20-2021

I'd need to check but, I suspect you are right that they use different algorithms; v3 of the scanning API is in beta.

GreenMan · ‎01-20-2021

To my knowledge, there's no way to remove the firewall function from the MR traffic processing chain. I'm guessing the SSID in question may be configured in NAT mode (because the default Destination:Local LAN is a deny - that mode is designed for Guest users) You can, of course, set that to Allow but, if you want to use the most 'natural' setup, you would use bridge mode, for the SSID (configured under Wireless > Acess control). For 'Dry' you definitely don't want the clients behind a NAT. As the question relates to MR Access Points, I'd suggest this thread be moved to Wireless LAN

GreenMan · ‎01-19-2021

Have you built VPN between the sites or are you exposing the server(s) via port forwarding / NAT? https://documentation.meraki.com/MX/NAT_and_Port_Forwarding/Port_Forwarding_and_NAT_Rules_on_the_MX

GreenMan · ‎01-19-2021

You can contact your Meraki account team to make official Enhancement Requests, beyond Make a Wish. You may be asked to provide some supporting input, in order to understand your business needs etc. As you can imagine, this particular feature is already baking...

GreenMan · ‎01-19-2021

It's in the Datasheets, under Data Logging. This example is for MT10 https://documentation.meraki.com/MT/MT_Datasheets/MT10_Datasheet_-_Temperature_and_Humidity#Technical_Specifications

GreenMan · ‎01-18-2021

I'd be interested to hear what you would lose in VPNC mode, which you need?

GreenMan · ‎01-18-2021

Just to be clear: the vMX100 and the (newer) Medium vMX have the same capacity, for sizing purposes. They should be considered different, however. E.g. the new vMX Medium product supports Availability Zones. It's possible that such functional differences may grow over time.

GreenMan · ‎01-18-2021

It looks like you're putting the MX in question in a Data Centre? Have you considered using one-armed VPN Concentrator mode?

GreenMan · ‎01-18-2021

Actually - I realise I partially misinterpreted what you said; you are not trying to terminate the VPN tunnels via the LAN interface (though what I said about that holds true) Only the IP addresses physically assigned to the MX WAN ports and/or the public IPs that they NAT behind are considered, when forming tunnels. VPN tunnels are formed based upon the public IP addresses of the MXs at each end. If both MXs break out via the same Public IP, they form their tunnel between the physical IPs. If they have different Public IPs, they form between the two public IPs. Your MPLS network will need to be able to break out to the Internet, as I mentioned in my previous reply.

GreenMan · ‎01-18-2021

MXs have a default route of last resort via either / both WAN ports by default and this can't be removed. These paths will always be used for management traffic by the MX. These WAN ports must be able to reach the Internet, somewhere upstream, in order for them to be deemed operable. See https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Connection_Monitoring_for_WAN_Failover It's not important that the WAN ports themselves have a public IP address. You can add static routes (including a default route) on the LAN side, if you so wish - this would affect 'user traffic' not MX management. While you can form AutoVPN tunnels over a LAN interface, not that the destination for those will remain one of the physical IP addresses assigned to one of the WAN ports. Bear this in mind when considering any SD-WAN rules, for instance.

GreenMan · ‎01-18-2021

@CptnCrnch nailed it. Remember too - if you need to be more granular about who can access what, across a VPN tunnel - down to devices within the VLANs at either end - you can also configure VPN firewall rules: https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-site_VPN_Settings#VPN_Firewall_Rules These are configured separately from general inter-VLAN/Internet firewall rules. Look under Security & SD-WAN > Configure > Site-to-site VPN

GreenMan · ‎01-18-2021

Remember that the config you apply is applied 'to the dashboard', which then pushes it down to the device, once the two have trusted comms. You will indeed need to make sure that whatever is upstream of the MX, by way of NAT (your 5G router) and firewall rules enables / allows those comms. Dashboard advises you what you need to permit, under Help > Firewall info. If you're uplink comes via a mobile network, beware of the use of carrier grade NAT, by your mobile network provider, if you need to get VPN working to your MX.

GreenMan · ‎01-15-2021

In addition to the previous comments; WiFi has far more overhead than wired connections and is essentially half-duplex. https://www.cwnp.com/wi-fi-overhead-part-1-sources-of-overhead/

GreenMan · ‎01-15-2021

If splash page is your particular ask, then this will apply: https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Splash_Page#MX_Splash_Page_Options I see you found that already, in Dashboard - and that the multi-client recommendation puts it out for you ( 😕 ). It's worth knowing that the authorisation, on that basis - if you did adopt it - is an on/off switch. Assuming the VLANs on your site are all routed by your MX, by default authenticated clients would be able to access all those. You could limit any access between them (and to the Internet, of course) using the MX Firewall features. Note that, if you're also using VPN, you would need to control any access to remote subnets over VPN tunnels separately, using VPN firewall rules under Security & SD-WAN > Configure > Site-to-site VPN

GreenMan · ‎01-15-2021

This is the document you're after, I think: https://documentation.meraki.com/MX/Access_Control_and_Splash_Page/MX_Access_Policies_(802.1X) This is the first line of the overview, which outlines the supported platforms: "MX64/65(W) and MX67/68(C/W) and Security Appliances as well as Z3(C) Teleworker Gateways support port-based access policies using 802.1X. This feature can be leveraged for deployments where extra authentication is desired for devices that are connecting to the MX." I would add that access policies for MX/Z3 do not offer the same flexibility as for MS switches. If you have sophisticated needs (which tends to come with the client density which would also drive a need for the extra LAN ports), I would recommend choosing 'smaller' MX (e.g. MC67) and pair it with dedicated MS switches, rather than going for (say) an MX68.

GreenMan · ‎01-15-2021

Meraki MS switches do not support NAT. You should look at the MX Security Appliances, for NAT-related functions. It's very unusual to need NAT in a LAN environment - what is the use case?

GreenMan

Community Record

Badges