MX84 stops passing all traffic for 3 seconds after adding VLAN
I have an MX84 that stops passing traffic anytime I make a change to the addressing and VLANs page. Even if it has nothing to do with existing flows such as adding a VLAN, the issue occurs. I had a ticket open with Meraki for more than 2 years and earlier this month they finally came back and said this is by design. I do not have this issue on my MX100s or any other model for that matter. Seems like a function of an enterprise grade firewall to be able to make a config change and have traffic not stop for 3 to 5 seconds and then start up again. This problem also happens if I make a change to the DHCP page. Say I change DNS for one DHCP scope, once again the MX completely stops passing all traffic momentarily while the change is implemented.
Can anyone who has an MX84 confirm whether or not this is happening to you?
I have seen this once before. It was related to spanning tree.
Do you by chance have the MX84 dual connected to a switch?
As far as I am aware, anytime you make a change on the VLAN page all MX's bounce the ports (the old "by design" thing). Usually this is so quick you don't notice it. However if you have spanning tree in the picture this can cause spanning tree to stop forwarding while it re-learns.
The MX is not dual connected to a switch. When the MX was initially implemented we were using Dell switches with STP disabled across the board. Since then we've implemented the MS220-48 with RSTP enabled and the issue was the same in both scenarios. I did as a test disable STP in my network and added a test VLAN and experienced 2 timeouts during a constant ping. The bouncing of the ports is something that support mentioned. However I don't experience the lapse in connectivity at any of my other sites where I'm running MX100 and MX64 both with STP enabled and disabled. I think this is a flaw with the MX84 but would like to know if this is an issue with all MX84 deployments or just in my network. Meraki did at one point replace my MX with another but the issue persisted. We also tested with all infrastructure disconnected from the MX and just a laptop connected to a LAN port and same result.