Yes, I’ve sent you backup file, Ticket#2011081966000477, hoping you will be able to reproduce it.
So it seems that problem is with L2MTU set to 2030. I can reset configuration, set L2MTU (not MTU!) to 2030 and connection is lost immediately. Perhaps I have not understood meaning of L2MTU well 
But why this was working in 5.5?
To finish this story: I’ve got response from support - problem is related to L2MTU and will be fixed for the next RouterOS release. So don’t use L2MTU higher than 2020 in SXT with version 5.6.
Hello Folks!
Is NV2 now stable to use in production or is suggestion to wait still some releases of routeros ?
I still see lot of fuzz regarding disconnection issues with NV2.
Well when MT say they cannot reproduce some of the on going disconnection issues in their test lab, effected users have sent in debug logs, we still await a solution from MT for this but it’s your call to use NV2 in production it may work flawlessly for you or cause you problems, there is only one way to answer the question you have asked (test)
Okey, i will give it a try in production on one smaller sector over the remaining weekend and possibly full next week to see how it behaves. The LAB tests here show good results in half year tests.
Hi ´steen´, as you could see in this forum, I had many issues with pre 5.6 releases and NV2. My whole network (+/- 250 radio’s in 15km radius with 16 AP’s) is now in 5Ghz upper band (200Mhz wide) working with NV2 and v5.6. I have no more disconnect issues like before that are NV2 related.
Users still should understand though that NV2 needs better channel separation between competitive AP’s working the same band and clients can at times having problems with interferences due strong signals from other working frequencies than its own. But if the channels (10Mhz!) are chosen with caution the network runs fine…
With me it runs some 3 weeks now in all v5.6ROS + updated firmwares and it has been long (pre NV2 era!) that I had such a stable network as I have now… 
Even the port flap issue still around is merely a ros notification issue than a real one. Although it is still wide spread over my network there seems to be not a single client noticing it. It only happens on Ethernet ports that are connected to 3rd party devices. I hardly see it between MT routers.
Maybe v5.7 might see some extra improvement here since it has improved Ethernet drivers (according newsletter) and hopefully the ´port flap´ issue has disappeared as well!
Lets hope, we have had rock solid network for years using nstreme here, customers exoect that also in future. Our network is in middle of town and willages, looot of interference. Directional antennas everywhere carefully aligned and placed, that pays off
Channel spacing is as big it can be to, shooting in different directions etc.
Our experience:
-
v5.6 solved our problem with /ip/route/cache where cache-size was growing and growing until it reached the max limit and then the router stopped respondng to all IP traffic. This happened in versions 4.x
-
CPU load of all RB433s and RB600 went up instead of down. RB600 that was under heavy load (75%) went to 95% and started causing serious problems - very high ping to certain interfaces (400ms or so on ethernet interface, no data overload, just high CPU).
-
Profiler tool is very usefull ! Was able to reduce CPU load by rearanging firewall rules and see the different.
-
On one RB433AH where the trafic is heavier (around 20Mbit) the router sometimes reboots without any reason. I thought it was because high CPU load - so rearanged firewall rules and reduced CPU load under 50%, but the problem occured again. Sent support.rif files to Mikrotik every time, but they did not reply or replied “upgrade to v5.8” which is not even stable yet - no, thank you.
-
After reboot (or power shut down, up) all graphing information is lost! This did not happen in version 4.x. Its a very sad thing to see.
Anybody has the same problem with rebooting and graphing?
IIRC the graphing issue is related to the NTP server package taking too long to sync the system clock, and when the graphs are updated the time gap causes it to clear them. If you don’t need the NTP server capabilities, using the simple NTP client rather than the separate package is supposed to avoid this. This has been reported by many people, so Mikrotik is aware of it, but sadly it seems to be a long, long way down their priority list.
IIRC the graphing issue is related to the NTP server package taking too long to sync the system clock, and when the graphs are updated the time gap causes it to clear them. If you don’t need the NTP server capabilities, using the simple NTP client rather than the separate package is supposed to avoid this. This has been reported by many people, so Mikrotik is aware of it, but sadly it seems to be a long, long way down their priority list.
I use NTP client and Im not using NTP server. So only disabling the NTP package will do the work? NTP client will be still working?
Yes, but it is actually the SNTP Client that will be working. They do basically the same job.
You can find it in /system sntp client (winbox), once you have disabled the NTP Package.