Hi
I have a been a fan of routeros/mikrotik, but I am becoming rather disillusioned, V7 has been coming for ages, 3+ years now. I am running into small issues that are getting fixed until V7.
I’m becoming rather frustrated.
A
I understand your frustration. It is just harder than expected.
Slight correction. The issues could only be fixed in v7. Not that they are being fixed, or are already fixed. The limitation to some problems is the kernel or drivers. They will be different in v7, then we can start to look at some problems that we can’t fix in v6.
I agree with this frustration. Why continue to add features to v6? Rather focus on Bug fixes and focus all efforts on getting v7 released, We see almost weekly issue that the famous line is used. IT will be fixed in v7
Well v7 is a myth, we haven’t seen any alpha versions or any proof it even exists.
Is it not a mind thing???
What does it matter wat version number it had.
If it is V6xxx or V7xxx?
If it is working it is fine.
So why is everybody asking for V7. If it can be fixed in V6 of V8 it will be great of is it wrong?
I agree with 49er
RouterOS V5 and V6 (with new features and support) works well, no matter how much time takes V7 to be release.
Is more important a V7 rechecked very well than V7 in beta release for many time with to many bugs.
v6 with a lot of BGP routes is NOT working well. Dropping BGP peers if you show advertisements etc.
It’s not a mind thing, there’s more to it than just the number itself
From what we can gather V7 is a fairly major overhaul that fixes underlying core issues that apparently can’t be fixed in V6
So it’s very much a case of is it viable to keep patching when inevitably there are walls that will stop you in your tracks, or focus effort into changing over so those walls aren’t a problem
I can imagine there’s a number of reasons for being so vague about V7 release. At the same time I don’t think its good practice to keep stringing people along. I know MT have never officially stated any sort of release date, but they do keep mentioning V7 as the future fix for some issues, and that is the problem. They should never have mentioned it in the first place. Now that they have, they should put much more emphasis on moving over to it, or provide us some insight into the delays or hold up other than ‘its not that easy’. People are much more sympathetic when they understand the reasons behind something
It means that some of the things coming in v7 take longer than expected, and we don’t want you guys to wait so long for some of the other nice stuff.
Until v7 is within reasonable release date, we backport improvements that can be easily backported.
… and we loose the rest…
wireless-rep package introduced new drivers for wifi, if I remember correctly? So, new Qualcomm 802.11ac (wave 2) ASICs don´t need V7. They can be supported with RouterOS V6, right?
For what it’s worth, I think most of us are probably ok with V7 taking longer if some resources can be added to just either fix bugs in the routing stack, or even add some very VERY small features. For example, I still don’t understand why something small like IPv6 BGP next hop resolution has NOT been added in the V6 routing stack. I think all of us would like to know if that is something that absolutely for sure cannot be changed within V6. I don’t think anyone here would argue over not spending much resources in V6 routing stack, I wouldn’t either, but something like IPv6 BGP next hop recursive resolution is one of those things that is mind boggling on why it hasn’t been added. The software underneath shouldn’t altogether be all that different from IPv4 next hop recursive route lookup.
I think it’s one of those things where a few baseline functionality features are missing, and honestly should have been there in the first place.
Here’s the hope that V7 can come out this year. I’m still holding out for June for late alpha/early beta…
All I care about are the long promised fixes for the routing bugs.
The back porting of features from v7 to v6 is restricted to non-routing features/fixes, it is a nice token from Mikrotik, but does not deal with the key problems we face, e.g. routing bugs in v6.
v7 can not come soon enough for us!
Doesn’t matter to me. I pulled out all my mikrotik stuff except in some “cheap” areas of my networks. Too little development was happening on features that really matter. Too much development on bullshit creature features.
It’s like they don’t care to fix all the big problems that would take a lot of work. So they sweep them under the rug and spend time on garden gnomes and lawn flamingos. I honestly don’t think they are capable of fixing any of the broken core features.
I’m thinking the same. I bought the orig ccr1036 when it came out, to be disappointing with the performance. the issue single threaded forwarding .. limit single tcp streams to 1G… on a 10G routers thats annoying. Fix … V7.
VRF with BFD and multiple IP addresses on an interface … issue / bug … will not (or maybe can’t ) fix in V6. V7 …
Now ICMP’s generated, on the box in relation to net unreachable etc , have wrong source address, ie the packet it not associated with the original VRF. fix not in V6 only V7
So no its not working in V6 and I was okay waiting for V7,
1st year okay maybe next year
2nd year well okay I have worked around the issue
3rd year … sigh I have other things to do
4th year … rework network, look at including mikrotik boxes and bang hit with more V6 V7 bug, things that don’t work.
I was under the impression that if a flow exceeds the ability of one CPU core to process, that it will actually split off and multiple CPU cores will process the flow.
Does that not happen?
I have followed this up a few time with tech support. and it has been a while, but 1 TCP stream is cpu bound, just like single core BGP …( that also is coming in V7 … multi core bgp).
I can put over 1G bu pushing multiple streams …
Hmm, so ok. If for example you start to push over that, what happens?
Do you just see packet loss?
I didn’t check, i was running iperf.
server A → server B direct 9.8Gb/s
server A → ccr (LACP + vlans, in one vlan out another vlan) → server B, approxy 0.98Gb/s
If i ran multiple streams I could push up to 9.6-9.8Gb/s
Well, it might be a good idea to check.
Don’t run TCP, use UDP. Force it to use somewhat smallish packets as to artificially make the flow harder per a resource perspective.
Then slowly start ramping up until you can see either packet loss, or force the CCR to load balance the flow on multiple cores.
Hi spent a bit of time with support and they acknowledge this was a limitation and that it would be fixed in V7 (i think now 4 years ago roughly).
I don’t have the inclination nor the time to do more testing ( I did some recently when i was testing some arista switches - last 4 months).