Considering the HUGE difference in feature set, it is going to take EdgeOS some years to even reach feature parity with what RouterOS currently offers, and I cant imagine Mikrotik are exactly sitting on their hands.
Each will carve out their niche in the market, their is certainly room for both.
As for the original question. I use Juniper gear on a daily basis, as do I use Extreme Networks and Fortinet. What is the primary difference between these vendors and Mikrotik? Support.
I know I can log a TAC request directly with any of these vendors and someone will call me within the hour and no matter how large or small the issue is stay on the phone with me until the issue is resolved, or my configuration query is answered. I once spent 18 hours on the phone with Extreme’s TAC in Europe to resolve an issue. I have had countless tickets with these vendors escalated to “Confirmed Bug” status and have in most cases been provided with ETA’s on software patches, and in the cases of Juniper and Fortinet received custom software builds with our specific bugs resolved in them.
This support does not come cheap. On average, vendor support contracts cost around 1/3rd the purchase price of the equipment per year to the “End User”.
As a top tier partner, we are also able to log higher priority tickets. A facility most end users would not get with these vendors.
Maybe as a start towards a “tiered support model” Mikrotik could offer MTCRE/MTCWE and greater certified individuals the ability to log Priority 2 tickets, and MTCINE to log Priority 3 tickets. This would help filter out the noise, and allow people who have invested their time and money in Mikrotik to receive better support, rather than the log a ticket and wait for a response that may take a long time to come.
Of course this would most likely mean having a web based ticketing system. This could easily be integrated in to the “Account” section on http://www.mikrotik.com similar to how the “Try Development Version” feature is now, and could see the users current certification level and unlock the ability to log higher priority tickets.
Sales volume and market share is not just a matter of having certain features. Support, logistics, marketing, sales machine are important too. Of courese the presence of mandatory features is necessary. Now UBNT have more wireless market despite the fact that the MikroTik have more features. While the market is growing everyone can find their niche.
I understand that UBNT take time to debug and MikroTik is ahead here. But I do not know if you noticed, but I noted two fundamental features that immediately push forward UBNT. First general-purpose operating system at the basis. And second using a separate chip for data plane. And if the second advantage is controversial because advances in multi-core CPU can make this approach impractical. Then use such OS is a huge plus (IMHO).
How so? You yourself are an expert! Are you the one about whom it was written: “We rely on consultants, because we have so many and so good ones.” Why do you need to support yourself? That is to say support for support. As I expected, this model does not work well in practice.
I am not claiming to be an expert. I need support from Mikrotik as much as the next person, I was just putting my personal observation of the differences between Mikrotik and the “Big Boys” out there.
Consultants rely on MikroTik for support (they also need Training). Although of course, anyone can contact MikroTik directly, but reply time is 1-3 business days. We also have a Forum where anyone can ask questions while waiting for an answer from support. I guess you know that.
No I’m not comparing RouteOS with general-purpose operating system. I understand the advantages of specialized systems - ready to use out of the box, stability, ease of setup.
But all specialized platforms even if they work on the core of the general purpose system (as RouterOS) restrict the ability of their adaptation. At the same time as the ability to adapt of general OS are almost limitless.
UBNT EdgeMAX tries to combine advantages of both approaches. Make the system ready for use, with no loss of functionality of the base OS.
Fast-Path is far to transfer data plane on a separate chip. Just look at the list of restrictions when Fast-path is automatically used.
Although in terms of adaptation of control plane it is a big step forward. Software of control plane now understands about distributed processing.
when you have restricted environment and that is working for you - it is fine, when you grow out of it you have a problem. Either you have to upgrade using technology from your current provider or you have to go to new equipment provider. As far as RouterOS goes - you can get basic device that has restrictions on how well it can perform, but it is possible to use stuff from us to upgrade further while still being in same environment you are used to know. This gives you speed of deployment, gives you device upgrade path and device re-use when you expand your network. I do not see this in competition products you are so eager to promote on this technical forum.
And this is for most part me talking as home user. Who started out with RB532 when that device was all the rage, now updated with 802.11n card still provides wireless.
It’s no doubt that ROS hardware addresses most of networking needs, from wired to wireless, from edge to datacenter. However MT’s success is limited by lack of stability. Even rudimentary knowledge base about bugs and available features is nonexistent. Change logs are incomplete and lack detail. It’s pretty much left to end user to do live tests to see if features continue on working. Everyone does a lot of redundant work validating if features are working. Maybe having users as testers keeps the cost in check, but it certainly does keep MT from competing with Cisco/Juniper in deployments where downtime is money lost.
Your accusations are unfair. I did not endorse and I say not the name of the competitor first. I picked up this theme to make your platform better. Not because I’m an altruist, but because I like it, we use it, and I do not want to re-learn again to a new vendor. “I come in peace”
The discussion showed that your customers see the main problem in the support. For me, it was unexpected. But just as soon as I was surprised that our client has a problem between Mikrotik and Juniper J-series. Mikrotik had a very low rate for download. The study showed that the cause of the high CPU load by management process. The result was that the reason in sha1. If IPSec uses this hashing algorithm, this results in high CPU utilization and low speed. Changing in both sides to md5 solved the problem . Have such bugs in version ending with .22 just ugly.
The problem was solved independently without seeking support. But I imagine a situation that I would not have access to the Juniper router and I could not go to the md5. We would have to wait a few days and without warranties of positive results?
Can be that the most resentful write in topic and they are wrong about the support? Conduct a survey . But do not pretend that everything is going as it should. Or write honestly that such support as it is now was, is and will be a part of your business model. We are not little children we can all understand.
When I wrote this topic I did not know about Edge. Maybe they have not announced these products, and maybe it’s just I’m so “dumb”. But reading the information about inner voice said to me - “Hey guy. This is what you wanted. Inexpensive specialized system with high perfomnce and without restrictions in the underlying operating system.” Of course it can be that they will not work. But so far I can only say - MikroTik do the same and I’ll be happy. If I wrote a long document right now a few points I would replace this phrase.
why the bad implementation would not come from Juniper or Cisco side ?
are you aware of the routers crash generated by RIPE announcing specific options in BGP ? ROS was not affected
do you ever submit a bug to Juniper or Cisco ?
i did whith Juniper and i just get answers like :
please let us use your equipment for testing
this will be send to developers
we are aware of it and we cannot help you
we may try to fix it for next release
the hardware approach for CCR as been discussed 10 years ago when multicore processors where emerging
i remember clearly some explanation about connecting processors directly to IO avoiding routing dedicated processors
may be all is not perfect but i think Mikrotik is a clear competitor for existing routing equipment providers
we have setup networks with ROS and RB providing same stability and efficiency with 10 times less money
i think that Mikrotik approach implies that IT must also change the way they design networks
and start innovating not trying to just reproduce what they saw
I guess it comes back to the age old question? Would you rather do a bit of extra work and save a large amount of cash. Or do you spend big bucks and make it a no brainer? In the business were in we go for the first one and we love Mikrotik for giving us that chance. After all that’s actually their niche in the market if you think about it. If it was to change then maybe you would just have another Cisco or Juniper and then you may as well just buy them anyway if that’s what you want. In my opinion your also overstating the quality of Cisco etc and understating the quality of Mikrotik anyway. They all make the odd mistake. I have never come across any big problems with Mikrotik in over 10 years as long as you do a bit of work fining out the hardware requirements etc?
It’s all about the right tool for the job. If I need UTM features, I generally use something else. Otherwise, I’d rather spend little cash AND make it a no-brainer. Configuration is NOT difficult once you have gained the experience. Experience also lets you know what versions of RouterOS to install for your clients. Do I need to spend thousands of dollars or hundreds, when hundreds will actually net me better performance and greater features / flexibility? THAT is the no-brainer.
Proper use of production and test environments are not isolated to Mikrotik, nor are patches that take down networks – I’ve seen that plenty from Cisco.
As I expected, this model does not work well in practice.