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
Feb 2 2024
8:33 AM
BTW, I don't think that running a custom script to perform failover to perform failover via API would work since it that depends on the local MX connecting to the Meraki cloud to get the configuration update at a time when the connection may already be down on ISP 1. I may be misunderstanding what you meant though or there might be an API to directly control the WAN connections on the MX from inside the network that I am not aware of.
... View more
Feb 2 2024
8:30 AM
As far as defeating the point of Meraki, I agree that could be the case. But that depends on the sort of solution that I devise of find. If there was a vendor that sold/serviced an affordable appliance that could do exactly what I (and presumably what others want) which is to: 1. sit in front of each ISP circuit and provide switching to downstream firewalls (so super useful for firewall HA pairs) 2. monitors the connection health 3. disables/enables ports to firewalls 4. sends alerts from devices and maybe cloud monitoring 5. (bonus) coordinates with other appliances at the same site and/or other sites to make sure that one ISP at each has traffic flowing even if connection monitoring isn't working as expected Or even if I were to implement this via custom scripting in a non-Meraki device, I don't think it would be that complicated. I would label the cables going through the non-Meraki device and include instructions on how to physically bypass the appliance for each ISP.
... View more
Feb 2 2024
8:21 AM
Thank you for the suggestion! I was imagining this type of idea when I listed: "Ideas that might work for others, but that I would prefer to NOT explore: 1. routing all traffic via VPN to a service or cloud VM from Cisco/Meraki to handle WAN failover" But I may end up exploring this type of solution. Right now I'm only concerned with one site that requires quick WAN failover, but I would like to roll this out at 1-2 more sites eventually. This first site is in the Chicago loop. This is what Bard just told me about vMX compatibility with Chicagoland regions in AWS and Azure: AWS: Local Zones currently don't support the specific instance types required by the vMX AMI (m4.large, c5.large, c5.xlarge). Available instance types in Chicago Local Zones (T3, C5d, R5d, G4dn) are incompatible with the vMX software. Azure: Azure doesn't offer a region specifically for Chicago. The closest region is "Central US", which doesn't guarantee local placement of your vMX instance. While vMX can be deployed on Azure, availability zones within regions limit Client VPN functionality. So, choosing an AZ for lower latency might restrict Client VPN access. So even putting vMX licensing and compute costs aside, there would be significant latency increase on each traffic which will likely limit speeds over TCP. Another type of option in this category might be Umbrella’s cloud-delivered firewall, which has a cluster in Chicago, but I don't know if I would have to contend with the same sort of WAN failover issues to get traffic there.
... View more
Feb 2 2024
7:53 AM
That was my first idea that I listed. Or at least, that was what I was attempting to describe. "1. Add a router upstream of the MX pair that handles all connection monitoring and routing. One obvious complication is that I would need to setup NPT upstream of the MX for IPv6 support."
... View more
Feb 2 2024
7:52 AM
Also, I didn't want to include this on the main post as it doesn't directly address the issue, but I am planning on using routing on DNS server IPs to attempt to mitigate DNS failures during a WAN failure or degradation event. This would be the routing to Umbrella DNS resolvers: IPv4 IPv6 Description 208.67.222.222 2620:119:35::35 Primary [Auto] 208.67.220.220 2620:119:53::53 Secondary [WAN2 always] 208.67.220.222 n/a Tertiary [Auto] 208.67.222.220 n/a Quaternary [WAN2 always] 208.67.221.76 2620:119:17::76 USA only Primary [Auto] 208.67.223.76 2620:119:76::76 USA only Secondary [WAN2 always] I have not yet run packet captures and testing to confirm that the Umbrella agent (or what may now also be an Umbrella module of the Cisco Secure agent) actually uses those addresses in the order specified by Umbrella to resolve DNS queries.
... View more
Feb 2 2024
7:42 AM
So based on the documentation and a few forum posts, the MX connection monitoring process takes 5-6 minutes for any kind of failover between WAN uplinks (including starting a graceful failover on WAN2) for a non-link failure. This means that unless the MX sees the uplink go down entirely, it will take over five minutes for traffic to use the backup ISP. And if there is an MX pair, then an uplink failure would only mean that my switch between MXes and the ISP went down, which means that even if the ISP router went offline, that it would not be seen as a link failure anyways on the MX. Since I am beginning to plan for a new network project, I would like to gather ideas on how I might be able to reduce the time it takes for traffic to shift to WAN2. Here are my current ideas: 1. Add a router upstream of the MX pair that handles all connection monitoring and routing. One obvious complication is that I would need to setup NPT upstream of the MX for IPv6 support. 2. Setup a non-Meraki device between the MX pair and each ISP. This non-Meraki device would both (1) provide L2 bridging between the ISP and the MX(es) and (2) use a WAN IP address to constantly test the connection health. Then I would setup scripting disable the port(s) connected MX(es). I currently like this idea the most. The only disadvantage besides hardware cost and solution development/management time seems to be the loss of 'native' MX uplink monitoring while the port is disabled by the non-Meraki device; but even this very minor issue could be mitigated by another MX/Meraki on older MX hardware. 3. Explore whether any ISPs serving the building can provide a DIA circuit with L2 redundancy to multiple routers on their side. Then consider if the potentially exorbitant costs for such a service would be worthwhile. This would also still require a separate switch. Ideas that might work for others, but that I would prefer to NOT explore: 1. routing all traffic via VPN to a service or cloud VM from Cisco/Meraki to handle WAN failover 2. adding non-standard routing downstream of the MX layer 3. paying for the "MX SD-WAN plus license" for the entire organization only to gain a partial WAN failover improvements by using SD-Internet. Does anyone have any other ideas and thoughts on how to reduce WAN failover time? Thank you all in advance!
... View more
Labels:
- Labels:
-
Firewall
Jan 11 2024
2:11 PM
What are the specific use cases for Wi-Fi 7 that apply to Meraki customers? This sounds like a matter of bragging rights. The only justification I can see is installing Wi-Fi 7 READY access points on the off-chance that there might be a use case before the Wi-Fi 8 standard is announced.
... View more
Jan 11 2024
2:01 PM
How about we start with Meraki devices being able to natively distribute DHCP leases based on MAC address filters like Windows Server has been able to do for 15+ years? Yes, I know that all sorts of things can be done with ISE, but that defeats the point of cloud-based system like Meraki.
... View more
Dec 27 2023
2:28 PM
If you're looking at testing tuning options related to WiFi roaming, I would also consider tweaking the _client_ roaming aggressiveness. Here's a doc for the intel driver: https://www.dell.com/support/kbdoc/en-mk/000132395/change-the-intel-advanced-wi-fi-adapter-settings-to-improve-slow-performance-and-intermittent-connections Roaming aggressiveness can also be set via powershell: https://answers.microsoft.com/en-us/windows/forum/all/roaming-aggressiveness-doesnt-change-anything/52890427-78de-4aa6-9eba-0456041addf3 Set-NetAdapteradvancedProperty -Name “Wi-Fi” -DisplayName “Roaming Aggressiveness” –DisplayValue “1. Lowest” Set-NetAdapteradvancedProperty -Name “Wi-Fi” -DisplayName “Roaming Aggressiveness” –DisplayValue “5. Highest”
... View more
Dec 6 2023
8:33 PM
This is great. That means that all MR devices listed in the current MR family datasheet have a scanning radio 802.11.
... View more
Dec 6 2023
8:30 PM
I completely misread the documentation and am appropriately embarrassed. That said, I still stand by my comments earlier arguing that almost everyone should stay away from all release candidates, even if they are labelled as stable, unless (1) there is a very specific known security fix, (2) a device is experiencing a major issue that Meraki support says will be fixed by a specific release candidate, or (3) an organization has enough extra Meraki gear, time and interest in testing release candidates. But to partially address item #1, the documentation says that "Critical updates, such as those to address high-impact security vulnerabilities, may be scheduled on a shorter timeline." I worry that I would be told by support to upgrade/rollback if on a release candidate since "The latest stable release candidate firmware is fully supported by our Support and Engineering teams. Older stable release candidates are supported with best effort; an upgrade to the latest beta, stable release candidate, or stable will ensure full support. "
... View more
Dec 6 2023
8:07 PM
@Ryan_Miles Thank you again for your help. That sounds great, but how does that square with the language I referenced in the Stable Release Candidate section? "These upgrades can be canceled, modified, or reverted using the firmware upgrade tool on dashboard." Does the documentation for the Firmware Upgrade Release Process need to be updated to reflect the information you provided?
... View more
Dec 6 2023
8:03 PM
The new AP Neighbors feature documentation says that a scanning radio is required, but I can't find any information in datasheets or official documentation. https://documentation.meraki.com/MR/AP_Neighbors I just found a few forum posts where people mentioned MRdevices that do and do not have scanning radios: https://community.meraki.com/t5/Wireless-LAN/MR20-vs-MR33-gt-Security-and-Scanning-Radio-Blue-Tooth/m-p/73331#M11196 https://community.meraki.com/t5/Wireless-LAN/Buying-options-for-a-single-user-and-for-learning-purposes-only/m-p/210017#M28890 I also looked at the firmware features page to see if it listed model-specific information there for this feature, but for some reason the feature isn't listed there. Maybe the features or necessary firmware version isn't listed because the firmware is still in public beta. But at the same time, the MX firmware page lists beta firmware features. Is this beta too new to have a public version number? https://documentation.meraki.com/Firmware_Features/Wireless_(MR)_Firmware_Features_Directory https://documentation.meraki.com/Firmware_Features/Security_and_SD-WAN_(MX%2CZ)_Features_Directory Can anyone tell me how to determine which MR devices have scanning radios? Or, is there that one weird trick your Meraki engineer doesn't want you to know? And are there different kinds of scanning radios to be aware of? Or, does one have to scour all of the MR datasheets to see which ones list dual-band scanning or just bluetooth scanning? And why does PMF on 6GHz result in no scanning radios on that band, at least per the MR 57 datasheet? https://documentation.meraki.com/MR/MR_Overview_and_Specifications/MR57_Datasheet
... View more
Dec 6 2023
7:03 PM
@Ryan_Miles I really appreciate explaining this and steering me on the right path. I would be happy to reach out to my contacts at Cisco to ask more about this before making any future Meraki license purchases. I hope that the co-termination documents can be improved by the appropriate parties at Cisco to make this information more clear for others. And now I know that simply ordering the three or five year license on a new device may actually not save any money in the long-term depending on the number/type of devices in-use and that will likely be not-in-use before the co-termination expiration date. Because even if I'm sure that a new Meraki device will be in service for the three or five year term, purchasing a longer license may be the wrong choice from an organizational perspective, if it is done with the expectation that paying more now will reduce future costs because it will delay the co-termination date which might be the only opportunity to stop paying to license devices that are not in use. I feel like I'm shooting the messenger. Thank you again @Ryan_Miles .
... View more
Dec 6 2023
6:33 PM
So under co-termination, is there any way to extend the license expiration if one removed/turned off Meraki equipment? I'm trying to understand if there's any sort of proration possible under any scenario without waiting until the license expiration. If not, it seems like the only approach might be to minimize the number of years of licenses associated with new equipment so the co-term license expiration would also be sooner so that the licenses paid for would be mapped to the devices in use.
... View more
Dec 6 2023
6:08 PM
I don't understand this, so it would be really great to get clarification. The "The Science behind Licensing Co-Termination" document always refers to devices needing to be both "purchased and activated". https://documentation.meraki.com/General_Administration/Licensing/Meraki_Co-Termination_Licensing_Overview/The_Science_behind_Licensing_Co-Termination The "Meraki Co-Termination Licensing Overview" mentions "active devices" which I read as devices that are part of a network in the dashboard. https://documentation.meraki.com/General_Administration/Licensing/Meraki_Co-Termination_Licensing_Overview I had always assumed that this happen when a device was first added to a network. Am I to understand that the license usage start immediately, even before devices are claimed into an organization? And if true, does that (perhaps obviously) mean that organizations would save money in many cases by only ordering licenses on the same order as hardware if there is a chance that not all hardware will be immediately deployed? It seems that with the 30-day grace period that this would make this very doable. And this could add up since the base price listed publicly (on that page) for the MX250 is $10,000.00. Adding up licensing costs for a few devices, and an extra bit of paperwork might be worthwhile. I don't expect to change any minds, and I don't expect to migrate to a new subscription modality. But I would like to better understand what I'm missing when reading the documentation. I'm assuming that it is clear and that I am just not reading the documentation correctly
... View more
Dec 6 2023
5:34 PM
Agreed. I have read the documentation: https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Managing_Firmware_Upgrades https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Cisco_Meraki_Firmware_FAQ https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Meraki_Firmware_Release_Process From what I read, if one upgraded to the most recent stable release candidate, then a new stable (or potentially not-classified-as stable) release candidate being released will only be support with "best effort". Quoth the Release Process documentation: "The latest stable release candidate firmware is fully supported by our Support and Engineering teams. Older stable release candidates are supported with best effort; an upgrade to the latest beta, stable release candidate, or stable will ensure full support. " To me this suggests that one should absolutely stay away from all release candidates, even if they are labelled as stable, unless (1) there is a very specific known security fix, (2) a device is experiencing a major issue that Meraki support says will be fixed by a specific release candidate, or (3) an organization has enough extra Meraki gear, time and interest in testing release candidates. But to partially address item #1, the documentation says that "Critical updates, such as those to address high-impact security vulnerabilities, may be scheduled on a shorter timeline." Quoting again from the Release Candidate documentation on the "Stable Release Candidate" section: "These upgrades can be canceled, modified, or reverted using the firmware upgrade tool on dashboard." That seems scary to me, but maybe reverting is easy if one just opens a support case. I'm happy to be wrong, corrected or exposed to other opinions on the utility/scariness of pushing the Stable Release Candidate to any production (or soon-to-be-production) device.
... View more
Dec 6 2023
5:26 PM
I guess I didn't read that doc to the end. Thank you! I'm still not sure one would configure the SSID, and potentially other configuration elements. But it's not a problem I need to solve today.
... View more
Dec 6 2023
5:18 PM
I haven't labbed this, but what you are describing seems to run counter to the "Extending the LAN and Configuring Network Segmentation" section where it says that allowing connectivity to any VLAN other than the one used on the wireless link "does require a layer 3 switch due to the nature of 802.11 frames preventing multiple VLAN IDs from traversing the wireless bridge link." I can see in my console where it has the pop-up menu for "Clients wired directly to Meraki access points" and then lists the SSIDs for the network. How have you set this up to allow for Layer 2 roaming to wired devices for multiple VLANs across one wireless link? What does support enable or setup when you engage them? This makes me wonder what other features are hidden like gnomes only to be revealed by calling Meraki support to ask for things that the documentation says are not possible.
... View more
Dec 5 2023
2:59 PM
1 Kudo
"Everybody has a testing environment. Some people are lucky enough enough to have a totally separate environment to run production in."
... View more
Dec 4 2023
7:56 AM
5 Kudos
It would be very helpful if Meraki would let us know what types of Wi-Fi integration with AAD/Entra/SAML and Intune are in the pipeline so we can better make decision on whether to (1) continue to configure Wi-Fi auth manually/non-granularly, (2) develop custom tooling (open sourced, if possible), or (3) seriously explore marketplace solutions that might be overkill or misaligned with basic use cases.
... View more
100% agree. I would also review the STP Guard settings on all the ports to make sure it is intended and in alignment with Meraki documentation and best practices. And as always, remember that MX firewalls do not participate in STP. Configuration: https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Configuring_Spanning_Tree_on_Meraki_Switches_(MS) https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Spanning_Tree_Protocol_(STP)_Overview <- this links to a basic eLearning module that might be helpful, esp. if there are other switches in your network Design docs: https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MS_Switching/General_MS_Best_Practices https://documentation.meraki.com/MS/Meraki_Campus_LAN%3B_Planning%2C_Design_Guidelines_and_Best_Practices
... View more
Dec 2 2023
1:17 AM
Just ask Comcast for a /29 WAN range. Inform them, if accurate, that you will/might be setting up an HA firewall and need 2-3 public IP addresses. It's also handy to have at least a /29 for testing and firewall migrations.
... View more
- « Previous
- Next »
Kudos given to
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 4324 | Apr 10 2024 4:52 PM | |
| 2276 | Feb 2 2024 9:34 AM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 5 | 846 | |
| 5 | 62893 | |
| 4 | 1618 | |
| 4 | 900 | |
| 3 | 733 |
© 2024 Cisco Systems, Inc.
