v7.19beta [testing] is released!

fischerdouglas · Thu Mar 27, 2025 8:47 pm

Did anyone configure VPNv6 successfully to work?
We are still waiting for VPNv6 support over IPv4 infrastructure.

+1 to vpnv6 over IPv4.

Larsa · Thu Mar 27, 2025 9:20 pm

Are you referring to MPLS L3 VPN RFC 4364, a generic IPv6 VPN RFC 4213, or tunneling methods like those in RFC 2473 or 2784/2890?

If you’re talking about MPLS, there are plenty of other mainstream capabilities I’d prefer to see implemented as well like EVPN, SR, TE and OAM.

firsak · Thu Mar 27, 2025 11:36 pm

Try:
/console/clear-history

That freed extra 80kb, thanks.

If is just netinstalled... already the history do not exist...

Turns out, it does.

buset1974 · Thu Mar 27, 2025 11:40 pm

We are still waiting for VPNv6 support over IPv4 infrastructure.
+1 to vpnv6 over IPv4.

+1 6vpe, 6pe hope they listen

fischerdouglas · Thu Mar 27, 2025 11:43 pm

Are you referring to MPLS L3 VPN RFC 4364, a generic IPv6 VPN RFC 4213, or tunneling methods like those in RFC 2473 or 2784/2890?

If you’re talking about MPLS, there are plenty of other mainstream capabilities I’d prefer to see implemented as well like EVPN, SR, TE and OAM.

Yep! I agree!
But they need to do at least the major adoption standard need to be well done first.

Let's imagine a small to medium network made with Ciscos and Huaweis.
Lets say 100-150 P/PEs.

Let's imagine it is a network that was born in the 2000's...
Where vpnv6 over v4 backbone got predominant.
And let's say there is no v6 on backbone until these days.

If I try to put a Mikrotik RouterOS as a cheap Seamless-MPLS PE of this network, what will happen?

And this hypothetical scenario in my day-by-day is very frequent.
Not by my choice... But because MikroTik is Cheap.

So, imagine that kind of network and you needing to convince that those 3 or 4 P.Router that has only 300-400 lines of config and switches more than 1-2 Tbps needs to receive v6.

In a green field? v4 over v6 for sure! MPLS, SR, or even VXLan. The flavor you want.
But how many cases of greenfield have you seen last year?

So, based on that I mentioned, my request is for an MP-BGP with NLRI of v6 with labels over v4.
With that delivered? My hope would be EVPN.
EVPN as a "happy eyeballs" of undelay-overlay protocols, choosing between "MPLSoverIPv4" vs "VXLan over v4 o v6", or even SRv6.

fischerdouglas · Thu Mar 27, 2025 11:57 pm

There is a conversation going around in the white box world that goes something like this:
"If we focus only on Segment Routing v6, we can remove all those drivers, all those interrupts, that are never used in an SRv6 only network. And even the FPGA instructions of the switchchips can be slimmed down...
This will give us a monstrous performance gain."

Is this true?
Well, I am not a programmer or a hardware developer, but from the basic knowledge I have, I can say that it is very logical that this is true.

But from a product point of view:
"Who would buy a switch-router that only knows how to speak Segment-Routing v6?"
"What would be the market for such a product."

With this line of reasoning in mind...

I am able to venture that perhaps MikroTik will have to think about different Software and Firmware (Routerboard) for the same hardware for different applications.

Something like:
"If you want to run pure SegmentRouting v6 with EVPN, this will allow you to use hardware offload."
"Or, if you want to stay with MPLS L2 and L3 VPN over v4, and not look at v6 as undelay, this will also allow you to use hardware offload."
"Now if you want both together? You'll have to get away from switchip..."

If you think about it, we're almost there today, right?
VXLan doesn't support hardware offload for IPv6 VTEPs, right?

P.S.: If the fight to split the main software package is already big, imagine thinking about multiple flavors of firmware? It's going to be CHAOS.

jszakmeister · Fri Mar 28, 2025 1:31 am

I'm not sure what the difference might be. I reported an issue with iOS devices in particular struggling with the beta, and beta6 improved the situation immensely--to the point that they no longer seem spurious. IOW, my hAP ax2 has been handling the situation better since upgrading to beta6.
I also perceive somewhat of improvement, but wifi "stalls" still happen a few times per day, especially when there is more traffic, for example when i push some heavy transfer from one laptop to another across wifi there is more chances of happening

Interesting! Good to know! I'll try and keep an eye out for that too. I hadn't noticed those issues, but we also haven't done any big file transfers recently.

FezzFest · Fri Mar 28, 2025 1:58 am

I updated my hAP ax2 from 7.16.2 to 7.19beta6 and while things seem to work well, I noticed CPU load is averaging 50% while idle. According to /tool profile, this seems to be caused by the routing process. There is a BGP peer on this router but it's only taking in ~2000 routes and there aren't any updates to process, so I'm not sure why the load is so high.

Update: if I enable "bgp, debug" logging I see hundreds of "Output publish 10.1.1.0/30" lines per second (10.1.1.0/30 is a subnet of a connected ROSv6 device on which the BGP peer with this router isn't even enabled). Downgrade to 7.18.2 fixed the problem.

Larsa · Fri Mar 28, 2025 12:12 pm

.. I am able to venture that perhaps MikroTik will have to think about different Software and Firmware (Routerboard) for the same hardware for different applications. ... If the fight to split the main software package is already big, imagine thinking about multiple flavors of firmware? It's going to be CHAOS.

Totally agree — at some point, splitting ROS or at least offering full-featured, mainstream add-on packages might be the only way forward. Trying to make one build do everything is starting to feel like a bottleneck.

Valerio5000 · Fri Mar 28, 2025 1:53 pm

I have been saying for years that the only valid solution following the current MK market strategy (ROSE, Home Market) is to create a "RouterOS HomeEdition" for the "hAP" series of Routerboards with only the "basic" functions + wifi + storage (DLNA, SMB) full of simple wizards for example the creation of a wifi mesh (capsman home edition?). This would allow to streamline the devices with 16MB of flash on which it will always be possible to install the classic professional version of ROS. As for ROSE, for me a dedicated environment should be created from scratch using open source projects and various collaborations dedicated exclusively to the storage environment.

Fri Mar 28, 2025 2:06 pm

Why Unix and it's descendands has been admired for 50+ years? KISS rule.
It's strange for me that kind of swiss-army-tool router software drifts towards something as

pe1chl · Fri Mar 28, 2025 2:50 pm

ROSE is already a separate package, so nothing to worry about.
What we need is removal of other functions from the base package so it again fits in a 16MB flash device. That is totally unrelated to ROSE.

millenium7 · Fri Mar 28, 2025 2:54 pm

I have been saying for years that the only valid solution following the current MK market strategy (ROSE, Home Market) is to create a "RouterOS HomeEdition" for the "hAP" series of Routerboards with only the "basic" functions + wifi + storage (DLNA, SMB) full of simple wizards for example the creation of a wifi mesh (capsman home edition?). This would allow to streamline the devices with 16MB of flash on which it will always be possible to install the classic professional version of ROS. As for ROSE, for me a dedicated environment should be created from scratch using open source projects and various collaborations dedicated exclusively to the storage environment.

It's a dangerous slippery slope though
For all the misgivings of RouterOS with broken, missing and half assed implementations of things, at least you get the ENTIRE suite of tools with any and all of their devices. And that fact alone largely makes up for its problems and shortcomings. If it starts splitting out into discrete operating systems with gimped functionality unless you buy the 'premium' devices, it can very quickly spiral into some licensed greedy BS model that favors profits and corporate squeezing over consumer power

You can still currently do a hell of a lot with a simple cheap 16MB mikrotik device. I sure as hell do not want to see functionality stripped out and relegated only to a 'premium' line of hardware

Larsa · Fri Mar 28, 2025 4:47 pm

I don’t mind paying a bit extra for enterprise-level functionality. This could serve as an additional revenue stream that helps fund continued development and support, especially with a focus on advanced functionality for businesses and service providers.

Fri Mar 28, 2025 5:06 pm

ROSE is already a separate package, so nothing to worry about.
What we need is removal of other functions from the base package so it again fits in a 16MB flash device. That is totally unrelated to ROSE.

I'm aware of that, but why to put more and more bells&whistles on the tree if they do not fit on branches?

Valerio5000 · Fri Mar 28, 2025 5:12 pm

But don't get me wrong, I wrote that the devices of the "hAP" series dedicated to the home environment and small offices come out of the factory with a hypothetical "RouterOS Home" perhaps with an eye to the aesthetic aspect of the interface but if you want you can install the "normal" RouterOS whenever you want. It's great that a small €30 device like the mAP lite has all the functions of a €3,000 router but if to allow this you start to lose stability during every blessed update on the 16MB devices you need to find a solution. We must start from the assumption that it now seems clear to me that the 16MB devices are having SERIOUS problems although Mikrotik denies this. My HAP AC2 two weeks ago completely blocked from 7.17. 2 to 17.18. 2 with 0 KB of internal memory forcing me to waste an afternoon with Netinstall and reconfiguration. For this reason I will avoid buying any other MK device that does not have at least 128 MB of flash. Mikrotik, in some discussion here on the forum replied that they are not the only ones that produce devices with 16 MB of flash but there is a small detail: the other manufacturers have a specific firmware for each product, they do not have a single operating system for all devices and this is the only substantial difference. Let me be clear, I also like that the cheapest Mikrotik device and the most expensive one have the exact same functions but if it has to go to the detriment of now chronic problems of full memory, either you eliminate such 16 MB devices from the support or you have to divide ROS. The problem is that MK released, I don't remember which model of RB, a short time ago still with 16 MB flash so the first is not a viable path..

itimo01 · Fri Mar 28, 2025 5:43 pm

The problem is that MK released, I don't remember which model of RB, a short time ago still with 16 MB flash so the first is not a viable path..

https://mikrotik.com/product/wap_lr8g_kit
https://mikrotik.com/product/ltap_lr8g_lte6_kit

And for a tat older models:
https://mikrotik.com/product/wap_lte_kit_2024
https://mikrotik.com/product/ltap_mini_lte_kit_2024
https://mikrotik.com/product/wap_ac_lte_kit24
https://mikrotik.com/product/lhgg_lte6

infabo · Fri Mar 28, 2025 6:00 pm

I think Mikrotik already realized that 16MB is a little tight. There are refreshes of existing device like Chateau LTE12 (2025) now with 32MB flash. There are other devices in the pipeline, see viewtopic.php?t=213245#p1131190, now with 32MB flash as well. Good to see Chateau 5G R15 has now 32MB. Where the 5G R16 only had 16MB (like the original Chateau 5G). I like the funny fact, people will think R16 is better/newer than R15. But it is the other way round.

Fri Mar 28, 2025 6:27 pm

I think Mikrotik already realized that 16MB is a little tight. There are refreshes of existing device like Chateau LTE12 (2025) now with 32MB flash. There are other devices in the pipeline, see viewtopic.php?t=213245#p1131190, now with 32MB flash as well. Good to see Chateau 5G R15 has now 32MB. Where the 5G R16 only had 16MB (like the original Chateau 5G). I like the funny fact, people will think R16 is better/newer than R15. But it is the other way round.

yeah, some weeks ago i received a CRS-309 with 32mb of storage

infabo · Fri Mar 28, 2025 6:34 pm

Interesting, this is not indicated on the product page (yet?).

mkx · Fri Mar 28, 2025 6:54 pm

Interesting, this is not indicated on the product page (yet?).

They might want to wait for old stock at distributors to drain before announcing larger flash ... to avoid complaints from people receiving devices with smaller flash. Nobody (except you ;-) ) complains about getting more than expected and paid for (I never complained due to getting 256MB RAM version of hAP ac2).

Larsa · Fri Mar 28, 2025 7:07 pm

@infabo: Not the new LMP 5G that was announced with just 16 MB of storage(!)

mkx · Fri Mar 28, 2025 7:15 pm

I don't think that 16MB of storage on LMP 5G is that critical. Since it hasn't got wifi, ROS installation is imediatelly around 2.5MB slimmer. And with "only" 256MB RAM iz's also not prime candidate for running containers ... I hope.

The above is also true for CRS309 though. So that 32MB-flash CRS309 might be a glitch in production as well.

infabo · Fri Mar 28, 2025 7:18 pm

@mkx Indeed, I would really complain if I got more than what the datasheet specifies. 😅

regarding LMP 5G, yes has 16MB, but it is an 5G device only. It does the job. But 32MB would not hurt. It is another device that prolongs the 16MB era.

Larsa · Fri Mar 28, 2025 7:29 pm

I just don’t get why they still go with only 16MB. Not exactly future-proof, if you ask me. If you look at the cost for 32MB, the difference is basically pocket lint. The only explanation I can come up with is that they’re sitting on some massive warehouse full of 16MB chips they’re desperately trying to offload...

Amm0 · Fri Mar 28, 2025 8:05 pm

Perhaps they should send someone to YouTube to tell some story on the 16MB situation.

Mikrotik really has acted indifferent to what is a real-world problem for me and others. I used to keep everything up-to-date way more regularly since historically "always worked"... but now updating RouterOS requires very careful planning for failure on remote 16MB LTE devices since now "upgrade is risky". i.e. I formally would said odds of upgrade failure are 1/1000, and now I'm maybe 1/10 or 1/20 – on anything with 16MB.

The only explanation I can come up with is that they’re sitting on some massive warehouse full of 16MB chips they’re desperately trying to offload...

That been my thought too. But if true... do some package split & put 2 x 16MB in device - market it as "redundant flash", given folks already worry about flash failures. i.e. make lemonaid from lemons.

oreggin · Fri Mar 28, 2025 8:14 pm

These devices mostly WiFi APs, and switches. Lets see, what functions is not inside in other vendors's APs. MPLS and Routing menu, because these are totally not Wireless AP functions. I don't know, how much space these two group consume and how much space that we would win, if MTik would baking separated routeros-wireless.npk, where wireless package compressed into the same squashfs main package without MPLS and routing functions, and baking routeros-diet.npk later (for switches) when 16MB will not enough even without wireless package. This would placing a little complexity into the system. They know what they could/would do.

Paternot · Fri Mar 28, 2025 8:18 pm

...Nobody (except you ;-) ) complains about getting more than expected and paid for (I never complained due to getting 256MB RAM version of hAP ac2).

You never know... Here people sued (yes, SUED) my ISP. Because it was selling 500Mbps and delivering 1Gbps. I kid You not - they had to put traffic shaping, by court order! Why? WHY?...

itimo01 · Fri Mar 28, 2025 8:24 pm

without MPLS and routing functions, and baking routeros-diet.npk later (for switches)

Did you just tell people to not use routing functions on an L3-Switch? What?

SwOS: "Am i a joke to you?"

Paternot · Fri Mar 28, 2025 8:25 pm

I don't think that 16MB of storage on LMP 5G is that critical. Since it hasn't got wifi, ROS installation is imediatelly around 2.5MB slimmer. And with "only" 256MB RAM iz's also not prime candidate for running containers ... I hope.

I believe that anything small enough that precludes me to use partitions, is too little. Really. Yes, do backups. Yes, do both an export and a binary dump. Yes, save both on your desktop, update winbox and netinstall - don't forget to download the right image too.

BUT

With two partitions I know that I'm a single boot away from a sane config. If this new version suffers from some regression, I can just boot the "backup" partition, and everything is fine. Really, partitioning is something miraculous. And this is why I say that Mikrotik should put enough storage in any device to AT LEAST have two partitions. This should be the bare minimum.

marlab · Sat Mar 29, 2025 10:04 am

ovpn is still broken on RB4011, it cannot connect to AWS when using TLS-auth... (TLS error, timeout) :/
Not sure when it got broken, it was still working fine with 7.17.2

pe1chl · Sat Mar 29, 2025 11:29 am

I believe that anything small enough that precludes me to use partitions, is too little. Really.

I agree with that.
And also I think that the way upgrades are downloaded and installed should be made the same on all hardware, or at least allowed to be configured the same.
When you have a 16MB device you get the "upgrades are downloaded into RAMdisk and then installed to the flash" for which you require no space in the flash except for the expansion of the new version compared to the old.
But when you have a 128MB device partitioned into 2x64MB, and more than 32MB in use due to optional packages (still e.g. 20MB free), you cannot upgrade due to lack of space. Because it wants to download the upgrade into that 20MB.
As RouterOS now allows a RAMdisk to be configured by the user, it could instead use a RAMdisk that is already configured, or dynamically configure a temporary RAMdisk, for the download and upgrade.

Paternot · Sat Mar 29, 2025 1:29 pm

As RouterOS now allows a RAMdisk to be configured by the user, it could instead use a RAMdisk that is already configured, or dynamically configure a temporary RAMdisk, for the download and upgrade.

Yes, that's just logical. Why they aren't doing this is beyond me.

fragtion · Sun Mar 30, 2025 1:57 pm

I updated my hAP ax2 from 7.16.2 to 7.19beta6 and while things seem to work well, I noticed CPU load is averaging 50% while idle. According to /tool profile, this seems to be caused by the routing process. There is a BGP peer on this router but it's only taking in ~2000 routes and there aren't any updates to process, so I'm not sure why the load is so high.

Update: if I enable "bgp, debug" logging I see hundreds of "Output publish 10.1.1.0/30" lines per second (10.1.1.0/30 is a subnet of a connected ROSv6 device on which the BGP peer with this router isn't even enabled). Downgrade to 7.18.2 fixed the problem.

I've just noticed that I have the same issue on recent betas (in my case, an RB5009UG+S+), which has been ongoing for a few weeks. I also have BGP session (about 100 routes).

mtik.png

Rebooting doesn't solve it. Copied config over to secondary partition running 7.18.2 and switched to that, and now everything is fine again (< 10% CPU usage).

millenium7 · Sun Mar 30, 2025 3:43 pm

It seems to me that 7.15.3 is the last 'stable' firmware without blatant issues

I don't know of the most effective way to handle it but I don't like the current naming scheme. MikroTik pushes a release to the 'stable' channel far too early, when it is often anything but stable..... I know 7.19 is still in 'testing' but 7.18 also has blatant issues so it definitely does not belong in that channel
I'd like to see a recategorization of the RouterOS releases. So far the latest 'stable' release (as far as V7 can be, I still consider it in beta-testing status) is 7.15.3
Everything since should be considered in an assessment/testing phase, and the latest 7.19 as 'experimental'
Only once thoroughly vetted (and possibly voted on by the community) should a release migrate from testing to 'stable'
MikroTik pushes to stable far too early, when its often anything but.... It takes several weeks/months to properly vet a release and establish it as truly stable

infabo · Sun Mar 30, 2025 4:28 pm

7.15 does not receive any fixes since 7.16 stable was released. So it is pointless to say, it takes several months. It is over. 7.15 is EOL.

pe1chl · Sun Mar 30, 2025 7:24 pm

7.15.x was the last version where BGP worked OK

spippan · Mon Mar 31, 2025 2:45 am

7.15.x was the last version where BGP worked OK

true.

whatever · Mon Mar 31, 2025 9:15 am

MikroTik pushes a release to the 'stable' channel far too early, when it is often anything but stable.....

That's not new, is it? I guess the real issue is that ROS 7 does not have a long-term release channel.

noradtux · Mon Mar 31, 2025 10:53 am

7.15.x was the last version where BGP worked OK

Is there a thread where I could read up on what is wrong with BGP? I just upgraded our 2216s to 7.18.2 and they seem to be running fine with full table Internet peering.

bratislav · Mon Mar 31, 2025 11:02 am

As RouterOS now allows a RAMdisk to be configured by the user, it could instead use a RAMdisk that is already configured, or dynamically configure a temporary RAMdisk, for the download and upgrade.
Yes, that's just logical. Why they aren't doing this is beyond me.

They do kind of, on 16MB (and some other) devices upgrade packages are downloaded to RAM not disk...

pe1chl · Mon Mar 31, 2025 11:34 am

They do kind of, on 16MB (and some other) devices upgrade packages are downloaded to RAM not disk...

Please read the posting again. What works for 16MB devices should work for all, but it does not.

pe1chl · Mon Mar 31, 2025 11:36 am

7.15.x was the last version where BGP worked OK
Is there a thread where I could read up on what is wrong with BGP? I just upgraded our 2216s to 7.18.2 and they seem to be running fine with full table Internet peering.

Wait until they are up for a day or two...
The problem has been discussed in release topics.

Paternot · Mon Mar 31, 2025 12:32 pm

Wait until they are up for a day or two...
The problem has been discussed in release topics.

But could You do a quick heads up here? Just a little list of small bullet points, Mikrotik style? :D

merkkg · Mon Mar 31, 2025 12:45 pm

Wait until they are up for a day or two...
The problem has been discussed in release topics.
But could You do a quick heads up here? Just a little list of small bullet points, Mikrotik style? :D

If someone (preferably from Mikrotik) could take up this would be good which i know has been requested before

In each feature/functionality to have bullet points of known issues and same for feature requests.

Cha0s · Mon Mar 31, 2025 2:31 pm

I updated my hAP ax2 from 7.16.2 to 7.19beta6 and while things seem to work well, I noticed CPU load is averaging 50% while idle. According to /tool profile, this seems to be caused by the routing process. There is a BGP peer on this router but it's only taking in ~2000 routes and there aren't any updates to process, so I'm not sure why the load is so high.

Update: if I enable "bgp, debug" logging I see hundreds of "Output publish 10.1.1.0/30" lines per second (10.1.1.0/30 is a subnet of a connected ROSv6 device on which the BGP peer with this router isn't even enabled). Downgrade to 7.18.2 fixed the problem.

I've just noticed that I have the same issue on recent betas (in my case, an RB5009UG+S+), which has been ongoing for a few weeks. I also have BGP session (about 100 routes).

mtik.png

Rebooting doesn't solve it. Copied config over to secondary partition running 7.18.2 and switched to that, and now everything is fine again (< 10% CPU usage).

The issue should be fixed in the next release.
Support sent me a link to use v7.20_ab165 build, and so far there are no issues with BGP. I've been running it on a non-critical router for about 12 days with no issues. I'll let it run a few days more to see if by any chance another issue that I've been having with BGP since 7.16, has been also fixed.

oreggin · Mon Mar 31, 2025 2:40 pm

Did anyone configure VPNv6 successfully to work?
We are still waiting for VPNv6 support over IPv4 infrastructure.

We don't insist to the IPv4-only backbone, we like IPv6, or we would like to :-)
Sure, it would be appreciated to move from MPLS to SR, maybe it would be better for the vendor and for the end-users, or SRv6 if too hard to implement IPv6 route over IPv4 nexthop.
World moving tovards IPv6 and SR.

pe1chl · Mon Mar 31, 2025 2:55 pm

Wait until they are up for a day or two...
The problem has been discussed in release topics.
But could You do a quick heads up here? Just a little list of small bullet points, Mikrotik style? :D

I have already done that in almost every release topic after 7.16 so no need to repeat it.
My support ticket was created July 2024 and has not received a reply after August 2024 despite several updates from me.
I fear there again is no available BGP developer at the moment.

bratislav · Mon Mar 31, 2025 2:57 pm

They do kind of, on 16MB (and some other) devices upgrade packages are downloaded to RAM not disk...
Please read the posting again. What works for 16MB devices should work for all, but it does not.

I did, and you said "it could instead use a RAMdisk that is already configured, or dynamically configure a temporary RAMdisk, for the download and upgrade." which is exactly what MT does...

pe1chl · Mon Mar 31, 2025 3:19 pm

I did, and you said "it could instead use a RAMdisk that is already configured, or dynamically configure a temporary RAMdisk, for the download and upgrade." which is exactly what MT does...

No, that is not correct.
In the 16MB models, a RAMdisk is ALWAYS configured, not only for the updates. The root directory of "Files" is the RAMdisk and the flash is mounted as a "flash" subdirectory.
As the upgrades are downloaded in a hidden directory in the root, they end up in the RAMdisk. This trick was required to be able to upgrade a 16MB device at all.
But my posting was about OTHER flash size devices. There a RAMdisk is not created automatically, but you can still do that as a user.
However, the root directory will still be the flash, and the RAMdisk will be a user-specified subdirectory.
Because you cannot specify a hidden directory for that, it is impossible to download updates to the user-created RAMdisk.
Alternatively, MikroTik could dynamically add a RAMdisk at the moment you download an upgrade (and not store that in the config) so the upgrade could still be done via RAMdisk.
But it would be a change, at this moment it is not possible.

infabo · Mon Mar 31, 2025 3:23 pm

But could You do a quick heads up here? Just a little list of small bullet points, Mikrotik style? :D
I have already done that in almost every release topic after 7.16 so no need to repeat it.
My support ticket was created July 2024 and has not received a reply after August 2024 despite several updates from me.
I fear there again is no available BGP developer at the moment.

But they could respond like: "Hello Mr. Pe1chl, at the moment, we do not have any available resources to address these issues. We will get back to you as soon as we start working on them. Thank you."

pe1chl · Mon Mar 31, 2025 3:28 pm

But they could respond like: "Hello Mr. Pe1chl, at the moment, we do not have any available resources to address these issues. We will get back to you as soon as we start working on them. Thank you."

That is likely against company policy...
I remember during the early days of v7 the BGP function was very lacking, essential features not working, BFD not available at all, and many many versions were released with all kinds of fixes but this remained the same.
I fear we have entered another such era.

loloski · Mon Mar 31, 2025 3:52 pm

We are lucky we moved our edge to other platform and we don't have to deal with this BGP situation anymore our use case now with MT is more limited (BRAS) but still crucial with our daily operation and our bandwidth management moved to OLT and libreQoS at least MT doesn't rob my sleep anymore, I hope MT should seriously change their hiring process so that they are not only limited to devs who can speak with their language that seriously hinders them to get great talent. I hope they give/care some loved with this BGP issues I know some people here buy MT as fully matured routing gear not just a DLNA player or storage server for that matter. MT please listen there are some vendor is around the corner which the last time I checked will going to enter your market if you are not careful they are known for their wireless and good UI.

oreggin · Mon Mar 31, 2025 4:04 pm

I have already done that in almost every release topic after 7.16 so no need to repeat it.
My support ticket was created July 2024 and has not received a reply after August 2024 despite several updates from me.
I fear there again is no available BGP developer at the moment.
But they could respond like: "Hello Mr. Pe1chl, at the moment, we do not have any available resources to address these issues. We will get back to you as soon as we start working on them. Thank you."

The IT Crowd ;)

buset1974 · Mon Mar 31, 2025 4:12 pm

But could You do a quick heads up here? Just a little list of small bullet points, Mikrotik style? :D
I have already done that in almost every release topic after 7.16 so no need to repeat it.
My support ticket was created July 2024 and has not received a reply after August 2024 despite several updates from me.
I fear there again is no available BGP developer at the moment.

They can outsource programmer if they want. And they have responsible to their customer that already bought they hardware

loloski · Mon Mar 31, 2025 5:25 pm

They can't easily outsource it even though they want it too, I strongly believed they document their code base using their language so it's hard to get / poach some people from the industry that can do smart coding having good oral and written communication in their language at the same time. I think MT can give good salary no question about that but the hard requirement from the JOB comes from their language

buset1974 · Tue Apr 01, 2025 9:27 am

We are still waiting for VPNv6 support over IPv4 infrastructure.
We don't insist to the IPv4-only backbone, we like IPv6, or we would like to :-)
Sure, it would be appreciated to move from MPLS to SR, maybe it would be better for the vendor and for the end-users, or SRv6 if too hard to implement IPv6 route over IPv4 nexthop.
World moving tovards IPv6 and SR.

Agreed, IPv6 route/forward/distribution using VPNv6 over IPv4 or SR are more efficient way for now and in the future when IPv6 implementation start rising massively, it will reduce memory/cpu requirement.

So adapting those feature in mikrotik is not exactly a special request , if i am not mistaken vyos already support SR, both are using linux kernel as a base.

pe1chl · Tue Apr 01, 2025 9:42 am

in the future when IPv6 implementation start rising massively

Are you calling us from 2010? Or is it an April fools joke?

Tue Apr 01, 2025 1:14 pm

What's new in 7.19beta7 (2025-Mar-31 10:55):

*) bgp - fixed excessive CPU usage;
*) bridge - properly flush bridge hosts when bonding is used as bridge port and loses hw-offloading status;
*) ike2 - improved initial key exchange process on slow or unreliable connections;
*) ippool6 - properly free IPv6 pool used prefix when it is not used any more;
*) isis - properly validate 3-way hello handshake;
*) ipv6 - fixed EUI-64 false error message on address update when "from-pool" option is used;
*) lte - fixed initialization for R11e-LTE6 modem;
*) lte - fixed initialization for Neoway N75 modem;
*) lte - reset internal link-recovery-timer on sim slot change;
*) netinstall - improved network socket re-opening when NIC status changes while running the server (additional fixes);
*) rose-storage - added Btrfs disk balance command (CLI only);
*) rose-storage - fixed mounting Btrfs subvolumes using macOS SMB client;
*) route-filter - fixed the "blackhole" option setting process;
*) system - improved system stability when sending TCP data from the router;
*) webfig - fixed graphs appearance under "Tools/Graphing" menu (introduced in 7.19beta2);
*) wifi - improved wifi connection stability when used as a station for "b" mode access point;
*) wifi - use at least TLS 1.2 for securing connection between CAPsMAN manager and CAPs (additional fixes);

Larsa · Tue Apr 01, 2025 1:51 pm

Anything about the VRRP bug yet?

fischerdouglas · Tue Apr 01, 2025 2:06 pm

What's new in 7.19beta7 (2025-Mar-31 10:55):

I updated 1xARM, 1xARM64, 1xMIPSBE.
Just 5 minutes running until now.

But during the process everything was OK.

LionB12 · Tue Apr 01, 2025 2:23 pm

Beta7 still does not fix fast track for me on my CCR2116 where my WAN is over a XGSPON SFP+ module.

fischerdouglas · Tue Apr 01, 2025 2:27 pm

Are you calling us from 2010? Or is it an April fools joke?

OK... I need to agree that:

in the future when IPv6 implementation start rising massively

I was pushed too hard! Sounded like negating round earth.

-----

IPv6 is already here!
On a common scenario ISP, around 50% of the traffic is IPv6.
It makes thing easier and cheaper.

If I Colud, I wolud certanly use IPv6 only with Segment Routing.
Sounds complicated, but after you look to the headers of a packet in wireshark hop after hop, it sound so logical that you think...
Hey, Its an stupidity not doing like this...

Buuuut... (there is always a but)
But Deploy IPv6 on greenfield backbone is an oportunity that almost do no exists.

And form every 10 networks of Telco that I deal with:

2 has no needs on Underlaying and Overlaying
5 Uses MPLS just with LDPv4 and IGP.
2 Uses MPLS with Kompella, also with LDPv4 as basis.
1 Has some use of Segment Routing, but with MPLS, and just for inner core(really big networks)
NONE uses dual-stack of LDPv4 and LDPv6.

The only case I dealed with dual stack of LDP, tried it for less then 2 months...
Removed it because of several devices in the network did not worked well with LDPv6.

Deploying VPNv6 Over IPv4 LDPv4, on an environment of per-vrf label allocation seams to be really simple in the point RouterOS is now.
Seams that if they just rework a bit how the NLRI of MP-BGP is created for this scenario and they are good to go.

So, PLEASE!
ADD VPNv6 over IPv4-Only / LDPv4-Only Backbones.

Larsa · Tue Apr 01, 2025 2:46 pm

It might actually happen sooner than you'd expect. Word is Mikrotik has recently brought on about 15 people, supposedly working full-time on developing business-oriented features.

mozerd · Tue Apr 01, 2025 3:03 pm

IWord is Mikrotik has recently brought on about 15 people ...

Excellent ... very nice to read !

mkx · Tue Apr 01, 2025 4:10 pm

Beta7 still does not fix fast track for me on my CCR2116.

It apparently works for many other users (or else there would be a massive outrage going on). It works for me on 7.18 (and .1 and .2).

So it must be something in your particular config.

And I'm sure you're aware that fasttrack is only enabled by adding a particular IPv6 firewall filter, without it it's disabled (just like it's done in IPv4). And ROS upgrades never changes configuration (it might convert existing configuration to newer syntax, but doesn't add new items).

LionB12 · Tue Apr 01, 2025 4:14 pm

Beta7 still does not fix fast track for me on my CCR2116.

It apparently works for many other users (or else there would be a massive outrage going on). It works for me on 7.18 (and .1 and .2).

So it must be something in your particular config.

And I'm sure you're aware that fasttrack is only enabled by adding a particular IPv6 firewall filter, without it it's disabled (just like it's done in IPv4). And ROS upgrades never changes configuration (it might convert existing configuration to newer syntax, but doesn't add new items).

It works fine on 7.18.2 but the moment I try the beta my speeds drop from 1Gbps to 0.15Mbps. This is for IPv4 currently, disabling the HW offload on the fast track filter on the beta does fix the speed issues. The moment the HW offload is enabled, I get 0.15Mbps

chrismfz · Tue Apr 01, 2025 9:31 pm

7.15.x was the last version where BGP worked OK

please don't scare me, I got 8 BGP connections and a AS on a CCR running 7.15 since July I think and just considering to update and saw this :P

buset1974 · Tue Apr 01, 2025 9:34 pm

Set blackhole yes on routing filter broken on 7.19.beta6
Last known work 7.18.2

Reported SUP-183157 with supout from both version.

Thx

*) route-filter - fixed the "blackhole" option setting process;

Yes, it work now, you may close the ticket

uCZBpmK6pwoZg7LR · Tue Apr 01, 2025 9:38 pm

We are still waiting for VPNv6 support over IPv4 infrastructure.
+1 to vpnv6 over IPv4.

They not able to make stable VPn4 but you want ipv6 already.

Larsa · Tue Apr 01, 2025 9:50 pm

please don't scare me, I got 8 BGP connections and a AS on a CCR running 7.15 since July I think and just considering to update and saw this :P

We’re still on 7.15 and won’t upgrade until there’s a long-term version with at least three patch releases.

buset1974 · Tue Apr 01, 2025 9:58 pm

naming inconsistent
cli =>/routing/filter/communities-list
winbox => /routing filters -> communites Set

Amm0 · Wed Apr 02, 2025 3:59 am

It might actually happen sooner than you'd expect. Word is Mikrotik has recently brought on about 15 people, supposedly working full-time on developing business-oriented features.

That make sense, given they've long implemented the now ratified RFC-9759

buset1974 · Wed Apr 02, 2025 6:36 am

It might actually happen sooner than you'd expect. Word is Mikrotik has recently brought on about 15 people, supposedly working full-time on developing business-oriented features.

True word or gossip?

mkx · Wed Apr 02, 2025 8:21 am

That make sense, given they've long implemented the now ratified RFC-9759

In my own timezone, your post was too late for April fools' day (posted on 2nd of April at 3am DST) ... but I appreciate it anyway.

Larsa · Wed Apr 02, 2025 8:25 am

True word or gossip?

As Amm0 mentioned, check out the latest RFC as they’re working on now: RFC 9759 – Unified Time Scaling (synchronizing timers for MPLS). 😉

buset1974 · Wed Apr 02, 2025 9:56 am

anyone have problem with bgp filtering for local as?
regexp ^$ or bgp-path-len < 1 did not works

thx

pe1chl · Wed Apr 02, 2025 11:33 am

anyone have problem with bgp filtering for local as?
regexp ^$ or bgp-path-len < 1 did not works

what do you want to achieve?

buset1974 · Wed Apr 02, 2025 12:12 pm

anyone have problem with bgp filtering for local as?
regexp ^$ or bgp-path-len < 1 did not works
what do you want to achieve?

Advertise any prefix originately from the router itself.

In v6 regexp ^$ works
But in v7 did not works

Thx

pe1chl · Wed Apr 02, 2025 12:20 pm

So you are filtering outgoing routes here?
The local AS is not yet part of the AS-path at the time the filters are applied!
As is stated in the documentation, the check for locally originated routes is "if ( bgp-network )"
I use that and it works OK.

bajodel · Wed Apr 02, 2025 3:13 pm

As is stated in the documentation, the check for locally originated routes is "if ( bgp-network )"

can you share the documentation link, google was not enough for me to find it
thanks

oreggin · Wed Apr 02, 2025 3:50 pm

Deploying VPNv6 Over IPv4 LDPv4, on an environment of per-vrf label allocation seams to be really simple in the point RouterOS is now.
Seams that if they just rework a bit how the NLRI of MP-BGP is created for this scenario and they are good to go.

As I know, RouterOS 7 is based on Linux kernel, maybe a 5.6.3 version, with a lot of MTik specific patch. If I see the kernel source of version 5.6.3, IPv6 route over IPv4-mapped nexthop is supported:

linux-5.6.3/net/ipv6/route.c @ line 3319
        if (gwa_type != (IPV6_ADDR_LINKLOCAL | IPV6_ADDR_UNICAST)) {
                /* IPv6 strictly inhibits using not link-local
                 * addresses as nexthop address.
                 * Otherwise, router will not able to send redirects.
                 * It is very good, but in some (rare!) circumstances
                 * (SIT, PtP, NBMA NOARP links) it is handy to allow
                 * some exceptions. --ANK
                 * We allow IPv4-mapped nexthops to support RFC4798-type
                 * addressing
                 */
                if (!(gwa_type & (IPV6_ADDR_UNICAST | IPV6_ADDR_MAPPED))) {
                        NL_SET_ERR_MSG(extack, "Invalid gateway address");
                        goto out;
                }

However, I don't know if this is enough to simply implement VPNv6 over LDPv4.

LDP is bleeding from multiple wounds in RouterOS, so if SR is easier to implement even if SRv6, we would be happy as most of high-end vendors simply skipping LDPv6 from their codes, they prefer SR over LDP. You said right, SR seems as complex as simple it is.

buset1974 · Wed Apr 02, 2025 6:43 pm

Deploying VPNv6 Over IPv4 LDPv4, on an environment of per-vrf label allocation seams to be really simple in the point RouterOS is now.
Seams that if they just rework a bit how the NLRI of MP-BGP is created for this scenario and they are good to go.
As I know, RouterOS 7 is based on Linux kernel, maybe a 5.6.3 version, with a lot of MTik specific patch. If I see the kernel source of version 5.6.3, IPv6 route over IPv4-mapped nexthop is supported:
Code: Select all
linux-5.6.3/net/ipv6/route.c @ line 3319
        if (gwa_type != (IPV6_ADDR_LINKLOCAL | IPV6_ADDR_UNICAST)) {
                /* IPv6 strictly inhibits using not link-local
                 * addresses as nexthop address.
                 * Otherwise, router will not able to send redirects.
                 * It is very good, but in some (rare!) circumstances
                 * (SIT, PtP, NBMA NOARP links) it is handy to allow
                 * some exceptions. --ANK
                 * We allow IPv4-mapped nexthops to support RFC4798-type
                 * addressing
                 */
                if (!(gwa_type & (IPV6_ADDR_UNICAST | IPV6_ADDR_MAPPED))) {
                        NL_SET_ERR_MSG(extack, "Invalid gateway address");
                        goto out;
                }
However, I don't know if this is enough to simply implement VPNv6 over LDPv4.

LDP is bleeding from multiple wounds in RouterOS, so if SR is easier to implement even if SRv6, we would be happy as most of high-end vendors simply skipping LDPv6 from their codes, they prefer SR over LDP. You said right, SR seems as complex as simple it is.

Hope the new MT guys will solved this

pe1chl · Wed Apr 02, 2025 8:04 pm

As is stated in the documentation, the check for locally originated routes is "if ( bgp-network )"
can you share the documentation link, google was not enough for me to find it

https://help.mikrotik.com/docs/

pe1chl · Thu Apr 03, 2025 7:58 pm

CHR version still has the issue that disk space is greatly reduced after an upgrade, usually but not always back to normal after an extra reboot.

Fri Apr 04, 2025 6:55 pm

What's new in 7.19beta8 (2025-Apr-04 13:24):

*) certificate - fixed cloud-dns challenge validation for sn.mynetname.net (CLI only);
*) device-mode - added new "rose" mode where "container" feature is enabled by default;
*) fetch - fixed false successful messages in FTP mode;
*) ipsec - lower standalone cipher, hash priority when using ctr aead;
*) log - fixed remote logging after reboot when hostname is forwarded to a DNS server;
*) lte - fixed LTE status update or possible crash when modem is unexpectedly removed from system;
*) netinstall-cli - check for other running Netinstall servers on startup;
*) ptp - allow multiple instances;
*) sfp - improved QSFP link stability for CRS354 devices;
*) system - fixed "/system reboot" when the system disk is completely full;

rpingar · Fri Apr 04, 2025 6:56 pm

we tested 7.19beta7 and it is working fine about bgp on x86 and arm64!
thanks Mikrotik.

roggles · Fri Apr 04, 2025 7:14 pm

Hello,

RouterOS v7.19beta8
The comments are missing in the Winbox "Multi Passphrase Group" Window.

Thanks for your hard work!

infabo · Fri Apr 04, 2025 9:12 pm

*) system - fixed "/system reboot" when the system disk is completely full;

Nice to see this! Thank you!

vadvm · Sat Apr 05, 2025 12:36 am

arp=reply-only with hotspot arp records is invalid
viewtopic.php?t=187802

firsak · Sat Apr 05, 2025 11:21 am

After upgrading old RB2011 to 7.19 beta7, can't upload anything any longer (e.g. can't upgrade to beta8). File list empty. Scripts that create backups fail.
What's up with that?

mkx · Sat Apr 05, 2025 12:03 pm

What's up with that?

Routerboard firmware (mostly) up-to-date? Does another reboot change anything?

firsak · Sat Apr 05, 2025 12:42 pm

Routerboard firmware (mostly) up-to-date? Does another reboot change anything?

no idea how to check firmware. it was shown only in old 6.x routeros. also, no firmware for RB2011UiAS-RM on mikrotik website.
reboot didn't help

mkx · Sat Apr 05, 2025 1:09 pm

Routerboard firmware (mostly) up-to-date? Does another reboot change anything?
no idea how to check firmware.

/system/routerboard/print

If it shows upgrade-firmware and it's notably newer than current-firmware, then upgrade it.

Since quite many versions ago, routerboard firmware is shipped together with main routeros package and it's not necessary to download it separately.

pe1chl · Sat Apr 05, 2025 7:32 pm

After upgrading old RB2011 to 7.19 beta7, can't upload anything any longer (e.g. can't upgrade to beta8). File list empty. Scripts that create backups fail.
What's up with that?

Flash memory full?

wiktorbgu · Sat Apr 05, 2025 7:47 pm

I have ax3 and 2 partitions and dns adlist are configured. And I'm tired of deleting adlist to install the update.
Also, if you interrupt the download of the update, then it is impossible to restart it without rebooting the entire device due to lack of memory.
Disabling and setting a pause for adlist does not free up memory.

rm78 · Sat Apr 05, 2025 10:41 pm

After upgrading old RB2011 to 7.19 beta7, can't upload anything any longer (e.g. can't upgrade to beta8). File list empty. Scripts that create backups fail.
What's up with that?
Flash memory full?

The RB2011 has 128MB of flash so unless you have installed a lot of other packages or an extremely large adlist there should be many issues I would guess?

rm78 · Sat Apr 05, 2025 10:46 pm

I have ax3 and 2 partitions and dns adlist are configured. And I'm tired of deleting adlist to install the update.
Also, if you interrupt the download of the update, then it is impossible to restart it without rebooting the entire device due to lack of memory.
Disabling and setting a pause for adlist does not free up memory.

How large are your partitions?
have you checked the free storage space using the /system resource print command in the terminal?

CGGXANNX · Sun Apr 06, 2025 12:23 am

After upgrading old RB2011 to 7.19 beta7, can't upload anything any longer (e.g. can't upgrade to beta8). File list empty. Scripts that create backups fail.
What's up with that?

Check System -> Users: Is there any other user groups than full/read/write. Does the group full still have all checkboxes? Is your login still member of the full group? Is there any unrecognized usernames?

wiktorbgu · Sun Apr 06, 2025 12:46 am

How large are your partitions?
have you checked the free storage space using the /system resource print command in the terminal?

I would prefer to store the downloaded adlist data in ram memory.
It also seems to me that I have a lot of writing going on in the internal memory, judging by the write-sect-total and write-sect-since-reboot fields.

firsak · Sun Apr 06, 2025 7:50 am

mkx

/system/routerboard/print

Just returns routeros as firmware.

routerboard: yes         
model: RB2011UiAS  
serial-number: 77AD0866172B
firmware-type: ar9344      
factory-firmware: 3.41        
current-firmware: 7.19beta7   
upgrade-firmware: 7.19beta7

-
pe1chl

Flash memory full?

My screenshot above shows plenty of memory.

-
CGGXANNX

Check System -> Users: Is there any other user groups than full/read/write. Does the group full still have all checkboxes? Is your login still member of the full group? Is there any unrecognized usernames?

Absolutely nothing out of ordinary there. Default admin user and default full/read/write groups, that I never changed. All checkboxes are there.

Trying to export RSC config or save any other files returns "invalid file name" error.

spippan · Mon Apr 07, 2025 2:31 pm

we tested 7.19beta7 and it is working fine about bgp on x86 and arm64!
thanks Mikrotik.

can confirm too. same for me.

BGP (+BFD) now good again and no odd up to 100% CPU load any longer

wiktorbgu · Tue Apr 08, 2025 2:03 pm

setup url-registry for containers does not work via ui

LionB12 · Tue Apr 08, 2025 10:41 pm

The latest 7.19beta8 on the CCR2116-12G-4S+, the moment L3 HW offloading is turned on, on the switch chip, my WAN to LAN connection drops to 0.10Mbps This has been the case since the beta6.

sirbryan · Wed Apr 09, 2025 4:54 am

If you're doing NAT, you need to disable the Internet-facing port. Presumably you've done that already for other versions.

Kentzo · Wed Apr 09, 2025 7:03 am

I have noticed a bug in 7.18.2 where `/interface/veth/get value-name=address` returns incorrect value:

> /interface/veth
> add address=2001:db8:1:1:1:1:1:1/64 gateway="" gateway6=2001:db8::1 name=example
> :put [get example value-name=address]
2001:db8:1:1::/64

Note how the result zeroed bits outside of the prefix. Could someone check if the issue was fixed in the current 7.19 beta?

rpingar · Wed Apr 09, 2025 8:02 am

we find an issue about retreving bgp configuration through api.
the afi is never found through api, if it is specified.
this is what api give in 7.18.2: - NapAfr-korcom2-ipv6: ipv6
this is what api give after the upgrade to 7.19beta (any): - NapAfr-korcom2-ipv6: <non specificato>

please fix it asap, it broke our outmated script.

loloski · Wed Apr 09, 2025 8:05 am

same no dice

[admin@MikroTik] > /interface/veth/add address=2001:db8:1:1:1:1:1:1/64 gateway="" gateway6=2001:db8::1 name=example
[admin@MikroTik] /interface/veth> :put [get example value-name=address]
2001:db8:1:1::/64
[admin@MikroTik] /interface/veth> /system/resource/print
                   uptime: 2m2s
                  version: 7.19beta8 (testing)
               build-time: 2025-04-04 10:24:19
         factory-software: 7.1
              free-memory: 57.5MiB
             total-memory: 256.0MiB
                      cpu: QEMU
                cpu-count: 1
            cpu-frequency: 3192MHz
                 cpu-load: 1%
           free-hdd-space: 70.4MiB
          total-hdd-space: 89.2MiB
  write-sect-since-reboot: 1600
         write-sect-total: 1600
        architecture-name: x86_64
               board-name: CHR QEMU Standard PC (i440FX + PIIX, 1996)
                 platform: MikroTik
[admin@MikroTik] /interface/veth>

loloski · Wed Apr 09, 2025 8:46 am

@MT quick question I hope if you don't mind asking, what's your rationale why you don't have public bug tracking system where everyone can chime in or at least can lookup what ticket are open / close or about to get fix or invalid, so that everyone has a valuable insight if they are affected by the bug or it's just a misconfiguration or user error maybe?, not to mentioned can greatly reduce tickets on your end?

Honestly most people here don't want to hijack this release page unnecessarily I hope you guys can think this through. What are you afraid of opening a bug tracker to the public? even read-only is enough we don't necessarily need to can comment if you don't want it to it's not an opensource project anyway

infabo · Wed Apr 09, 2025 8:50 am

I guess they attach supout.rif and other sensitive information in their bug tracker.

loloski · Wed Apr 09, 2025 8:52 am

supout.rif attach to the ticket can be hidden if that's the only concern, if they can program the linux kernel they can easily do that for sure don't they? I think this will greatly help them along the way

Wed Apr 09, 2025 9:33 am

It's company policy and I can't comment on that, but what I can tell you personally, is that we get hundreds of "bug reports" every day, and 99.99% of them are bad configuration or misunderstanding about something. If all these would be turned into bug reports directly, it would be utter chaos. It would be very nice if more people made some proper testing, steps to repeat, etc. as a normal bug tracker requires. This is not a DIY hacker software or github, there are millions of home users and basic level techs that are using these devices.

As I have said multiple times, this forum is a deep dark corner of geeks, amongst millions and millions of other people that have never seen this forum in their life, but are using mikrotik products.

loloski · Wed Apr 09, 2025 12:30 pm

Fair enough but you can still control the things if you want it too like just list all the confirmed bugs that you triage and all of us outsider can just take a look.

ros_version            ticket_id             title             description                  status_code             created_on        will_be_fixed_on_version?

this are the fields that is needed status_code should be as follows

bugs_and_will_be_fixed
not_going_to_get_fix_ever_no_futher_discussion
bugs_but_because_lack_of_code_in_the_codebase_no_further_discussion

I don't think this is so much to ask because you have this for sure already internally, I hope this is not farfetch for you guys please remember we are contributing for your products to improved by submitting a bug report and not to mentioned we are customer not your Q&A department so please give us back something,

I believed there are a few dozen of people here can make proper bug reports to your standards and liking. What we just need is where do we stand in the bug report it's known already that we can't force you to come up with the exact date to fixed the bug ("That's fair") we just need at least to know if the bug will be FIXED or NOT or even better WHEN at least on which release_in_future_version not specific DATE.

if that version will happen 20 to 30 releases in the future at least you let us know and I personally grateful to that and it's up to us as your customer on how we are going to react in our own pace on that particular bug in our own network. Just three options we stay and wait because there's hope for the bug to get fixed or we reduce mikrotik footprint in our tech stack or we leave for good.

Thank you!

infabo · Wed Apr 09, 2025 3:19 pm

It's company policy and I can't comment on that, but what I can tell you personally, is that we get hundreds of "bug reports" every day, and 99.99% of them are bad configuration or misunderstanding about something. If all these would be turned into bug reports directly, it would be utter chaos. It would be very nice if more people made some proper testing, steps to repeat, etc. as a normal bug tracker requires. This is not a DIY hacker software or github, there are millions of home users and basic level techs that are using these devices.

As I have said multiple times, this forum is a deep dark corner of geeks, amongst millions and millions of other people that have never seen this forum in their life, but are using mikrotik products.

It was not said to make the ticket system public. This would not make any sense at all - as you said - many tickets may not even be bugs.

But I usually receive this automated message when an "accepted issue" was resolved:

This is an automated message. Our bug tracker reports that your issue has been fixed. This means that we plan to release a RouterOS update with this fix. Make sure to upgrade to the next release when it comes out. To be sure this specific fix is included, read the changelog when the next version comes out. If your issue is not mentioned, it might mean it will be in the next release.

So there is a bug tracker - a different system than the ticket system. I totally understand the "company policy" thing - the fear of "leaking" details to exploit issues. I would not suggest to make the bug tracker public either. But a curated list of issues with a description and to which version it applies would be great - other vendors do that (without risking to disclose critical data).

felixka · Wed Apr 09, 2025 4:15 pm

The company I work at also manufactures networking equipment, albeit for a different customer segment (almost exclusively B2B with barely any consumer or consumer premises equipment products). When you file a bug with us you receive a number that you can share publicly and that other customers can use to look up the basic information on the bug:
- summary written by the support engineer
- when the bug was filed
- when it was last modified
- bug status (fixed, open, etc.)
- affected products
- affected releases
- known fixed releases
- related support cases (possible that this is visible only to me, although I don't work in support)
- list of threads on this bug in our community forums (with a button to start a thread if there is none)
- comments from other customers they choose to post publicly on that bug

MikroTik wouldn't have to go to that level of detail or effort. But I think the most common complaints around this are:
- Is this already a known problem or do I need to file a support ticket myself?
- What is the status of this bug report if I did not file it myself?
That's information that would make everyone's life a bit easier.
Another complaint I think can be paraphrased as "How can I know that my bug report I posted in the beta thread has been acknowledged and is being worked on?" and the answer to that is usually to file a ticket which then goes full circle to the two complaints mentioned above.

I think the topic of the quality and clarity of MikroTik's changelogs has also been discussed to death already. At my company we have an entire process for how something makes it from a bug report into the change log of a release, so there is full transparency for the customer to see how that issue was reported, worked on and how it reflects as a fix in the release. Many of our customers actually require this level of transparency to fulfil certification requirements on their end.

loloski · Wed Apr 09, 2025 5:03 pm

@MT to give you context on why we need some sort of transparency here is this, we are about to consider to buy some CRS354 because we are considering mikrotik for a pet project rather than considering juniper / arista for our project that requires MLAG I can't make a decision upfront because this 354 has some serious issues that some of it's port stop working at random and it has been fixed at least on 7.16.x but we are not quite so sure if that was really the case, if some how we have a bug tracker system that we can digest for ourselves that will give us solid confidence that we are good to go right?

MLAG is also is a little bit sketchy because there's a lot of report also in the forum that it also has some serious issues, again we are not sure because we don't have data to validate this claim, I was task to commissioned this but I can't just trust what I read in the forum right? because if something goes haywire on the purchase they are going to deduct this to my salary and not to mentioned it will be on my record that I just recommend something that it's not working because I just have a hunch that it will work because i trusted what I read in the forum?

Sorry for the off-topic :( just real talk

infabo · Wed Apr 09, 2025 5:39 pm

When you file a bug with us you receive a number that you can share publicly and that other customers can use to look up the basic information on the bug

Mikrotik support would even benefit from this. Now bugs get reported over and over again. Because nobody knows if it is already known to Mikrotik.

buset1974 · Wed Apr 09, 2025 5:45 pm

It's company policy and I can't comment on that, but what I can tell you personally, is that we get hundreds of "bug reports" every day, and 99.99% of them are bad configuration or misunderstanding about something. If all these would be turned into bug reports directly, it would be utter chaos. It would be very nice if more people made some proper testing, steps to repeat, etc. as a normal bug tracker requires. This is not a DIY hacker software or github, there are millions of home users and basic level techs that are using these devices.

As I have said multiple times, this forum is a deep dark corner of geeks, amongst millions and millions of other people that have never seen this forum in their life, but are using mikrotik products.

So do u think that your product already perfect?
So you can stop build more update then, because 99 % mikrotik users are just stupids
And all geeks that has been reported all problem and maybe having problem with their business are just missconfig and leave it with their own stupidity.

Thx

pe1chl · Wed Apr 09, 2025 6:42 pm

@felixka I have been arguing many times that this should be done at least for the release notes. Right now we get basic and cryptic statements about what has changed in a release, but we never see a complete description and an underlying bug report.
It is often difficult to guess what is really meant with "system - improved system stability when sending TCP data from the router" (an example picked from the release notes above) and it would be so much better when there would be a link to a more detailed description of what was changed or added....

Wed Apr 09, 2025 6:52 pm

Mikrotik support would even benefit from this. Now bugs get reported over and over again. Because nobody knows if it is already known to Mikrotik.

Even if bugs are resolved, no one knows what they were as solutions are hidden in one-liners: "improved stability", "corrected behaviour", "better handling".

Kentzo · Wed Apr 09, 2025 7:13 pm

One approach is for someone on this forum to set up an independent bug tracker for interested users to duplicate their reports. Although it’s an additional burden on the reporter to file twice (and then update once the issue confirmed / resolved). Ultimately it may nudge Mikrotik to open up their system.

Developers for Apple ecosystem have a thing called Open Radar (https://openradar.appspot.com/page/1 w) which has similar origin story.

Amm0 · Wed Apr 09, 2025 7:53 pm

Developers for Apple ecosystem have a thing called Open Radar (https://openradar.appspot.com/page/1 w) which has similar origin story.

Or in JIRA allow the reporter to have some "mark public", so if you link to a issue (especially "feature request" type) in forum, it's be read-able (perhaps requiring some help.mikrotik.com login).

But some list of "known issues" – in whatever form — has long been missing.

fischerdouglas · Wed Apr 09, 2025 8:15 pm

It would be very nice if more people made some proper testing, steps to repeat, etc. as a normal bug tracker requires.

By making better documentation, the MikroTik team would achieve this wish.

And to be clear, the MikroTik team has improved A LOT regarding documentation in recent times!
I don't know who, but someone deserves to be congratulated for this. Please give it to this person.

What I miss the most are the use cases!
Something that there was much better back in the wiki days.

fischerdouglas · Wed Apr 09, 2025 8:23 pm

@felixka I have been arguing many times that this should be done at least for the release notes. Right now we get basic and cryptic statements about what has changed in a release, but we never see a complete description and an underlying bug report.
It is often difficult to guess what is really meant with "system - improved system stability when sending TCP data from the router" (an example picked from the release notes above) and it would be so much better when there would be a link to a more detailed description of what was changed or added....

I completely agree with your statement.

The impression is that they are trying to be vague to allow for evasive maneuvers when responding if the problem reoccurs.

I imagine that many of you have already read Release Notes from other manufacturers such as Cisco, Juniper, Huawei. Or manufacturers from other software segments such as Jira and Confluence, even MikroTik uses them.

It is normal and expected that there will be statements such as:
Fixed bug #12345 "Failure in the screw clamp when users are eating pasta".

The closest MikroTik comes to this is with CVEs, and even with these it is extremely evasive.

LionB12 · Wed Apr 09, 2025 9:38 pm

If you're doing NAT, you need to disable the Internet-facing port. Presumably you've done that already for other versions.

Do you mean disable the HW offload on the internet facing port on the switch ? I have L3 HW offloading on on all ports and the switch1 cpu with v17.8.2, and speeds are fantastic, on the beta, even with L3 Hw Offloading disabled on SFP1 which has my XGSPON module for my WAN and a vlan on it in order to get internet access from my ISP, speeds drop to 0.10Mbps. Only if I do Switch -> Settings -> L3 Hw Offloading disable, do the speeds restore the full ISP speeds. So I need to fully disable it on the Beta, where are the stable release seems to have no issue (or doesn't work properly? ).

pe1chl · Wed Apr 09, 2025 10:18 pm

And to be clear, the MikroTik team has improved A LOT regarding documentation in recent times!
I don't know who, but someone deserves to be congratulated for this. Please give it to this person.

What I miss the most are the use cases!
Something that there was much better back in the wiki days.

Well, there is always something left to be desired....
For example, I have a ticket open for (just) over 2 years now, which requests documentation for "/queue simple".
In that chapter, there is only a single use case example, but no description at all what it actually does and what the parameters mean.
(usually there is a list of all parameters with a short description, but not for this one)

I can only guess how it works based on how Linux "tc" works and what is explained for some other queues (e.g. "/queue tree")...

infabo · Thu Apr 10, 2025 9:34 pm

As I have said multiple times, this forum is a deep dark corner of geeks, amongst millions and millions of other people that have never seen this forum in their life, but are using mikrotik products.

It is irritating that you see it this way. A bunch of geeks. I visit the "active topics" section daily and what I see is: regular people seeking for help and solutions to their issues with Mikrotik products. That is I guess the primary purpose of this forum - people helping each other.

Apachez · Fri Apr 11, 2025 4:12 am

Using 7.19beta8 on a CRS326 with an older Firefox browser to get to webfig the horisontal menus/tabs at the top seems to be missing & nbsp; or similar so they all becomes like one or two centimeters in width even if the text is much larger (if there would be a proper non breaking space being used the tabs would fit the textcontent).

The result becomes that the textcontent will be almost vertical and by that it will become hard to read the menus/tabs at top of webfig.