Meraki

Mloraditch

It's not listed on the 9176 or 9172 datasheets, but the 9178 does list the supported bands and those are not included: https://documentation.meraki.com/MR/MR_Overview_and_Specifications/CW9178I_Datasheet My assumption would be if the highest model doesn't have them, the lower levels won't either, but your account rep may be able to have an SE confirm.

Mloraditch

You can have a static route that is set to be only active when the next hop or host responds to the ping. See Static Route Tracking here: https://documentation.meraki.com/MX/Networks_and_Routing/MX_Routing_Behavior

Mloraditch

You have two options NPS authentication following this guide: https://documentation.meraki.com/MX/Client_VPN/Configuring_RADIUS_Authentication_with_Client_VPN_IPsec and this one: https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-nps-extension You would just be doing the meraki side settings on the anyconnect page vs client vpn. Or you can use SAML: https://documentation.meraki.com/MX/Client_VPN/AnyConnect_on_the_MX_Appliance/AnyConnect_Azure_AD_SAML_Configuration and then in Entra you would control whether MFA is prompted for.

Mloraditch

While someone else may have an answer they can share, generally anyone who knows a timeline (if it exists) is not going to be allowed to communicate it. If you reach out to your account rep they may be able to get you info under NDA.

Mloraditch

Yes i see that now too. I definitely just copied and pasted so they must have edited. Crazy if that's finally fixed

Mloraditch

I think the thrust of the question is what exactly determines when Meraki automatically pushes upgrades. Its not clear at all to me. Sometimes they do, sometimes they don't. I often find networks on firmware with Critical Status. The FAQ here: https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Cisco_Meraki_Firmware_FAQ#How_often_are_upgrades_done.3F just says periodically. Part of the simplicity of Meraki is (in theory) not having to manage firmware updates (see this old post: https://meraki.cisco.com/blog/2016/09/firmware-upgrades-merakified/ )unless we need to try a new feature or experience a bug, but I know I find myself scheduling updates for networks with releases several months behind a critical date. It's a bit frustrating and I'm considering having our developer add firmware status to our tools as checking all of my orgs individually is a nightmare

Mloraditch

Lots of Bug Fixes, several having to do with Radius that sound suspiciously like random forum posts I've seen! EDIT: "Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID's (Wi-Fi 6, Wi-Fi 6E APs)" was moved to fixes by Meraki after the original post. Very very long outstanding bug that may finally be fixed. Important note Wi-Fi 5 Wave 2 MRs support - This version and subsequent MR 31.x.x are only supported on 802.11ax (Wi-Fi 6) and newer MR models. 802.11ac Wave 2 and older products will only upgrade to the backup version (MR 30.7.1) if they are in networks configured for MR 31.x.x versions, and thus, the new features will not be available. The bug fixes listed below will also not apply to Wi-Fi 5 Wave 2 and older MRs. (https://documentation.meraki.com/MR/Other_Topics/Cisco_Meraki_MR_Firmware_Restrictions_Overview_and_FAQ) Includes support for Wi-Fi7 APs (https://documentation.meraki.com/MR/MR_Overview_and_Specifications/CW9176I_%2F%2F_CW9176D1_Datasheet, https://documentation.meraki.com/MR/MR_Overview_and_Specifications/CW9178_Datasheet) Bug fixes General stability and performance improvements MR56 ethernet port flaps occur when connected to C9300-48UN(V04) at 5Gbps speeds MR57 ethernet port flaps occur when connected to MS355 at 5Gbps speeds MR46 not responding to Probe Requests from clients Channel & power not configurable via LSP on CW9163E APs Wildcard NAS-IPv6-Address AVP sent on config change (Wi-Fi 6, Wi-Fi 6E APs) NAS-IP-Address discarded (Wi-Fi 6, Wi-Fi 6E APs) RADSec authentication failures (Wi-Fi 6, Wi-Fi 6E APs) DHCP offer is not forwarded if broadcast flag is set (Wi-Fi 7 APs) mDNS traffic blocked (Wi-Fi 7 APs) SSIDs broadcast on 6Ghz despite being disabled when using WPA3 transition mode (Wi-Fi 7 APs) Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID's (Wi-Fi 6, Wi-Fi 6E APs)

Mloraditch

I believe that bug exists in every release after 18.211.3. You will need to get support to downgrade to that for now. Unfortunately it's not listed in the release notes.

Mloraditch

This can work if you have a routed block from the ISP, however that doesn't appear to be the case. If you are not meraki users I would just remove the meraki and connect your sonicwall directly. Probably will have to put it somewhere secure so you can return once you the contract is up and you are able to renegotiate to DIA only. There may be other solutions but I would operate on this like when FiOs almost always ships a router that is unnecessary, remove it and do your thing the way you want. Might have to turn off some alert emails but I wouldn't think att will care.

Mloraditch

You mean they stop working after any configuration change or you made a specific change and this has been happening since? Have you tried undoing the change? What was the change? If you aren't on the latest firmware, I definitely suggest that. I don't see any known issues or fixes even going back a bit, but Meraki doesn't always list every bug. If that doesn't help, you could try a factory reset to see if it resolves the issue. Something may be gummed up on the config on the device. Alternatively or if that fails, give support a ring when one of them isn't working. They can hopefully identify the issue and open a bug if necessary.

Mloraditch

Given what they do, I would think they can generally coexist. The only thing they both can do to a port is define the access VLAN on a port. 802.1x policies should take precedence to SmartPorts IMO, but perhaps someone from Meraki can confirm. Although I would imagine you can test now with ISE or another radius server. I have to imagine from the switch side there is no difference in how it handles things. It's definitely still just using access policies on the ports as that's shown in the documentation.

Mloraditch

I'm not aware of any and just paged through everything that might and don't see it anywhere. It's not something you can change on the WAN or LAN on the dashboard so I expect it may be truly a local only configuration.

Mloraditch

Like most network gear you can just unplug it. There is no shutdown command necessary.

Mloraditch

You need to have Meraki Systems Manager licensing to do this and then an admin would create a Systems Manager network where you can do this. I can't speak to each individual setting you mentioned, but those are the type of things you can do in MDM systems. You can start to read about Meraki SM here: https://documentation.meraki.com/SM

Mloraditch

https://documentation.meraki.com/Go/Features/Decoding_the_Meraki_Go_Hardware_LED_Lights It may mean something is wrong with the unit. It should be blinking orange if it's booted and just can't connect to the internet. I suggest contacting support

Mloraditch

One of the reddit posts about this indicated it is slowly rolling out to the EA page and will be like other early access features with the warning that you will need advantage licenses once it GAs later this year. Of course someone from Cisco could post a blog/page/anything and explain all of this in some easy to read location... 🙃

Mloraditch

As others have said checking the cabling as that's the likely culprit usually, if you have Meraki switches you can use this tool: https://documentation.meraki.com/MS/Monitoring_and_Reporting/Using_the_Cable_Test_Live_tool

Mloraditch

I believe you are saying (as an example) you have an internal subnet that is 192.168.1.0/24 and certain end users also have this as their home LAN. That will definitely cause a conflict and Meraki does not have a solution that I am aware of. The only NAT translation over VPN is for S2S for Auto VPN peers. You can handle this with regular Cisco Firepower devices as they can handle complex NAT situations. Generally it is not recommended to put your corporate LAN on the most common 192.168 subnets. I would also look into re-iping your internet networks to get outside of these ranges that home devices usually use.

Mloraditch

I haven't done it, and would definitely believe it to be unsupported officially. It appears it may work given what it does, but for a supported option (beyond running a normal drop) you'd want to put an normal 802.3 injector in place and get normal power for it. MA-INJ-4 is the current model

Mloraditch

1. See here for how to find the rules for your network (Help/Firewall Info) https://documentation.meraki.com/General_Administration/Other_Topics/Upstream_Firewall_Rules_for_Cloud_Connectivity 2. There is no direct option. There are some third parties who have written API based tools that do it to some extent. I have not used any so can't recommend any but here is an example in the marketplace: https://marketplace.cisco.com/en-Us/apps/426592/backup-meraki 3. No, if it's the same exact model you can use the clone option, but it doesn't cover everything, this guide has details: https://documentation.meraki.com/MS/Other_Topics/Switch_Cloning

Mloraditch

There was a bug with client balancing where certain SSID slots wouldn't work when enabled. That was fixed. There may have been other issues, but I'm not specifically aware of any.

Mloraditch

I can't imagine it will be free after the preview (if it's even free then) based on the type of product. There has also been no partner briefing on it so I'm as clueless as you. I could maybe see it being included with advantage licensing. Hoping someone can talk about it soon!!

Mloraditch

I saw it yesterday, the documentation linked therein explains it. Have not seen an announcement

Mloraditch

This heavily depends on your endpoints being compatible with newer speeds. It also depends on your available lan and internet bandwidth. If you don't have a bunch of ancient equipment you will likely see some improvements. The biggest improvements of using 6 Ghz are perhaps the hardest to realize as compatible endpoints are fewer. Coming from MR32s if nothing else there are stability improvements in the overall platform. MR44s are Wifi 6 so unless you have 6Ghz compatible clients, I wouldn't necessarily replace those yet unless you are getting a fantastic deal from your partner/account rep. MR 32s are EOL and I would recommend replacing. Meraki is selling their WiFi 7 aps for the same pricing as their 6e options so I do generally recommend getting them, but be careful to understand the power requirements and what does and doesn't work if you don't yet have switching with the full PoE requirements necessary. The new 9172s just announced may be good for you: https://www.cisco.com/c/en/us/products/collateral/wireless/catalyst-9100ax-access-points/wireless-9172-series-access-points-ds.html

Mloraditch

I suggest you submit a "Make a Wish" on the dashboard. https://documentation.meraki.com/General_Administration/Other_Topics/Give_your_feedback_(previously_Make_a_Wish) You may also want to mention if to your account rep as well. There may be Microsoft limitations as well driving this but the above are the best way to ensure your feedback gets to the right people.

About Mloraditch

Mloraditch

Matthew Loraditch

Community Record

Badges