RouterOS v7.0 beta1 - when?

dominiaz · Fri Jan 16, 2015 6:53 pm

Hi,

When RouterOS v7 beta1 is gonna to be released?

k3dt · Tue Jan 20, 2015 9:06 pm

we all are interested too

StubArea51 · Fri Jan 23, 2015 1:39 am

Same here....we are starting to think v7 is a unicorn

Fri Jan 23, 2015 10:56 am

Same here....we are starting to think v7 is a unicorn

a magical unicorn

PtDragon · Sun Jan 25, 2015 8:36 am

Be patient guys!
I'm sure they work on it but let's wait for their news.
Don't pus them, they should work without our pressure to make it good ^_^

Sun Jan 25, 2015 2:00 pm

I wish it was true. Experience says that we will need to betatest and request the connections during next two years after first stable release to get really working ros. Anyway I am looking forward.

felipeandrade55 · Sat Jan 31, 2015 1:36 pm

Hello friends,

Someone had news about the V7 release date?

PtDragon · Mon Feb 02, 2015 12:28 pm

As normis said here

Sometimes versions are released sooner if there is a critical issue that needs to be resolved. Sometimes we work on a bigger change, so version takes longer.

v7 is currently in internal testing, and will be released as beta when it's stable enough

So no exact date for us.

Mon Feb 02, 2015 7:08 pm

Mikrotik people never give dates as they are not able to fulfil any given date. Their official answer is "when it will be then it will be". Take it or leave it. I just live with that as with exogenous fact.

honzam · Mon Feb 02, 2015 8:45 pm

Mikrotik people never give dates as they are not able to fulfil any given date. Their official answer is "when it will be then it will be". Take it or leave it. I just live with that as with exogenous fact.

Really accurate and truthful description

paoloaga · Tue Feb 03, 2015 12:05 am

Mikrotik people never give dates as they are not able to fulfil any given date. Their official answer is "when it will be then it will be". Take it or leave it. I just live with that as with exogenous fact.
Really accurate and truthful description

It's better to not publish a deadline if it's not sure that it could be honored.

It's even better to release 7.0 beta 1 tomorrow!

(I didn't know that the maximum amount of smilies allowed in a message is 3).

cchance · Tue Feb 03, 2015 6:55 pm

Whats the point of a beta if you don't release it, beta's are meant to be unstable. Release the beta, and start getting broad input early.

Not like they're asking when v7 Final or even RC will be out but beta, for all we know there cud be 900 beta releases before rc1

chemp86 · Fri Feb 06, 2015 6:30 am

(I didn't know that the maximum amount of smilies allowed in a message is 3).[/quote]
In that forum we don`t like smiles!

Fri Feb 06, 2015 10:12 am

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.

cchance · Sun Feb 22, 2015 7:10 am

Thanks normis, understood is their a timeline/roadmap for when you guys think you'll reach feature complete for beta? Or even a feature list for what your planning to implement, i mean right now all the forum seems to be is a wishlist.

Things like proper DHCPv6 with radius and other v6 stuff that don't match up with the v4 counterparts sort of are forcing some of us into chosing between investing in MT now for large deployments knowing that the v6 features are coming, and just going another way (cisco etc) which i personally would rather not do.

dtaht · Sat Mar 07, 2015 8:10 am

Have you got fq_codel working yet in 7.0?

I have done fq_codel backports (where needed) for several manufacturers at this point, and can help out - I also do things like BQL - and I would really like to get some performance numbers out of it + sqm-scripts on your higher end hardware, when your next version of the OS arrives.

We hit a pretty hard shaping limit on a lot of lower end gear at about 60Mbits of HTB, (the fq_codel part is nearly invisible to the cpu, but HTB, oh, my!), and the market, at least in the US, is migrating to 110Mbits of needed inbound shaping on comcast's deployment to cut inbound latencies from about 600ms to 10ms, under load.

I keep hoping to find an off-the shelf solution for my userbase that works as well as 110mbit as it does at 50mbit.

http://burntchrome.blogspot.com/2014/05 ... -with.html

semenko · Fri Mar 13, 2015 6:06 am

Have you got fq_codel working yet in 7.0?

Hey -- you wrote one of the RFCs here!

Awesome!

+1 for fq_codel. This is one of the ~only things significantly holding back our RouterOS userbase.

We have to significantly throttle bandwidth to preserve some highly interactive apps at peak throughput. fq_codel would be of *huge* benefit to us!

cchance · Mon Mar 16, 2015 8:47 pm

I just wish MT was more open with the 7.0 development, i'm really silently praying that MUM March they start to announce some things. I mean even just a "what we have working so far" "whats we want to work" " what we plan to fix in 7" something...

I mean are we looking at mid-late 2015 or 2018 lol

There's a number of blockers that everyone's aware of,
1gigabit tcp stream limit due to it being non-threaded
DHCP RADIUS Accounting
fq_codel support
lldp support
ipv6 NAT64/DNS64/6rd/Radius... pretty much everything beyond the basic bare minimum

Radius COA Support

Nevon · Tue Mar 31, 2015 8:15 pm

Would like to know as last post.. Mikrotik.. are we talking 4 weeks or 4 years?
Please lets us know any information..

/Markus

k3dt · Tue Mar 31, 2015 9:50 pm

I just wish MT was more open with the 7.0 development,

yes, PLEASE make RouterOS opensource or create quality SDK. I'll bet there are a lot of good programmers who can help make RouterOS better.

Tue Mar 31, 2015 9:57 pm

I just wish MT was more open with the 7.0 development,
yes, PLEASE make RouterOS opensource or create quality SDK. I'll bet there are a lot of good programmers who can help make RouterOS better.

I'm pretty sure that's not what cchance meant, and besides... It's totally not in MikroTik's interest to close down one of their two primary revenue streams (the other being RouterBoard devices).

The ability to create additional modules with some sort of an SDK would be nice though. I can already think of several scripting related features I could implement myself, if given such access (think commands and menus related to manipulating variable data; akin to ":pick", ":find", etc.).

cchance · Wed Apr 22, 2015 6:35 pm

LOL ya poor wording on my part when i said "open" i didn't mean open source, i just meant more open with roadmap/featureplans/timelines for the beta.

DJGlooM · Sun Jan 10, 2016 5:24 pm

2016 is up!
When?

Chupaka · Sun Jan 10, 2016 8:57 pm

looking forward to EU MUM 2016

paoloaga · Mon Jan 11, 2016 4:06 am

timoid · Wed Jan 13, 2016 1:25 pm

Duke Nukem Forever

leoktv · Wed Jan 13, 2016 3:08 pm

Chupaka CU at the MUM

Chupaka · Wed Jan 13, 2016 3:19 pm

Chupaka CU at the MUM

seems like I won't be there

I can't find affordable plane tickets from Minsk to Ljubljana. 500 euro is a bit expensive

satish143 · Wed Feb 17, 2016 6:26 pm

I heard they are releasing v7 beta second half of this year...

PtDragon · Sat Apr 16, 2016 7:27 am

I heard they are releasing v7 beta second half of this year...

That are just rumors.
Nobody knows when exactly, even developers.
Lot of things are ready but they need to hunt unpredictable number of bugs before it can reach good enough to be shown.
Sadly they don't wish to publish any news on progress(not even asking for timeline, just bit of news how it goes).
Also they currently work on 6x branch too so they don't fully focus on 7x.

paoloaga · Mon Apr 18, 2016 10:55 am

But we like to hunt bugs in new firmwares!

rextended · Mon Apr 18, 2016 11:08 am

I prefer ultra-stable 6.66
than new software to debug from 0

What 7.x can have than is impossible to get from 6.x ???

paoloaga · Mon Apr 18, 2016 11:57 am

What 7.x can have than is impossible to get from 6.x ???

Several IPv6 features, at the current state iBGP for IPv6 is unusable.

Mon Apr 18, 2016 1:19 pm

What 7.x can have than is impossible to get from 6.x ???

Off the top of my head:

- New IPSEC with IKEv2 support
- Proper VRF support
- Ability for router services (WinBox, SSH, WebMin) to be available inside VRF's
- OSPFv3 recursive next-hop fixes
- MPLS Fast Re-Route
- Improved MPLS logging
- VPNv6 support
- MPLS label per VRF rather than per prefix
- ARP PVLAN Mode
- Route filtering improved speed and granularity
- Route processing improved speed
- BGP Route Reflector mode, e.g. Routes never enter the FIB.
- Ability to view route types other than IPv4/IPv6. e.g. VPNv4, VPNv6, L2VPN
- Ability to view advertised/received routes on BGP PE-CE sessions (inside a VRF)
- Routing filter action "Update Address List" which adds/removes matching prefixes from an address list
- VXLAN support
- IGMP Proxy
- VRF aware multicast routing
- 802.11ac Spectral-Scan
- Bridge filter action "FastTrack"
- Netflow contains AS info
- Support for a large number of LTE cards

Chupaka · Mon Apr 18, 2016 4:44 pm

- Routing filter action "Update Address List" which adds/removes matching prefixes from an address list

oh my gosh!

shut up and take my money!

patrick7 · Mon Apr 18, 2016 5:46 pm

Missing on the list:

BGP MIB for SNMP
Community Filtering by Regex

Mon Apr 18, 2016 10:26 pm

Missing on the list:

BGP MIB for SNMP
Community Filtering by Regex

Both have been promised and would be wonderful.

Mon Apr 18, 2016 10:37 pm

- Routing filter action "Update Address List" which adds/removes matching prefixes from an address list
oh my gosh! shut up and take my money!

+1 - then it would be easy to use an IP reputation vendor's BGP feed to automatically update an IP filter in real time.

rextended · Mon Apr 18, 2016 11:21 pm

What 7.x can have than is impossible to get from 6.x ???
Off the top of my head:

- New IPSEC with IKEv2 support
- Proper VRF support
- Ability for router services (WinBox, SSH, WebMin) to be available inside VRF's
- OSPFv3 recursive next-hop fixes
- MPLS Fast Re-Route
- Improved MPLS logging
- VPNv6 support
- MPLS label per VRF rather than per prefix
- ARP PVLAN Mode
- Route filtering improved speed and granularity
- Route processing improved speed
- BGP Route Reflector mode, e.g. Routes never enter the FIB.
- Ability to view route types other than IPv4/IPv6. e.g. VPNv4, VPNv6, L2VPN
- Ability to view advertised/received routes on BGP PE-CE sessions (inside a VRF)
- Routing filter action "Update Address List" which adds/removes matching prefixes from an address list
- VXLAN support
- IGMP Proxy
- VRF aware multicast routing
- 802.11ac Spectral-Scan
- Bridge filter action "FastTrack"
- Netflow contains AS info
- Support for a large number of LTE cards

And why that can not be done on 6.x?
Is one true question, is not a joke...

Tue Apr 19, 2016 12:16 am

I think the fact that 6.x uses an old Linux kernel is the main thing behind a lot of this.

Also, I think a major overhaul of the routing protocols is being done for ROSv7. For instance, it seems that currently, BGP pretty much uses the FIB to store its data, and juggles the active/inactive state of routes that it picks... as opposed to keeping a separate table for BGP and dumping the winning routes down into the FIB. I've come across a few oddities resulting from this behavior, and I think that they're probably redoing BGP to use its own table separate from the FIB, which makes me smile - but something like this probably requires quite an overhaul. Also, the fact that BGP can't multithread in the tile platform is pretty freakin' broken. I know lots of folks on here are chomping at the bit for a threaded BGP process that can benefit from more cores.

Hopefully IPv6 gets lots of love in ROSv7. I know lots of people here are dying to have a NAT table in IPv6 (and what a holy war THAT discussion is)

k750 · Tue Apr 19, 2016 1:00 am

And DHCPv6

cchance · Tue Apr 19, 2016 3:08 am

How is there still no 7.0 news or alpha

paoloaga · Tue Apr 19, 2016 10:20 am

How is there still no 7.0 news or alpha

Because 7.0 news or alpha are not ready, yet.

Tue Apr 19, 2016 12:10 pm

+1 - then it would be easy to use an IP reputation vendor's BGP feed to automatically update an IP filter in real time.

That's a good idea!

There are many uses for this functionality.

We are planning to use it so we can advertise ranges with communities via ExaBGP to our Route Reflectors. Our Border Routers will then update address lists from the BGP communities and we can then queue traffic differently for each list.

Tue Apr 19, 2016 12:36 pm

And why that can not be done on 6.x?

I guess it can... but at a price of breaking something existing so severely so it is just logical to change version numbering from 6 to 7...

Actually, that's how software development is usually done overall.

Tue Apr 19, 2016 5:03 pm

+1 - then it would be easy to use an IP reputation vendor's BGP feed to automatically update an IP filter in real time.
That's a good idea!

There are many uses for this functionality.

We are planning to use it so we can advertise ranges with communities via ExaBGP to our Route Reflectors. Our Border Routers will then update address lists from the BGP communities and we can then queue traffic differently for each list.

In fact, I was quite sure that "add prefix to address list" was already an option and I set out to implement this one day. I started to configure the route filters and was genuinely surprised when I didn't find this action - it seemed like such a simple but powerful way to distribute IP policy that OBVIOUSLY it was already in there, right?

I was also surprised when I couldn't find "next hop address" as a matcher....

sigtrm · Tue May 24, 2016 8:18 pm

I think you should name it RouterOS 10 or RouterOS X already.( and implement UDP and LZO in ovpn)

Wed May 25, 2016 11:40 am

I think you should name it RouterOS 10 or RouterOS X already.( and implement UDP and LZO in ovpn)

Mikrotik have already confirmed UDP support for OpenVPN is coming in RouterOS v7.

pe1chl · Wed May 25, 2016 2:59 pm

Mikrotik have already confirmed UDP support for OpenVPN is coming in RouterOS v7.

The issue is not "what exciting features will v7 have" or "in which version will (some feature) be available".
The issue is "when will v7 be released as beta".

paoloaga · Wed May 25, 2016 5:32 pm

6.xx release candidates are not released daily anymore, could this be a sign that 7.0 is ready?

Cross your fingers and fasten your seatbelts.

sigtrm · Thu May 26, 2016 2:26 am

Mikrotik have already confirmed UDP support for OpenVPN is coming in RouterOS v7.
The issue is not "what exciting features will v7 have" or "in which version will (some feature) be available".
The issue is "when will v7 be released as beta".

Indeed, also I am lost, what is confirmed and what won't be implemented, because I swear I saw info somewhere that ovpn will not have any new features implemented!

Thu May 26, 2016 8:24 am

You all know that even mikrotik doesn't know when and what will be done. More than that they normally don't know even if it will be done. There is only one valid and relevant answer you can get from them: when it will be then it will be. Due to that all speculations are useless.

pe1chl · Thu May 26, 2016 10:48 am

6.xx release candidates are not released daily anymore, could this be a sign that 7.0 is ready?

Cross your fingers and fasten your seatbelts.

That would be great!
Talks about it have gone on for a long time... it is often not a good idea to put so much announced functionality
in a new version because even when it is very good it can still be a disappointment.

pe1chl · Thu May 26, 2016 10:52 am

Indeed, also I am lost, what is confirmed and what won't be implemented, because I swear I saw info somewhere that ovpn will not have any new features implemented!

Fortunately I am not waiting for OpenVPN changes. I don't use it on MikroTik routers.
However, I sort of smell that there are issues with OpenVPN on closed source platforms. I have had a router from
another manufacturer that introduced OpenVPN at some time, and in a later version it suddenly disappeared without
good explanation. Maybe the OpenVPN developers are not to keen on seeing their product in closed source
environments? It could be that MikroTik is doing their own development of a compatible implementation, and that
this explains why it is so hard to just align the OpenVPN in 6.35 with the current state of open-source OpenVPN...

Thu May 26, 2016 10:59 am

OpenVPN is not the reason v7 is not out yet

New kernel and routing are.

pe1chl · Thu May 26, 2016 11:09 am

OpenVPN is not the reason v7 is not out yet
New kernel and routing are.

I understand that, but there must be some reason why OpenVPN is not updated in the 6.x version despite the
thousands of requests to do so. When RouterOS is running a more-or-less standard OpenVPN internally, I see
no reason why often-requested features of OpenVPN could not be added to the 6.x version. They don't
require a new kernel or different routing.
There is always the issue of "how much work to we spend on 6.x that we better spend on 7.0" but when such
a new version remains a myth for several years it does not help both the users and the manufacturer.

Thu May 26, 2016 11:12 am

I have heard that it is very hard to work on, and nobody likes it for that. But OpenVPN UDP support has been made in v7.

MTusewk · Sat May 28, 2016 4:16 pm

Thanks normis for confirming that.

pe1chl · Sat May 28, 2016 6:06 pm

I think there is a risk that RouterOS v7 will go into the Windows Vista scenario.

Remember, after Windows XP was released we heard the endless stories about how the "Longhorn" version
would change everything and it would be the Windows version we should all look forward to.
But it was postponed time after time, and when it was no longer tolerable to postpone it more the "innovative features"
we heard about all the time were quickly ripped out to gain time, and the product was released as Windows Vista,
arguably the biggest disappointment ever in Windows releases.

Not only because some of the features had been stripped out, but also because expectations had grown skyhigh
during the long wait. MikroTik, please try to avoid this situation (if still possible).

paoloaga · Mon May 30, 2016 12:29 pm

[...] and the product was released as Windows Vista, arguably the biggest disappointment ever in Windows releases [...]

The comparison isn't appropriate. There has ever been a stable and good windows release?

Mon May 30, 2016 12:40 pm

Easy solution - do not make any expectations

We have already posted from time to time, that the biggest change is under the hood (minor kernel upgrade). There is no new GUI or anything. We are also working on a new routing engine.

Actually we are making really cool stuff even in v6. Look at the recent RC versions - interface lists, domain lists for firewall, repeater mode etc.

efaden · Mon May 30, 2016 1:32 pm

Easy solution - do not make any expectations

We have already posted from time to time, that the biggest change is under the hood (minor kernel upgrade). There is no new GUI or anything. We are also working on a new routing engine.

Actually we are making really cool stuff even in v6. Look at the recent RC versions - interface lists, domain lists for firewall, repeater mode etc.

Do the domain lists for firewall resolve only once or do they resolve at the ttl of the record?

Sent from my XT1575 using Tapatalk

Mon May 30, 2016 1:39 pm

ttl record

Mon May 30, 2016 5:17 pm

I must have missed the announcement of domain lists. That should be very helpful for people who want to block YouTube.

Chupaka · Mon May 30, 2016 11:39 pm

I must have missed the announcement of domain lists

the same thing here. Normis, could you add changes to the top or bottom of the changelist, not in the middle?

pe1chl · Tue May 31, 2016 10:46 am

It looks like a cool feature! Are there operational limits to the number of IP addresses that the domain name returns?
It could be tempting to setup a domain name with a blocklist of known "intruders" and have several routers query
that domain name to adjust the firewall, but of course there are limits to the number of A records in a DNS reply
over UDP, it will have to do the query in TCP mode, and even then there may be buffers in your implementation
that limit the number of addresses actually processed. Depending on the actual limit, the feature may be more
or less useful for that purpose.

Tue May 31, 2016 10:57 am

It looks like a cool feature! Are there operational limits to the number of IP addresses that the domain name returns?
It could be tempting to setup a domain name with a blocklist of known "intruders" and have several routers query
that domain name to adjust the firewall, but of course there are limits to the number of A records in a DNS reply
over UDP, it will have to do the query in TCP mode, and even then there may be buffers in your implementation
that limit the number of addresses actually processed. Depending on the actual limit, the feature may be more
or less useful for that purpose.

no

pe1chl · Tue May 31, 2016 11:43 am

no

I created a domain name with 1789 addresses and added it as an address list.
Indeed the router (in this case a CHR) processes it OK, but my browser gets in trouble when visiting the address list
page after that.

This is something that maybe needs to be looked at, it also causes problems when opening the "connections" page
when 2000 connections are active. It requires a good browser and a lot of memory. Maybe there could be some
limit on the number of lines displayed in such tables?

Tue May 31, 2016 11:45 am

It requires a good browser and a lot of memory. Maybe there could be some
limit on the number of lines displayed in such tables?

Well wouldn't the browser get into trouble if any other DNS server replied with so many results? I don't think something like that is common.

pe1chl · Tue May 31, 2016 11:54 am

It requires a good browser and a lot of memory. Maybe there could be some
limit on the number of lines displayed in such tables?
Well wouldn't the browser get into trouble if any other DNS server replied with so many results? I don't think something like that is common.

No, the browser is not making the DNS query! I added a domain name to the address list, the router resolves that,
and as a result it inserts 1789 rules in the address list. So far it works fine. However, when I visit the address list
page in WebFig, the resulting table on the screen is so large that the browser gets in trouble processing that table.

I see this also when I open the Connections list at work on a router which has 250 mobile users all doing NAT.
The connections table normally has like 2000 entries and when I visit that tab, the processor is 100% loaded and
the browser allocates lots of memory.

Maybe there could be some system setting for a maximum number of rows displayed on such a page, default
unlimited, that I could set to 1000 or so to limit the number of rows (and the final row would be something like
"nnn more rows not shown due to row limit" or so).

In this area I have another enhancement request: a "freeze" icon that appears on any dynamic page that stops the
updating on that page (timers, counters) that one can click when studying such a page and not wanting the continuous
data traffic that such a page incurs.

Chupaka · Wed Jun 01, 2016 2:05 am

domain lists for firewall

please check dynamic entries with domain name. they count down to 0s and stay here forever

pe1chl · Wed Jun 01, 2016 9:52 am

domain lists for firewall
please check dynamic entries with domain name. they count down to 0s and stay here forever

I don't see that behavior here! The dynamic entries show no timeout value, they are apparently directly managed
by the parent entry and it uses the DNS TTL as timeout. Maybe you have explicity assigned a timeout?

Chupaka · Wed Jun 01, 2016 4:52 pm

I don't see that behavior here! The dynamic entries show no timeout value, they are apparently directly managed
by the parent entry and it uses the DNS TTL as timeout. Maybe you have explicity assigned a timeout?

add entry with timeout and address=IP-address. it will count to 0s and disappear. now add entry with timeout and address=some.domain. time will go to 0s and entry will stay in list. that's the point

Bergante · Thu Jun 02, 2016 11:08 am

They are switching to FreeBSD, it takes time!

alibloke · Fri Jun 03, 2016 12:14 am

They are switching to FreeBSD, it takes time!

Is this true??

leoktv · Fri Jun 03, 2016 11:51 am

The last info i got is that is not right

Fri Jun 03, 2016 4:44 pm

I don't recall if it was earlier in this thread or in some other thread, but I seem to recall Normis saying that v7 included a "minor kernel update"
Switching to a BSD kernel would be pretty major...

dlynes · Mon Jun 06, 2016 5:19 pm

I have heard that it is very hard to work on, and nobody likes it for that. But OpenVPN UDP support has been made in v7.

Awesome! I've always wondering why v6 didn't support UDP on OpenVPN...afaik, almost nobody uses TCP-based OpenVPN on Linux.

paoloaga · Mon Jun 06, 2016 6:00 pm

Anyway is there a ballpark figure of how long will it take to publish the first releases, or is still wildly unknown?

Is Mikrotik trying to surprise us all releasing it suddenly, or are they going to announce it?

My routers are still crying for the IPv6 workarounds (I imported the full BGP view into OSPF because of the address recursion problems, and it is not wise to have such a giant OSPF routing table).

Mon Jun 06, 2016 6:04 pm

I expect that mikrotik will announce it on some mum at the time when it will be ready in rc stage. So it will be very sudden surprise.

Bergante · Tue Jun 07, 2016 12:08 pm

They are switching to FreeBSD, it takes time!
Is this true??

Just kidding!

Whatever they use, I am really itching to see what they're up to!

kemerovo · Tue Jun 07, 2016 7:44 pm

Easy solution - do not make any expectations

We have already posted from time to time, that the biggest change is under the hood (minor kernel upgrade). There is no new GUI or anything. We are also working on a new routing engine.

Actually we are making really cool stuff even in v6. Look at the recent RC versions - interface lists, domain lists for firewall, repeater mode etc.

1. There are any plans igmp snooping in the seventh version ros ???
2. License the fourth version include only the sixth version of ros, have to buy a new license ??

Tue Jun 07, 2016 10:28 pm

2. License the fourth version include only the sixth version of ros, have to buy a new license ??

No, there is no need to buy a new license. That restriction has been eliminated ~2 years ago. Check the wiki.

Milan · Wed Jun 08, 2016 1:25 am

For more than 3 years I'm waiting for v7 as I really need IPv6 NAT and this feature is there since 3.9.0 Linux kernel (but v6 has 3.3.5).

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.

paoloaga · Wed Jun 08, 2016 2:26 am

For more than 3 years I'm waiting for v7 as I really need IPv6 NAT and this feature is there since 3.9.0 Linux kernel (but v6 has 3.3.5).

Just a small advice: if you need NAT on IPv6 you are doing something wrong...

leoktv · Wed Jun 08, 2016 7:08 am

That is needed id NAT64 to be able to go 100% IPv6. This is for translating from IPv6 to IPv4 for 100% IPv6 clients.

pe1chl · Wed Jun 08, 2016 11:14 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.

kemerovo · Mon Jun 20, 2016 5:45 pm

Easy solution - do not make any expectations

We have already posted from time to time, that the biggest change is under the hood (minor kernel upgrade). There is no new GUI or anything. We are also working on a new routing engine.

Actually we are making really cool stuff even in v6. Look at the recent RC versions - interface lists, domain lists for firewall, repeater mode etc.

There are any plans igmp snooping in the seventh version ros ???

!!!!

mrz · Mon Jun 20, 2016 5:59 pm

http://forum.mikrotik.com/viewtopic.php ... p+snooping

kemerovo · Mon Jun 20, 2016 7:18 pm

http://forum.mikrotik.com/viewtopic.php ... p+snooping

question must necessarily be repeated 2 times ???
can be answered yes or no , and not throw the link .
I need a clear answer as to what version of it will work .
response when normal will operate IPTV , I still have not seen

Zorro · Mon Jun 20, 2016 7:38 pm

That is needed id NAT64 to be able to go 100% IPv6. This is for translating from IPv6 to IPv4 for 100% IPv6 clients.

both NAT6to4, NAT4to6 and even NAT6to6 was pretty common requests actuallyl aswell as differnt (not only by name, but design)implementations of Dual stack.
as for kernel - moving to fBSD would be COOL(routers wise), but unlikely, especially considering dependance on processors SDK and toolchain, which isn't so good over there(non-existent for some vendors).
DragonFlyBSD would be even better, btw, especially CCR-wise(its scale as hell to both on many-core and multi-core hosts and routers - difference is overhelming. i used to enjoy other portions in it, like HAMMERFSv2 and other stuff, simply impossible in other OS'es, thus.

mrz · Tue Jun 21, 2016 12:38 pm

http://forum.mikrotik.com/viewtopic.php ... p+snooping
question must necessarily be repeated 2 times ???
can be answered yes or no , and not throw the link .
I need a clear answer as to what version of it will work .
response when normal will operate IPTV , I still have not seen

Answer is in the second post.

kemerovo · Tue Jun 21, 2016 12:49 pm

Answer is in the second post.

is not the answer , it is an evasion .
More specifically , you can ?

kemerovo · Mon Jun 27, 2016 4:00 am

why not answer my question ?

javajox · Sat Jul 16, 2016 4:05 pm

Any news about v7 ? I understand that the mikrotik staff can't give an exact date. I would like to know at least if it will be released this year (2016) or not ?

patrick7 · Sat Jul 16, 2016 6:39 pm

11.01.2016:

-> It definitely will be released this year

13.06.2016:

Can we still expect v7 this year?
-> i hope so.

javajox · Sat Jul 16, 2016 10:47 pm

patrick7, how do you know ? You aren't from staff

patrick7 · Sun Jul 17, 2016 12:16 am

Ehm, Support Ticket?

dawg · Tue Aug 09, 2016 11:56 pm

I bought an MC7355 6+ months ago to use as a cell modem. Your page claims it will be in v7, but that still hasn't come out yet. When can I expect to be able to use it? It doesn't even show up in the USB list, let alone the "/interface lte" menu.

Thanks.

tierpath · Tue Aug 16, 2016 4:58 am

I have heard that it is very hard to work on, and nobody likes it for that. But OpenVPN UDP support has been made in v7.

OMG. I feel the fires of hell.

cityboy · Tue Aug 16, 2016 2:49 pm

I bought an MC7355 6+ months ago to use as a cell modem. Your page claims it will be in v7, but that still hasn't come out yet. When can I expect to be able to use it? It doesn't even show up in the USB list, let alone the "/interface lte" menu.

Thanks.

I bought MC7304 and I have the same problem

maxluq1990 · Sat Aug 20, 2016 1:50 am

Hi, guys!

I'm Max from Argentina and new in this forum.

I bought one month ago (like other members) a Sierra Wireless AirPrime MC7355 4G Mini PCI-E card for my basebox 5 and I thought that the OS 7 is already released because I read on the "Hardware Compatibility" page that the MC73xx is compatible with that version. My surprise was when I noticed that the os7 is not released yet and neither there are an RC or beta version

.

I seen that We are several users waiting for the arriving of the new version.

Thanks by the space for our expression and questions.

Greetings!
Max!

RogerWilco · Fri Aug 26, 2016 2:32 am

I bought an MC7355 6+ months ago to use as a cell modem. Your page claims it will be in v7, but that still hasn't come out yet. When can I expect to be able to use it? It doesn't even show up in the USB list, let alone the "/interface lte" menu.

Thanks.
I bought MC7304 and I have the same problem

The MC7304 DOES work now with PPP.

cityboy · Fri Aug 26, 2016 4:01 pm

I know but I'm waiting for lte

pe1chl · Fri Aug 26, 2016 4:04 pm

I would prefer PPP on my Huawei sticks because LTE introduces yet another layer of NAT.

Siona · Sun Aug 28, 2016 12:47 am

But using ppp is slowing you to 20-30mbps

pe1chl · Sun Aug 28, 2016 12:19 pm

But using ppp is slowing you to 20-30mbps

I have no problem with that. Realistically the speed is not much more than that anyway.
Remember the advertised speed is the aggregate speed for all users on that access point.

Siona · Sun Aug 28, 2016 12:33 pm

Sure but there are some places in Poland you can get 75 Mbps easly.

pe1chl · Sun Aug 28, 2016 5:52 pm

Sure but there are some places in Poland you can get 75 Mbps easly.

I would still prefer not having NAT. Unfortunately on the Huawei E3372 sticks that I use it is very difficult to switch between LTE and PPP, otherwise I would do it.

I don't see why the stick has to have NAT to use the LTE interface. In earlier 2G and 3G sticks there were similar interfaces and they worked
just like an ethernet interface with DHCP. Should be possible with LTE as well.
(note this is not a MikroTik gripe, the problem is in the "Hilink" firmware of the Huawei stick)

Siona · Sun Aug 28, 2016 5:56 pm

Best one would be an e3372 with bridge mode possible ... but there isn't.

smurphy · Fri Sep 16, 2016 10:35 am

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.

Right.
Any chance to get (even in early Alpha) one minimal V7 release, just to test the installation/booting capabilities on a j1900 Atom board? (x86).
It has taken me a while to figure out a way to install 6.x on it, as the USB gets disconnected as soon as the kernel drivers take over.
At least, if you provide me access to your currently used kernel source code so I can compile it and run it on that beast (Probably with an alpine OS base).

I really just want to make sure that when it is release it will run on that hardware of mine :}
Thx.

Fri Sep 16, 2016 11:00 am

At least, if you provide me access to your currently used kernel source code so I can compile it and run it on that beast (Probably with an alpine OS base).

I really just want to make sure that when it is release it will run on that hardware of mine :}
Thx.

RouterOS v7 will use a 4.4 or newer kernel as a base. If 4.4 or newer boots on J1900 than chances are RouterOS v7 will boot and work.

pe1chl · Fri Sep 16, 2016 11:10 am

If 4.4 or newer boots on J1900 than chances are RouterOS v7 will boot and work.

Of course it does not only depend on the kernel version number but also on the kernel configuration options used
at compile time. We cannot know what drivers MikroTik include in the compile, we only know that it is not all of them.

smurphy · Fri Sep 16, 2016 11:28 am

At least, if you provide me access to your currently used kernel source code so I can compile it and run it on that beast (Probably with an alpine OS base).

I really just want to make sure that when it is release it will run on that hardware of mine :}
Thx.
RouterOS v7 will use a 4.4 or newer kernel as a base. If 4.4 or newer boots on J1900 than chances are RouterOS v7 will boot and work.

This I know. I have This device: http://hamsing.com/product/html/?39.html - and managed to install routerOS 6.36.3 on it. Only I have no usage of any USB ports after the kernel takes over.
The network interfaces works though. And because that box has no Serial-Port, I have no console access at all to it.
I managed to also run this system very fine using a 3.16.0 / Debian Jessie 8.5 and had no problems at all. Even installing from CDRom worked fine (Using UEFI device).
On the other hand, I am unable to install any RedHat/CentOS 5.x or 6.x system, as the USB gets disconnected as soon as the kernel takes over, disconnecting the CDRom drive and preventing the installer to load additional data. ClearOS also fails (even though I tried Legacy and UEFI boot methods). Didn't try CentOS/RedHat 7 yet... Will try Ubuntu Server 16.04 LTS next.

Most of the time where the installation works, is when I do it using netinstall (after initial system and ramfilesystem are loaded, the rest is done over network), or when using UEFI boot mode (Even if I also have seen it fail). Netinstall does not require USB, while with UEFI sometimes, the USB still works after kernel takes over.

smurphy · Fri Sep 16, 2016 11:29 am

If 4.4 or newer boots on J1900 than chances are RouterOS v7 will boot and work.
Of course it does not only depend on the kernel version number but also on the kernel configuration options used
at compile time. We cannot know what drivers MikroTik include in the compile, we only know that it is not all of them.

This is why I asked for the kernel source and configuration file. That way, I could test and make a running kernel (eventually also identifying what went wrong - if it went wrong

).

Fri Sep 16, 2016 1:02 pm

Maybe wait until v7 beta is out, and if there are any issues with your specific hardware you can work with support to get the relevant drivers added at that point.

smurphy · Fri Sep 16, 2016 2:26 pm

Maybe wait until v7 beta is out, and if there are any issues with your specific hardware you can work with support to get the relevant drivers added at that point.

This - I will definitely do

Hopefully it comes out before I get my Fiber connection

nadeu · Fri Sep 16, 2016 5:34 pm

Maybe wait until v7 beta is out, and if there are any issues with your specific hardware you can work with support to get the relevant drivers added at that point.

You keep thinking that the version 7 is published?

smurphy · Sat Sep 17, 2016 1:11 pm

Maybe wait until v7 beta is out, and if there are any issues with your specific hardware you can work with support to get the relevant drivers added at that point.
You keep thinking that the version 7 is published?

No. When it comes out.

okoun · Fri Dec 02, 2016 12:43 am

Now it is December 1 and version 7 beta is not even a comma ... Does not Mikrotik?

It looks like the end of the world?

Chupaka · Fri Dec 02, 2016 3:17 am

What's wrong with December 1?

Fri Dec 02, 2016 11:24 am

Maybe next summer. I don't think anyone promised December 1st

patrick7 · Fri Dec 02, 2016 11:29 am

Maybe next summer. I don't think anyone promised December 1st

Not 1st of december, but 2016... See ticket 2016010866000027.
Waiting would be much easier if mikrotik would provide additional information about v7 (screenshots, a list with fixed bugs, roadmap, any status update about the progress, etc...).
At the moment the only thing MikroTik tells us is "it's done when it's done". And that for more than 3 years, with serious bugs in v6 which MikroTik refuses to fix because "it is fixed in v7".

Fri Dec 02, 2016 11:33 am

Your ticket.

Question from you: "Will it still be end of the year?

"

Support answer: "I cannot tell you when exactly. It's ready when it's ready."

You ask again, later: "I didn't ask for an exact date."

Support answer again: "There are delays so It is not even known when first beta will come out."

patrick7 · Fri Dec 02, 2016 11:55 am

Not true.

It definitely will be released this year. Unfortunately I do not have specific date.

-> That was the promise.

Some time later I asked if this promise still is valid and then you said no.

Don't get me wrong, I don't expect you to release it tommorrow, but some additional informations (and bugfixes in v6, like recursive routing, BGP peers dropping when you show advertisements) would be appreciated.
It looks like you already started to fix v6 - see the 0:0 bug. Thanks for that.

Fri Dec 02, 2016 12:03 pm

Manipulating a support desk agent into giving such an answer can't speed up programmers with their work

Sorry about that.
It will be ready when finished.

patrick7 · Fri Dec 02, 2016 12:11 pm

I didn't manipulate anyone. And as said, I don't expect you to be faster. But maybe to change the information strategy, and don't say "we don't fix v6 because v7 will do".

Fri Dec 02, 2016 12:15 pm

You are twisting my answers. The issues can't be fixed because of limitations in v6 kernel. Not because we don't want to, or because v7 is coming soon.

patrick7 · Fri Dec 02, 2016 12:23 pm

Accepted. But it isn't possible to make some workaround? As an example, limit print commands to 25% cpu?

Chupaka · Fri Dec 02, 2016 1:20 pm

Maybe next summer

http://mum.mikrotik.com/2017/EU/info/EN

Fri Dec 02, 2016 1:21 pm

Maybe next summer
http://mum.mikrotik.com/2017/EU/info/EN

Barely spring, not summer in Latvia yet.

okoun · Fri Dec 02, 2016 5:57 pm

The energy that is spent on these MUMs would be better to move the development RouterOS 7
MUM same thing all the time but this has probably nobody cares much ...

patrick7 · Fri Dec 02, 2016 7:28 pm

@MikroTik Feature request which should not depend on kernel version: delete / match bgp communities by regex. Asked a lot here in the forum, and it would make many setup's much better.

AndreaTIK · Fri Dec 02, 2016 9:53 pm

Your ticket.

Question from you: "Will it still be end of the year? "

Support answer: "I cannot tell you when exactly. It's ready when it's ready."

You ask again, later: "I didn't ask for an exact date."

Support answer again: "There are delays so It is not even known when first beta will come out."

To be fair, in the company I work for, a support rep daring answer a customer "it is ready when it is ready" would experience an unpleasant moment.
And, I am not particularly waiting for v7, but this thread, and the similar ones, are starting to become offensive to customers.
I understand that you may be joking, but I don't particularly like answers I consider the official Mikrotik voice when coming from an employee similar to
When it is summer, when it is spring... not yet summer in Latvia... not there yet... maybe in some time...

Please, do as you say.
If you cannot provide a roadmap, or further info, "sorry but we cannot comment on this" would be in my opinion a way better answer than continuous postponing. Especially if you do this for years.

Edit: typos and grammar

Tonda · Sat Dec 03, 2016 9:37 am

I fully agree with AndreaTIK. Normis, please do not play with customer's patience. For me personally delays with RouterOS v7 means, that I will not buy another bunch (around 50) of Mikrotiks, because I have to use 3G dongles with promised support in RouterOS v7, so I currently have to evaluate another solutions. Of course, you can tell yourself, what is bunch of 50 Mikrotiks for us when we sell them by millions, but I am sure, that there are lot of similar stories all around the world.
And in fact it is harm not for us, your customers, but for you - Mikrotik.

Milan · Sun Dec 04, 2016 9:11 pm

Just a small advice: if you need NAT on IPv6 you are doing something wrong...

Masquarade is dynamic NAT, which is not needed in IPv6. Static NAT (1:1) is another question and it's non-presence is a showstopper in many situation. Inability to make a hot fix for IPv6 addressing means you are unable to do/fix a lot of critical (ie not-planned) situation... I have to avoid IPv6 until proper NAT is available or I have to make special IPv6 subnet for every server I have (in a shared segment).

kopimi · Tue Dec 06, 2016 2:14 am

Hi,

long time mikrotik user here, first time poster.
I am guessing that 95% of the people in here waiting for v7 are patiently awaiting the multi-core features, especially (for me) the BGP part. I have lots of cisco equipment that is junk compared to the mikrotik but still the only thing I can use because the multi-core is non-existant in v6. I don't care about the v7 beta, I just care about being able to get full usage of the current hardware we run.

If the v7 is taking so enormous amounts of time, and we know how much better v7 is (I've talked to lots of people at mikrotik about this, I've been at the meetups etc, seen the stats in the slides) - why can't you just release the bgp parts? Is this also a kernel limitation?

I rarely have issues with people joking but agree that the tone from the support is just annoying now. Don't joke about things when people are upset and annoyed. Timing is what's needed. And don't have bad timing when people are tired of spending time waiting...

Tue Dec 06, 2016 8:50 am

One of the reasons v7 takes so long, is that routing programs are being completely re-made from scratch. There is nothing yet to backport.

Tue Dec 06, 2016 10:03 am

For some reason I think of this:

okoun · Tue Dec 06, 2016 11:11 am

One of the reasons v7 takes so long, is that routing programs are being completely re-made from scratch. There is nothing yet to backport.

I understand.
So please leave a development version 6 and let everyone FULLY engaged only version 7 and will be out soon ..

ErfanDL · Tue Dec 06, 2016 2:02 pm

releasing V 7.0 stable for christmas

Tue Dec 06, 2016 2:04 pm

Yeah, but which year?

Chupaka · Tue Dec 06, 2016 2:21 pm

17th

2117th...

Tue Dec 06, 2016 2:28 pm

https://www.youtube.com/watch?v=yesyhQkYrQM

ErfanDL · Tue Dec 06, 2016 3:01 pm

17th

2117th...

ErfanDL · Tue Dec 06, 2016 3:02 pm

Yeah, but which year?

Maybe century 22

cheeze · Tue Dec 06, 2016 7:42 pm

One of the reasons v7 takes so long, is that routing programs are being completely re-made from scratch. There is nothing yet to backport.

Yeah I can totally understand that. Conforming to RFCs and programming a routing stack is *NOT* easy. I'm sure it's one of those things where the programmers sat down and said that it would just be better to redo it from scratch. Which I believe is fine. If the current routing stack is not flexible enough then I think we completely understand that. However I'm kinda looking at it from the business perspective as well. Would it be worth getting something like IP Infusion's ZebOS and integrate that into RouterOS as the routing stack and letting the programmers focus on non-routing stack related features? The reason why I say that is because a routing stack is something that is just a *very* high amount of work that will consistently keep on requiring more and more work (as more and more RFCs come out requiring a routing protocol to do this or that). It sounds like Mikrotik has said that they want to put in that amount of work into developing their own. That's fine and all, however I think adding some small routing features to the current RouterOS is needed just to keep RouterOS moving forward. Reason why I say that is because other vendors are adding more and more features faster (because they have more engineers) and if Mikrotik is to keep up then Mikrotik will have to make a compromise on where to add development time. Now I am not suggesting that Mikrotik scrap the work they have done. I'm sure that the routing stack is probably about 40-50% completed. I'm sure that by about April/May it'll be "feature" complete and probably summer it'll be released as "Beta" for us to test out and around September to October ROS 7 will likely be released. That is fine, but in the mean time we as customers are literally begging for some features that can be put into ROS 6 that aren't big. The one thing that I've been chomping at the bit for is IPv6 BGP next hop resolution. All of the other IPv6 stuff I think can wait, but man that one right there is paramount for making IPv6 "work" on RouterOS. Not being able to get that to work is really a killer. Even if Mikrotik says no, and says that it's not worth investing into the current RouterOS routing stack, then that's fine. I also know that people have requested for a roadmap. Not a development roadmap, but more of a "this is kind of what we are looking to get into ROS 7 on first release" roadmap. Is ISIS going to be added? Is BGP (and other routing protocols) going to be multithreaded (we have the answer to this one....but just using as an example)? Will we be given an ability to be able to tweak convergence time in the routing protocols (like SPF algorithm controls in OSPF, protocol independent convergence for BGP)?

It's more of a transparency thing that's all. We as customers generally like Mikrotik and I think we all generally want to see the equipment get better and better. I know I personally do. I know that Mikrotik can't reveal too much about the state they are in with what they develop because of business agility and keeping other competitors on their toes (like UBNT), but there has to be some give and take with customers....especially since we are waiting and building our networks around Mikrotiks' releases. How about this, on the next big MUM that happens (like the biggest MUM of the year) is it possible for Mikrotik to give a roadmap of what they would like to get into ROS 7.0 release? Just as an olive branch for us customers so we can know how to plan our networks out in the mean time?

For what it's worth that's I guess my feeling on the situation. I'm sure most other people would probably agree and others won't but I figure being honest isn't bad...

pietroscherer · Tue Dec 06, 2016 8:15 pm

I received in my whatsapp

rOS7.png

cheeze · Tue Dec 06, 2016 8:47 pm

I received in my whatsapp

Ok so that's just hilarious.

blingblouw · Tue Dec 06, 2016 8:50 pm

Got me too...dang

AndreaTIK · Wed Dec 07, 2016 6:20 pm

One of the reasons v7 takes so long, is that routing programs are being completely re-made from scratch. There is nothing yet to backport.

Coding is hard.
Project management is hard.
But this is your job.

Excusatio non petita, accusatio manifesta

Second time, please, stop making fun of us.
Maybe it is just me, but I feel It is disrespectful coming from an employee to a customer.
This tends to backfire, in spectacular ways.

cheeze · Wed Dec 07, 2016 8:43 pm

One of the reasons v7 takes so long, is that routing programs are being completely re-made from scratch. There is nothing yet to backport.
Coding is hard.
Project management is hard.
But this is your job.

Excusatio non petita, accusatio manifesta

Second time, please, stop making fun of us.
Maybe it is just me, but I feel It is disrespectful coming from an employee to a customer.
This tends to backfire, in spectacular ways.

I think you're being a little...harsh here. The reason why I say that is because generally the people on these boards are NOT the people whom make the decisions at Mikrotik. So giving the support people grief will only generally cause for nothing to get done. It might even be a detriment honestly.

That being said, I agree that it's very frustrating on the end of the customer. However the "best" general way to do things is to just push consistently. If more people pushed consistently then there would be more pressure upon the management to do something different. However we need to be nice to the people we interface with.

As always, that's why I send emails, support tickets, and generally keep on bothering them in a nice way.

jenechka · Sat Dec 10, 2016 5:21 pm

are there any plans in version 7 fix problems with iptv ??

Chupaka · Sat Dec 10, 2016 7:25 pm

what problems?

jenechka · Sat Dec 10, 2016 7:43 pm

http://forum.mikrotik.com/viewtopic.php ... hilit=iptv
http://forum.mikrotik.com/viewtopic.php ... hilit=iptv

Chupaka · Sat Dec 10, 2016 7:49 pm

Feature request is not a problem

So just wait for the release

jenechka · Sat Dec 10, 2016 7:56 pm

no, not request
igmp snooping very need)

mirhav · Thu Dec 15, 2016 11:52 am

v7 ?

I think it will be a Christmas gift

Mirek

mikruser · Thu Dec 15, 2016 1:06 pm

v7 ?

I think it will be a Christmas gift

I expect v7 immediately after Christ Second Coming

Chupaka · Thu Dec 15, 2016 1:35 pm

I'm more optimistic. Immediately BEFORE

pe1chl · Thu Dec 15, 2016 2:21 pm

I think it will be a Christmas gift

But what year?

jenechka · Thu Dec 15, 2016 5:21 pm

RouterOS v6: may 2013 — present (based on Linux kernel 3.3.5)
RouterOS v5: March 2011 — September 2013 (based on Linux kernel 2.6.35)
RouterOS v4: October 2009 — March 2011 (based on Linux kernel 2.6.26)
RouterOS v3: January 2008 — October 2009 (based on Linux kernel 2.4.31)

delay)))

ErfanDL · Thu Dec 15, 2016 7:37 pm

I think it will be a Christmas gift
But what year?

Century 22

honzam · Thu Dec 15, 2016 10:38 pm

RouterOS v6: may 2013 — present (based on Linux kernel 3.3.5)
RouterOS v5: March 2011 — September 2013 (based on Linux kernel 2.6.35)
RouterOS v4: October 2009 — March 2011 (based on Linux kernel 2.6.26)
RouterOS v3: January 2008 — October 2009 (based on Linux kernel 2.4.31)

Thanks for the info. V6 is there over 3 years

It seems that Mikrotik have a "tiny" delay

cheeze · Thu Dec 15, 2016 10:48 pm

What version of Linux is ROS 7 supposed to be built on.....is it in version 4?

Fri Dec 16, 2016 11:11 am

It is 4.x Kernel. We won't know exactly which one until it is released.

Mikrotik need to find a Kernel that can be patched for all their different architectures and that has the features they need. Not an easy task I am sure !

Netsplite · Sun Dec 18, 2016 2:47 pm

Rewriting mayor parts from scratch while still maintaining stable releases takes time, RouterOS is not something small anymore with plenty of hardware to support and it doesn't have the same amount of resources like the mayor ones (Cisco / Juniper).

So think it's a bit unfair by some to demand an early release especially since we have a perfectly fine release right now (6.x) which gets regular updates with new features and bug fixes, pretty sure Mikrotik shifts priorities to the important areas right now and we will see ROS 7.0 beta at best early next year after they launched a new line-up.

pe1chl · Sun Dec 18, 2016 3:01 pm

Rewriting mayor parts from scratch while still maintaining stable releases takes time

That is why it is not a good idea to rewrite all major parts from scratch for a new revision.
As you can see, new functions and extra capabilities for existing functions are introduced in 6.x all the time.
To rewrite the routing, a sensible approach would be to have new routing code in a new optional package (as was done with wireless)
and keep the old package for the normal user until the new package is stable.

Chupaka · Sun Dec 18, 2016 10:44 pm

To rewrite the routing, a sensible approach would be to have new routing code in a new optional package (as was done with wireless)
and keep the old package for the normal user until the new package is stable.

new routing requires new kernel. a new optional package with a new kernel (and all the other 'optional packages' compatible with that kernel) is just a new version of RouterOS

docmarius · Mon Dec 19, 2016 8:35 am

I would rather see another approach:
The release of a 7 beta with the new kernel (let's say 4.4 - the latest LTS) together with the exiting current packages, which should be not such a big fuss, since kernel networking is generally backwards compatible at API level. This would actually test kernel stability in various scenarios.
Afterwards, a progressive rollout of new features is possible, making use of the new features (which are really interesting - e.g. VRF, multipath routing, per flow routing, KVM).

Mon Dec 19, 2016 9:23 am

The problem is getting all the kernel patches from each chipset vendor working optimally on that kernel. E.g. they need a Kernel that can take Qualcomm MIPS, MediaTek MIPS, Qualcomm ARM, Freescale PPC and Tilera patches. No easy feat!

I'm sure this is made even harder by Tilera being acquired by EZ Chip and then EZ Chip by Mellanox, I can't imagine SDK support on the Tile GX is that fantastic for newer Kernels

Then on top of that you have the VRF and network namespaces changes around Kernel 3.16

So I don't think it's as easy as just running v6 routing on a 4.4 Kernel. There are too many other parts that need to work, and the way VRF's work is fundamentally different.

pe1chl · Mon Dec 19, 2016 11:18 am

To rewrite the routing, a sensible approach would be to have new routing code in a new optional package (as was done with wireless)
and keep the old package for the normal user until the new package is stable.
new routing requires new kernel. a new optional package with a new kernel (and all the other 'optional packages' compatible with that kernel) is just a new version of RouterOS

What I mean is they should have released a new version with a new kernel without combining that effort with a rewrite of all the routing, and then do that rewrite independently in an optional package just like the wireless.
The old routing code can run on the new kernel without much effort, at least it can on all the major Linux distributions.
Combining so many rewrites in a single new release means it will never get done.

pe1chl · Mon Dec 19, 2016 11:19 am

I would rather see another approach:
The release of a 7 beta with the new kernel (let's say 4.4 - the latest LTS) together with the exiting current packages, which should be not such a big fuss, since kernel networking is generally backwards compatible at API level. This would actually test kernel stability in various scenarios.
Afterwards, a progressive rollout of new features is possible, making use of the new features (which are really interesting - e.g. VRF, multipath routing, per flow routing, KVM).

That is exactly what I had in mind.

paoloaga · Tue Dec 20, 2016 12:34 am

Look at Tesla. They rolled out hardware autopilot 2.0. The first shipped units have no features enabled, there aren't even basic ones like cruise control. Features will be added with software updates.

Maybe it could be possible to follow the same path using RouterOS V7: Released featureless in parallel with V6, with features added over time allowing the community to test it.
In many use cases it will be good because not every router make use of ALL the features at the same time.

My 0.02 bitcoins.

pe1chl · Tue Dec 20, 2016 1:03 pm

Released featureless in parallel with V6, with features added over time allowing the community to test it.
In many use cases it will be good because not every router make use of ALL the features at the same time.

Yes, I think it is much better. An all-rewritten RouterOS 7 will have so many little bugs scattered all over the place that nobody
will be able to use it at the very early stages. There is always some showstopping bug that makes it impossible to roll it
out on a nontrivial network. Hence it will not be field tested well and when it comes out of beta, there will be an enormous flood
of bugreports and frustration.
When instead the new version 7 will just be a move to a new kernel with the absolutely required changes in all the software
around it, subsequently every part that they always wanted to improve can be done and tested by those who require that
functionality, while all the others are just running the code and find the minor bugs, just as is happening now with v6 and has
happened with the wireless-fp and wireless-rep packages. Even there you could see that some people only moved to the new
package when the old one was discontinued and only THEN they found it did not work in their environment. With a monolithic
v7 release that would happen for many functions at the same time.

StubArea51 · Mon Dec 26, 2016 4:45 pm

I would like to go ahead and put RouterOS v7 on my Christmas list for 2017

jrpaz · Fri Jan 13, 2017 2:34 pm

I would like to go ahead and put RouterOS v7 on my Christmas list for 2018.

hknet · Sat Jan 14, 2017 12:11 am

as we won't get ROSv7 anytime soon, anyone with knowledge how to crosscompile for the CCR platform and build a system to run quagga or similar?

Chupaka · Sat Jan 14, 2017 2:24 am

as we won't get ROSv7 anytime soon, anyone with knowledge how to crosscompile for the CCR platform and build a system to run quagga or similar?

maybe, something like http://www.mellanox.com/repository/solutions/tile-scm/ ?

uid99 · Wed Jan 18, 2017 1:24 am

I would just like to add my voice to several others here. I really like Mikrotik, and thankfully I'm not running into all of the problems recounted here, as my implementation is more localized and isn't leveraging BGP. However, it was frustrating after buying the device to discover just how dated the OpenVPN implementation was, and its completely lack of support not only for UDP but certificate based TLS authentication.

Maybe there's something in the core implementation that blocks this, but my *guess* is that it's (at best) a slightly customized version of OpenVPN. The kernel interfaces haven't changed AFAICT, so why in the world a more current support for secure SSL VPNs can't be provided is beyond me. It's great to see improved IPSEC in the latest releases, but it only underscores for me the frustration in not having this implemented, and not having any kind of idea of when it might be.

patrick7 · Wed Jan 18, 2017 1:33 am

Or maybe it's a complete rewrite of OpenVPN? (licence issues?)

Wed Jan 18, 2017 9:10 am

I have heard from a few sources that the OpenVPN code base is a nightmare to work on.

janisk · Wed Jan 18, 2017 10:00 am

Or maybe it's a complete rewrite of OpenVPN? (licence issues?)

OVPN tunnel has no common code with open source implementation of the said tunnel type.

PtDragon · Thu Jan 19, 2017 10:02 pm

Dear support and developers, could you please spend 10-15 min a month to post progress summaries for V7?
I'm not asking for huge detailed report, just very quick summary so we can see some progress going.

cheeze · Thu Jan 19, 2017 11:39 pm

Dear support and developers, could you please spend 10-15 min a month to post progress summaries for V7?
I'm not asking for huge detailed report, just very quick summary so we can see some progress going.

This is a great freaking idea actually.

Kinda give like an outline of, "hey this is what we're working on now."

I think it would help a lot of us understand kind of the view of how Mikrotik is approaching what they are doing.

honzam · Thu Jan 19, 2017 11:56 pm

Dear support and developers, could you please spend 10-15 min a month to post progress summaries for V7?
I'm not asking for huge detailed report, just very quick summary so we can see some progress going.

+ 1

JimmyNyholm · Wed Jan 25, 2017 3:14 pm

+1 Summarized status updates at given intervall is considered good Customer Relations.

Vitis · Thu Jan 26, 2017 12:18 pm

Hello Normis,
I would like to know, when we can expect, that the ROS version 7 will be out.
There are so many things that you promise to solve in v7 and we are waiting too long.

Those are your words from 2015

Not yet, but v7beta is coming later this year

http://forum.mikrotik.com/viewtopic.php?t=70274#p490716

dlynes · Thu Feb 02, 2017 5:56 am

Easy solution - do not make any expectations

We have already posted from time to time, that the biggest change is under the hood (minor kernel upgrade). There is no new GUI or anything. We are also working on a new routing engine.

Actually we are making really cool stuff even in v6. Look at the recent RC versions - interface lists, domain lists for firewall, repeater mode etc.

Minor kernel upgrade? I heard RouterOS 7 is based on FreeBSD, whereas all previous versions were based on Linux?

shahbazian · Thu Feb 02, 2017 2:05 pm

Dear support and developers, could you please spend 10-15 min a month to post progress summaries for V7?
I'm not asking for huge detailed report, just very quick summary so we can see some progress going.

+1

mhugo · Mon Feb 06, 2017 5:13 pm

New routing engine is a big expectation together with multicore bgp. That would be great

/Mikael

sailor082 · Mon Feb 06, 2017 8:50 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.

Exactly 2 ( two) years ago your info was that V7 is in alpha stage. Any progress? At least for a beta release....
We are all looking forward .Maybe some new info will be apriciated by all from your side.
Regards

patrick7 · Mon Feb 06, 2017 9:50 pm

I don't think there will be news soon. A few weeks ago MikroTik wrote something about VRF/Linux Network Namespaces. They mentioned that network namespaces "may" be used. VRF is something very fundamental. Many things are depending on that (Firewall, MPLS, BGP, ...). It looks like not even MikroTik knows what will be implemented in v7.

I personally started switching to SuperMicro 5018D-FN8T (2x 10Gig, 6x Gig) with Debian and bird. The routing "just works", no performance issues, bgp multicore, Large BGP Communities support, BGP Additional Path support, conntrackd, working OpenVPN, much more ....

Tue Feb 07, 2017 9:08 am

A few weeks ago MikroTik wrote something about VRF/Linux Network Namespaces. They mentioned that network namespaces "may" be used. VRF is something very fundamental.

Where did they write this ?

patrick7 · Tue Feb 07, 2017 11:15 am

Here: http://forum.mikrotik.com/viewtopic.php ... 5&p=572578

sailor082 · Wed Feb 08, 2017 8:33 am

I see.
I had some hopes when I knew that MIkrotik have a good support , taking action on costumers request's but unfurtunately I was wrong. As long anyone knew the long list of request and expectation from V7 and not even a small good will we can't see .....I don't know.If will keep the good work as was by now is very probably to have in 2 years first beta, if we are lucky, and some of us will notice ( hope not) that the hardware we own will not be in minimum requirment list !!!
Give us a hope Mikrotik as we trust on you when we pass to use your hardware.

Regards

guilhermeramires · Fri Feb 17, 2017 4:05 pm

as we won't get ROSv7 anytime soon, anyone with knowledge how to crosscompile for the CCR platform and build a system to run quagga or similar?

But does it support multi thread? Last time I read quaggas docs it says that quagga is planned to support but so does not have the right libs for that...

hknet · Wed Feb 22, 2017 3:38 am

as we won't get ROSv7 anytime soon, anyone with knowledge how to crosscompile for the CCR platform and build a system to run quagga or similar?
But does it support multi thread? Last time I read quaggas docs it says that quagga is planned to support but so does not have the right libs for that...

True, but at the moment on BGP and IPv6 I'd settle for anything that works without having to set static ipv6 routes to other BGP speakers loopback IPv6 addresses...

jenechka · Mon Feb 27, 2017 5:11 am

just in case let me remind you, it is waiting for full support multicast and IPTV in 7 versions

rxmd · Thu Mar 02, 2017 10:28 am

Dear support and developers, could you please spend 10-15 min a month to post progress summaries for V7?
I'm not asking for huge detailed report, just very quick summary so we can see some progress going.

+1 - that would be very nice, just to have the feeling that you are keeping the users up to date. And to know whether we are more like at the 40% or the 90% progress mark.

In the meantime, we can go back to reading the classics and assuming that some of the following has happened:
The Big Rewrite
Rewrites Considered Harmful
Second-System Effect (also on Wikipedia)

Let's hope you guys have it under control.