During some research which found CVE-2018-19298 (MikroTik IPv6 Neighbor Discovery Protocol exhaustion), I uncovered a larger problem with MikroTik RouterOS’s handling of IPv6 packets. This led to CVE-2018-19299, an unpublished and as yet unfixed (despite almost one year elapsing since vendor acknowledgement) vulnerability in RouterOS which allows for remote, unauthenticated denial of service. Unpublished… until UKNOF 43!

…and sadly @mikrotik_com continue to stonewall me saying this remote unauthenticated denial of service is a “bug” not a “security vulnerability” — which is probably why they haven’t prioritised it for the last 50 weeks.

…and sadly @mikrotik_com continue to stonewall me saying this remote unauthenticated denial of service is a “bug” not a “security vulnerability” — which is probably why they haven’t prioritised it for the last 50 weeks.

https://twitter.com/maznu

We are aware of this issue and are working on it.

We are aware of this issue and are working on it.

I've been talking to Marek (the presenter) this morning. In a nutshell,if you run v6 on a public-facing interface, you're f***ed come 9th April.Every script kiddie out there can remotely crash your router, and do it over and over again. The only solution is to disable ipv6, not even firewalling will help here.

Mikrotik: I hope you have every developer you have available working on a fix for this. The consequences of you not having a patch in time for the 9th do not bear thinking about.

I am not convinced that your statement is acceptable, Normis. This is a serious issue that could destroy many businesses and cost millions. Given the gravity of the situation, I would expect at the very least:

1. Reassurance that you are taking the matter seriously (unlike the past year where it has been ignored)
2. A statement to the effect that you are putting every bit of development effort available to you towards identifying the source of this problem
3. A guarantee that a fix will be available in good time before this knowledge is made public

I look forward to your response.

We are aware of this issue and are working on it.

Would somebody please post some additional information about this.
I need to understand what is the problem, the potential impact and what vulnerabilities are possible.
Where can I find information to read/learn about this?

That's normal standard from Mikrotik when they are faced with a problem to resolve

That's normal standard from Mikrotik when they are faced with a problem to resolve

That is not true at all! We have always reacted to issues quickly, all the previous vulnerabilities have been fixed within hours or days time.

即使在这种情况下,我们做了和acknowledg繁殖e the issue. In this case though, the cause is very low level and is not simple to fix. The person who submitted it, has given a publication date. We have therefore a target date before which the issue must be fixed. In fact, most CVE reports have a release date set, before which the software company can fix the issue. The date has not yet come to pass.

If you just have the package enabled and absolutely no configuration from an IPv6 perspective are you okay?

If you just have the package enabled and absolutely no configuration from an IPv6 perspective are you okay?

I also would like to know this.

Yes, it is kernel level and is very hard to fix, since RouterOS v6 has an older kernel version and we can't just change the kernel.

If you just have the package enabled and absolutely no configuration from an IPv6 perspective are you okay?

I also would like to know this.

Would somebody please post some additional information about this.
I need to understand what is the problem, the potential impact and what vulnerabilities are possible.
Where can I find information to read/learn about this?

I am not aware of any workarounds or mitigations any of us can use.

We aim to fix the issue before the mentioned publication date.

I believe I saw you comment that this can't be mitigated in MIkroTik at Layer3.

What about using a MikroTik router at Layer 2 (or a non-MikroTik) inline in bridge mode before the Internet connection and using the firewall to filter out whatever is in the crafted packet that creates the issue? I'm assuming something is getting set in the header to cause this which means we ought to be able to apply the same types of techniques that are used to detect and mitigate zero day attacks by WAFs, DDoS filters, L7 firewalls, etc. Even if a non-MikroTik solution is required until the patch is released.

If you just have the package enabled and absolutely no configuration from an IPv6 perspective are you okay?

I also would like to know this.

Even if you haven't configured it, you still have a link-local address. An attacker in your network can target that address.

>ipv6 export >/ipv6 nd >set [ find default=yes ] disabled=yes >/ipv6 settings >set accept-redirects=no accept-router-advertisements=no forward=no

That's normal standard from Mikrotik when they are faced with a problem to resolve

That is not true at all! We have always reacted to issues quickly, all the previous vulnerabilities have been fixed within hours or days time.

即使在这种情况下,我们做了和acknowledg繁殖e the issue. In this case though, the cause is very low level and is not simple to fix. The person who submitted it, has given a publication date. We have therefore a target date before which the issue must be fixed. In fact, most CVE reports have a release date set, before which the software company can fix the issue. The date has not yet come to pass.

You've had close to a year to work on a fix...

So all this "close to year" shouting is overestimation. So i suggest to keep calm and wait for release, as MikroTik admitted 2nd CVE as vulnerability.

Quote fromsecond thread:

Yes, it is kernel level and is very hard to fix, since RouterOS v6 has an older kernel version and we can't just change the kernel.

Is that v7 announcement?Hurray!

The fix is in v7 guys c'mon

For those who won't notice it otherwise: MT just announcedROS 6.45 betaversion which includes fix for these two issues.

Hopefully fix will land in other (stable and long term) branches shortly.

For those who won't notice it otherwise: MT just announcedROS 6.45 betaversion which includes fix for these two issues.

Hopefully fix will land in other (stable and long term) branches shortly.

CVE-2018-19299 isnotfixed in 6.45beta22, I am afraid.

For those who won't notice it otherwise: MT just announcedROS 6.45 betaversion which includes fix for these two issues.

Hopefully fix will land in other (stable and long term) branches shortly.

CVE-2018-19299 isnotfixed in 6.45beta22, I am afraid.

Please clarify

For everyone here, I wanted to clarify, that to my best knowledge, the author of the CVE has not contacted MikroTik and we are in the dark as to what he plans to publish.

The UK Network Operators' Forum has accepted my talk about this subject: "Scanning IPv6 Address Space… and the remote vulnerabilities it uncovers"

https://indico.uknof.org.uk/event/46/co ... s/speakers

I shall be discussing IPv6 neighbor discovery exhaustion, and also how RouterOS will crash when routing IPv6 packets, i.e. both vulnerabilities I have disclosed to MikroTik in April 2018, currently unpublished as CVE-2018-19298 and CVE-2018-19299.

Do you think that MikroTik will have an update about these vulnerabilities that I can include in my presentation on April 9th?

We fixed the crashes that were reported to us. You said, we have not fixed "The CVE". I don't know what you will publish in the CVE. You have only provided a video that doesn't help at all.

This version fixes:
1) Soft lockup when IPv6 router is forwarding IPv6 packets;
2) Soft lockup when the router is forwarding packets to a local network (directly connected) due to large IPv6 Neighbor table.

We are still working on improvements for IPv6 Neighbor table processing in userspace which can lead up to OOM condition.
Since CVE detials are not yet published, we did assume that CVE targets software lockup (#2) which we did fix in this release.

For everyone here, I wanted to clarify, that to my best knowledge, the author of the CVE has not contacted MikroTik and we are in the dark as to what he plans to publish.

For everyone here, I wanted to clarify, that to my best knowledge, the author of the CVE has not contacted MikroTik and we are in the dark as to what he plans to publish.

"maznu" wrote the dates he sent it to you. Ticket numbers. Description... All this a year ago. What do you need more?

Maznu- Thank you for your comments

Normis - "Maznu" wrote the dates and when sent it to you. Ticket numbers... Description... All this a year ago. What do you need more?

Until we release the next beta with memory exhaustion fix, this firewall config should stop any attack even with small amount of RAM:

Code:Select all

admin@MikroTik] /ipv6 firewall> export /ipv6 firewall filter add action=drop chain=forward connection-mark=drop connection-state=new /ipv6 firewall mangle add action=accept chain=prerouting connection-state=new dst-address=\ 2001:db8:3::/64 limit=2,5:packet add action=mark-connection chain=prerouting connection-state=new dst-address=\ 2001:db8:3::/64 new-connection-mark=drop passthrough=yes

Replace 2001:db8:3::/64 with your network.

不。他did not send proof of concept for all issues, just a generic report about a crash. When he now said that CVE number such and such is not fixed, It was not clear, since we don't know what he will publish in that CVE. There is not a single issue, there are multiple issues, we fixed most, now he has stumbled upon another (memory leak in some other condition). We are fixing the others as well.

We have tested the same on our local network and managed to reproduce the same problem. We will see what we can do about this problem and improve IPv6 functionality in future RouterOS releases.

Your report and input into reproducing this problem is higly appreciated.

For CVE-2018-19299, Are systems that do not have IPv6 connection tracking enabled affected?

Until we release the next beta with memory exhaustion fix, this firewall config should stop any attack even with small amount of RAM:

Code:Select all

admin@MikroTik] /ipv6 firewall> export /ipv6 firewall filter add action=drop chain=forward connection-mark=drop connection-state=new /ipv6 firewall mangle add action=accept chain=prerouting connection-state=new dst-address=\ 2001:db8:3::/64 limit=2,5:packet add action=mark-connection chain=prerouting connection-state=new dst-address=\ 2001:db8:3::/64 new-connection-mark=drop passthrough=yes

Replace 2001:db8:3::/64 with your network.

Normis...i'm pretty confident we have replicated the conditions of one of the CVEs from doing some digging on our own for this issue. Without the rules, the router crashed. When we added the rules the router stayed online.

Normis...i'm pretty confident we have replicated the conditions of one of the CVEs from doing some digging on our own for this issue. Without the rules, the router crashed. When we added the rules the router stayed online.

May I please add "discovered independently by a third party" to the timeline and credit you during my UKNOF 43 talk, then?

/ipv6 firewall filter
add action=drop chain=forward connection-mark=drop connection-state=new
/ipv6 firewall mangle
add action=accept chain=prerouting connection-state=new dst-address=\
2001:db8:3::/64 limit=2,5:packet
add action=mark-connection chain=prerouting connection-state=new dst-address=\
2001:db8:3::/64 new-connection-mark=drop passthrough=yes[/code]

看着剩下的解决方案,通常的最终用途r blocking any incoming traffic not already established / related, isn't impacted, right?

This version fixes:
1) Soft lockup when IPv6 router is forwarding IPv6 packets;
2) Soft lockup when the router is forwarding packets to a local network (directly connected) due to large IPv6 Neighbor table.

We are still working on improvements for IPv6 Neighbor table processing in userspace which can lead up to OOM condition.
Since CVE detials are not yet published, we did assume that CVE targets software lockup (#2) which we did fix in this release.

I've sent through all the details in a new ticket, Ticket#2019032922005182, which I hope includes all the information you need collated into one place.

I'm very glad you've prioritised this issue with your development team, and I look forward to testing releases that address the problem soon.

Maznu, thank you for showing that you are seeking a solution for the whole community.
Could you inform me if disabling SSH and Winbox service also works the exploit?
Using RoMon only can be a "temporary" solution?

Until we release the next beta with memory exhaustion fix, this firewall config should stop any attack even with small amount of RAM:

Code:Select all

admin@MikroTik] /ipv6 firewall> export /ipv6 firewall filter add action=drop chain=forward connection-mark=drop connection-state=new /ipv6 firewall mangle add action=accept chain=prerouting connection-state=new dst-address=\ 2001:db8:3::/64 limit=2,5:packet add action=mark-connection chain=prerouting connection-state=new dst-address=\ 2001:db8:3::/64 new-connection-mark=drop passthrough=yes

Replace 2001:db8:3::/64 with your network.

While many of you are notably upset about the extraordinary amount of time that has gone by on this issue. I note some of you are wanting to move to new product vendors. This is your prerogative to do so. That said, I will point out the BIG VENDORS such as CISCO are smashed by CVE's problems ALL the time. Mikrotik is doing pretty well on the CVE footprint issue comparatively.

At some point enough, is enough. And yes, other vendors have other issues. Other vendors may also be more costly. But at least other vendors take responsibility for their products, have a clear guideline what a timely response to a ticket is and implement critical features, that customers and the industry needs. Again .. a good example: it's taken Mikrotik over a decade to implement IPV6-Delegated-Prefix, but then they decided only to implement it for DHCP and not for PPPoE. I mean .. where is the logic in that ?

https://openwrt.org/toh/hwdata/mikrotik/start

Also if your unhappy with RouterOS on your hardware, feel free to flash OPENWRT onto your MT hardware devices, and become pro-active in network code design and development for the community

Maznu, thank you for showing that you are seeking a solution for the whole community.
Could you inform me if disabling SSH and Winbox service also works the exploit?
Using RoMon only can be a "temporary" solution?

How youaccessthe router isn't the major factor here… I'm not sure I understand your question?

也许时间太考虑并行通讯unity" like edition version of RouterOS. That open to view /compile "source code" and allows the community to quickly fix issues(CVE's !!!) and add networking functionality as community made plugin's for MT Hardware..

We believe that we have now recreated the conditions of both CVEs and have been able to cause a memory leak and router crash in both of the conditions listed below using software from a common offensive linux security tool for IPv6.

soft lockup when forwarding IPv6 packets (CVE-2018-19299);
soft lockup when processing large IPv6 Neighbor table (CVE-2018-19298)

Our engineers are working on mitigation options and so far have been able to keep the test routers online by limiting to 5k new connections with 256MB of memory. We still have some testing to do and a number of different options to try.

Will post our rule sets as we further refine the testing but it is a variation on what Normis already posted.

Maznu, do the following:

ip service disable [find]

Verify that even with all Mikrotik access media services the problem occurs?

Normis...i'm pretty confident we have replicated the conditions of one of the CVEs from doing some digging on our own for this issue. Without the rules, the router crashed. When we added the rules the router stayed online.

Mistry7,

Good call moving off of mikrotik for security reasons. I couldn't agree more. I did too for some things. Today is a security day for us Cisco fans too. There are 17 flaws to fix. Have you seen this.

https://www.networkworld.com/article/33 ... flaws.html

R

Normis...i'm pretty confident we have replicated the conditions of one of the CVEs from doing some digging on our own for this issue. Without the rules, the router crashed. When we added the rules the router stayed online.

Meanwhile CVE-2018-19299 still needs fixing, because even with those performance-crippling firewall rules on 6.45beta22, I'm crashing routers.

In exactly the same lab layout as before, and with exactly the same single command that MikroTik has known for over 11 months, and still attacking 2001:db8:3::/64 (so your firewall rules are just a copy-and-paste):https://youtu.be/vJBUdAMrKJw

The fix is in v7 guys c'mon

Ros 7 is like the Yeti or Mrs. Colombo. Everyone talks about it, but nobody has ever seen it.

You don't have to disable it.

We will never see it. Mikrotik is more concerned at improving Kids Control and other useless features than working on a better platform for IPv6 and BGP multi threading for the CCR series. We have nine CCR1072 that can't receive full tables because they literally froze processing them. Already thinking on changing our routing equipment, and we are one of the biggest ISPs of the south of South America. Now I have to disable IPv6 (We are the FIRST provider implementing this on our region) because of this bold***t.

And not speaking about CCRs rebooting itself with no reason and other things like that....

Keep up the good work Mikrotik

The fix is in v7 guys c'mon

Ros 7 is like the Yeti or Mrs. Colombo. Everyone talks about it, but nobody has ever seen it.

Totally disabling IPv6 before the details of the bug as well as how to exploit it are even public is over-reactionary and knee-jerk extreme, especially since MT has said that a fix will be available before the disclosure.

Totally disabling IPv6 before the details of the bug as well as how to exploit it are even public is over-reactionary and knee-jerk extreme, especially since MT has said that a fix will be available before the disclosure.

If your networks are so huge and yet you have failed to scale your infrastructure accordingly so that updating them is not manageable, and yet you have money to change over many of your devices just tells me you have other issues to overcome before changing equipment over.

Besides the fact that you actually believe that a proven long term vendor exists.............

Totally disabling IPv6 before the details of the bug as well as how to exploit it are even public is over-reactionary and knee-jerk extreme, especially since MT has said that a fix will be available before the disclosure.

It is actually not.

MT having a fix ready before disclosure is not enough. The fix needs to be ready, it needs to be in a stable release tree, it needs to tested and validated and customers need time to implement it.

@maznu has provided a clear timeline of when this was reported to Mikrotik, when the CVEs were issued and Mikrotik has ignored this until an imminent threat of it going public came about. If they had used the time from the report and the creation of the CVEs to mitigate this, there would have been plenty of time.

So in my case, it means IPv6 will be removed from all Mikrotik gear, because the risk of loss of business is too great. And where necessary, the gear will have been replaced with gear from other vendors, that's long term proven. Even if Mikrotik released a fix in time, there would be no time for testing. I would literally have to roll it out across 300+ devices in the core network. We have near to 10k Mikrotik devices in our network, if every one of them needs to be updated. This is not something you do in a few hours .. or days. And automated updates are not an option. The quality control of the release trees supplied by Mikrotik are not good enough. We aren't even on the current long-term release yet, as it has bugs we can't live with.

问题是,这已经不是第一次,that Mikrotik has handled an issue this way. It is every single time. They only react, when issues become public knowledge.

/M

My opinion is clear: IPv6 is a required service, disabling it is akin to shutting off power.

despite the author has being less than helpful about providing details.

My opinion is clear: IPv6 is a required service, disabling it is akin to shutting off power.

但this is where you are getting me wrong:

I'm not shutting IPv6 off on our network. We have been providing IPv6 to endusers since 2008. And even longer on the infrastructure. I'm turning it off on everything Mikrotik, because it is too big a risk.

And a good chunk of CCRs will have to replaced with alternative gear, not only because of this bug, but also because Mikrotik does not implemented features needed by the industry. I have tickets going back to before 2007 for some stuff that still isn't implemented. Can't even get a timeline.

There is plenty of hardware that is not affected.

/M

despite the author has being less than helpful about providing details.

I have provided MikroTik with every detail at every step of the way.

I cannot provide anyone else with any more detail at all as this would literally give them the means to carry out the attack.

I have not shared any mitigation options because I do not believe there are any which do not involve significant expenditure of time and resources — something that many MikroTik users may not be able to afford.

I remain convinced that the fix can only come from MikroTik.

If you haven't already, I would strongly encourage those of you who discovered and reverse engineered these bugs to compare notes and check that they are in fact the same methods - the last thing we need is for MikroTik to release a fix for the original issue, and then find that those who reverse engineered it discovered a related but different issue that is still unfixed.

If you haven't already, I would strongly encourage those of you who discovered and reverse engineered these bugs to compare notes and check that they are in fact the same methods - the last thing we need is for MikroTik to release a fix for the original issue, and then find that those who reverse engineered it discovered a related but different issue that is still unfixed.

An alternative that doesn't necessarily mean we need to disclose vulnerabilities to each other or pass around weaponised PoCs is that MikroTik could send us the beta and we all bash it with our labs on Monday morning…?

If you haven't already, I would strongly encourage those of you who discovered and reverse engineered these bugs to compare notes and check that they are in fact the same methods - the last thing we need is for MikroTik to release a fix for the original issue, and then find that those who reverse engineered it discovered a related but different issue that is still unfixed.

An alternative that doesn't necessarily mean we need to disclose vulnerabilities to each other or pass around weaponised PoCs is that MikroTik could send us the beta and we all bash it with our labs on Monday morning…?

My opinion is clear: IPv6 is a required service, disabling it is akin to shutting off power.

但this is where you are getting me wrong:

I'm not shutting IPv6 off on our network. We have been providing IPv6 to endusers since 2008. And even longer on the infrastructure. I'm turning it off on everything Mikrotik, because it is too big a risk.

And a good chunk of CCRs will have to replaced with alternative gear, not only because of this bug, but also because Mikrotik does not implemented features needed by the industry. I have tickets going back to before 2007 for some stuff that still isn't implemented. Can't even get a timeline.

There is plenty of hardware that is not affected.

/M

now that we know what command to run

When I launch the attack, the chr reboots but the other routers are not affected by the attack.

Firewall rules seems not to be effective.

但if I increase the chr memory from about 300 MiB to 3000 MiB the router seems to be ok: the free memory goes between 2200 and 2400.

As my lab is made in gns3 maybe it can't be the same as IRL with Mikrotik hardware so I plan to make some tests tomorrow with several ccr1009.

但I would ask @maznu if he can check what happens if he increase the ram. In his Twitter video he has about 300 MiB. And I would ask him if he has tested with routerboards or only chr.

As a consequence, I am now assuming the exploit is out there in the wild and is being used.

This sounds almost exactly the same as what MikroTik will be fixing on Monday.

What would be characters 9, 10, 11, 12 of the md5sum?

I have been spreading the word around in other forums.

If it's of any interest / help I am happy to act as a remote test case providing no harm is done.

Sorry @maznu but I don't get the same md5sum you expected. Maybe mine is a different but correlated attack

FastNetMon may work if the netflow is being generated by an intermediate device in the path (like off of a tap), it's very fast and can potentially mitigate assuming null routing is performed before cache write.

FastNetMon may work if the netflow is being generated by an intermediate device in the path (like off of a tap), it's very fast and can potentially mitigate assuming null routing is performed before cache write.

EDIT: with only:

* a route back to the attacker
* and only a default null route in my victim router's table
* (besides dynamic routes from link local addresses)

my lab looks like it will still OOM.

(the attack is coming from a single IPv6 address)

Mikrotik have publicly disclosed the details of the vulnerability, on a Sunday, in a way that a child could exploit it - before even providing a fixed beta, let alone a stable release version, let along giving us time to test and deploy it.

Truly despicable behaviour there Mikrotik. Do you have no respect for your customers at all?

-davidc

就我个人而言,我认为Mikrotik产品雷竞技网站都是可能的a bit too cheap and I would be happy to pay a few extra bucks if it meant they were properly resourced so we don't have these types of issues.

Where is this posted? I did a quick search and didn't find anything.

Dumb question, have you validated that this is remotely exploitable outside of a contained lab?

@bmann has made some very good points which I can relate to.

I come from the Cisco camp and I was amazed when I bought my RB1100AHx4 what I was getting for the money... and it's made in Latvia, not China!

就我个人而言,我认为Mikrotik产品雷竞技网站都是可能的a bit too cheap and I would be happy to pay a few extra bucks if it meant they were properly resourced so we don't have these types of issues.

Dumb question, have you validated that this is remotely exploitable outside of a contained lab?

.
That is certainly a critical question that needs to be answered and understood. The extraordinary amount of "pre-show publicity" has lead many to form strong opinions and responses before the full facts are understood.

人比你在这个线程说there should be separate terminology between denial of service (CPU high, out of memory, crash etc) and something that allows attacker to gain access to devices, steal credentials, install malware and read private data. You are shoving them both under one term. I'm not expert, but at least that is what I mean when I said Denial of Service and Vulnerability are different things.

This may be the final straw. Time to start researching other products.

We have near to 10k Mikrotik devices in our network, if every one of them needs to be updated. This is not something you do in a few hours .. or days.

...

问题是,这已经不是第一次,that Mikrotik has handled an issue this way. It is every single time. They only react, when issues become public knowledge.

/M

We have nine CCR1072 that can't receive full tables because they literally froze processing them.

We have nine CCR1072 that can't receive full tables because they literally froze processing them.

对不起,什么?

How many tables on 1072?
I use 1036 - and this work with 2 FV tables

Don't do full tables on CCRs. They are terrible at it.

where the reporter didn't report it as a security concern and left it for 6 months till he was able to get a CVE

Don't do full tables on CCRs. They are terrible at it.

Why?
Is work fine, i receive FV and default route (while router compute FV's - used default route, when session up, internet work after 2 sec)

So what firmware do we need to install on what routers to prevent this ?

where the reporter didn't report it as a security concern and left it for 6 months till he was able to get a CVE

完整的时间表将于下周可用。但when I reported this in April 2018, my request to MikroTik was to plead with support to treat this as a serious security vulnerability, and asked that they themselves allocate a CVE to it. After no action for six months, I then raised CVEs myself and communicated this to MikroTik to try and pressure them into taking another look at this.

> This is not a security vulnerability as I would describe it.

Then what EXACTLY would you call the ability to stop your router from routing, remotely, without authentication? Because we in the Infosec world call that an Unauthenticated Denial of Service. (Which is a bad thing)

Look, MikroTik have dropped the ball on this. That they haven't gone 'Shit, yes, we made a mistake, we're sorry, and we're making (these changes) to make sure it doesn't happen again' is MORE telling.

/ip rp-filter

Don't do full tables on CCRs. They are terrible at it.

Why?
Is work fine, i receive FV and default route (while router compute FV's - used default route, when session up, internet work after 2 sec)

Default routes mean you can't use uRPF.

Such high CPU usage during table churn means you'll be at best sub-optimally routing packets and at worst, sending them down blackholes for 10 - 20 minutes at a time.

maznu - can you contact me via Twitter? I sent you a tweet already.

If you just have the package enabled and absolutely no configuration from an IPv6 perspective are you okay?

Something about this question?

It's true, MikroTik should have handled it better. It was mistakenly filed as just another ipv6 bug, which there are more of, until the author complained about lack of action. Then we looked at it again, and started to look for alternative solutions to handle it (because kernel change is not possible in v6). But in the end, the issue is fixed finally.

P.S.: we don't rely on kernel for TILE support, so new kernel doesn't affect it.

Also, send @maznu a present/gift/bounty/4011. He sure as hell earned it.

@normis

Is it possible to get an honest responce about ROS v7's release timetable? We and many other people have been struggling with BGP performance so much so we've had to reject larger potential clients because we cannot offer MPLS due to large packet loss with routing convergence on the CCR1072.

We are not a high volume network and cannot hold a single full table from any of our Transit providers because of CPU load and extended outages if for some reason one of the sessions drop. We were holding out until MUM Europe as we were told by support there would be an announcement there about it but alas there wasn't one.

We now have to seriously look at switching vendors away from Mikrotik which we've used for 15+ years because we just cannot wait any more with such a loose open ended timeline that everything appears to be "Fixed in ROS v7" and there being no release deadline.

Even if you were to release it today it would be 6 months before we could roll it out with enough confidence and testing in LAB given the extended development timeline.

I hope you can take the time to responce publicly or even privately as I'm under alot of pressure to grow our network but with current hardware not able to without potentially impacting client performance and reliability.

We'd also be happy to pay a few thousand dollars a year for advanced support/updates if required to offset the cheap licensing charges.