Long list of bug fixes, but these two new behaviours mentioned in the end are a doozy.
These are really going to mess up customers, who don't expect their MX to randomly reboot because Dashboard Connectivity was lost.
Came here to comment that.
What. The. Hell.
My thought exactly.
Er! How is that deemed a good idea?
I have decided, after thinking about it, that I think this is a good idea.
8 hours without internet connection is a long time.
And we actually had a scenario yesterday where an local ISP did "something" so a lot of this customers Z3C and Z4 gateways on remote locations needed a reboot - this could have solved that problem.
I can see scenarios where this may be a good thing, but I can definitely also see ones where this may potentially wreck havoc.
Cloud connectivity != Internet connection
Just remember the next dashboard outage and when your MX will reboot every 8 hours , you might not enjoy that.
I know ..... but have the dashboard ever been away for 8+ hours ?
I mean, this is of course now in "Cisco / Merakis hands" never to have the dashboard be offline for more then 8 hours.
I've definitely seen internet connections where despite the ISP being restored the firewall (of whatever vendor) doesn't come online without a restart.
Outside of an over 8 hour dashboard outage, which certainly could happen, but has not in my memory, I'm curious what other scenarios folks think of that could cause issues? At least with my customers no internet means no operations.
Here to play devil's advocate on these:
It's not uncommon for network equipment to do this, similar to other Linux appliances. In the event of a process crash, a watchdog will attempt to restart it. If it crosses a threshold of multiple crashes within a timeframe or the process cannot be restarted, the watchdog triggers a device crash and restart. I'd rather that occur than certain components silently not working (Eg. firewall rules or IPS not applying, or logging suddenly stopping).
Despite the fact that I don't necessarily agree with this, I believe it's standard from version 17 and above:
"On firmware versions MX 17+ the MX will reboot after 8 hours without dashboard connectivity to support self-healing" - Behavior during Connection Loss to Cisco Meraki Cloud - Cisco Meraki Documentation
I'm 100% fine with the first point. However , how is rebooting the MX every 8 hours is helping at all ? I don't understand
Agreed, I'm not a fan of it either.
Just pointing out that I don't think it's new functionality specific to 19.x
Linux does try to recover services and watchdogs by restarting them. So fair point that it's not uncommon. But I have yet to see a Linux machine reboot completely by itself in order to recover from a services stopping.
True about Linux machines in general.
I was thinking more to Nexus switches which I have managed a lot of in the past. They would reboot with a reboot reason of a hap reset if there was a critical system process that had crashed and the watchdog could not recover it.
Usually this would be related to a bug causing the process to crash which got resolved in later versions.
And sorry for hijacking your usual good work, @cmr 😉
On a side note , this looks very similar to my old post. We had issues with MX85 not loading up when a large amount of vlans were configured.
https://community.meraki.com/t5/Security-SD-WAN/Maximum-vlan-limit-on-a-MX/m-p/235244
Who needs 350+ VLANs?
Long story short. "Security" asked to split all IOT devices in groups. HVAC , Cameras , card scanners and so on PER vlan and PER floor. We have a building with 80 floors. 6 groups ( vlans ) x 80 = insane amount of empty vlans 😀. Ugly design that I have to live with for another 12 months.
😂🤣
I bet those firewall rules were fun as well!
Oh man that's disgusting!
I've been through a similar scenario, and absolutely hate that kind of design.
Oh my, that is just insane! 😮
I think the auto-reboot function would be great providing:
* You can turn the functionality off in the dashboard with a tickbox per network.
* The reboot reason and crash data is uploaded to the cloud once connectivity is restored.
I think we can all agree that this is a good idea 🙂
So let me get this straight. They start to support an advanced feature like having eBGP over a non Meraki VPN tunnel but they still don't support something basic like a route based non Meraki VPN? I do question what features get priority...
How about:
- More rule granularity (L7 allow rules), IPS rules only on specific L3/4 rules
- STP and LACP support on the LAN ports
- Bouncing VPN sessions
- Viewing queue status and explicit configuration of the realtime queue.
- Viewing and killing of open firewall sessions.
I wish they had something like Sophos used to, where you could suggest a feature and the community voted on it. The ones with the top votes got considered and reasonably often got added. @AmyReyes could we do something here? 🙏
I'm not throwing stones at Meraki here but I do want to give my opinion.
The place I work at does several vendors for networking and security.
I'm a Cisco only guy, but I can impart my general networking knowledge to my colleagues doing other vendors.
The issue is that the security people also work alot with another vendor that starts with F and ends in T and find it very weird that things they can accomplish easily has no support in Meraki. And yes this is quite hard to defend it sometimes.
Funny thing was that on my last Cisco live I had a meet the engineer session and he told me they didn't expect that there would be so many people would be asking about LACP support on the MX and that it was pretty low on their priorities list and perhaps has to be reevaluated. Over half a year later, it's still not on the list...
I always think of F......t as more like FirePower or even SRX, which all need a networking expert. Whereas Meraki is much easier for generalists, but doesn't have all the bells and whistles that some people want. Personally I've never had an MX as an enterprise edge device, but they are great for SD-WAN, outbound protection, client VPN, data centre core and all those sorts of things.
True, I don't expect all the bells and whistles. However I do expect all basic must haves to finally come on MX'es so I don't have to excuse it all the time. Without LACP and STP support there are still weird issues happening that can't be helped.
Without more customization on the site 2 site VPN side you can't always integrate with other solutions.
Having no firewall rules on site 2 site non Meraki VPN's is definitely a big no no.
I agree that STP support really is a must, but I've never really missed LACP as the MXs can't generally run faster than a single 10Gb connection anyway and the new MX650 has 25Gb ports to cater for it's improved performance. But I do agree it should be supported.
LACP is not used for the speed. LACP is used so you can make simple bundels of 2 LAN ports to go to two members of the connected stack without having blocked ports.
The whole Meraki design is about simplified campus architecture by using stacks everywhere thus eliminating blocked links. However the MX appliance does not play ball here.
If we uplink another vendors firewall to the access or distribution stack (yes in smaller networks the firewalls get connected directly to the distribution switch). We can use 1 port channel per firewall and each of them have a port on both stackmembers. This is the most stable design and does not suffer from transient loops that occur on MX250's in our case each time we add or remove a VLAN.
Do you dual connect the MX250s? I'd generally just connect one MX to one switch and the other MX to another in the stack. If STP were supported I would dual connect.
MX75 upgraded 3 days ago, just crashed and rebooted, hopefully not a sign of things to come, 19.1.3 was rather stable for me...🤔
I had a weird thing happen to me as well.
"Shut / No shut" WAN 2 on my MX85, and it took down the network for, what felt like, a couple of minutes. 😕
WAN2 is connected to a MG, and WAN1 is of course just the normal internet connection, and WAN1 of course has the priority (just to be clear 🙂 )
A change on a WAN interface incurs a reset on all WAN interfaces. E.g. if you change the IP address on WAN2 - even if it's not connected - will reset both interfaces.
It's expected behaviour - https://documentation.meraki.com/MX/Monitoring_and_Reporting/Appliance_Status/MX_Uplink_Settings#Sec...
I never noticed that in the documentation.
Oh well .. not a bug ... but a "feature" then ... 🙂
Lol and also the LAN interfaces I see ... what kind of horror is this :
State (enabled/disabled) of any LAN interface
Neither did I, untill I was preparing a WAN port for a Internet circuit switch to a tagged VLAN, and my MX went Offline. I opened a case with Meraki, who then pointed me towards the behaviour. 🙂
I wasn't impressed either, to say the least.
Think I will wait before upgrading my MX75
Security and SD-WAN (MX,Z) Features Directory - Cisco Meraki Documentation
There is also now public documentation on the new features in the beta release, this info was lacking until recently.
Once "eBGP over non-Meraki site-to-site VPN connections" is configured on Hub MX, can those 3rd party prefixes/routes learned on MX Hub be propagated to other MX branches over Auto VPN?