Meraki

GreenMan · ‎Sep 30 2022

Just one thing to add, almost as an aside: using OSPF on the MX, in the way described, is not an option here; OSPF on MX advertises AutoVPN branch subnets to the upstream DC neighbour only - it does nothing in relation to underlay networking (e.g. the default route). The MX also does not learn any subnets from upstream of the internal router. Hence the title of the related KB article: https://documentation.meraki.com/MX/Site-to-site_VPN/Using_OSPF_to_Advertise_Remote_VPN_Subnets It should also be said that, even for the VPN subnet re-distribution use case, OSPF has been largely superseded by using eBGP, which is far more feature-rich: https://documentation.meraki.com/MX/Networks_and_Routing/BGP

GreenMan · ‎Sep 30 2022

@AxL1971 This is why many companies contract-in wireless site surveys to a Cisco partner, who can afford the right tech and have the appropriate experience - cos they are using it for many customer, frequently. Remember that a site survey is more of a tested design operation, so experience is really important; the tool, by itself, won't give you all the answers.

GreenMan · ‎Sep 29 2022

If your APs are connected via Meraki switches, there's no need to use scripting to reboot / switch off APs - use MS Port Schedules. While you're switching them off, why not leave them off (overnight?) to save some energy and CO2s https://documentation.meraki.com/MS/Access_Control/Port_Schedules

GreenMan · ‎Sep 22 2022

Did you follow the configuration guide? In my experience, doing it just using Windows wizards etc. never works - you need to follow the step-by-step guide carefully for your version of OS: https://documentation.meraki.com/MX/Client_VPN/Client_VPN_Overview Check out the Network-wide > Event log for details of what the MX is seeing too. You can, of course, also ask for assistance from Meraki Support.

GreenMan · ‎Sep 16 2022

If I recall, BIDI involves send and receive over the same fibre core. I don't believe Meraki switches support this.

GreenMan · ‎Sep 15 2022

While Advanced Security protections do add load to any MX, they aren't enabled by default and just enabling those features alone shouldn't restrict throughput that much (see Page 3 number for the MX64 column here: https://documentation.meraki.com/MX/Networks_and_Routing/MX_Routing_Behavior#AutoVPN_and_Non-Meraki_VPN_peers).) I'd check that you're on the latest stable firmware release and contact Meraki Support if it stays the same.

GreenMan · ‎Sep 15 2022

https://documentation.meraki.com/MX/Networks_and_Routing/MX_Routing_Behavior#AutoVPN_and_Non-Meraki_VPN_peers It's not model-dependent

GreenMan · ‎Sep 15 2022

Model-dependent, your MS switch will provide critical temperature alerts, if you enable it (Network-wide > Configure > Alerts > Switch (if the option isn't there, your switch model doesn't support it). https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Alerts_and_Notifications#MS_Alerts But MT10 is probably your best option

GreenMan · ‎Sep 15 2022

You can't pass ACLs to the switch directly, as with dACLs, but you can effectively activate ACLs that have been previously configured there in the Dashboard, most powerfully, using Group Policy like this (which allows you to also apply things like rate shaping in a full-stack deployment): https://documentation.meraki.com/MS/Access_Control/Meraki_MS_Group_Policy_Access_Control_Lists#:~:text=Group%20Policy%20ACL%20on%20MS,server%20associates%20with%20the%20client. https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Creating_and_Applying_Group_Policies

GreenMan · ‎Aug 26 2022

I was looking only to help with the original question. 😉 In my experience, there are a number of compelling reasons for choosing VPNC over routed mode for the majority of Hubs - with licensing cost not really a part of that design calculation. I also can't help feeling that, whilst I understand people don't want to pay for features they will not be using, the overall 'cost' in time and complexity of needing to specify (and separately renew) licensing for individual devices probably outweighs the extra spend from a simple one-choice, applied to all approach - given the majority of networks have greater numbers of Spokes (where you want Adv Sec/SD-WAN+) than Hubs.

GreenMan · ‎Aug 26 2022

I'm not 100% sure, but I have a feeling this must have to do with the recommendation that Hubs are configured as One Armed Concentrators - with just one uplink.

GreenMan · ‎Aug 24 2022

As highlighted early in this documentation, they will essentially lose their config: https://documentation.meraki.com/General_Administration/Inventory_and_Devices/Moving_Devices_between_Organizations Bear in mind that you can have a replacement config all ready for them, in a new Network, in the destination Organization. It's possible to use the Dashboard API and some publicly available scripting to 'get' config from the existing Org and 'put' it into the destination too. (this is discussed in other threads on here)

GreenMan · ‎Jul 28 2022

To my knowledge we've never had that capability. Most customers would simply use syslog directly, with an appropriate syslog server in their central off network location - perhaps with a secure tunnel between the two, to carry the syslog traffic.

GreenMan · ‎Jul 28 2022

Yes - webhooks are about alerts, rather than events. You can pull the event log though, via the Dashboard API: https://developer.cisco.com/meraki/api-v1/#!get-network-events

GreenMan · ‎Jul 12 2022

You can't do this on the same SSID - the 'MAC-based access control (no encryption)' and 'Enterprise with my RADIUS server' config options are mutually exclusive. Remember that, as per the description, the MAC authentication option does not result in an encrypted WLAN session between the client and the AP as Enterprise 802.1x does. I'd recommend you look at using Identity PSK with RADIUS (assuming you;re using a reasonably recent MR access point model and firmware). iPSK combines WPA2-PSK authentication / encryption with a check of the client MAC address. https://documentation.meraki.com/MR/Encryption_and_Authentication/IPSK_with_RADIUS_Authentication Note that this would still be a separate SSID to your Enterprise 802.1x SSID - but you should be able to use the same RADIUS server for both.

GreenMan · ‎Jul 8 2022

Doing this centrally via the Dashboard itself would be the way, using Network-wide alerts and converting to SMS: https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Alerts_and_Notifications#Receiving_Email_Alerts_via_SMS You may also be able to achieve similar using webhooks into a messaging platform, such as Webex, to alert admins using a mobile version of the app I think it highly unlikely a localised solution using the onboard SIM and SMS would also be developed.

GreenMan · ‎May 31 2022

Answered in your previous thread... It's essentially permanent, Meraki-side

GreenMan · ‎May 30 2022

As others have suggested - you probably need to focus on why the port went down (and how it came back up again) the STP messages you're seeing are expected, for a port going down, then recovering later.

GreenMan · ‎May 18 2022

The get and put calls for appliance site to site vpn can't be applied to a Template: { "errors": [ "Unsupported for configuration templates" ] } From what I've seen, as you usually have few Templates (because it's Templates itself that generally caters for change at scale), things like changing Hubs would normally be made in the UI. If you go down the road of scripting things, to cover change at scale, you'd normally unbind Networks from a Template and go solely for scripting. That might not be the case for Service Providers, looking after lots of customers, but then you wouldn't have lots of customers pointing at the same VPN Hubs anyway...?

GreenMan · ‎May 6 2022

Can I ask what you're looking to do using this? Note that an MX automatically obtains a publicly visible DNS hostname - which you can then use as a destination for things like Client VPN, instead of needing to use the public IP address, which may change from time-to-time, depending on your Internet service: https://documentation.meraki.com/MX/Other_Topics/Dynamic_DNS_(DDNS)

GreenMan · ‎May 6 2022

If you haven't already, I'd suggest you read this document carefully: https://documentation.meraki.com/MX/Site-to-site_VPN/China_Auto_VPN Also this one, at a higher level: https://documentation.meraki.com/General_Administration/Support/Information_for_Users_in_China Basically, in China you are recommended to deploy Meraki devices into an Organization within the China cloud. Doing this precludes forming AutoVPN (SD-WAN) tunnels to an MX in a different Organization, of course. If you choose not to follow the recommendation and physically deploy an MX in China, but as part of a non-China Org, while you may or may not get VPN to come up, to other locations, there would be no guarantees around whether it would stay working, nor around its performance .

GreenMan · ‎May 6 2022

I found this was pretty easily fixed using Rain-X - I'm sure there are other similar products out there, too: https://rainx.co.uk/rain-x-products/rain-x-rain-repellent/

GreenMan · ‎May 5 2022

Are the devices communicating via bluetooth or WiFi? To my knowledge both of these technologies leave any roaming decisions to the client device itself (so check documentation and config / firmware options for those) If it's WiFi, check to see if there are any AutoRF-related reconfigs of the APs, at the times in question - changing channels or Tx power, that might affect the client's decisions. You could consider fixing those WiFi parameters through an RF Profile: https://documentation.meraki.com/MR/Radio_Settings/Manual_Channel_Selection%2C_Transmit_Power_Adjustment%2C_and_Antenna_Configuration

GreenMan · ‎May 5 2022

L2 isolation doesn't prevent broadcasts and multicasts from being generated. Proxy ARP within broadcast suppression will help with this, to some degree and client devices are generally better these days at handling resultant traffic in some volume than previously, but not to the level of a /16 subnet, I would think. https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Broadcast_Suppression_and_Control_Technologies_for_MR_Access_Points

GreenMan · ‎Apr 30 2022

Woah there! I chose my masks carefully... /23 = c. 500 clients /22 = c. 1,000 clients. = basically doable (think: short DHCP leases) but /16 = > 65,000 clients! That's a big jump and not one I'd recommend. But there are certainly advantages if you can stick to layer-2 roaming. One thing to bear in mind - unless you have contiguous coverage between buildings on a campus (i.e. outdoor APs etc.) then clients are not even going to need Layer-2 roaming everywhere, as they won't remain associated between buildings anyway. It's also much less likely to be manageable to extend the same VLAN between buildings on a campus. The analogy comparing floors in the same building with different buildings on a campus isn't necessarily the best, unfortunately. Mind you; even in a building, maintaining coverage between floors can be a significant challenge anyway (stairwells and lift shafts are difficult and expensive to fully cover). All these things make a difference.

About GreenMan

GreenMan

Community Record

Badges