Hi @ all,

With regret I share with you some experiences about the Mikrotik products.

Initially just discovered the existence of these products I was very fascinated, and working in the telecommunications sector, given the affordable price I'm testing some models.
I bought almost all models of the RB700 series and after a first initial phase where I tried a bit to understand how they work, I encountered some problems.

The problems and bugs are part of any man-made system, and here comes in the intention to remedy these problems.
Support Mikrotik unfortunately leaves something to be desired, and the documentation is very poor.

An example:
- Finding a problem, are encouraged to sending files supout.rif in assistance
——协助回答我(再一次,每一次)pdate the OS, knowing well that have not worked on that problem to the new version and then the problem would be solved.
- The ticket is hardly the most watched.

In Cisco or FortiGate when a problem arises, if the problem is not resolved soon, it opens the scaling phase of ticket, and eventually somehow resolved.

Mikrotik is lost forever to release new versions, and never stabilize a version permanently.
联合国fortunately there is no true and sincere contact with the support, we could give users suggestions, in fact many of us are engineers and could participate actively in solving problems, which may be found in products like theirs.

What can I do with a "certified Mikrotik MTCNA", when their products even when properly configured have feeding problems, problems that cpu is used at 100% during read/write phase, problems to restarting the network interfaces, problem to recognize and make operate the usb wireless interfaces (AR9271) and many others problems?

Another example? For the read/write problem I have on or two suggestion
1) probably the nanya memory is too slow in order to write correctly all information.
2) the algorithm used to write is too old or has poor performance
3) why mikrotik doesn't specify what exactly is used in flash memory?

Mikrotik human resources is exact as "The Wall"

just my two cents

A.

ps sorry for my english

I wish I could write a similar story about my experience with RB433 - a device which made me invest in MT hardware and also attend MUM, but I don't have that much spare time now. Long links, short links, ptmp, ptp, big antennas, small antennas, ferrite tape, male/female connectors - it all works. I think it's mainly the success of MT wireless networking which has attracted people like me and you, but also the potential of bridging distant networks over VPN. There are certainly minor quirks that need to be ironed out, like those which you laid out, but it does not prevent me from making users happy, which live in places where no corporate ISP is willing to go to, because they are either too bureaucratic and too old fashioned or just don't get the benefits of 5Ghz.

We would like to give you additional support to help you accomplish your objective, please write support and we will try to help.

Please understand that in such a complex networking device, we need you to upgrade to the current version so that in case we are trying to reproduce the issue you report, we are at least seeing the same things happen. Also, changes in any code can and sometimes does have effects on features that would seem unrelated -- though not usually the case but all too common with the most difficult bugs --, debugging with both sides using the same version can save time and effort in finding the solution.

For hands on debugging and support of a complex configuration (that requires understanding your specific network configuration or checking multiple devices in you network) we suggest hiring a consultant. They will surely be cheaper than the support programs you commented on and could give your network hands on attention.

We would like to give you additional support to help you accomplish your objective, please write support and we will try to help.

Please understand that in such a complex networking device, we need you to upgrade to the current version so that in case we are trying to reproduce the issue you report, we are at least seeing the same things happen. Also, changes in any code can and sometimes does have effects on features that would seem unrelated -- though not usually the case but all too common with the most difficult bugs --, debugging with both sides using the same version can save time and effort in finding the solution.

For hands on debugging and support of a complex configuration (that requires understanding your specific network configuration or checking multiple devices in you network) we suggest hiring a consultant. They will surely be cheaper than the support programs you commented on and could give your network hands on attention.

Upgrading a production network to an untested ROS version simply isn't possible for alot of people, Until such time that MT release full changelog's we have to assume you've messed with everything.

Hiring a consultant isn't practical either as they dont have the access into the guts of ROS like you do, Cost isn't an issue for us - We'd pay ALOT in order to be able to log a P1 site down fault and have a MT engineer on the phone with us within an hour to figure out why it went down

Using MT products is only a viable option if you have required technical skills, have much time and are willing to do MT part of their job: testing and troubleshooting bugs (hoping for fixes of known bugs ("try next release" mantra) and finding out probable regressions).
MT and routerOS are in all sense "cheap".

Hard but true.
Wouldn't bring so much hard feelings if people didn't try to pretend it's not the case.