MikroTik

Posted: **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.

Posted: **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.

Posted: **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.

Posted: **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

Posted: **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.

Posted: **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.

Posted: **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.

Posted: **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.

Posted: **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.

Posted: **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.

Posted: **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

Posted: **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.

Posted: **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

Posted: **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.

Posted: **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?

Posted: **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..

Posted: **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

Posted: **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.

Posted: **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

Posted: **Fri Mar 28, 2025 6:34 pm**

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

Posted: **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).

Posted: **Fri Mar 28, 2025 7:07 pm**

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

Posted: **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.

Posted: **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.

Posted: **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...

Posted: **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.

Posted: **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.

Posted: **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?...

Posted: **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?"

Posted: **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.

Posted: **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

Posted: **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.

Posted: **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.

Posted: **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).

Posted: **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

Posted: **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.

Posted: **Sun Mar 30, 2025 7:24 pm**

7.15.x was the last version where BGP worked OK

Posted: **Mon Mar 31, 2025 2:45 am**

7.15.x was the last version where BGP worked OK

true.

Posted: **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.

Posted: **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.

Posted: **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...

Posted: **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.

Posted: **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.

Posted: **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

Posted: **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.

Posted: **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.

Posted: **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.

Posted: **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.

Posted: **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...

Posted: **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.

Posted: **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."

Posted: **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.

Posted: **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.

Posted: **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 ;)

Posted: **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

Posted: **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

Posted: **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.

Posted: **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?

Posted: **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);

Posted: **Tue Apr 01, 2025 1:51 pm**

Anything about the VRRP bug yet?

Posted: **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.

Posted: **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.

Posted: **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.

Posted: **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.

Posted: **Tue Apr 01, 2025 3:03 pm**

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

Excellent ... very nice to read !

Posted: **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).

Posted: **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

Posted: **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

Posted: **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

Posted: **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.

Posted: **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.

Posted: **Tue Apr 01, 2025 9:58 pm**

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

Posted: **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

Posted: **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?

Posted: **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.

Posted: **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). 😉

Posted: **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

Posted: **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?

Posted: **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

Posted: **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.

Posted: **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

Posted: **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.

Posted: **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

Posted: **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/

Posted: **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.

Posted: **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;

Posted: **Fri Apr 04, 2025 6:56 pm**

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

Posted: **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!

Posted: **Fri Apr 04, 2025 9:12 pm**

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

Nice to see this! Thank you!

Posted: **Sat Apr 05, 2025 12:36 am**

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

Posted: **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?

Posted: **Sat Apr 05, 2025 12:03 pm**

What's up with that?

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

Posted: **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

Posted: **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.

Posted: **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?

Posted: **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.

Posted: **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?

Posted: **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?

Posted: **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?

Posted: **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.

Posted: **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.

Posted: **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

Posted: **Tue Apr 08, 2025 2:03 pm**

setup url-registry for containers does not work via ui

Posted: **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.

Posted: **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.

Posted: **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?

Posted: **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.

Posted: **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>

Posted: **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

Posted: **Wed Apr 09, 2025 8:50 am**

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

Posted: **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

Posted: **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.

Posted: **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!

Posted: **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).

Posted: **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.

Posted: **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

Posted: **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.

Posted: **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

Posted: **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....

Posted: **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".

Posted: **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.

Posted: **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.

Posted: **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.

Posted: **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.

Posted: **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? ).

Posted: **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")...

Posted: **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.

Posted: **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.

Posted: **Fri Apr 11, 2025 11:32 am**

[..] we get hundreds of "bug reports" every day, and 99.99% of them are bad configuration or misunderstanding about something. [...] It would be very nice if more people made some proper testing, steps to repeat, etc. as a normal bug tracker requires. [...]

It's nice that you described what some of us actually want from you, MikroTik.
A public place to keep track of new and known issues, a place where people can find/report the said issues and maybe do some tests, maybe some of us are willing to pinpoint the first release when it was introduced & help out to rule out a "bad config or misunderstanding about something" before the said issue gets pushed as an actual bug report for you guys to solve. And THEN add a final "fixed in version ..." to the said issue.
The "Please keep this forum topic strictly related to this particular RouterOS release" rule is bullshit. Why? Because by the time users trust the release enough to upgrade to it, the topic is already closed, and bug reports get carried over to the new topic or in other corners of the forum, Discord or well, as a bug report on your current bug tracker. It's a mess, nobody can keep track of them this way.
I hope you find a solution to this, it would be easier for you guys I think too.
Obviously that solution will not allow attaching support files, and will not allow security related (vulnerabilities) to be reported there, those should be sent directly to you and not available for public view.
But a public place to keep track of known functional / non-functional / cosmetic / performance / compatibility bugs or however you want to classify them would be nice.

Posted: **Fri Apr 11, 2025 1:16 pm**

Can anyone provide an example of another commercial networking vendor with a public bug tracker ?

Posted: **Fri Apr 11, 2025 1:22 pm**

https://bst.cisco.com/bugsearch
Not a full bugtracker, but you can get some precious insights
.

Posted: **Fri Apr 11, 2025 1:35 pm**

@fischerdouglas

It would be very nice if more people made some proper testing, steps to repeat, etc. as a normal bug tracker requires.
...
What I miss the most are the use cases!...

+1 on that
more use cases/examples would go a long way in the docs

Posted: **Fri Apr 11, 2025 2:25 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.

He probably means that there are millions of users that use a MikroTik router as a plain home WiFi AP and NAT router, running with default config.
They of course do not know about the forum and they rarely file bug reports.
But they also are the reason why we are now confronted with things like "device-mode", while it does not even solve the problem for them because they never upgrade.
When you remove that category of users, a much larger fragment of what is left are the technically oriented people that make more advanced configurations and are more likely to encounter bugs or look for information...

Posted: **Fri Apr 11, 2025 5:12 pm**

Can anyone provide an example of another commercial networking vendor with a public bug tracker ?

Also not exacly a public bug tracker, but at least they have this: https://arubanetworking.hpe.com/techdoc ... 12.0.5.htm

But for MikroTik to have even something like this requires work and manpower, and require the bugs filed via the current bug tracker to pass the initial "we couldn't reproduce" ping-pong replies that take some .. time.

Posted: **Fri Apr 11, 2025 11:37 pm**

If there is a thought that Cisco and Aruba are too large to compare to MikroTik (e.g. have more resources for something like this), then I suppose Ubiquiti might be a closer comparison. And they do sometimes publish known issues:
https://community.ui.com/releases/UISP- ... 8420964a78

Granted, this is not good enough as one has to look through specific release notes. But I don't remember ever seeing anything from MT that says "known issues". As if there are none in any given release, which is simply not true.

It's almost like MT is afraid to publish a super-long list of known issues and scare customers away. Well, at least give us a page of the top 20 or so of the most important issues, at your discretion.

Posted: **Sat Apr 12, 2025 5:37 am**

Can anyone provide an example of another commercial networking vendor with a public bug tracker ?

https://vyos.dev/

Posted: **Sat Apr 12, 2025 5:39 am**

Can anyone provide an example of another commercial networking vendor with a public bug tracker ?
Also not exacly a public bug tracker, but at least they have this: https://arubanetworking.hpe.com/techdoc ... 12.0.5.htm

But for MikroTik to have even something like this requires work and manpower, and require the bugs filed via the current bug tracker to pass the initial "we couldn't reproduce" ping-pong replies that take some .. time.

Mikrotiks backend for supportcases is Jira so would that really be that much of work in reality?

Posted: **Sat Apr 12, 2025 12:56 pm**

Can anyone provide an example of another commercial networking vendor with a public bug tracker ?
https://vyos.dev/

Isn't vyos open source?
So that's far from "commercial"

Posted: **Sat Apr 12, 2025 3:01 pm**

It's almost like MT is afraid to publish a super-long list of known issues and scare customers away. Well, at least give us a page of the top 20 or so of the most important issues, at your discretion.

The list of issues should not only include the known issues but also the resolved issues. Then the list of open issues is (hopefully) relatively short compared to the total list.
And issues would not only be (critical) bugs, but also enhancement requests.
When this list is made into an externally publishable form (i.e. does not include sensitive information) it can be used as a basis for the release notes as well.
Each item has a version number in which it is resolved, and generating a release notes list is a simple query on that database.
The generated list can then contain links to the detailed records so users can lookup what is meant which each of the (often unclear) release notes lines.
So it is a win-win for everyone.

Posted: **Sat Apr 12, 2025 8:12 pm**

Isn't vyos open source?
So that's far from "commercial"

"Opensource" and "commercial" aren't mutually exclusive.

Posted: **Sat Apr 12, 2025 9:41 pm**

Can anyone provide an example of another commercial networking vendor with a public bug tracker ?

.
pfSense might be an example ...
https://redmine.pfsense.org/projects/pfsense/roadmap

Posted: **Sat Apr 12, 2025 10:23 pm**

With those several examples, opensource and copyright, it's very clear that is possible.
Whether for bug reports or for the roadmap.

Now what needs to be answered is the willingness of MikroTik of doing that.

Posted: **Sun Apr 13, 2025 12:52 am**

https://vyos.dev/
Isn't vyos open source?
So that's far from "commercial"

Its an opensource project but with commercial licenses:

https://vyos.io/subscriptions/software

Posted: **Sun Apr 13, 2025 10:26 am**

Nice chatter and surely many things could be improved. Following some o-s projects on Github though, I can also see lots of user's frustration, seeing all those hundreds of small issues not being fixed for multiple years :-)

But - I can see systems like Aruba being pointed to in regards to support, which I would like to comment on. Thouse f*ckers created incompatible generations of wireless equipment / firmware in just maybe 2 years? We were told by the integrator, that we need to scrap the old ones, or move them to the secondary locations, if we want to run new ones. We've also got their support to look into our network, being effectively useless, connecting after 2-3 days after the problems occrued.

Mikrotik aproach might not be ideal, but gee - I run hAP ac2s in few of my friend's locations. Those little beasts just refuse to die, and are still supported by the latest firware, free of charge. Nowadays, all of our corporate location firewalls are CCR based, with zero of problems. For security measures / load balancing, we use Fortigate family.

Maybe, instead of public bug database (which I am not generally against), Mikortik could create a group of voluntarily dedicated beta testers under NDA, as it could provide also some internal information, not being preliminarily shareable with the public. I myself work in a different IT area like that with some companies.

Posted: **Sun Apr 13, 2025 11:44 am**

But - I can see systems like Aruba being pointed to in regards to support, which I would like to comment on. Thouse f*ckers created incompatible generations of wireless equipment / firmware in just maybe 2 years? We were told by the integrator, that we need to scrap the old ones, or move them to the secondary locations, if we want to run new ones.

That's not unusual. Cisco do the same. The incompatibility between 3800 series and 9100 series meant we had to retire hundreds of 3800. Apparently related to roaming between the WiFi 5 series 3800 and WiFi 6 series 9100.

Posted: **Sun Apr 13, 2025 12:20 pm**

That's not unusual. Cisco do the same. The incompatibility between 3800 series and 9100 series meant we had to retire hundreds of 3800. Apparently related to roaming between the WiFi 5 series 3800 and WiFi 6 series 9100.

I know, this is not that vendor's forum, but what kind of incompatibility? AireOS WLC can drive C9100 APs and vica versa, IOS-XE WLC can also drive 3800 APs. BTW if you want to throw 3800 APs out at all costs, tell us where to look. Save the planet from unnecessary littering ;)

Posted: **Sun Apr 13, 2025 7:09 pm**

It's an incompatilibility between the Marvell chipsets used in each apparently. A change of CPU revision.

Sorry for the OT!

Posted: **Mon Apr 14, 2025 12:31 pm**

@Mikrotik time for v7.19 to to go RC, then release so we can get v7.20 out the door.

I will keep pushing for fast releases until I see the key features I need for my business

- VRF L3HW Offload
- MPLS Multi Threaded and/or MPLS L3HW Offloaded

Posted: **Mon Apr 14, 2025 1:01 pm**

No, please don't rush v7.19. Instead, prioritize stability for everyone’s sake. @merkkg, if you have a business case, request access to v7.20 for internal testing.

Posted: **Mon Apr 14, 2025 1:18 pm**

No, please don't rush v7.19. Instead, prioritize stability for everyone’s sake. @merkkg, if you have a business case, request access to v7.20 for internal testing.

That's what v7.19.1, v7.19.2 and 7.19.x is for

Posted: **Mon Apr 14, 2025 1:34 pm**

@Mikrotik time for v7.19 to to go RC, then release so we can get v7.20 out the door.

I will keep pushing for fast releases until I see the key features I need for my business

- VRF L3HW Offload
- MPLS Multi Threaded and/or MPLS L3HW Offloaded

YEEEESSS!!!
PLEEEEEAAAASEEE!

On the data-plane world

VRF L3HW Offload
- Especially to be able to put a management VRF and this does not disable fast-path and fast-track for the entire box.
MPLS Multi Threaded and/or MPLS L3HW Offloaded

On the control-plane world

L3VPN 6vPE/6PE (This one, still in version 7.19. Please!)
BGP-LU (This can be for 7.20.)

Posted: **Mon Apr 14, 2025 1:39 pm**

That's what v7.19.1, v7.19.2 and 7.19.x is for

@merkkg: Only if you have an active issue involving existing functionality in v7.19 that has been confirmed by support. Otherwise, you need to request access to v7.20 for internal testing, provided that support has confirmed your request for new functionality or for fixes to older issues not included in v7.19. If it is really urgent, contact support and ask for a custom patch.

Posted: **Mon Apr 14, 2025 1:45 pm**

If it is really urgent, contact support and ask for a custom patch.

I still have tickets open since October, November last year.... contacting support is pointless, by the time i get a response v7.23 will be out

Posted: **Mon Apr 14, 2025 1:51 pm**

Well, considering you haven’t received any feedback at all, it’s unlikely there’ll be any fix or addition in v7.19, and certainly not in v7.20 either, so what’s the point in trying to rush the closure of v7.19?

Btw, are there any threads describing your issues? Would be interesting to read what you’re talking about.

Posted: **Mon Apr 14, 2025 2:22 pm**

It probably depends on whether there is an active developer with interest and time for the specific topic...
The problems introduced in simple BGP use-cases (not all those VPN and VRF things but simply routing in a small partial-mesh network) in 7.16 have not been taken up either...

Posted: **Mon Apr 14, 2025 3:02 pm**

Yeah, with how slowly the bgp/mpls stuff is getting sorted, it seems they're short on resources in that area..

Posted: **Tue Apr 15, 2025 5:27 am**

@Mikrotik time for v7.19 to to go RC, then release so we can get v7.20 out the door.

I will keep pushing for fast releases until I see the key features I need for my business

- VRF L3HW Offload
- MPLS Multi Threaded and/or MPLS L3HW Offloaded

100% agree with you and hope these are being actively worked on.

Its great to have more people pushing Mikrotik for these features!

Posted: **Tue Apr 15, 2025 7:44 am**

Its great to have more people pushing Mikrotik for these features!

It makes absolutely bugger all difference. We've been 'pushing' for things like Segment Routing for well over a decade and gotten absolutely nowhere. MikroTik does its own thing, often spending an eternity and barely improve any of the core routing functionality

Posted: **Tue Apr 15, 2025 7:55 am**

It makes absolutely bugger all difference. We've been 'pushing' for things like Segment Routing for well over a decade and gotten absolutely nowhere. MikroTik does its own thing, often spending an eternity and barely improve any of the core routing functionality

To be fair to Mikrotik, they have redeveloped the routing engine from the ground up in that timeframe. But in theory they have a nice new clean code base to work with, they should be able to implement new features like SRv6/SR-MPLS and fix bugs much more quickly, but so far the only major feature addition we have seen has been ISIS support.

Posted: **Tue Apr 15, 2025 7:58 am**

It's ok to wait as long as you have confirmation that they are being tackled or acknowledge being develop, I hope this essential features will come to fruition in my lifetime

Posted: **Tue Apr 15, 2025 10:59 am**

I guess it is much easier to find developers that can create stuff like "detect internet". "kid control", "device mode", "media server" and "storage server" than to find those that can develop all those complicated routing protocols in a locally created codebase...

Posted: **Tue Apr 15, 2025 12:03 pm**

ehehehe, I'm looking forward for the new 15 developers just onboard with MT will make a real difference and concentrate on more pressing issues (L2,L3 and HW offload stuff) rather than what you have mentioned above :). I hope this is real news rather than gossip

Posted: **Tue Apr 15, 2025 3:09 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.

loloski, you mean this April's fool joke?

Posted: **Tue Apr 15, 2025 3:26 pm**

oh my..... my bad it was an april fools joke sucks to be me hahahahaha who knows MT make it reality it means we are back to reality of push and pull

Posted: **Tue Apr 15, 2025 5:06 pm**

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.

There is no need to turn all of them ticket numbers into bugID, but if some of them is misunderstanding, then you could improve your documentation if/where it needed, maybe asking the reporter what should be in the documentation to get it more understandable. For misconfiguration the same. Unfortunately the lack of knowledge is in the game many times. In our company there is a layered customer service with 4 layer. There are 50-100 "soldiers" in the front line, and we are on the end of the layers in a little office, like a cone. 10-15 years ago I have been on the front, respectable job!

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

RouterOS has made fun of me many times. I successfully reproduce a bug 3 times and filed a ticket and of course it didn't work that way the 4th time.But I guess the 99% of cases is not this. I feel sometimes the frustration caused by support jammers when a MT support staff response to my email and asks totally basic info which is in my original email. All my respect to you!

Posted: **Tue Apr 15, 2025 5:26 pm**

I've noted that something was changed on the wireguard logging.

#on 7.18.2 the logs for peer not responding was:
wg-vpn: [<peer-name>] <public-key>: Handshake for peer did not complete after 5 seconds, retrying (try 2)
#on 7.19betaX is now:
wg-vpn: Handshake for peer did not complete after 5 seconds, retrying (try 2)

this change wasn't documented and is a step backwards, as you cannot know which peer is not responding. A good behaviour would be to have at least the peer name, or a logic that if there is a name set, show only the name, else the public-key

Posted: **Tue Apr 15, 2025 8:31 pm**

There is no need to turn all of them ticket numbers into bugID, but if some of them is misunderstanding, then you could improve your documentation if/where it needed, maybe asking the reporter what should be in the documentation to get it more understandable. For misconfiguration the same. Unfortunately the lack of knowledge is in the game many times. In our company there is a layered customer service with 4 layer. There are 50-100 "soldiers" in the front line, and we are on the end of the layers in a little office, like a cone. 10-15 years ago I have been on the front, respectable job!

Well, I admit that I have been guilty myself of submitting a ticket in one or two cases where I had been pulling my hair for days about a problem which I did not see, but which finally turned out to be a typo in an IP address or similar, which I had overseen all the time and which the support person saw immediately.
That can happen, and it also has happened plenty of times that I saw the error in other people's program or config, just another look may be all it takes.
Unfortunately of course that wastes support time, it could be better to try the forum first.

However, there also are the cases that are certainly not a config issue, are reported by several people on the forum, but still are being ignored (both on the forum and in tickets).
I can sympathize with it, sometimes there are issues that a developer would rather not admit or he knows it will be a lot of work to find and fix it, but as a "victim" it remains irritating to have them...

Posted: **Tue Apr 15, 2025 10:42 pm**

However, there also are the cases that are certainly not a config issue, are reported by several people on the forum, but still are being ignored (both on the forum and in tickets).
I can sympathize with it, sometimes there are issues that a developer would rather not admit or he knows it will be a lot of work to find and fix it, but as a "victim" it remains irritating to have them...

This or that, they are already human like us, but as I imagine it, they rather be a jungle fighter, whom fighting with the jungle with machete.

Posted: **Wed Apr 16, 2025 6:34 am**

Perhaps if we did get a bug tracker, it would be best as a split community and developer effort. If MikroTik support receive multiple reports, it gets escalated and it is a CONFIRMED bug then it gets assigned an ID number with public visibility. This would indeed cut down on support tickets for the same issue over and over
At the same time the community could submit a bug but it sits in an unconfirmed/pending state until curated and voted on by a sufficient number of community members to confirm its an issue
All bugs should have version tracking capability with a similar voting process so we could see i.e. 'memory leak in XYZ process' has been marked as fixed by MikroTik in version 7.21.3 however the community has voted it is still present, thus it re-opens. MikroTik acknowledges and marks it as fixed in 7.22. Some months/years down the track the problem arises again and the community looks it up, finds the problem and marks it again as a problem in 7.31. So we can blatantly see that its fine between 7.22 and 7.31 and if that is a major problem for you, don't use a firmware that has the problem

This should be somewhat curated and not open to any and all comments to cut down on the noise. Members need to register with MikroTik and keep information short and to the point. MikroTik themselves could benefit from having more precise information and see what bugs are actively looked at and voted on by users. And users could benefit from having some transparency and direct to-the-point information on bugs without having to submit a support ticket 'to the void', completely oblivious to whether or not anyone else is having the same problem, and not just hoping and praying by trawling through all the changelogs only to find "improved stability" with zero tangible information beyond that

Posted: **Wed Apr 16, 2025 2:27 pm**

i got feeling that the stable version will come very very so0n

Posted: **Wed Apr 16, 2025 2:29 pm**

i got feeling that the stable version will come very very so0n

Not so fast, first there will be a release candidate.

Posted: **Wed Apr 16, 2025 5:15 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 ?

The way it's supposed to work for NAT (according to the documentation) is to enable L3HW on the switch, then enable it on the internal ports only and leave the WAN port disabled. That way the CPU sees the new sessions and can load (and unload) the tracked connections into the ASIC (switch chip).

Posted: **Thu Apr 17, 2025 11:34 am**

Perhaps if we did get a bug tracker, it would be best as a split community and developer effort. If MikroTik support receive multiple reports, it gets escalated and it is a CONFIRMED bug then it gets assigned an ID number with public visibility. This would indeed cut down on support tickets for the same issue over and over
At the same time the community could submit a bug but it sits in an unconfirmed/pending state until curated and voted on by a sufficient number of community members to confirm its an issue
All bugs should have version tracking capability with a similar voting process so we could see i.e. 'memory leak in XYZ process' has been marked as fixed by MikroTik in version 7.21.3 however the community has voted it is still present, thus it re-opens. MikroTik acknowledges and marks it as fixed in 7.22. Some months/years down the track the problem arises again and the community looks it up, finds the problem and marks it again as a problem in 7.31. So we can blatantly see that its fine between 7.22 and 7.31 and if that is a major problem for you, don't use a firmware that has the problem

This should be somewhat curated and not open to any and all comments to cut down on the noise. Members need to register with MikroTik and keep information short and to the point. MikroTik themselves could benefit from having more precise information and see what bugs are actively looked at and voted on by users. And users could benefit from having some transparency and direct to-the-point information on bugs without having to submit a support ticket 'to the void', completely oblivious to whether or not anyone else is having the same problem, and not just hoping and praying by trawling through all the changelogs only to find "improved stability" with zero tangible information beyond that

Sounds like you are asking for a Cisco Bug Tracker from Mikrotik. Let's start with the fact that Mikrotik doesn't have TAC to maintain such a database. Who is going to maintain it? Developers?

Posted: **Thu Apr 17, 2025 11:47 am**

Sounds like you are asking for a Cisco Bug Tracker from Mikrotik. Let's start with the fact that Mikrotik doesn't have TAC to maintain such a database. Who is going to maintain it? Developers?

I said split responsibility. The community can largely be the ones that maintain it but as mentioned things can be curated, and that can be done by the community as well. Not everything that gets submitted is listed as confirmed, it would take X number of people/votes to list it as such. Devs and community members both can provide input in a streamlined fashion - not random forum posts - ergo if 1 dude with some extraordinary obscure configuration posts a bug report, and nobody else can replicate it, then it never proceeds into a confirmed bug and it'll disappear into the void. If it's a well written bug report by a community member that outlines steps to reproduce the issue and community members can replicate and acknowledge the issue, then the community can vote and get it pushed into a confirmed state. Community members themselves can help clean up and curate said list, which devs would benefit from by having strictly confirmed bugs and not have to piece together often half assed information from support tickets

Devs could of course provide input and shuffle things around in line with patch releases. But I would imagine the vast majority of the legwork is actually handled by the community

Posted: **Thu Apr 17, 2025 4:23 pm**

Who wants to help I can provide hosting space and use freedns for the domain, I can provide bugzilla/mantisbt or any other bug tracking tool that makes the job done just let me know, but first we have to know if Mikrotik is also on-board with the idea otherwise this is futile.

Posted: **Thu Apr 17, 2025 5:49 pm**

If Mikrotik saw value in this it would have already done something in that direction, so I don't think you could count on their support for this effort.

You're probably looking at something for customers by customers. It should suffice to publicly track the information loloski mentioned in their post. You could even do this in a Google Spreadsheet or something. Limit it to issues people have actually filed bugs with Mikrotik for (include ticket numbers). You'd want to keep this as light touch as possible, otherwise people will just not bother.

Posted: **Thu Apr 17, 2025 6:17 pm**

If Mikrotik saw value in this it would have already done something in that direction, so I don't think you could count on their support for this effort.

That's not always how things work. Companies that have been doing things a certain way for a long time often get stuck in a "this is how we do things" mode, and suffer from "Not Invented Here" syndrome. The recent back-and-forth with the community over changes in device-mode is a great example of MikroTik not doing a lot of (the right kind of) research ahead of the decision-making process. It takes a good set of leaders in the C-suite to be introspective and re-evaluating processes and comparing "the way we've always done it" to alternatives. (It usually centers around resources; if you're stretched thin, you tend to spend as little on retooling as possible.)

In other words, I don't even think this idea (as proposed) has even crossed their minds. The focus has been elsewhere, like getting v7 out the door and stable, as well as launching new products that leverage the features they're adding.

Posted: **Thu Apr 17, 2025 6:45 pm**

Honestly they have to do something big or small because this will be a recurring theme that someone is high jacking this release thread hoping to convey/share/discuss or event rant out of frustration just like what we are doing now :) the irony is MT is getting angry when someone high jacking this thread but they don't want to do something about it, this will be for sure going in circles for eternity

Posted: **Thu Apr 17, 2025 8:18 pm**

this will be for sure going in circles for eternity

Well when the release mgmt discussions start to overwhelming the "testing" thread... the "process" is that beta becomes a rc ;).

Posted: **Fri Apr 18, 2025 2:12 am**

ahhah I hope that's not case whatever noise gather here shouldn't affect the development task at hand, personally i want them to succeed their hardware is good just got side track for lots of unnecessary distraction due to self inflicted decision.

@MT if you truly start the development of EVPN + VXLAN could you please update the routing protocol overview page and include RFC 7432 to make it official and for our peace of mind :) roadmap pleaseeeee heheeheheh

Posted: **Fri Apr 18, 2025 3:33 am**

i got feeling that the stable version will come very very so0n
Not so fast, first there will be a release candidate.

Dont hope too.much as they said, 99% problems caused by miss configuration.

MikroTik

v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!

Re: v7.19beta [testing] is released!