Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About K2_Josh
K2_Josh
Building a reputation
Member since Nov 6, 2023
2 weeks ago
Kudos given to
Community Record
85
Posts
42
Kudos
2
Solutions
Badges
Jun 26 2024
5:48 AM
This is a great example of a business problem that could benefit from an automation solution. But it might be more economical just to hire someone to manually change SSID settings across the networks in your Org.
... View more
Jun 20 2024
3:53 PM
3 Kudos
I volunteer to be the one to say that: MAC-based authentication on Wi-Fi is not a legitimate security measure. So as mentioned above, IPSK authentication w/o RADIUS is your best bet (with good passwords/passphrases).
... View more
Jun 20 2024
4:34 AM
@PhilipDAth and @alemabrahao, is this a decent summary of all of the posts above for the layman not familiar with the intricacies of the co-termination model? If a Prod org ever has unused licenses, then they should always be transferred to a Graveyard org before adding new licenses. And in the event that any licenses from the Graveyard org are ever needed, then they can be added back to the Prod org whenever new devices are added/re-added to Production. Moving licenses from Prod has zero effect on the co-term date unless new licenses are being added to the Prod org.
... View more
Jun 17 2024
9:03 AM
@RaphaelL Thanks for your help! I should have used the terms major and minor version numbering in my question but blanked on the terminology. I'm still left with the original question: How can one map a build number to a minor release number since the build number only contains the major release number?
... View more
Jun 17 2024
8:31 AM
For at least MX (and some MR) firmware, releases (defined as a set of features) are published at the dot level (e.g. 30.1 instead of 30). However, it is unclear which firmware build numbers map to the dot releases (e.g 30.0 vs 30.1). I would expect that the dot release would be part of the build number (e.g. it should be 30.1.1234.5 instead what we have now which would be 30.1234.5). To be clear, my recommendation would be to include the dotted release number in the build number. The Firmware FAQ does not explain this, nor do the release notes that one can page through from the Firmware status page. One impact of this is that it's not obvious which firmware features should be available for a given firmware upgrade (if it is not on the latest build number within the non-dotted version number). This is true when looking at the "Current Firmware" column in "schedule upgrades". But this is also just generally confusing. I would like to know if others have encountered confusion regarding this or have figured out ways to compensate for the confusing version numbers for firmware releases distinguished by dotted numbering.
... View more
Labels:
- Labels:
-
Firmware Upgrades
Apr 29 2024
1:15 PM
Thank you for getting that addressed. The KB still says that "All MV models are supported." https://documentation.meraki.com/MV/Initial_Configuration/MV_Cloud_Archive And the FAQ says "You also have the option of using Cloud Archive on select cameras for continuous 24/7 recording " [emphasis mine]. https://documentation.meraki.com/MV/MV_Smart_Camera_FAQ Those two statements appear to be conflicting, or at least confusing to me. Are there some MV models that don't support Cloud Archive?
... View more
Apr 24 2024
6:34 PM
And I just noticed that the MV13 is missing from the list of resolutions in the FAQ. https://documentation.meraki.com/MV/MV_Smart_Camera_FAQ#MV_Cloud_Archive_FAQs
... View more
Apr 24 2024
6:33 PM
Adding to the confusion about whether all cameras are supported, the FAQ says "You also have the option of using Cloud Archive on select cameras for continuous 24/7 recording " [emphasis mine]. https://documentation.meraki.com/MV/MV_Smart_Camera_FAQ
... View more
Apr 24 2024
6:30 PM
Does anyone know if MV13 is supported by Cloud Archive? The KB does say that "All MV models are supported.", but it doesn't list all of the models. Also, what resolutions and frame rates are supported? https://documentation.meraki.com/MV/Initial_Configuration/MV_Cloud_Archive When trying to understand "Enhanced Resolution", I found a separate KB related to resolution that does list the MV13 quality options. Based on comparing both pages, I'm guessing that MV13 might have the same Cloud Archive options as MV63(X) and MV93(X). https://documentation.meraki.com/MV/Initial_Configuration/Video_Retention
... View more
Apr 17 2024
3:04 PM
2 Kudos
This might be a comboport issue, depending on the MX model. If you lookup the MX model the installation guide should make it clear which ports to use when mixing SFP and copper uplinks.
... View more
Apr 16 2024
3:56 PM
2 Kudos
I recommend Cloudlare as a WAF for its ease of use, security and cost effectiveness. Whether you go with Cloudflare or another SaaS-based WAF, you would setup your MX to only allow HTTPS ingress from the vendors IP ranges. Another option that might work in some cases, in conjunction with or in place of VPN-solutions, is to allowlist IP ranges from remote sites with static IPs on the MX. In this case, the traffic is still flowing directly over the internet but the data is encrypted and it can only originate from specific locations.
... View more
Apr 15 2024
6:38 PM
This is not from Cisco Meraki, but I would look at this article: https://cyber-fi.net/index.php/2022/03/13/how-to-connect-the-meraki-mx-to-ms-switches/
... View more
Apr 15 2024
6:36 PM
2 Kudos
For more HA design approaches, please see @KarstenI's excellent article.
... View more
Apr 13 2024
8:48 AM
Usually some degree of overlap is part of a Wi-Fi design to allow for roaming. Hiring a Wi-Fi consultant is the best way to tune radio settings. If there's no budget a business case for hiring specialists, you can start with Meraki's RF Spectrum tool to assess the perceived dBm values from each of the APs. Also, some devices, such as Windows computers with Intel chipsets, allow controlling their roaming aggressiveness (from Device Manager) so that they will more quickly switch to APs with better signal strength.
... View more
Apr 12 2024
7:23 AM
4 Kudos
I'd expect 300-500mbps, at least for a single client on 5 GHz. The actual number is influenced by all sorts of things including RF interference, channel size, device type/chipset, device drivers/OS, device config (inc. power saving, as mentioned by @PhilipDAth) exact positioning/angle of the device to the AP, AP mounting, AP radio config, number of clients connecting/using the SSID/AP, etc. You may want to test the bandwidth with multiple similar, ideally identical, devices at the same time to see if this might be a client-related limitation. Out of curiosity, is there a reason why speeds of over 300mbps+ per wireless client are important to your organization? Video streaming maxes out at 20-30mbps.
... View more
Apr 10 2024
4:52 PM
2 Kudos
Here's a few advantages of a device running the VPN server behind a separate firewall: 1. There is potentially less of a CPU impact on the VPN server (assuming that Geoblocking consumes CPU). And fastpath could be enabled on the FTD. 2. No logging of the failed connections from the blocked IP ranges(/countries), unless all logs are being ingested back into the same SIEM 3. Not needing to be dependent on MX firmware not supporting certain Any connect features 4. Being able to restart only the VPN server for firmware upgrades. The advantages of moving VPN to the MX is a simpler configuration and lower licensing costs.
... View more
Apr 9 2024
7:50 AM
Is Static NAT configured on the MX? Meraki calls this 1:1 NAT. If so, the inbound traffic should maintain the source IP address. https://documentation.meraki.com/MX/NAT_and_Port_Forwarding/Port_Forwarding_and_NAT_Rules_on_the_MX
... View more
Apr 9 2024
7:19 AM
Also, I would try adding outbound firewall rules on the MX. That should prevent an actual attack and may cause the logging of such attempts to stop, depending on how logging and alerting is configured.
... View more
Apr 9 2024
7:13 AM
The FTD platform allows GeoBlocking/GeoAllow and IP firewall rules for VPN access. Why not add the rules to the FTD?
... View more
Apr 6 2024
10:22 AM
If it's a 24x7 environment then testing ahead of time and performing a staged migration is your best bet. If you engage (or are working with) a wireless consultant, they can help you plan the the least disruptive migration plan, possibly using extra un-mounted APs (from either vendor) temporarily in the middle of the migration.
... View more
Apr 6 2024
10:13 AM
Planning for a co-existence between AP vendors depends on the Wi-Fi authentication type and network design. If the APs can share a VLAN during a staged migration, there should be no impact to production as long as you confirm that authentication/roaming works between both sets of devices. You can setup at least one test Meraki AP and one Extreme AP in roughly the same area to test roaming between them.
... View more
Please let us know what you find.
... View more
This is from the official documentation on the MS130. https://documentation.meraki.com/MS/MS_Overview_and_Specifications/MS130_Datasheet Port LED is off if: "Port is operating at less than full speed. For example: 10/100M on a 1GE port 100M/1GE on 2.5GE ports 1G on SFP+ ports"
... View more
So now if we want to plug in a 100mbps device and see an LED indicator, we will need to buy a 200/300 series switch (since the MS130 only turns on the LED at full port speed). This seems like a downgrade in usability.
... View more
Apr 3 2024
7:54 PM
I built a stack of four MS355s today. I mounted and cabled them based on the order of their serial numbers. This turned out (not surprisingly) to be the same order as the MAC addresses. After I built the stack, the Switch Stack Overview page showed them in the reverse order. I opened up a ticket and was advised that there's no way to change this, but that renaming the switches (from the MAC address) should be done anyways. Later, after renaming the switches, they did end up showing up in the correct order in the Overview page. So, I wonder if they are sorted the wrong way only when they do not have a name set. The IP address order is currently the same as serial/MAC/physical order, and it was almost certainly the same when I created the stack; so I don't think that the IP address plays a role. In any case, it would improve the deployment experience if this could be fixed or at least answered by a KB. I also noticed that blinking the switches didn't work for one of the four switches. This was only tested when they were in a stack.
... View more
Kudos given to
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 4318 | Apr 10 2024 4:52 PM | |
| 2275 | Feb 2 2024 9:34 AM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 5 | 844 | |
| 5 | 62847 | |
| 4 | 1618 | |
| 4 | 899 | |
| 3 | 733 |
© 2024 Cisco Systems, Inc.
