Meraki

Mloraditch

This is not infrequent as of late, recommend opening a case just to get the visibility up, in the meantime try hitting ctrl+f5 to force a full page reload, that sometimes helps, or if the page has new/old versions, switch that if you can see that link.

Mloraditch

This is backend, it can happen for multiple reasons (presuming a single delivery address, multiple addresses will always create multiple orders) 1) Ordering team (Disti if you are Tier 2) is placing multiple web orders in CCW 2) Ordering folks are placing order without the ship complete flag 3) Orders featuring multiple levels of MX licenses (i.e, a HW MX at SDW and VMX at SEC) will generate multiple license emails. May also effect advantage licensing, but we don't use that so i'm not sure. You can ask disti or if you are T1, your ordering team, to flag orders as ship complete and that should ensure you get everything at once if that's desired but you will not get things until the last item is available so check your lead times before asking. The partner can definitely get the emails. We get all of the emails. You just have to make sure whomever places the orders puts the right email in the reseller partner fields. We have a disti we use that goes to purchasing and actually have Exchange rules that forward only those emails (based on the subject formats) to our network engineers. If you have CCW access you can also access all this info from there. Your PSS admin can help with that possibly.

Mloraditch

Important fixes for MS150s! and some new known issues Important notes This firmware release only includes updates for MS150 switches. All other MS switches on MS 18.1.4 will run firmware identical to MS 18.1.3.1. New feature highlights Group Policy ACL on MS130 & MS150 Maximum MAC support in MAC Allowlists 802.1x limited access mode with pre-auth GPACL Local Status Page connectivity diagnostics enhancements Layer 2 multicast live tool Traffic Mirroring: RSPAN & VLAN Based SPAN Fixed issues Ms150 fixed issues Fixed a bug that caused MS150 switches to incorrectly remove or update SGT tags when no policy or VLAN mapping was defined Resolved an issue that caused some SFP and QSFP modules to experience intermittent flapping Fixed a bug that caused some MS150 switches in stack configurations to lose connectivity while reporting redundant uplinks as blocked Resolved a bug that caused some 48 port MS150 switches connected to MX gateways to experience reductions in uplink throughput if the uplink was connected to any port in the 41-48 range Known issues General known issues MS130 and MS150 switches may not properly display IPv6 RA packets in dashboard packet captures In rare circumstances switches may experience uplink instability when IPv6 link-local addresses are enabled. If this issue is encountered it can be resolved by enabling IPv6 RA Guard to block ICMPv6 neighbor discovery messages. Some switches may encounter an error, "incompatible configuration for attributes: allowed_vlans" when attempting to aggregate ports regardless of allowed VLANs configured in Dashboard Ms120 known issues Switches may fail to provide PoE power to legacy access points (always present) Cable tests may report incorrect cable lengths Ms130 known issues Switches may incorrectly remove or update SGT tags when no policy or VLAN mapping is defined. Until a firmware fix is available, correct SGT tags can be preserved by defining a policy for the SGT group in Adaptive Policies, and binding the SGT group to a VLAN using VLAN profiles. MS130X mGig ports may fail to establish a link when both sides are forced to 100 Mbps full-duplex. If either side of the connection uses auto-negotiation the link will be established normally Ms150 known issues When a stacking cable is disconnected from MS150 switches in stack configurations the disconnected port will incorrectly continue to be marked as connected while the still-connected stacking port will incorrectly be marked as disconnected In rare circumstances MS150 switches in stack configurations may experience a software crash following a stack member reboot, resulting in an unexpected active member election In rare circumstances MS150 switches in stack configurations may experience a software crash following a stack member reboot, resulting in a multicast storm and possible interruption of connectivity until the stack has been rebooted MS150 switches incorrectly advertise 60-watt PoE++ on all ports. PoE++ is only available on mGig ports; ports 17-24 on MS150 24MP-4X switches, and ports 33-48 on MS150 48MP-4x switches. In certain circumstances, MS150 switches using cross-stack LACP may place a port into a discarding state after a stack member reboot, with the affected port failing to transmit LACPDUs until the LAG group is recreated. MS150 switches may intermittently negotiate USB-C Ethernet adapters at 10 Mbps half-duplex instead of the expected speed for the switchport, requiring a physical reseat to correct the issue. Ms350x known issues Switches may experience an unexpected reboot (present since MS 15) Ms355 known issues Switches in stack configuration may experience some ports failing to reconnect after a firmware upgrade Ms410 known issues Some MS410 switches may encounter alerts for fan failures that will eventually self-resolve Ms425 known issues In rare circumstances MS425 switches may encounter a software crash that results in a reboot

Mloraditch

I guess I need to be thankful for new firmware this Thanksgiving, I already got notice that this was being pushed to every network I had 32 at. Either one of these fixes is major (although I don't recognize either problem) or there is a yet to be revealed CVE fix that is critical. Important note MR45/55 APs are not supported on MR 32.x.x and will instead upgrade to the backup version (MR 31.1.8) if they are in networks configured for MR 32.x.x versions, and thus, new features will not be available. Bug fixes General stability, performance, and experience improvements APs that require 802.3bt PoE for full capability request greater than 30W via CDP when connected to 802.3at (30W-capable) switch port (Wi-Fi 7) AP disassociates previously disassociated client with reason code 2 (Wi-Fi 6, 6e, Wi-Fi 7)

Mloraditch

Meraki GO has been retired. You will need to transition to a new product, recommendations and info here: https://community.meraki.com/t5/Meraki-Go/Meraki-Go-End-of-Sale-April-2025/m-p/233755

Mloraditch

Named VLANs and profiles would be the solution for, you can use names in ISE and then apply different vlan numbers to groups of switches for the same name https://documentation.meraki.com/Switching/MS_-_Switches/Design_and_Configure/Configuration_Guides/Port_and_VLAN_Configuration/Named_VLANs_in_MS_Configurations https://documentation.meraki.com/Platform_Management/Dashboard_Administration/Design_and_Configure/Configuration_Guides/Routing_and_Firewall/VLAN_Profiles

Mloraditch

The boot time is variable depending on the platform, most MS switches I'd say are 3-5 minutes, IOS-XE could be longer ~10-15, but all of that can also depend on firmware CS IOS-XE will be slower than regular IOS-XE, etc. To be clear the switches don't gain their config, they will have it already. Unless you are making changes while they are offline they will boot up and not need to apply any new config. If they all boot simultaneously they will come online nearly simultaneously. If you have concerns that devices won't recover correctly if the network is not fully online, I suggest you have them powered off or just inform the end users that they may need to reboot first thing.

Mloraditch

Presuming you mean Meraki only has the mac and IP from seeing what switch port it's on, then yes, you will need to get up there and look at the device.

Mloraditch

Here is the main documentation page for Workflows: https://documentation.meraki.com/Platform_Management/Workflows It's basically a set of tools that put common api actions into a more user friendly and/or prebuilt format. This specific automation would be a way you could tag your networks in your own way (say release rings or geography) and then schedule the updates. To do what you want (upgrade everything once a new stable is released), you'd need to add a bit more logic to read the stable firmware versions and then when it changes push the update. I'm not actually aware of an API Endpoint that has this info, although I could be missing something.

Mloraditch

I've used it at a client and it was as simple as setting up the third party vpn with a 0.0.0.0/0 remote subnet listing. You seem to have resolved the one problem you were having, is there something specific you are looking for insight on? This wasn't available when I used it, but you may want to look at VPN exclusions for certain known traffic to optimize performance: https://documentation.meraki.com/SASE_and_SD-WAN/MX/Design_and_Configure/Configuration_Guides/Site-to-site_VPN/VPN_Full-Tunnel_Exclusion_(Application_and_IP%2F%2FURL_Based_Local_Internet_Breakout)

Mloraditch

That changed earlier this year with 19.1. They added SEC to vMX and made it mandatory for SEC or SDW orgs to have SEC vMX. https://documentation.meraki.com/Platform_Management/Product_Information/Licensing/Meraki_Licensing_FAQs In the middle of the big blue box.

Mloraditch

The skus definitely exist, we loaded some in a deal yesterday. I'd check again today and if not, ask your disti rep or the relevant Cisco AM if they can help. I've definitely heard of CCW errors where skus briefly disappear.

Mloraditch

Depends on the quantity of SFP ports needed. If it's 2 or 3 drops sure maybe, also depends on how far things need to be.

Mloraditch

For connection to the cloud they just need internet. I'm not aware of any feature that requires the APs be able to talk to each other directly. Example: https://documentation.meraki.com/Wireless/Design_and_Configure/Architecture_and_Best_Practices/Seamless_Roaming_with_MR_Access_Points The requirements for roaming have no need for direct communication.

Mloraditch

Is the DDNS updating? if not, contact support If the DDNS is updating, there could be some sort of ISP issue, especially if you are using the older client vpn. What is your secondary ISP? Do you have public ips from them?

Mloraditch

I'm pretty sure OP is talking about the switch port view which does default to 30 ports and it would be really nice if a lot of the view preferences were referenced from the user profile vs the organization or network.

Mloraditch

You can technically do that if your Hubs are concentrators (or have another firewall to send traffic to) AND you can define the services via static routes. I.e. if you want to reach X.X.X.X/Y via Hub 1 you can advertise that from that Hub. Unless the services in question have fixed IPs, you would not be able to do this.

Mloraditch

If it's not in your inventory but you remember when it was and it's within the time the change logs keep, you may be able to hunt it down from when you removed it or added it.

Mloraditch

That's curious, I thought that was just for IOS-XE on 17.18. I wonder if it's a GUI bug.

Mloraditch

I remember hearing about this at either Cisco Live or a partner training, It appears you have to load the new aps and then match them up, which is fine, but I'd prefer to have them pre-loaded and just rely on matching up serials as an option, then things could happen automatically as soon as they are plugged in. I can see why you might want the other way, but having both would be ideal imo.

Mloraditch

https://documentation.meraki.com/Platform_Management/Dashboard_Administration/Operate_and_Maintain/How-Tos/Give_your_feedback_(previously_Make_a_Wish) Just in case you aren't aware, the most official way to submit this type of wish feedback. It definitely should be a per admin setting instead of per org, IMO.

Mloraditch

You will need to upgrade the firewall to get higher speeds. See here for what's available at what speeds: https://documentation.meraki.com/?title=MX%2FDesign_and_Configure%2FArchitectures_and_Best_Practices%2FMX_Sizing_Guide_%26_Principles#Performance_Data Be mindful of the various throughput levels depending on what features are enabled. Also bee aware that if you can live with speeds less than your circuit max but still higher than currently and are co-term you can upgrade to an MX67 with no license charge: https://documentation.meraki.com/Platform_Management/Product_Information/Licensing/Meraki_Co-Termination_Licensing_Overview#License_Conversion If you need full use of the circuit, you will have to pay for a new license for your chose hardware. Your meraki rep may be willing to soften the blow and give you some credit for your existing license, but you will need to talk to them.

Mloraditch

What support can do and what your sales teams can do are different things. Support cannot modify these things, but your Cisco account team may be able to help you with this by doing some sort of modify. I suggest reachout out to them/your partner to ask.

Mloraditch

Oddly, the new switch view loads for me but the old won't.

Mloraditch

Thanks and congrats to everyone!

About Mloraditch

Mloraditch

Matthew Loraditch

Community Record

Badges