Changing MTU on the interface is a disruptive process and causing the interface address to be reset, so I don't believe these log messages are giving much clue rather the logs may be expected on any QFX you change MTU on. Also check if the interface itself is flapping after the change? So you may just be masking the problem which temporarily fixes due to this reset, unless you have any technical reason like large packets getting dropped etc. that correlates to MTU.
It's better to spend a few minutes in troubleshooting when the issue occurs to get to the bottom of this. Some questions that come to mind are: a) Check if there are protocol adjacencies over the impacted trunks and if they remain stable. b) Check if all traffic is impacted or some? When you say VC stops handling packets, does it mean there's ingress but no egress? c) Check and clear interface statistics - for broadcast packet count, errors if any. d) Check if MAC learning works as expected: show ethernet-switching table show ethernet-switching mac-learning-log <<<<<<<<<<< e) Do we have STP enabled? Check if there's any frequent change topology changes. Etc.
You can keep "set system syslog file messages any any" to see if there's anything on the device logging at the time. However, from your notes, it seems as though traffic is not even coming in on this interface, is that right? If that's right, then there's a lot of possibilities here. It's impossible for the L3 protocols to be up and you won't learn any MAC addresses on the port. So better to take a copy of the MAC table "show ethernet-switching table" in working state and compare in non-working.
Also, you've shown two different interfaces altogether (ae0 and ge-0/0/24) does "ae0" have links in both FPCs and are these both expected to be uplinks or connect to complete different network segments? This data isn't given much meat to think about as far as I know.
It should be good if you open a case with JTAC. Those kinkd of issues requires some live troubleshooting. I may suspect of several things, but at the end a troubleshooting session is a better approach that just assuming things.
Those kind of situations most of times are related to memory leaks, high CPU, DDoS policers, file system corruption or a misprogramming issue.
Possible workarounds could be a mastership change, a reboot of the affected member or all members in a virtual-chassis, an upgrade or a format install. However, you will need some troubleshooting to determine the root cause.
I'm not sure if there is any traffic coming in to the interfaces when this happens. I will setup a mirror port to better be able to troubleshoot this and to see what actually is on the interface next time.
I did do a copy of the mac table when the problem was active, and compared it with the table once it was "fixed" and it was only missing mac-addresses on that port.
Ge-0/0/24 is connected to a different segment then what ae0 is, and ae0 only has one interface (from the same fpc as ge-0/0/24) at the moment.
There must be some logic to why this has happend to two different trunks/interfaces, there are lots of other interfaces and ae's that could be affected, i would like to narrow it down to whats causing this.
There surely must be some logfiles i could search in to find more information?
What happends in the switch/interface when mtu is changed?