RouterOS v7.0 beta1 - when?

kaidoe · Thu Mar 16, 2017 8:22 pm

+1 IGMP snooping, and full support for IPTV/multicast

Cheers !

Wyz4k · Tue May 16, 2017 6:00 am

I too would love to have this to start testing LTE on MC7304.

RogerWilco · Tue May 16, 2017 6:45 am

I too would love to have this to start testing LTE on MC7304.

+ 8.8 million for the MC7304.

jenechka · Tue May 16, 2017 2:04 pm

+ 8.8 million for the IGMP snooping

Tue May 23, 2017 1:43 am

Any time now guys...

Only 4 years overdue.

juliokato · Tue May 23, 2017 4:31 pm

By chance will version 7 not run on soho devices?

pe1chl · Tue May 23, 2017 4:52 pm

Any time now guys...

Was this presented on a MUM? Was it by MikroTik?

Chupaka · Tue May 23, 2017 5:37 pm

Yes, it was on MUM. On US MUM in 2014

https://mum.mikrotik.com//presentations/US14/ccrros.pdf

paulct · Tue May 23, 2017 6:42 pm

Yes, it was on MUM. On US MUM in 2014

https://mum.mikrotik.com//presentations/US14/ccrros.pdf

Too many bud lights that day....

Railander · Thu Jun 01, 2017 11:11 am

ack · Sun Jun 11, 2017 12:40 am

Dear MikroTik team and Dear Developers,

Like most people here, we are waiting ROS v7.0 like our Christmas toy, but although the wait has been long, we won’t blame you. Everybody that had to manage a complex programming project will know that it takes a lot of time and effort to get proper work, especially when having to interact with RFC and many not-so-standard features to include.

My one and only concern (for improvement) is the lack of communication and vision from the company itself. While we do not expect to get a date if you can’t commit, we could be all interested to know what is going on behind the curtains. We all know that we will have to wait for a proper result, but there is for sure a roadmap, goals and tracking of them.

Unlike most other vendors, MikroTik is way more than just a brand. It is a different attitude, a real community and a very versatile and flexible system. I wished with ROS v7.0+ that the hardware becomes as well more high-end with more high-speed port density, while keeping very cheap entry-level devices too, so we can have one experience from SOHO all the way to carrier-grade routers.

However, we have not given up and we look forward to hearing soon that somebody big is coming.

/troll on

/troll off

Milan · Tue Jul 11, 2017 12:25 am

I have small LAN and my provider gives me IPv6 /64 network, but I'm not able to use it in my internal infrastructure yet (I have few routed LANs with UTP and WiFi).

Also I have bigger LAN, where I do NAT for IPv4 and when something change, I'm not able to fix IPv6 at the same time as IPv4, as I have no NAT for IPv6. This drives me crazy and is a showstopper why to not deploy IPv6 at every place it could be (until RouterOS with IPv6 NAT). Also this is a reason why to not use/suggest Mikrotik at all.
You need to talk to your provider. This is insane! We certainly need to avoid getting NAT everywhere for reasons
like that. I get a /48 from my provider on a consumer connection, which can be argued to be a bit large, but any
provider should at least give a /60 or /56 to a customer that has a (home) router.
/64 can only be reasonably given to e.g. a rack in a colocation environment where the provider does the routing.

Do not mess up IPv6 NAT (wich is must have)[1] and IPV6 masquerade (not needed).

[1] what I have to do when something breaks and I have to move service/server in internal LAN? I simply do NAT (1:1), but it is possible with IPv4 only, not with IPv6. This is why one needs IPv6 NAT (to be able to do a fix in minutes/seconds, not in hours because of IPv6 address change and DNS caching issues).

Fri Jul 14, 2017 11:07 am

+ 8.8 million for the IGMP snooping

Already in v6
*)bridge - implemented software based "igmp-snooping"

pe1chl · Fri Jul 14, 2017 12:19 pm

I have small LAN and my provider gives me IPv6 /64 network, but I'm not able to use it in my internal infrastructure yet (I have few routed LANs with UTP and WiFi).
You need to talk to your provider. This is insane!
Do not mess up IPv6 NAT (wich is must have)[1] and IPV6 masquerade (not needed).

I agree that it is useful to have IPv6 prefix translation (1:1 NAT of entire /64 networks) but that is not related to your "my provider gives me IPv6 /64 network"
which cannot be worked around by prefix translation (when you want to have separate networks for yourself an guests, for example, or want to route internally).
Providers that give only a /64 to their customers really need to study IPv6 again and re-do their rollout before it is too late.
It should not be the task of router manufacturers to devise all kinds of workarounds for situations like that.

For prefix translation, there are some good use cases. Also see the writeups done by user ZeroByte about this matter.

jenechka · Mon Jul 31, 2017 3:56 am

Already in v6
*)bridge - implemented software based "igmp-snooping"

thank you so much, how to configure this feature to work correctly?

Insanityflea · Fri Aug 25, 2017 8:10 am

I'm just waiting for more LTE driver support which on the wiki states coming in ROS V7. At this rate I might as well look for another device haha.

Xtreme512 · Sat Sep 02, 2017 7:45 pm

as of feb 2017, cake took place of fq_codel now. as in the description of cake, it looks like PCQ to me (equal bandwidth in src, dst address).

There is piece_of_cake for trees I guess... I wonder what are the differences between HTB that we use in routeros.

jspool · Sat Sep 02, 2017 9:15 pm

If they rush a alpha level product out the door the response would be more negative as many expect it to work near perfectly upon release. I hope that they use it internally for the time needed to work out the basic bugs prior to a public release. Of course the longer they wait to release the more is expected from the release as people are looking at the amount of time it has been under development.
Once released the myriad of users will use it in varying ways that testing cannot simulate and then the real bugs can be worked out.

russman · Wed Sep 06, 2017 7:44 pm

Yes, it was on MUM. On US MUM in 2014

https://mum.mikrotik.com//presentations/US14/ccrros.pdf

In the pdf you referenced from 2014, it talks about, v6.8 I haven't seen anything beyond 6.41 in RC or beta yet in 2017. Where are these being released at?

jspool · Wed Sep 06, 2017 7:53 pm

Yes, it was on MUM. On US MUM in 2014

https://mum.mikrotik.com//presentations/US14/ccrros.pdf
In the pdf you referenced from 2014, it talks about, v6.8 I haven't seen anything beyond 6.41 in RC or beta yet in 2017. Where are these being released at?

6.8 was released in Jan of 2014: What's new in 6.8 (2014-Jan-29 15:52)
As math goes 41 is higher than 8.

Anyway thanks for the chuckle.

ziegenberg · Fri Sep 08, 2017 9:42 pm

Do not ask for v7.0 beta1, instead ask for 7.0 alpha. Maybe we'll get a different answer...

blackmesawireless · Thu Sep 14, 2017 11:41 pm

Starting to think it's the Duke Nukem Forever of RouterOS.

It'll come out about a decade after it was expected and suck.

patrick7 · Mon Sep 18, 2017 8:20 pm

Any news?

JimmyNyholm · Thu Sep 21, 2017 2:17 pm

An alfa to play in the lab would be most welcome.....

maara · Sun Oct 15, 2017 9:54 pm

This is getting ridiculous....

patrick7 · Sun Oct 15, 2017 11:16 pm

Stop asking and switch to another vendor

.

nadeu · Wed Oct 18, 2017 8:40 pm

Stop asking and switch to another vendor .

I'm currently switching to another vendor. Cumulus on ONIE + router.

More than 240Mpps of performance, tested.

7Tb/s with prefixes that are loaded on TCAM module.

Regards,

patrick7 · Thu Oct 19, 2017 12:20 am

I have replaced CCRs mostly with Supermicro 5018D-FN8T + debian + FRR. Works like a charm.

Murmaider · Thu Oct 19, 2017 7:52 am

Stop asking and switch to another vendor .
I'm currently switching to another vendor. Cumulus on ONIE + router.

More than 240Mpps of performance, tested.
7Tb/s with prefixes that are loaded on TCAM module.

Regards,

What vendor has routers with ONIE?
I thought this was only for sdn switches.

jmginer · Sun Nov 05, 2017 1:36 pm

We bought a year ago a CCR1072,
We are using with 4 peers providing us full routing and with more than 800 filters.
After a reboot, it takes more than 2 hours to apply all routes and filters and it's only using 2% of CPU.
Resume: Sh it product.

Sun Nov 05, 2017 8:29 pm

We bought a year ago a CCR1072,
We are using with 4 peers providing us full routing and with more than 800 filters.
After a reboot, it takes more than 2 hours to apply all routes and filters and it's only using 2% of CPU.
Resume: Sh it product.

That is a lot of route filters for such a small number of peers !

jmginer · Mon Nov 06, 2017 4:42 pm

That is a lot of route filters for such a small number of peers !

One peer is IX point, with a lot of members.

+300 filters based on different members of the IX and for different /24 subnets.
+500 filters setting a BGP-Local-Pref based on the BGP-AS-Path.

pe1chl · Mon Nov 06, 2017 11:47 pm

We bought a year ago a CCR1072,
We are using with 4 peers providing us full routing and with more than 800 filters.
After a reboot, it takes more than 2 hours to apply all routes and filters and it's only using 2% of CPU.
Resume: Sh it product.

The problem is that it has a 72-core processor but the BGP update task is single-threaded so it uses only 1 of the 72 cores.
The remaining cores are available for routing.
It is apparently not so easy to write a multithreaded BGP implementation, the easiest is to have a separate thread for each instance but that will probably not buy you much.
In circumstances like this, the router would benefit more from a higher clockrate than from so many cores.

alibalalo · Wed Nov 08, 2017 10:45 am

Please find a solution to the programs and hide the MAC and find a solution to the problem of connecting tp Link WDS

alibalalo · Wed Nov 08, 2017 10:45 am

You must find a solution to the problem of Internet theft through the Mac

Thu Nov 09, 2017 10:17 pm

You must find a solution to the problem of Internet theft through the Mac

MAC-based authentication/accounting is broken in general because it is trivial to spoof MAC addresses. The solution is to utilize some higher level of AAA such as PPPoE or WPA2-Enterprise

jenechka · Wed Nov 22, 2017 6:31 pm

+ 8.8 million for the IGMP snooping
Already in v6
*)bridge - implemented software based "igmp-snooping"

how to configure it ?

Chupaka · Thu Nov 23, 2017 7:28 am

how to configure it ?

Currently available only in 6.41rc

[admin@RouterOS-Testing] /interface bridge set 0 igmp-snooping=
no  yes

StubArea51 · Wed Dec 06, 2017 7:08 pm

Dear Santa Claus,

I would like RouterOS v7 for Christmas

juliokato · Wed Dec 06, 2017 7:27 pm

Dear Santa Claus,

I would like RouterOS v7 for Christmas

of which year?

patrick7 · Wed Dec 06, 2017 8:11 pm

I'm sure we'll not survive that year.

gringoZ · Thu Dec 07, 2017 12:25 pm

Dear Santa

This year i would like a intel i210 nic support at mt ros 6.x or mt ros v7 (is exists)

please please see my post from past: viewtopic.php?f=2&t=94834

we are very patient...

Thu Dec 07, 2017 2:50 pm

Dear gringo,
Santa is also only a man. This Christmas you can get 6.40.6 at maximum, if you behaved well all the year. Please, stay tuned and train your patience.
Your Santa.

StubArea51 · Thu Dec 07, 2017 5:02 pm

Dear Santa Claus,

I would like RouterOS v7 for Christmas
of which year?

2017...I'm hoping for a Christmas Miracle

cgood · Fri Dec 08, 2017 12:59 pm

Just for an example. Less about OpenVPN TCP. We have more than 100 connected clients (ROS/Linux devices) to CHR (1G RAM P1 lic) - all use TCP. Speed-test between two VPS connected to CHR via ovpn-client:

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  22.8 MBytes  19.1 Mbits/sec   41             sender
[  4]   0.00-10.00  sec  22.0 MBytes  18.4 Mbits/sec                  receiver
[  6]   0.00-10.00  sec  14.1 MBytes  11.8 Mbits/sec   38             sender
[  6]   0.00-10.00  sec  13.4 MBytes  11.2 Mbits/sec                  receiver
[SUM]   0.00-10.00  sec  36.9 MBytes  31.0 Mbits/sec   79             sender
[SUM]   0.00-10.00  sec  35.4 MBytes  29.7 Mbits/sec                  receiver
iperf Done.

And with all nice features of OpenVPN we with impatience expect UDP support

shaoranrch · Fri Dec 08, 2017 3:42 pm

+1 On this request, please tell us when, the faster you release the faster we can test and give feedback for you to perfect it.

I mainly work in the carrier side, we use MikroTik a lot but some things we do miss, specially related to the BGP and MPLS side...

Your brand has been quickly evolving from a "well I know it I use it in some small projects" to one that powers backbones of not-so-small ISP and DC networks, it's also used in research fields and to build systems for harsh environments (I saw "internet bots" in a coal mine powered by MikroTik).

We really need all the promises (and more) made for this version.

freemannnn · Fri Dec 08, 2017 3:58 pm

that reminds me of apple with IOS11. full of bugs for new features that some care and some dont care. i prefer an IOS10 shiny than a shitty IOS11. fortunately i stayed at 10.3.3 on my iphone.
and not to forget IOS11 removed showing mac address of devices in usefull aplications like FING, NET ANALYZER.

patrick7 · Fri Dec 08, 2017 6:10 pm

Stop asking, you're wasting your time...
Switch to plain linux, problem solved.

Steveocee · Fri Dec 08, 2017 10:20 pm

Mikrotik wont release a v7. There is so much hype built over it that it won't surprise me if they completely jump a gen to 8 or even go all out and release a new naming convention.
v7 is the embarrassment of the family mocked heavily by all within the MikroTik community.

Fair play to the devs though for constantly working on current software and not leaving us in the lurch whilst they develop new stuff.

WireDick · Sun Dec 10, 2017 3:33 pm

Could we expect hardware acceleration AES for RB3011UiAS-RM?

Could we expect a setup assistent for IPV6 Nat in Router OS?

Kind Regards

Cha0s · Mon Dec 11, 2017 4:00 pm

Could we expect hardware acceleration AES for RB3011UiAS-RM?

Not before v7. Even after v7 I am not so sure they will add HW AES support. The CPU does support it, but MikroTik don't seem to want to invest in RB3011.
They never released any other model as they did with the various models of RB2011...

Tue Dec 12, 2017 8:04 pm

Could we expect a setup assistent for IPV6 Nat in Router OS?

IPv6 NAT - I bet we have to wait longer than the IGMP snooping people waited before it comes out. . .

If Mikrotik _does_ decide to add this in, I would request the following flavors (most-preferred first)
- NAT64 protocol translation (stateful)
- NAT64 protocol translation (stateless)
- NAT66-PT (stateless prefix translation)
-NAT66 (dstnat) - This is useful for things like transparent service redirection
- NAT66 (srcnat many-to-1) - this one I could be happy if they never implemented. I'd prefer for the IPv6 community to never deploy in a way that requires this because once it's there, the wound can never be completely healed.

Vooray · Sat Jan 06, 2018 7:57 pm

Up

It is 2018 already. May we have some status report or plans on v7 release? Or it is abandoned already?

mistry7 · Sun Jan 07, 2018 9:03 pm

Looks like it is Canceled.....
Nothing in the last 4 years
So we are Stil on Kernel 3.xx.xx

telcouk · Mon Jan 08, 2018 4:03 pm

I think we can safely assume that v7 is some way off, with Mikrotik staying tight lipped on a release date.
Indicating that they themselves have no idea of when it is going to be released.

We are getting to the stage where we are outgrowing our Cloud Core routers, yet we’re only doing 10-100Mb of traffic typically throughout the day! What is killing us is BGP updates, causing jitter / latency spikes on our network… We have a total of 3 full BGP feeds on a total of 4 Mikrotik Cloud Core routers.

Unfortunately, we have lost patience with Mikrotik and we are in the process of exploring alternatives. We won’t be purchasing further Mikrotik products which require BGP.
I really do think they should spell out the limitations of BGP… As on paper everything looks amazing with the Cloud Core routers, however the reality is VERY different.

Mon Jan 08, 2018 5:03 pm

I think we can safely assume that v7 is some way off, with Mikrotik staying tight lipped on a release date.
Indicating that they themselves have no idea of when it is going to be released.

We are getting to the stage where we are outgrowing our Cloud Core routers, yet we’re only doing 10-100Mb of traffic typically throughout the day! What is killing us is BGP updates, causing jitter / latency spikes on our network… We have a total of 3 full BGP feeds on a total of 4 Mikrotik Cloud Core routers.

Unfortunately, we have lost patience with Mikrotik and we are in the process of exploring alternatives. We won’t be purchasing further Mikrotik products which require BGP.
I really do think they should spell out the limitations of BGP… As on paper everything looks amazing with the Cloud Core routers, however the reality is VERY different.

Not noticed this BGP generated jitter/latency so far. Searched the forum and did not find something regarding this. Did you post/discussed this problem?

Mon Jan 08, 2018 5:12 pm

I think he's referring to the fact that BGP runs in a single thread - ergo cannot take advantage of multi-core tile platform. It could be that during convergence, his network performance is spotty due to various reasons, but that's just speculation on my part. At the end of the day, though, there have been many "oh that will be fixed / added / addressed in ROSv7" issues - more than I can recall, really.

zyzelis · Mon Jan 08, 2018 7:34 pm

I think we can safely assume that v7 is some way off, with Mikrotik staying tight lipped on a release date.
Indicating that they themselves have no idea of when it is going to be released.

We are getting to the stage where we are outgrowing our Cloud Core routers, yet we’re only doing 10-100Mb of traffic typically throughout the day! What is killing us is BGP updates, causing jitter / latency spikes on our network… We have a total of 3 full BGP feeds on a total of 4 Mikrotik Cloud Core routers.

Unfortunately, we have lost patience with Mikrotik and we are in the process of exploring alternatives. We won’t be purchasing further Mikrotik products which require BGP.
I really do think they should spell out the limitations of BGP… As on paper everything looks amazing with the Cloud Core routers, however the reality is VERY different.

+1
to say more: we already moving out from mtik wireless, now after some accidents bgp routers are on the way.

patrick7 · Mon Jan 08, 2018 7:54 pm

Maybe we should collaborate and make a list of alternative devices / software solutions?

As a start:

CloudCoreRouter
SuperMicro 5018D-FN8T
- 6x Gigabit Ethernet (RJ45)
- 2x 10 Gigabit Ethernet (SFP+)
- 16GB RAM
- Xeon-D 1518 Quad Core

RB75X
PCEngines APU2
- 3x Gigabit Ethernet
- 4GB RAM
- 1 GHz Quad Core X86

BGP/OSPF/MPLS done with FRR, multiple fulltables no issue.

mistry7 · Wed Jan 10, 2018 5:36 am

We are lucky and dont buy Mikrotik CCR for BGP....
http://mum.mikrotik.com/presentations/RU14/megis.pdf
But for all other, this Dokument is 4 years old and still nothing...
The most CCR for BGP would sorted out before they will release v7
so the problems also resolve themselves, no more need for ROS v7

I am also looking for an alternative for Mikrotik Wireless, because of missing
- spectral scan
- Nv2 bad performance in 802.11ac
- missing innovation
- missing Sync
- Limitation in Channel width

After 14 years with MIKROTIK this is not easy. Our hole Netwotk is Mikrotik based,
But they don't here and don't care the needs in Wireless Market, so we have to look to another Brands!
Pity, but reality

Mistry7

honzam · Wed Jan 10, 2018 10:12 am

I am also looking for an alternative for Mikrotik Wireless, because of missing
- spectral scan
- Nv2 bad performance in 802.11ac
- missing innovation
- missing Sync

After 14 years with MIKROTIK this is not easy. Our hole Netwotk is Mikrotik based,
But they don't here and don't care the needs in Wireless Market, so we have to look to another Brands!
Pity, but reality

We have the same problem with wireless

We don´t use BGP on Mikrotik . The main problem is the old wireless kernel 3.0 in ROS V6

WireDick · Fri Jan 12, 2018 12:48 am

Can someone explain me why they just can't enable Hardware accelartion for AES in rb3011 for example as Routerboard update or license buy option???

We have 18 of them mostly for managing sophos / Cisco / Siemens stuff etc. .... via openvpn and during the last months with growing network complxity we run into bandwith issue ....

patrick7 · Fri Jan 12, 2018 1:57 pm

Don't expect anything kernel related to be fixed in v6.

mistry7 · Fri Jan 12, 2018 6:05 pm

Don't expect anything kernel related to be fixed in v6.

And don´t expect fast Release of ROS7,
we are now at 4.14.xx how long we will see Kernel 4?
Linux Kernel 5.0 Will be Coming in the Summer of 2018

Mikrotik is 4-5years behind development!

Chupaka · Sat Jan 13, 2018 7:12 pm

we are now at 4.14.xx how long we will see Kernel 4?
Linux Kernel 5.0 Will be Coming in the Summer of 2018

Mikrotik is 4-5years behind development!

RHEL 7.4 uses kernel 3.10.0-693. How many years are they behind development?

mistry7 · Sat Jan 13, 2018 9:59 pm

we are now at 4.14.xx how long we will see Kernel 4?
Linux Kernel 5.0 Will be Coming in the Summer of 2018

Mikrotik is 4-5years behind development!
RHEL 7.4 uses kernel 3.10.0-693. How many years are they behind development?

right....
But RHEL 8.0 is on the way based on Fedora 27 aka Linux Kernel 4.14

s9date · Sat Jan 13, 2018 11:54 pm

Hello. I have 11 Mikrotik 912 + Sierra MC7304. I too would love to have this to start testing LTE on MC7304. Thank you.

RogerWilco · Tue Jan 16, 2018 3:35 am

Hello. I have 11 Mikrotik 912 + Sierra MC7304. I too would love to have this to start testing LTE on MC7304. Thank you.

I only have 1 of each, but I'd love to be able to use LTE too.

wilsonlmh · Wed Jan 17, 2018 8:34 am

The most CCR for BGP would sorted out before they will release v7
so the problems also resolve themselves, no more need for ROS v7

No, I'm still waiting for VirtIO support in v7

mark73 · Thu Feb 08, 2018 5:01 pm

ROSv7 will be released just after Duke Nukem Forever!

*SCNR*

Thu Feb 08, 2018 5:33 pm

DNF was released in 2011, so ...

juliokato · Thu Feb 08, 2018 6:51 pm

No comments....
kkk
:wq!

Chupaka · Fri Feb 09, 2018 7:59 am

DNF was released in 2011, so ...

So it's time for ROS v7!

Fri Feb 09, 2018 9:06 am

Apparently not yet. Don't you remember the well known sentence of Normis? "When it will be then it will be."

patrick7 · Sat Feb 10, 2018 12:34 am

After waiting 5 years, I think it won't ever be released.

pe1chl · Sat Feb 10, 2018 11:55 am

They have moved themselves into incredible difficulty by raising the expectations so much....
When v7 would just have been a move to a new kernel that would then allow the gradual introduction of new features that required that new kernel,
and in parallel to the usual changes like we now see in the 6.x series there would be some "experimental packages" that introduce radical changes
(like the mighty new routing code), everything would have proceeded smoothly.
And it has been done before. Autorouting has been an experimental package before, and several packages for Wireless.
After some feedback and development, these respective packages became part of the standard distribution.

But now, v7 is kind of a magic bullet that promises to fix many issues and limitations, and of course it can never be completely ready for release
(without bugs and loose ends). So no matter how long it is postponed, there will always be a lot of disappointment and support calls. And by now
it is much too late to go back to the more gradual migration as described above. At least under the designation RouterOS v7.

Paternot · Sat Feb 10, 2018 4:58 pm

And by now it is much too late to go back to the more gradual migration as described above. At least under the designation RouterOS v7.

Well, there is always RouterOS v8...

patrick7 · Sat Feb 10, 2018 9:05 pm

Release of v8 will be in ~ 40 years if they proceed with the same speed.

pe1chl · Sun Feb 11, 2018 12:14 pm

Release of v8 will be in ~ 40 years if they proceed with the same speed.

I think it refers to the option of skipping v7 altogether and then proceed the way described above.
(i.e. make v8 a v6 with current kernel and then incrementally build from there just as done in v6.xx releases)

Paternot · Mon Feb 12, 2018 3:19 am

Release of v8 will be in ~ 40 years if they proceed with the same speed.
I think it refers to the option of skipping v7 altogether and then proceed the way described above.
(i.e. make v8 a v6 with current kernel and then incrementally build from there just as done in v6.xx releases)

Yes, that's it. I just think V8 should come with a new kernel - and the rest should be improved sequentially. The worst part of a new kernel are the hardware drivers. The rest is, for the most part, high level enough to not be directly affected by it.

bearmeister · Thu Feb 15, 2018 5:58 am

we are now at 4.14.xx how long we will see Kernel 4?
Linux Kernel 5.0 Will be Coming in the Summer of 2018

Mikrotik is 4-5years behind development!
RHEL 7.4 uses kernel 3.10.0-693. How many years are they behind development?

And yet, they are still able to deliver a working stateful DHCPv6 server, irony much?
Meanwhile, Mikrotik who are supposed to be in the SP space can't deliver a decent BGP or a working DHCPv6 server.
ROS7 has been thrown around so much over the years as far as I'm concerned its just vaporware, I'll believe it exists when I see it.
Until then, I like others, will continue to explore alternative that meet basic industry requirements.

Sob · Thu Feb 15, 2018 6:21 pm

When v7 would just have been a move to a new kernel ...

It's pure speculation, but I think that "just switching kernel" might be the problematic part. If they modified too much in the old one (and it looks like a lot of what RouterOS does is not just in userspace), porting everything forward can be hard. Linux is evolving, and it's being worked on by many people, much more than MikroTik has (I guess). So they can either break from it, go own way, and lose all those nice improvements already done by someone else. Or they can try to keep up with changes, port their stuff, but that can be an awful lot of work.

Paternot · Fri Feb 16, 2018 9:49 pm

When v7 would just have been a move to a new kernel ...
It's pure speculation, but I think that "just switching kernel" might be the problematic part. If they modified too much in the old one (and it looks like a lot of what RouterOS does is not just in userspace), porting everything forward can be hard. Linux is evolving, and it's being worked on by many people, much more than MikroTik has (I guess). So they can either break from it, go own way, and lose all those nice improvements already done by someone else. Or they can try to keep up with changes, port their stuff, but that can be an awful lot of work.

I'm not sure about that. The drivers are kernel bound, of course. So are the NV protocols - with all that TDMA and whatnot. But (almost) everything else? Is just userspace. Even routing: you change it in linux with a userspace command. The kernel may change as much as they want - the interface is still the same.

Even things like L2TP shouldn't be a problem: You still talks to the kernel through a userspace interface. IPv6, PPP, OpenVpn, IPSec... everything is userspace controlled. Yes, yes. OpenVpn creats an interface (tun or tap). They are provided by the kernel, and are userspace controlled. If the Linux kernel was ported to a given architecture, chances are they're already available.

The drivers... well, the drivers are the hard part. If they aren't part of the kernel three, then Mikrotik must get them, compiled to the new kernel, from the hardware makers. And this is not always easy... Then they need to test, test, test, integrate, validate... a truly hellish task.

I agree with what was said: they promised too much, and now are trying to live up to their promises. This means a lot of development, in a lot of packages. And the drivers! Have I said how hard the drivers part will be?

Sob · Fri Feb 16, 2018 10:40 pm

I'm not sure either (and I hope I made it clear enough).

My basic argument is that used kernel was said to be limiting factor for adding some new features years ago. So it would make sense to upgrade it, and not wait for too long before doing so. Not only can the new version already have some wanted features built-in, but also hardware manufacturers are more likely to support current kernel in their (not yet built-in) drivers, if we're talking about newish hardware. If there was only relatively small amount of modifications made by MikroTik, then why hold off for so long?

I'd also say that there's a difference between controlled from userspace and being in userspace, but I can't really go far with that, because that would be too thin ice for me.

I doubt that MikroTik will share exact details, so speculations is the only thing we have. Other than just waiting, but it's a little boring already.

Paternot · Sat Feb 17, 2018 12:22 am

I'm not sure either (and I hope I made it clear enough).

My basic argument is that used kernel was said to be limiting factor for adding some new features years ago. So it would make sense to upgrade it, and not wait for too long before doing so. Not only can the new version already have some wanted features built-in, but also hardware manufacturers are more likely to support current kernel in their (not yet built-in) drivers, if we're talking about newish hardware. If there was only relatively small amount of modifications made by MikroTik, then why hold off for so long?

I'd also say that there's a difference between controlled from userspace and being in userspace, but I can't really go far with that, because that would be too thin ice for me.

I doubt that MikroTik will share exact details, so speculations is the only thing we have. Other than just waiting, but it's a little boring already.

I don't know. Just passing time, with idle speculation.

mhugo · Sat Feb 17, 2018 10:57 pm

We have been waiting too long for basic SP features like multithread BGP and something as simple as DHCP Option 82 Circuit ID. I think that if Mikrotik showed that anything was actually happening it would be easier to not look at other vendors.

Sun Feb 18, 2018 12:12 am

This is always possible and I encourage you to do that. There is free competition on the market and you should spend money on the products that fits your needs the best.

thobias · Mon Feb 19, 2018 12:29 pm

I think we can safely assume that v7 is some way off, with Mikrotik staying tight lipped on a release date.
Indicating that they themselves have no idea of when it is going to be released.

We are getting to the stage where we are outgrowing our Cloud Core routers, yet we’re only doing 10-100Mb of traffic typically throughout the day! What is killing us is BGP updates, causing jitter / latency spikes on our network… We have a total of 3 full BGP feeds on a total of 4 Mikrotik Cloud Core routers.

Unfortunately, we have lost patience with Mikrotik and we are in the process of exploring alternatives. We won’t be purchasing further Mikrotik products which require BGP.
I really do think they should spell out the limitations of BGP… As on paper everything looks amazing with the Cloud Core routers, however the reality is VERY different.
+1
to say more: we already moving out from mtik wireless, now after some accidents bgp routers are on the way.

We are also now in the process of throwing out everything Mikrotik running BGP as it cannot handle it.

patrick7 · Mon Feb 19, 2018 5:48 pm

We too. Using SuperMicro Xeon-D appliances with debian and FRR. Works like a charm, BGP with X fulltables, VRF (v4/v6), Route Leaking, ...

netravnen · Tue Mar 06, 2018 2:09 pm

Looking away from RouterOS v6.x running IPv6 BGP [tables]?

Not being able to verify IPv6 routing table (when not main table!) is really a big deal. (But seeing the routes exists by the number the route counter shows. :sigh:)
And doing policy routing rules for anything else than main table in IPv6.

It feels a bit poorly planned/immature(still?) when compared to I can do the WHOLE vrf-mpls infrastructure with IPv4. But it is only partially implemented with IPv6 (vrf's?) in RouterOS v6.x. :/

Still looking for equalized feature set between IPv4 and IPv6 in RouterOS version 7 or 8(?) in 2020 or 2025(?)

@Mikrotik: Would be nice with a roadmap somewhere telling all us customers which year to expect the release of the first release candidate for the next major release of RouterOS. (Currently it feels sort of I'm/we are left out to dry just looking/scraping for news about the next major below the earths horizon and outer space past the planet of Uranus.)

Would REALLY appreciate a lot more openness compared to fx when GitLab.com encountered extended downtime for days due to an engineers non-intended blunder while doing maintenance that fateful day last year (2017).

Cha0s · Tue Mar 06, 2018 2:19 pm

Looking away from RouterOS v6.x running IPv6 BGP [tables]?

Not being able to verify IPv6 routing table (when not main table!) is really a big deal. (But seeing the routes exists by the number the route counter shows. :sigh:)
And doing policy routing rules for anything else than main table in IPv6.

It feels a bit poorly planned/immature(still?) when compared to I can do the WHOLE vrf-mpls infrastructure with IPv4. But it is only partially implemented with IPv6 (vrf's?) in RouterOS v6.x. :/

Still looking for equalized feature set between IPv4 and IPv6 in RouterOS version 7 or 8(?) in 2020 or 2025(?)

@Mikrotik: Would be nice with a roadmap somewhere telling all us customers which year to expect the release of the first release candidate for the next major release of RouterOS. (Currently it feels sort of I'm/we are left out to dry just looking/scraping for news about the next major below the earths horizon and outer space past the planet of Uranus.)

Would REALLY appreciate a lot more openness compared to fx when GitLab.com encountered extended downtime for days due to an engineers non-intended blunder while doing maintenance that fateful day last year (2017).

Didn't you hear? Almost all v7 features have been backported to v6!
Doesn't matter that routing (bgp), ipv6, drivers and all necessary 'routing' stuff cannot get backported due to old kernel version in v6. At least we now have kids control and detect internet! Super essential features for routers running BGP in the public internet

netravnen · Tue Mar 06, 2018 2:39 pm

Didn't you hear? Almost all v7 features have been backported to v6!

No. I have not (before now) stumbled across that information.

At least we now have kids control and detect internet! Super essential features for routers running BGP in the public internet

So looking forward to when RouterOS will support SR !

carlhjerpe · Wed Apr 04, 2018 1:42 pm

If we draw some conclusions:

Almost everything from 7.x has been backported to 6.x
MikroTik has been in trouble about GPL
It's been in development for a long period of time
Linux has dropped TILE support

Could it possibly be that they're moving to something that isn't GPL licensed?

Just saying, there are options that aren't Linux.

mtsphere · Thu Apr 05, 2018 3:11 am

Didn't you hear? Almost all v7 features have been backported to v6!
No. I have not (before now) stumbled across that information.

At least we now have kids control and detect internet! Super essential features for routers running BGP in the public internet
So looking forward to when RouterOS will support SR !

I'm sure that this will never happen... Much like IS-IS..
Somehow i'm sad that many people are leaving MT platform (numerous reasons) since i'm following and using MT basically from the begging.
Number of our customers moved to Quagga / Bird just because BGP glitches.. They waited.. but - Big Foot (v7) never came around..

Cheers

ziegenberg · Thu Apr 05, 2018 11:24 am

If we draw some conclusions:

Almost everything from 7.x has been backported to 6.x

MikroTik has been in trouble about GPL

It's been in development for a long period of time

Linux has dropped TILE support

As mentioned several times on this forum, this does not apply as MikroTik did not use the linux community TILE code in any way. They do not rely on the TILE support of Linux at all.

Could it possibly be that they're moving to something that isn't GPL licensed?

Just saying, there are options that aren't Linux.

cheeze · Sun Apr 15, 2018 10:04 pm

Mikrotik, please please please please.

Leave the development of *NEW* features/things/whatnot out of ROS 6 now. Please, move the developers out of ROS 6 feature development and have them go to ROS 7 development. Bugfixes should still keep going on ROS 6 as they are going now (if possible).

There needs to be a harder development push towards ROS 7. If there's nothing else to develop for ROS 7 (which I have high doubts on as I know more and more features are being added to it all the time), then can we please get a glimpse of how things are going with it. I think we can all more or less surmize that Mikrotik is probably building an entirely new routing stack from scratch and that it is taking far more amounts of time than anyone ever expected. As much as it is feasible, can more people be thrown at developing ROS 7 instead of adding more features to ROS 6?

Mon Apr 16, 2018 3:43 pm

Déjà vu?

Don't we remember the transition years between the version 5 and 6?

dynek · Mon Apr 16, 2018 3:51 pm

Well if they say they backported most (all ?) v7 functionalities into v6, I don't really see a problem here.

mistry7 · Mon Apr 16, 2018 4:28 pm

Well if they say they backported most (all ?) v7 functionalities into v6, I don't really see a problem here.

The problem is the old kernel ROS 6 based on, there much improvements only possible with newer kernel.
And we will see ROS 7 with 4.xx Kernel when Linus Towards launch Kernel 5.xx, happens probably this summer....

And the delay will getting bigger.
All new products with IPQ have driver throughput problems, Mikrotik works with a back ported driver, it would be easier to use the origin one,
but it is only available for newer kernels...
here the delay takes its toll

pe1chl · Mon Apr 16, 2018 9:12 pm

All new products with IPQ have driver throughput problems, Mikrotik works with a back ported driver, it would be easier to use the origin one,
but it is only available for newer kernels...
here the delay takes its toll

It becomes more clear that the kernel has been so heavily modified that it is not so easy to upgrade it anymore.
This is of course always a tough decision: do you limit the kernel changes and try to forward them to the kernel development group, which will cause a lot of wasted time due to discussion about how to implement some feature, or do you just "fork" the kernel based on some version uptodate at that time, causing the problem there is now.
On the other hand, when you do all the work on a forked kernel, you are not affected by decisions like the dropping of TILE support in the kernel.

honzam · Mon Apr 16, 2018 9:56 pm

Linus Towards launch Kernel 5.xx, happens probably this summer....

Maybe Mikrotik wait for kernel 5.x

Mon Apr 16, 2018 11:06 pm

... Just to start waiting for the 6.x kernel...

mistry7 · Mon Apr 16, 2018 11:18 pm

All new products with IPQ have driver throughput problems, Mikrotik works with a back ported driver, it would be easier to use the origin one,
but it is only available for newer kernels...
here the delay takes its toll
It becomes more clear that the kernel has been so heavily modified that it is not so easy to upgrade it anymore.
This is of course always a tough decision: do you limit the kernel changes and try to forward them to the kernel development group, which will cause a lot of wasted time due to discussion about how to implement some feature, or do you just "fork" the kernel based on some version uptodate at that time, causing the problem there is now.
On the other hand, when you do all the work on a forked kernel, you are not affected by decisions like the dropping of TILE support in the kernel.

right, and then hang on old drivers, that is exactly what happend
The problem Beginns if you has to support up to date Hardware with this old software!
And now we are standing in the rain, Mikrotik has no timeline for Ros7, flawless ARM Wireless driver, Spectral Scan........

cheeze · Tue Apr 17, 2018 12:35 am

I am still not sure why Mikrotik didn't go with IP Infusion....

CTSsean · Thu Apr 26, 2018 5:37 pm

DNF was released in 2011, so ...

so 15 years from version to version. Nice... so we only have another 11 years.

Fri Apr 27, 2018 12:12 am

I am still not sure why Mikrotik didn't go with IP Infusion....

That is not the problem.

The problem is getting a modern kernel that boots on all of the platforms while supporting hardware offloads.

Just my opinion...

cheeze · Mon Apr 30, 2018 12:19 am

That is not the problem.

The problem is getting a modern kernel that boots on all of the platforms while supporting hardware offloads.

Just my opinion...

To be honest, I think it's both. However I think what you bring up is likely more of the issue though.

I wonder if it's worth it for Mikrotik to just focus on like.....x86-64/ARM/TILE going forward. Not sure if the MIPS devices are still supported to be honest. I also have been hearing that TILE is no longer going to be a supported hardware platform. Which sucks.

Mon Apr 30, 2018 10:15 am

It was written several times here. Future versions of ros will be running on tilera further. Ros is not affected by this.

Mon Apr 30, 2018 10:29 am

RouterOS uses very little of open source code. MikroTik is in direct relationship with the CPU manufacturers. We use the official drivers and code. We don't use open source code.

mistry7 · Mon Apr 30, 2018 10:44 am

RouterOS uses very little of open source code. MikroTik is in direct relationship with the CPU manufacturers. We use the official drivers and code. We don't use open source code.

Then explain the difficulty's with migrating on to newer Kernel.....

Mon Apr 30, 2018 11:56 am

This is the difficulty

If we were using all open source code, it would be easy to upgrade. Now we must only rely on ourselves to upgrade all programs.

Vitis · Mon Apr 30, 2018 4:04 pm

This is the difficulty If we were using all open source code, it would be easy to upgrade. Now we must only rely on ourselves to upgrade all programs.

Do you have any timeline? We are waiting more than 4 year for the VRF support

lillecarl · Mon Apr 30, 2018 4:09 pm

This is the difficulty If we were using all open source code, it would be easy to upgrade. Now we must only rely on ourselves to upgrade all programs.

Is RouterOS 7 going to ship a Linux kernel?

levicki · Tue May 01, 2018 11:56 am

MikroTik (just like Ubiquiti and many others for that matter) are depending on the hardware (CPU/chipset) manufacturer for major upgrades. Those manufacturers are the ones who provide SDK and drivers (the latter usually in binary form only due to patents), and those drivers cannot be loaded on newer kernel without recompile. If the manufacturer does not supply updated binaries and SDK they cannot update anything.

patrick7 · Fri May 18, 2018 3:13 pm

While I understand it needs some time to make good software, it's getting embarrassing with v7 (or its promised bugfixes). Since 2013 MikroTik promises to fix bugs with v7 (recursive ipv6 nexthops etc), and absolutely NOTHING happens. I'm sorry, but such a product is absolutely unsuitable for professional use.

Florian · Fri Jun 01, 2018 2:50 pm

To be fair, some of "wait for v7" problems were in fact corrected in v6.XX (like more options for DHCPv6 Server)

My theory is that they didn't plan to push v6 this far, and they realised that SOME of v7 features could be in fact in v6, so this "helped" delay V7.

Now, Mikrotik is not a small fish, but they're not Cisco or HPE/Aruba. If V7 is a major overhaul, I can't image the hour/man needed to do that.

pe1chl · Fri Jun 01, 2018 3:17 pm

If V7 is a major overhaul, I can't image the hour/man needed to do that.

That is why it is often impractical to develop software that way.
Announcing a new version that is to be "rewritten from scratch" or similar claims usually results in failure.
Gradually developing new features and maybe rewriting some subsystems one at a time has more chance of succeeding.
Probably a chance to survive this mess is to make a release that aligns the kernel with a reasonably current version and
then work from there on replacement of the subsystems that were announced to be rewritten. However it will be impossible
to release such a change as "v7.0" because there will be a big flood of "you announced it will be fixed in v7 and now we have
v7 and it is still not fixed!" complaints. No idea how to work around that. Go to v8 immediately, change the version naming
(like Microsoft did many times) so it is e.g. called "RouterOS 2018" or "RouterOS Vista"?

Paternot · Fri Jun 01, 2018 6:28 pm

Probably a chance to survive this mess is to make a release that aligns the kernel with a reasonably current version and
then work from there on replacement of the subsystems that were announced to be rewritten. However it will be impossible
to release such a change as "v7.0" because there will be a big flood of "you announced it will be fixed in v7 and now we have
v7 and it is still not fixed!" complaints.

I agree that would be the best way to handle this.

About the problem of "You said it would be done on V7!": Make the version 7 a big announcement. Keep telling about the improvements the new kernel would bring. And - here is the thing - create a roadmap. Something like this:

V7.0 -> Inicial release. Low level kernel/drivers work.
V7.1 -> Subsystem "X" revamped.
V7.2 -> Subsystem "Y" revamped. Feature "Z" included. Long pending limitation "W" addressed.

Better than trying to deliver whole mythical unicorn. V7.X to V7.Y would be like V4.41.X to 6.42.X, in terms of time and development.

How about?

juliokato · Sun Jun 03, 2018 6:06 pm

I just want to get an idea of how much this unicorn will give birth.

R1CH · Tue Jun 05, 2018 4:17 pm

This is the difficulty If we were using all open source code, it would be easy to upgrade. Now we must only rely on ourselves to upgrade all programs.

Why is Mikrotik so against using open source software? We would have working 802.11ac Wave2, 5 GHz spectral scan, OpenVPN UDP support, more secure smbd, httpd, etc if Mikrotik would stop re-inventing everything in-house and use well-tested open source software. You could combine open source kernel with proprietary modules for hardware offloading etc in much the same way NVIDIA provides proprietary Linux graphics drivers for their chips.

pe1chl · Tue Jun 05, 2018 4:26 pm

One reason is probably that when you use opensource software and keep tracking all the updates, you end up with more and more bloated software that does not fit into a space-limited router anymore.
It works fine on the PC platform where space and other resource usage (CPU) has grown with the code, but on embedded hardware it is a bit more difficult.
Remember the current routers mostly have only 16MB of flash space!
(the previous generation usually had 128MB which was a bit more generous, but to store generic opensouce software for all functions you would need more like 512MB-1GB in my experience)

Paternot · Tue Jun 05, 2018 4:48 pm

One reason is probably that when you use opensource software and keep tracking all the updates, you end up with more and more bloated software that does not fit into a space-limited router anymore.
It works fine on the PC platform where space and other resource usage (CPU) has grown with the code, but on embedded hardware it is a bit more difficult.
Remember the current routers mostly have only 16MB of flash space!
(the previous generation usually had 128MB which was a bit more generous, but to store generic opensouce software for all functions you would need more like 512MB-1GB in my experience)

I don't see all this bloat. Well, not at where we talking: low level, kernel, drivers and servers. Take a look at the RaspberryPi: Full OpenSource, ARM, Linux kernel. This is fdisk usage from one I have access to (default install, with graphic desktop and full updated).

df -h
Sist. Arq. Tam. Usado Disp. Uso% Montado em
/dev/root 15G 4,6G 9,4G 33% /
devtmpfs 370M 0 370M 0% /dev
tmpfs 375M 0 375M 0% /dev/shm
tmpfs 375M 9,9M 365M 3% /run
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 375M 0 375M 0% /sys/fs/cgroup
/dev/mmcblk0p1 41M 22M 20M 53% /boot
tmpfs 75M 0 75M 0% /run/user/1002
tmpfs 75M 0 75M 0% /run/user/1001

I am using 4,6GiB of disk space. Not that bad.

True, it doesn't have OpenVPN and everything else installed - but it would not use more than 1 GiB. Even if it used 3 more GiB: It would be still using less than ROS.

So, no. To me is more about control. If they build it, they can guarantee the software through the expected life cycle of the product.

If it is a good idea, if this costs less resources than going full OpenSource, if the competitive advantage is worth the trouble (even if there is one or not) is another problem - and a strategical decision to Mikrotik.

Wyz4k · Tue Jun 05, 2018 5:37 pm

3GB is less than ROS? ROS is 20-40MB...

pe1chl · Tue Jun 05, 2018 6:05 pm

True, it doesn't have OpenVPN and everything else installed - but it would not use more than 1 GiB. Even if it used 3 more GiB: It would be still using less than ROS.

I think you somehow are confusing MB and GB here. Quite common these days!

juliokato · Tue Jun 05, 2018 6:17 pm

many people also confuse bit (b) and byte (B) for traffic analysis.

Chupaka · Tue Jun 05, 2018 6:36 pm

many people also confuse bit (b) and byte (B) for traffic analysis.

many people think that if 1 megabyte = 1024 kilobytes, then 1 megabit per second = 1024 kilobits per second

Paternot · Tue Jun 05, 2018 9:58 pm

True, it doesn't have OpenVPN and everything else installed - but it would not use more than 1 GiB. Even if it used 3 more GiB: It would be still using less than ROS.
I think you somehow are confusing MB and GB here. Quite common these days!

LOL True enough. Things move so fast, we lost track of these things. Nowadays we carry in the pocket a mobile with 4GiB of RAM - and my first computer had 16KiB of RAM... Sometimes is enough to make lost track of things...

R1CH · Wed Jun 06, 2018 2:22 pm

One reason is probably that when you use opensource software and keep tracking all the updates, you end up with more and more bloated software that does not fit into a space-limited router anymore.
It works fine on the PC platform where space and other resource usage (CPU) has grown with the code, but on embedded hardware it is a bit more difficult.
Remember the current routers mostly have only 16MB of flash space!
(the previous generation usually had 128MB which was a bit more generous, but to store generic opensouce software for all functions you would need more like 512MB-1GB in my experience)

I don't really buy this argument. Linksys, DLINK, etc all use open source software and have no issues selling $50 routers with enough disk space to support all these packages. With good compilation options and stripping of binaries it's possible to get very small versions of many popular packages. And as you say, Mikrotik used to have plenty of disk space with their products, only recently have they been skimping on the NAND size.

brotherdust · Fri Jun 08, 2018 12:24 am

I think @levicki is correct about being beholden to the manufacturer's release cadences. Most manufacturers of embedded networking kit are still hanging out on kernel 3.x. It's really annoying! If any manufacturer is reading this: STOP DOING OUT-OF-LINE KERNEL RELEASES. UPSTREAM YOUR CHANGES.

I digress...
In terms of features, at release, ROS 6 was in the unique position of supporting some fairly advanced scenarios; but these had to be developed in-house. Since that time, much effort (and a LOT of money) has been put in to the Linux network stack, especially in the v4.x series. As a result, vanilla Linux kernel can do almost everything ROS can do, and more besides. ROS can't leverage those developments unless they backport the features from v4 kernel to v3 kernel, because most manufacturer SDK's are, as mentioned previously, still stuck in kernel v3-land.

So, all this to answer the question, "When?" My gut tells me that it won't happen until it's more painful to maintain ROS v6 than it is to start over and leverage open-source efforts better. As ROS v6 continues to age, use-cases in [newer, more complex, software-driven] environments will shrink; to the point where it's only useful for very small providers, small business, and home users.

From where I'm standing, as a service provider, the competitive landscape is changing rapidly. To survive, I must be able to offer new services my customers are demanding as quickly as possible. Right now, my biggest limiting factor in delivering those services is RouterOS. I really, really love RouterOS, but it's not growing with me and, sadly, I don't think Mikrotik is all that interested in what we have to say.

Evidence:
- Numerous attempts to solicit ideas for future products from the forum community (see: viewtopic.php?f=2&t=121533&hilit=flagship+router), then basically ignoring it and going a different direction
- Continued focus on last-mile and switching-type devices and software supporting said devices
- Inability and/or unwillingness to maintain a coherent feature request list (see: https://community.ubnt.com/t5/UNMS-Feat ... reRequests as an example of how to do it better) that the community can vote/provide feedback on

Am I wrong? Possibly. I'm trying to be as objective as I can in this analysis; but I'll admit I'm at the point of "believe-it-when-you-see-it".

Fri Jun 08, 2018 3:10 am

I agree with almost everything @brotherdust has said above, his comments match my own feelings on the current state of Mikrotik.

I have been a huge fan of Mikrotik's RouterOS, but I am using it less and less. The service provider market has kept evolving but RouterOS has not evolved with it.

Mikrotik had a lot of momentum with RouterOS and Service Provider features, e.g. they moved from Quagga to their own Routing engine and added MPLS features during the 3.x and 4.x phase, and then it all just stopped during the 5.x phase. That was over 7 years ago now!

Mikrotik's sales are growing and they are focusing on the areas where they see growth, but that does not mean long term success.

This reminds me somewhat of Toyota thinking they could keep growing by making variations of the Corolla and Camry, so they stopped producing cars like the Celica and Supra, but what they did not realise was that while sales volumes for the Celica and Supra were low, they were the "hero" cars that were attracting buyers to the brand... The result, Toyota, from #1 to #6...

The Service Provider features like BGP, OSPF, MPLS, BNG (PPP/DHCP) are the "Hero" features of RouterOS...

Chupaka · Fri Jun 08, 2018 1:07 pm

If any manufacturer is reading this: STOP DOING OUT-OF-LINE KERNEL RELEASES. UPSTREAM YOUR CHANGES.

Well, sometimes those changes are simply not accepted into kernel

patrick7 · Fri Jun 08, 2018 5:38 pm

2 years ago I had CCRs running in 3 locations. Now all CCRs have been replaced with debian+FRR boxes. Are much better (features, open source), and the price is +- the same.
The only mikrotik device I'm still using is a small CRS at home.

brotherdust · Fri Jun 08, 2018 10:15 pm

I agree with almost everything @brotherdust has said above, his comments match my own feelings on the current state of Mikrotik.

I have been a huge fan of Mikrotik's RouterOS, but I am using it less and less. The service provider market has kept evolving but RouterOS has not evolved with it.

Mikrotik had a lot of momentum with RouterOS and Service Provider features, e.g. they moved from Quagga to their own Routing engine and added MPLS features during the 3.x and 4.x phase, and then it all just stopped during the 5.x phase. That was over 7 years ago now!

Mikrotik's sales are growing and they are focusing on the areas where they see growth, but that does not mean long term success.

This reminds me somewhat of Toyota thinking they could keep growing by making variations of the Corolla and Camry, so they stopped producing cars like the Celica and Supra, but what they did not realise was that while sales volumes for the Celica and Supra were low, they were the "hero" cars that were attracting buyers to the brand... The result, Toyota, from #1 to #6...

The Service Provider features like BGP, OSPF, MPLS, BNG (PPP/DHCP) are the "Hero" features of RouterOS...

What it really boils down to is management decision to go where the money is. This is not unexpected or really all that surprising. Apple does the same thing. What's troubling is that they are effectively alienating some of their fiercest advocates, service providers, in the same way Apple is alienating their professional customers. From where I stand, it's a short-sighted and frustrating turn of events; especially since they aren't really communicating this change in strategy to their customers (maybe in shareholder meetings, but I'm not privy to those).

I think what angers me the most is they aren't willing to fess up and stop leading their service provider customers on with false hope of being able to deliver the features we need. I'm willing to be patient, to bend over backwards, but only if expectations are clearly communicated. If they can't deliver, they should explain why, and set new expectations. It's that simple. =/ Is that too much to ask?

brotherdust · Fri Jun 08, 2018 10:16 pm

If any manufacturer is reading this: STOP DOING OUT-OF-LINE KERNEL RELEASES. UPSTREAM YOUR CHANGES.
Well, sometimes those changes are simply not accepted into kernel

That's a fair point. It's not a simple matter to get those changes accepted. But that begs the question: if they're being denied, why? Maybe write better code? =)

PtDragon · Sat Jun 09, 2018 6:23 pm

Dear MikroTik team!
Can we have some info on v7 progress?
Like "Release possible this year" or like "Release can be in next few years roughly" or "Don't even wait for it until 10-15 years".
You know in which state your code is, right?
And we still do not have any info at all so year after year we wait it blindly.

Sat Jun 09, 2018 6:29 pm

Why to wait for something that none knows anything about it?

jspool · Sat Jun 09, 2018 11:08 pm

I'm more excited that they are hiring Android & iOS programmers as well as mobile application WEB application programmers. Some native management apps would be very nice.
https://darbs.mikrotik.com/darbs/

When they are ready they will release the newer RouterOS. Their new building is more conducive to their growing needs and should allow them to evolve to the needs of the industries they serve.

Sun Jun 10, 2018 10:17 am

Unfortunately they are not seeking the persons they need the most: the security engineers.

z1022 · Thu Jun 14, 2018 6:42 pm

We will release a beta, when it will exist. Currently v7 is in alpha stage, many functions are not completed and non functional. Beta needs at least all functions to be somewhat operational.

waiting for three year la

paoloaga · Wed Jun 20, 2018 6:34 pm

It seems that releasing a complete RouterOS v7 is a very complex task.

What if Mikrotik publishes new release branches? Something like:

Legacy-v5 - Stable-v6 - Current-v6 - Daily-v6 - Current-v7 - Daily-v7

V7 can be published starting with a minimal set of features. Who needs the complete set can install v6-current, who needs v7 features (like ipv6 recursive next hop) but doesn't need other things can optionally install v7.

Vooray · Wed Jun 20, 2018 11:43 pm

Hmm.. heared that U named company released linux 4 based firmware for their routers. Just to mention.

And, as i heared u can have frr on it.
No hands on that equipment, but i keep my eye on it.

And, as i track linux kernel changes, some descent work has been done in networking stack by guys from 6wind and cumulus.

So, mikrotik team, you have a chance. Or had?

huntermic · Wed Jul 04, 2018 4:01 pm

Hmm.. heared that U named company released linux 4 based firmware for their routers. Just to mention.

And, as i heared u can have frr on it.
No hands on that equipment, but i keep my eye on it.

And, as i track linux kernel changes, some descent work has been done in networking stack by guys from 6wind and cumulus.

So, mikrotik team, you have a chance. Or had?

This makes me seriously thinking about goin back to this U named company, the lack of news on the great version 7 with support for 'old' thing like wave2 support and serious ipv6 support for instance. The Mikrotik hadware is capable but the software is limping on this hardware. Shame on Mikrotik for not even ging us an indication on how far development is. I'm done waiting.

pe1chl · Wed Jul 04, 2018 4:39 pm

This makes me seriously thinking about goin back to this U named company, the lack of news on the great version 7 with support for 'old' thing like wave2 support and serious ipv6 support for instance. The Mikrotik hadware is capable but the software is limping on this hardware. Shame on Mikrotik for not even ging us an indication on how far development is. I'm done waiting.

The problem is that the U named company has so few options for routers, and so little router functionality in WiFi equipment.

huntermic · Wed Jul 04, 2018 5:30 pm

This makes me seriously thinking about goin back to this U named company, the lack of news on the great version 7 with support for 'old' thing like wave2 support and serious ipv6 support for instance. The Mikrotik hadware is capable but the software is limping on this hardware. Shame on Mikrotik for not even ging us an indication on how far development is. I'm done waiting.
The problem is that the U named company has so few options for routers, and so little router functionality in WiFi equipment.

The real issue is lack of clarity. No communication or anything to keep us posted on the progress of the new kernel version. ( they call it version 7 but that's just a number ).
All they say is 'hey we have hardware that can do this, only the software can't but we will fix that in the next version, 7. But we might keep you waiting for many years'

ofer · Wed Jul 04, 2018 6:57 pm

from what I'm seeing from a business perspective there is no point pushing for the mythical v7 as long as the v6 still sells well
Mikrotik doesn't see v7 as a priority because v6 still sells.
when v6 will become a deterring factor we will see v7 being worked on seriously until that day comes don't expect to see any major investment in v7
you should all that this is the way things are v6 is available as is because there is no official word about v7 or future roadmap take that to consideration when buying Mikrotik products.

v7 the eternal alpha will be a unicorn until maintaining v6 will cost more than developing a new one

Sob · Wed Jul 04, 2018 7:58 pm

Except when v6 will become a deterring factor, it will be too late. It isn't easy to fix damaged reputation.

mistry7 · Wed Jul 04, 2018 8:26 pm

from what I'm seeing from a business perspective there is no point pushing for the mythical v7 as long as the v6 still sells well
Mikrotik doesn't see v7 as a priority because v6 still sells.
when v6 will become a deterring factor we will see v7 being worked on seriously until that day comes don't expect to see any major investment in v7
you should all that this is the way things are v6 is available as is because there is no official word about v7 or future roadmap take that to consideration when buying Mikrotik products.

v7 the eternal alpha will be a unicorn until maintaining v6 will cost more than developing a new one

the customers answer of missing features, don't buy it

mirhav · Thu Aug 23, 2018 1:51 pm

After these years, I do not expect any serious answers to come from the Mikrotik. .... Ubiquity is much more flexible in communication ... another region, another morality

alidamji · Sat Sep 29, 2018 7:12 pm

V7 beta seems to be already in development. You can see mrz's post:

viewtopic.php?t=130551

Seems to be v7beta running on Virtualbox.

buset1974 · Sat Sep 29, 2018 7:49 pm

After these years, I do not expect any serious answers to come from the Mikrotik. .... Ubiquity is much more flexible in communication ... another region, another morality

true endeed

joegoldman · Sun Sep 30, 2018 2:07 pm

After these years, I do not expect any serious answers to come from the Mikrotik. .... Ubiquity is much more flexible in communication ... another region, another morality

I've been forced into ubiquiti for Wireless gear (PtMP Sector -> CPE networks), comfortably finding 27dbi, 29dbi dishes , 20+dbi sectors and a functioning proprietary high-speed AC protocol beat out Mikrotik systems - but FUCK ME if Ubiquity's management tools are absolute shit compared to Mikrotik / Winbox - talking purely over 500+ms links here my ubiquity web-portals are constantly timing out, where I can manage my RB1100's spread out over the same country fine (still use Mikrotik for routing and PPP termination).

wispmikrotik · Wed Jan 02, 2019 10:28 am

2019?

ofer · Wed Jan 02, 2019 10:57 am

2019?

Router OS v7 is never going to happen.

wispmikrotik · Wed Jan 02, 2019 8:29 pm

2019?
Router OS v7 is never going to happen.

Well ... so let's get routeros v8.0.0 ...

mrmut · Fri Jan 25, 2019 2:58 am

Maybe they will release v13 out of joke.

Numbering doesn't matter, I am happy with them as it is.

Vitis · Fri Jan 25, 2019 11:12 am

Numbering doesn't matter, I am happy with them as it is.

Are you also happy with VRF implementation?

mrmut · Fri Jan 25, 2019 11:31 am

I had to google VRF to see what it is, so I guess the current implementation is just fine by me

pe1chl · Fri Jan 25, 2019 11:41 am

Well today the numbering is usually enforced by marketeers and it could well be that a next release suddenly is called "2019" or whatever symbolic name.
But I agree that it is quite unlikely that we will ever see a version 7. There will undoubtedly be some creative move to work around that.

cgood · Sat Jan 26, 2019 12:28 pm

unsubscribe ...

enzain · Wed Jan 30, 2019 10:48 am

When?

We need multicore BGP (different peers connections on diffirent cores is minimum)

NAT64, DNS64, etc

Full OVPN support (compression, UDP)

etc.

enzain · Wed Jan 30, 2019 10:49 am

When?

Minimum - is multicore BGP

connorgoodwolf · Thu Feb 21, 2019 8:26 pm

Many are exceptionally disappointed at MikroTik's transparency on the release of RouterOS v7.0.

If MikroTik is unwilling to be transparent at the very least they could do is help RouterOS become Open Source so those who care about the platform can assist in development. Many of us have the skills needed and are willing to sign agreements with vendors to help push Mikrotik ahead.

Currently Mikrotik's lack of a roadmap, transparency, implementing standards like VXLAN which is documented by IETF in RFC 7348 is causing Mikrotik adoption to slow and companies are starting to choose competing products like ubiquity. Releasing new hardware isn't "helping" adoption, so please refrain from making statements like, "We're releasing new technology."

The ball is on your court MikroTik:
1) Choose to be transparent
2) Choose to work on Open Sourcing RouterOS
3) Continue the nose dive, destroy the company

Fri Feb 22, 2019 2:12 pm

What do you mean? We have been very open about it.

V7 is not ready for public release, however, development continues. When it will be released? When it's stable enough. That's all.

Chupaka · Fri Feb 22, 2019 3:31 pm

3) Continue the nose dive, destroy the company

"MikroTik. Destroying the company since 1999. For 20 years already." (c)

P.S. OMG! RouterOS is 20 years old this year?!? What's the exact date?

Fri Feb 22, 2019 3:35 pm

Only RouterOS v2, but there was another one.

1995	Arnis and John start to provide Internet services to local businesses.
	Wireless network project in Moldova.
1996	SIA “Mikrotīkls” is incorporated. The name means “Small network” in the Latvian language.
1997	Starting work on a routing utility, which then is a MS-DOS program and is called “Tik” software system.
	PC routers based on 2.4GHz Aironet platforms IC2200.
1999	Installations in Kosovo and the first Linux based RouterOS v2.0

Chupaka · Fri Feb 22, 2019 4:52 pm

So, the first version of RouterOS was RouterOS 2.0, that's why I'm asking

boldsuck · Fri Feb 22, 2019 6:50 pm

If MikroTik is unwilling to be transparent at the very least they could do is help RouterOS become Open Source so those who care about the platform can assist in development. Many of us have the skills needed and are willing to sign agreements with vendors to help push Mikrotik ahead.

Yes, then the Mikrotik hardware would finally openWRT friendly.
For our "Freifunk" projects in Germany, we mostly use / recommend AP's from Ubiquity or TP-Link. Every DAU can flash openWRT on it. Both companies are very community friendly. Sources per ftp downloadable. To send on CD as Mikrotik, is a nasty joke.

connorgoodwolf · Sun Feb 24, 2019 11:08 am

What do you mean? We have been very open about it.

Can you please define the definition of transparency? I'll save you some time, "the quality or state of being transparent".

All you have told us since 2015 goes along the lines of "v7 is currently in internal testing, and will be released as beta when it's stable enough"

I don't like being direct, but what Mikrotik is doing to people who've spent years around Mikrotik hardware, certifications and dedication is wrong. You're hurting not only Mikrotik by not being transparent or forthcoming, you're hurting us.

Items YOU need to address:
1) A graph or document indicating the current status of RouterOS v7.0, even if the features are in flux.
2) Missing standards which will not be targeted in RouterOS v7.0, i.e. VXLAN
3) Update the community with facts and projections on current development

This whole situation would be made easier if Mikrotik had a developer program to work on an open source side project. It would not be hard to set up a lab, virtualization platform or real testing hardware for those who want to be serious about contributing.

Mon Feb 25, 2019 10:40 am

Those are subjects to change. I don't want to promise anything and later tell you that we decided to remove something, or similar.

vecernik87 · Mon Feb 25, 2019 11:44 pm

Hey guys, stop harassing Mikrotik about V7

It is a good topic for jokes but bad choice for serious discussion.
I am not a blind fan, but in this case, @normis is right. Anyone, who ever did a continuous development, knows that specifying future dates of release is a suicide. If you don't make it on time, everyone will complain (and it will be legit because promise was not delivered). If you rush it and make mistake/bug, everyone will complain (and it will be legit because even a simple bug can cost business millions).
Can't you be just happy that there are free updates which not only fix security holes but also improve functionality? And you can get all of that with device prices starting at $50?

In addition, demanding things this way is a bit ridiculous: "what mikrotik is doing ... is wrong" , "you need to address". Cmon... are you a shareholder or what?

Ubiquity is much more flexible in communication

Yeah. They flexibly told me that their products will misbehave if power is lost unexpectedly and the only solution is factory reset and restore from backup. Unfortunately I am stuck with them on three hospitality sites...

Sob · Tue Feb 26, 2019 4:32 am

I think the idea is that after years in development, it should be slowly shaping up and they should be getting some rough idea what it will contain and when it might come out. This very thread is four years old, and third post already mentions the "codename" unicorn. And that popped up only after some time of waiting, when people started to think that it maybe takes a little bit too long. And again, that was four years ago. I wanted to add "when I was still young", but it hasn't been that long, my chances to see RouterOS v7 are still good.

connorgoodwolf · Tue Feb 26, 2019 4:59 am

Those are subjects to change. I don't want to promise anything and later tell you that we decided to remove something, or similar.

This is apart of the development process, many of us are the people who build complete platforms and architectures from the ground up. Even if a timeline or development status stated there was work on a specific feature which was later removed during a release then people would be enthralled there's at least some level of transparency.

Nobody is saying "promise us this," if you're working on an idea/feature/standard which doesn't make the cut then we may be a bit disappointed but it's better than "we're working on it"

connorgoodwolf · Tue Feb 26, 2019 5:02 am

Yeah. They flexibly told me that their products will misbehave if power is lost unexpectedly and the only solution is factory reset and restore from backup. Unfortunately I am stuck with them on three hospitality sites...

All network equipment should have UPS units with AVR, to not have conditioning and backup power supplies attached to radio and networking equipment is asking for trouble.

zandhaas · Tue Feb 26, 2019 2:55 pm

Can't you be just happy that there are free updates which not only fix security holes but also improve functionality? And you can get all of that with device prices starting at $50?

Totally agree

telcouk · Tue Feb 26, 2019 4:31 pm

Those are subjects to change. I don't want to promise anything and later tell you that we decided to remove something, or similar.

Without sounding harsh, I think you would have been better off not telling us about v7 if that's the case.

We would not have invested in Mikrotik kit and would have a fully working IPv6 setup by now.

Tue Feb 26, 2019 4:53 pm

We have not advertised v7 as a version. The first post in this forum thread is by a user.
MikroTik only mentions v7 if there is some feature, that can't be implemented because of kernel limitations. In that case, it's technically not possible to make something until we have new kernel.

Other than that, have we told you there will be a v7 soon?

Sob · Tue Feb 26, 2019 6:06 pm

You didn't, but since the first time someone from MikroTik said "sorry, feature X is not possible now, it needs new kernel", the clock started ticking in users' heads. It's mix of optimism and trust, they (want to) believe that you want to give them the best and the right time for that is now, or at least soon.

Jotne · Tue Feb 26, 2019 6:12 pm

We have not advertised v7 as a version.

No??
Who created the subforum with the name RouterOS v6 RC and v7 BETA?? A user

telcouk · Tue Feb 26, 2019 6:21 pm

We have not advertised v7 as a version. The first post in this forum thread is by a user.
MikroTik only mentions v7 if there is some feature, that can't be implemented because of kernel limitations. In that case, it's technically not possible to make something until we have new kernel.

Other than that, have we told you there will be a v7 soon?

Just google, site:mum.mikrotik.com "v7"
Also what Jotne said.

#facepalm

connorgoodwolf · Tue Feb 26, 2019 6:34 pm

MikroTik only mentions v7 if there is some feature, that can't be implemented because of kernel limitations. In that case, it's technically not possible to make something until we have new kernel.

You know what would help fix this? Having an open source version of Mikrotik. Some of your users are the engineers who develop operating systems, have worked on various OSes including integrating code from KAME in to the BSD projects.

If there's a new kernel required, or a code in an existing kernel which needs to be modified, then perhaps this is the time to be transparent with the community.
Perhaps this is the time to engage the community and inquire if there's any interest in having a community driven project for Mikrotik hardware.

joegoldman · Wed Feb 27, 2019 12:28 am

The development going into 6.x is development FOR 7.x as well. A lot of the roadmapped features have been put into 6.x because of the delays 7.x brings. 7.x isnt going to suddenly have a heap of new features, 7.x will likely be the latest 6.x but on new kernel, and will take a few iterations to start getting new features that were otherwise impossible on the 6.x kernel - for instance my main feature request as of right now would be VRF aware management services and better VRF implementation over-all - my understanding is that this is a kernel limitation in 6.x, but i wont be expecting this feature in 7.0beta1, i'll probably not expect it till 7.5 or later, just because the first few iterations of 7.x will be just making sure everything runs as expected on new kernel.

Development is time. There's not an unlimited amount of developers working on this, and they are obviously still pumping out 6.x (230 odd changes/fixes in current changelog, massive!) so you just have to be patient - if you want massive company resources and promises, go spend massive dollars on Cisco/Juniper/whoever.

huntermic · Wed Feb 27, 2019 11:24 am

We have not advertised v7 as a version. The first post in this forum thread is by a user.
MikroTik only mentions v7 if there is some feature, that can't be implemented because of kernel limitations. In that case, it's technically not possible to make something until we have new kernel.

Other than that, have we told you there will be a v7 soon?

Fake News!

Sorry, this is the first thing that i think of when i read this crap.
You do sound a lot like Trump in this regard, you just can/will not tell the truth.

Wed Feb 27, 2019 11:33 am

Sorry to break the news to some of you, but the official stance has always been - use v6. We are working on v7, and it will be released when it will be ready.

huntermic · Wed Feb 27, 2019 11:49 am

Sorry to break the news to some of you, but the official stance has always been - use v6. We are working on v7, and it will be released when it will be ready.

Correct, that indeed is the thing you keep telling us.
The problem we have is that for many years now you refer to this V7 and there even is a subforum called V7Beta, this raises expectations that after many years turn into frustration

Wed Feb 27, 2019 11:56 am

I can repeat again, we only refer to v7 if there is something that can't be implemented in v6 due to kernel limitations. It doesn't even mean v7 exists.

mistry7 · Wed Feb 27, 2019 12:00 pm

Sorry to break the news to some of you, but the official stance has always been - use v6. We are working on v7, and it will be released when it will be ready.
Correct, that indeed is the thing you keep telling us.
The problem we have is that for many years now you refer to this V7 and there even is a subforum called V7Beta, this raises expectations that after many years turn into frustration

Developing on old Platforms often costs more ManPower then needed, there are so much changes in 4.xx Linux Kernel, why invest the time to back port them?
And it happend what i promise last year, Linux kernel is now at 5.00 and we don't see anything about ROS 7.......
We even don't know on that Kernel ROS 7 would be based.....but it would be outdated from the first day it released on....

huntermic · Wed Feb 27, 2019 12:07 pm

It doesn't even mean v7 exists.

In that case, please do not say V7 but instead say: Some version we might release in the (probably distant) future

nescafe2002 · Wed Feb 27, 2019 12:10 pm

In that case, please do not say V7 but instead say: Some version we might release in the (probably distant) future

Really?

huntermic · Wed Feb 27, 2019 12:12 pm

In that case, please do not say V7 but instead say: Some version we might release in the (probably distant) future

Really?

Why not, holds the same informational value: nothing

connorgoodwolf · Wed Feb 27, 2019 4:45 pm

Sorry to break the news to some of you, but the official stance has always been - use v6. We are working on v7, and it will be released when it will be ready.

ZERO TRANSPARENCY

Wed Feb 27, 2019 4:46 pm

When is the new Tesla Y model coming out? What features will it have?

Which company, even the transparent ones, give you information about unreleased products?

connorgoodwolf · Wed Feb 27, 2019 4:51 pm

When is the new Tesla Y model coming out? What features will it have?

Elon has stated publicly the release of information about the model will come out around March 15.

When will we see a roadmap for v7?

connorgoodwolf · Wed Feb 27, 2019 4:52 pm

A lot of the roadmapped features have been put into 6.x because of the delays 7.x brings. 7.x isnt going to suddenly have a heap of new features, 7.x will likely be the latest 6.x but on new kernel

The current kernel needs quite a few modifications in order to accommodate much needed improvements.

Wed Feb 27, 2019 4:55 pm

Elon has stated publicly the release of information about the model will come out around March 15.

Before he said that. You didn't know about March 15, right?

OK so, please wait for a similar statement.

telcouk · Wed Feb 27, 2019 4:58 pm

Elon has stated publicly the release of information about the model will come out around March 15.
Before he said that. You didn't know about March 15, right?

OK so, please wait for a similar statement.

We've been patiently waiting 5+ years :/

connorgoodwolf · Wed Feb 27, 2019 5:07 pm

Before he said that. You didn't know about March 15, right?

OK so, please wait for a similar statement.

How about you get the big boys at Mikrotik to the table so we can have an adult discussion?

You're only showing us how worthless the MikroTik training is since there is "no v7", no road map, nothing to show, no transparency and no engagement for the community who would gladly work on an community distribution (sort of like how people can load SwOS).

anav · Wed Feb 27, 2019 5:46 pm

@vecernik87

Hey guys, stop harassing Mikrotik about V7 It is a good topic for jokes but bad choice for serious discussion.
I am not a blind fan, but in this case, @normis is right. Anyone, who ever did a continuous development, knows that specifying future dates of release is a suicide. If you don't make it on time, everyone will complain (and it will be legit because promise was not delivered). If you rush it and make mistake/bug, everyone will complain (and it will be legit because even a simple bug can cost business millions).
Can't you be just happy that there are free updates which not only fix security holes but also improve functionality? And you can get all of that with device prices starting at $50?

In addition, demanding things this way is a bit ridiculous: "what mikrotik is doing ... is wrong" , "you need to address". Cmon... are you a shareholder or what?

Ubiquity is much more flexible in communication
Yeah. They flexibly told me that their products will misbehave if power is lost unexpectedly and the only solution is factory reset and restore from backup. Unfortunately I am stuck with them on three hospitality sites...

Wait, isnt this poster the magic unicorn? Even the magic unicorn doesn't know when v7beta will come out and thus we are all being treated equally. By the way buset1974 is obviously a student of software engineering and knows of what he speaks, the rest of you yahoos are smart as whips but on big picture stuff not really. Anyway, the real question is what will happen first, v7Beta released or a fricken stable version of Apex Legends.........

ofer · Wed Feb 27, 2019 9:15 pm

Before he said that. You didn't know about March 15, right?

OK so, please wait for a similar statement.
How about you get the big boys at Mikrotik to the table so we can have an adult discussion?

You're only showing us how worthless the MikroTik training is since there is "no v7", no road map, nothing to show, no transparency and no engagement for the community who would gladly work on an community distribution (sort of like how people can load SwOS).

Same here I'm willing to join forces towards a community driven project.

patrick7 · Wed Feb 27, 2019 9:16 pm

When is the new Tesla Y model coming out? What features will it have?

At least you can repair a broken tesla. But we can't repair RouterOS. BGP has been broken for 5+ years now and nobody knows when it will be fixed.
Oh, sorry, we do! It will be fixed with RouterOS v7 (tm)

connorgoodwolf · Wed Feb 27, 2019 9:25 pm

Same here I'm willing to join forces towards a community driven project.

I'd be interested as well. A community driven firmware could push MikroTik back in to the limelight, but as right now they're falling to the way side.