@bbayles That doesn't sound like expected behavior to me. Might be worth giving Support a quick ring and having them validate. ... View more

Hi @Squuiid, I definitely hear your concern. Given the delay, the MX team is going to be moving a version of r12 that contains all of the security updates available in r13/14+ to SRC very soon; likely within the next week.  ... View more

Hi @Philippe. The topology page is populated using LLDP and CDP inputs received on Meraki switches.    If you're not seeing the catalyst switch, I'd first double-check that CDP is enabled on it's connected interface. If it is, it might be worth giving Meraki Support a call to see if they have any additional compatibility insight. ... View more

Correct on both. ... View more

@jordeliason, Here's a quick explanation from the AMP KB.   The MX Security Appliance will block HTTP-based file downloads based on the disposition received from the AMP cloud. If the MX receives a disposition of malicious for the file download, it will be blocked. If the MX receives a disposition of clean or unknown, the file download will be allowed to complete.   The supported file types for inspection are: MS OLE2 (.doc, .xls, .ppt) MS Cabinet (Microsoft compression type) MS EXE ELF (Linux executable) Mach-O/Unibin (OSX executable) Java (class/bytecode, jar, serialization) PDF ZIP (regular and spanned)* EICAR (standardized test file) SWF (shockwave flash 6, 13, and uncompressed)   * This includes the inspection of XML-based Microsoft Office file types (.docx, .xlsx, etc...). ... View more

@JPAWELCHAK, I'm not on the Meraki Product team, so I'll my responses here are purely from someone who's also in the field interacting with this stuff on a daily basis.  There has never been a firmware release schedule, but rather a fairly common 3-4 release cycles per CY. This is clearly well beyond that and they're working to ship this GA as soon as they're able. My understanding is that the last major obstacle to that process is working with a couple of the largest ISPs who use cable modems that don't play with with the new MX static WAN IP assignment in Dashboard. That includes a fail-to-DHCP mechanism which some mainline modems don't respect.    Hopefully that's useful insight. ... View more

This might be a useful read as well. I put that together as a way of documenting MX warm spare deployment best practices and considerations. https://willette.works/mx-warm-spare/ ... View more

In fairness, it is considered stable. The name Stable Release Candidate was used for that reason. ... View more

@JPAWELCHAK I definitely get where you're coming from here. The current MX GA is long in the tooth and many great enhancements and bug fixes have been available in wired13 for some time now. A couple thoughts here: The Meraki product teams recently made significant changes to the firmware release process to provide more structure, provide better QA, and also change the name on late-stage firmware from beta to stable release candidate (a label that more accurately reflects the code) Introducing stable RC step added additional bake time requirements to the existing MX beta cycle, which I wouldn't expect going forward Checkout the details here. Note the 20% of customers running the stable RC requirement before going GA. This is why you see Dashboard and email prompts to try the new firmware. More customers running RC for the feature enhancements means GA ships sooner. I can tell you that we (Meraki) want to move to wired13 as badly as our customers. We also want to ensure our firmware QA process is mature. This round is unusually long because of that. I'm on your side here but hope that helps provide some color on the situation. ... View more

All configuration for the MX65W's wireless configuration must be done under the Security appliance > Wireless settings page. There, you can see that Meraki Authentication is not currently a supported SSID auth method.   ... View more

The next hop IP should not be the MX84 IP address. It should be the IP address of the "next hop" towards your internal LAN. Essentially the IP address of the device you have the MX connected to on the LAN-side. Most likely a L3 switch interface or router. ... View more

Assuming your DC MX84 is in NAT mode, then you would need to add a static route for b.b.b.b/32 on your MX84 appliance under Addressing & VLANs with a next hop of a router/switch connected to one of the local, internal subnets. Make sure you select "in VPN, yes". That will inject the route into the AutoVPN global route table and tell the MX64 peer to send all traffic destined for b.b.b.b tunneled to the MX84 first.   ... View more

@AnythingHosted If I'm tracking with what you're trying to get to, then this should be a fairly simple fix but depends on the AutoVPN posture of your DC MX84. If you go to Dashboard > Select your MX84 Network > Security appliance > Addressing & VLANs, are you running in NAT mode or concentrator? Both are supported AutoVPN roles for a DC deployment, but the way routes are injected into the AutoVPN table for remote MX peers is different.   Knowing if it's NAT mode or concentrator should help us guide you towards a solution. ... View more

They pushed an MX template enhancement last week that allows child MX networks' uplink bandwidth sliders to override the template uplink settings. This unlocks the ability to optimize the WAN bandwidth settings on a per-site basis.   That might solve most of your issue.         ... View more