*) bgp - added initial support for prefix limit;

Where can read about lacp-user-key?

/interface bonding monitor-slaves

Where can read about lacp-user-key?

The setting is documented on https://help.mikrotik.com/docs/display/ ... escription
LACP key can be monitored with:

Code: Select all

/interface bonding monitor-slaves

*) lte - added MCS, CQI and RI value reporting for Fibocom FG621;

- "Old style" routing filters add (like v6), not only syntax

*) gps - added GPS package support for Chateau devices;
*) lte - added SMS sending support for MBIM protocol;
*) lte - improved stability when configuring multiple APN's at the same time in MBIM mode;
*) lte - improved stability when upgrading LTE firmware on Chateau 5G;

Is mac-protocol=arp setting requirement (so the need for the second rule) a limitation from the RB5009 switch chip (88E6393X) ?

Now I have the same key on all the bonding interfaces. As far as I understand, this is normal. Could you give an example when need to manually change the key?

*) torch - properly capture all related IPv6 traffic;

Beta 33? Out of the world version numbering.

Currently there is no mechanism to count exact session prefixes, That is why this parameter is not even set. If you want to know exact prefixes installed in the routing table received from a specific peer, then use /roruting route print command with appropriate filtering options, like "belongs-to" or "bgp.peer-cache-id"

Doesn't sound the new routing engine was very well thought out before implementing.
How is it possible that basic features were not even considered during the design phase?

As it was already mentioned in one of the topics we will try to think of some user friendly GUI method to add routing filters but doing that and implement it is not going to happen right away.

Currently there is no mechanism to count exact session prefixes, That is why this parameter is not even set.

Currently there is no mechanism to count exact session prefixes, That is why this parameter is not even set. If you want to know exact prefixes installed in the routing table received from a specific peer, then use /roruting route print command with appropriate filtering options, like "belongs-to" or "bgp.peer-cache-id"

- View received-prefixes on a per peer basis[/b]

[zuul@ccr2216-02.test.lab.ipa] > routing/stats/origin/print interval=1 where instance-id=1686070274
Flags: Y - synthetic; Z - terminal; X - stopping; D - owner-dead; H - hold; U - attrs-updated; M - attrs-merge 
12         name="BGP IP routes from 198.18.92.254" instance-id=1686070274 publisher-idx=12 route-type="8" owner=28 route-count=0,387726,0,0,0,0,0,0,0,0,0,0,0 total-route-count=387726 

13         name="BGP IP routes from 198.18.92.253" instance-id=1686070274 publisher-idx=13 route-type="8" owner=30 route-count=0,329737,0,0,0,0,0,0,0,0,0,0,0 total-route-count=329737 

14         name="BGP IP routes from 100.126.100.1" instance-id=1686070274 publisher-idx=14 route-type="8" owner=31 route-count=0,517453,0,0,0,0,0,0,0,0,0,0,0 total-route-count=517453 

Doesn't sound the new routing engine was very well thought out before implementing.
How is it possible that basic features were not even considered during the design phase?

+1
Not only that, but it takes ages and many versions to get it fixed.

Prefix count per peer

- View received-prefixes on a per peer basis

- View advertised-prefixes on a per peer basis

max-prefix-limit

+1
Not only that, but it takes ages and many versions to get it fixed.

Don't be ridiculous. Bare essential functionality is very well though out and has the highest development priority. Which means that features that are not absolutely essential for BGP to work or their functionality can be done alternatively with other already existing features but in a bit less convenient way has lower priority. What you are asking here are mostly cosmetic things with lower priority. Pretty GUI and convenient counters are not the things that are needed for BGP to work properly, but it does not mean that these features will not be implemented ever (as already mentioned in this topic and other topics).

From your requests should we stop working for example, on BFD support, just to implement cosmetic counter in session stats? Or should we stop fixing found problems just to try to make pretty GUI for routing filters?

I have posted the list of features we NEED to have to be able to deploy v7 several times. BFD is certainly at the top of that list, but there are several others:
- working aggregation, both as a source and when processing/forwarding aggregated routes
- working route refresh (when filters are changed, for example)
- meaningful error messages when some connection fails, not "Holdtime expired, session *=0x30110240" but a session NAME instead. nor "Write to bgp failed (32) { #buf=1 max=64 sk=Socket{ 5[" but some message that includes a session name instead, so I can know where to look for a potential problem.

You are missing the point, should we stop working on these features then just to implement prefix counter to show up in BGP session?
You are willing to tolerate BGP crashes that we could fix instead of possibility to get a counter in a specific manner?

You already can get prefix count with methods mentioned previously. If you already had a script to get prefix count for monitoring of ROS v6, then only difference is that this script line will look a bit different for ROS v7. Its not like you cannot get prefix count at all.

Meaningful error messages when some connection fails, not "Holdtime expired, session *=0x30110240" but a session NAME instead. nor "Write to bgp failed (32) { #buf=1 max=64 sk=Socket{ 5[" but some message that includes a session name instead, so I can know where to look for a potential problem.

However what I do not understand is why this new v7 with the new BGP takes so long to get feature-complete. After all, we are hearing nearly 10 years from MikroTik about this exciting new routing engine that will be part of v7 and will end all troubles. After all that preparation it could have been a bit more polished.

You are missing the point, should we stop working on these features then just to implement prefix counter to show up in BGP session?
You are willing to tolerate BGP crashes that we could fix instead of possibility to get a counter in a specific manner?

Meaningful error messages when some connection fails, not "Holdtime expired, session *=0x30110240" but a session NAME instead. nor "Write to bgp failed (32) { #buf=1 max=64 sk=Socket{ 5[" but some message that includes a session name instead, so I can know where to look for a potential problem.

Regarding cryptic error messages, I am really surprised that MT didn't take the opportunity to introduce error numbering in V7 that could be explained in more details on, for example, the help page and a corresponding text file with error messages (which is a good solution if you want to keep the program size down)

and usually there are almost no changelist items related to BGP.

develops its own BGP stack from scratch which is a challenge

It is all about the priorities you guys are pushing.

and usually there are almost no changelist items related to BGP.

Exactly because of the above mentioned priorities. According to forum users "bgp advertisements" and "prefix limits" were the most essential features, so it was set as a highest priority and took all the development time instead of fixing actually important problems.
It is all about the priorities you guys are pushing.

And also to filter and recognize error messages in either internal scripts or an external system...

Probably more time has been spent on discussing the problem than would have to be spent on fixing it.

Has anyone updated a chateau yet?

Maybe create the poll? Should we stop fixing crashes and switch to working on pretty logs because you do not experience crashes ?

Maybe create the poll? Should we stop fixing crashes and switch to working on pretty logs because you do not experience crashes ?

The same question again, do you think that we should stop working on BFD or fixing crashes to make pretty BGP logs?

Any RB5009 owners updated?

P3 - Capsman V7 with new wifi driver
P4 - Announce Cap AX and Cap AX-E 2x2 & 4x4

Yes, IPsec / IKEv2 should rather be used instead IMO...
Properly supported by MikroTik, and by all OSes / mobiles devices etc...
Much nicer solution...

I agree about split-tunnelling issue with multiple networks, only the first subnet is considered by some clients, and especially macOS.
SUP-59668 created months ago regarding this, MikroTik knows the issue and will fix it (as the problem is on RouterOS side), but no ETA unfortunately :-/

Sorry about this one guys, but every time we have a new version released I see some kind of battle here and I sort of (unfortunately) understand both sides.

Thing is: it is non-sense to ask a customer if MikroTik should focus or not on any (kind of) feature that... crashes one device. Crashing is that kind of behavior that should (almost) never happen.

But I am against promoting a new major release to "stable" status (and prominently recommending it for installation on the webpage) before it is even feature-complete relative to the previous one (and without mentioning that in the description). … There apparently is a (human) resource bottleneck in working on BGP and other (auto)routing. I do not know which of the MikroTik employees is/are working on this and if we ever see them here, but it looks like they are overburdened in finishing their work.

You are missing the point, should we stop working on these features then just to implement prefix counter to show up in BGP session?

If it is that much difficult to implement basic stuff like showing the prefix count and advertisements (and no, pcap dumps is a joke), that it would take sooo much time from implementing and fixing other BGP stuff, then something is seriously wrong with the new BGP implementation.

If it is that much difficult to implement basic stuff like showing the prefix count and advertisements (and no, pcap dumps is a joke), that it would take sooo much time from implementing and fixing other BGP stuff, then something is seriously wrong with the new BGP implementation.

Either that, or you don't know how it's implemented and why it's implemented that way, and you're making prescriptions from that point of ignorance.

The old (v6) BGP implementation was single-threaded, which caused it to have serious scalability problems. We can no longer depend on more GHz to solve problems like this. Instead, we rely on more CPU cores, but to make use of that, you need a parallel implementation, which requires a rewrite. You can't just take a single-threaded program and launch N threads on it and expect it to work properly because reasons…

In rewriting their BGP implementation to be multi-core friendly, they caused there to be no single location for certain details like these counters you're wanting. It's possible to bottleneck everything down to a single thread to collate these values, but in doing so, you throw away the speed advantage of v7's BGP implementation.

I get that you want all of the features, and you want them 2 years ago. However, you might want to consider the possibility that MikroTik's software developers are doing their best with the resources they have.

You are missing the point, should we stop working on these features then just to implement prefix counter to show up in BGP session?
You are willing to tolerate BGP crashes that we could fix instead of possibility to get a counter in a specific manner?

This is completely false and shows no understanding on threading. If we're able to use filters for export/import of prefixes that shows there should not be any reason not to also add a counter to that since there's already logic in place to permit or deny prefixes.

This is completely false and shows no understanding on threading. If we're able to use filters for export/import of prefixes that shows there should not be any reason not to also add a counter to that since there's already logic in place to permit or deny prefixes.

Peeking from the outside in the black box it appears that the new BGP has a separate thread per peer, that just accepts all routes from the peer and puts them into a big table, and then the filtering is done in another thread that marks those table entries with a filtered/not_filtered status, and the active route is chosen from those that are not filtered.
So, the process handling the peer connections does not know how many of the received routes actually make it past the filtering, and the filtering process has no "counters".
It is possible to get counts by doing searches on the table, like "how many routes received from this peer are not filtered", but it is a "costly" operation as it has to walk the entire table every time you want to obtain the count. It can be done in a script, but it isn't done in the "session overview".
Also, the command-line language does not make it easy. E.g.:
/routing/route/print where belongs-to="BGP IP routes from 1.2.3.4"
neatly prints all routes received from that peer.
/routing/route/print count-only
prints the total number of routes in the table. but:
/routing/route/print count-only where belongs-to="BGP IP routes from 1.2.3.4"
always prints zero :-( so you need to write a script that actually does the full print and counts the lines. what a waste!

It can be difficult to make an existing algorithm multi-threaded. And it obviously was an objective of the BGP rewrite, as (especially at that time) MikroTik routers have lots of cores and a single-threaded BGP would not effectively use them. But it looks like while making the multithreaded design, this particular aspect was overlooked or considered not that important.

If they designed it without communication between the peer-processes and the filter process(es) then I can understand why it wouldn't work. But that would be a strange way of designing it. The filter process gets the remote peer ip etc also so it's not that it just sees routes flying in without knowing where they came from.

If they designed it without communication between the peer-processes and the filter process(es) then I can understand why it wouldn't work. But that would be a strange way of designing it. The filter process gets the remote peer ip etc also so it's not that it just sees routes flying in without knowing where they came from.

The peer communication process sees routes coming in but does not keep a table of them to know how many unique routes there are.
The filtering process runs through the central table and applies the filters but it sees all the routes so it is "difficult" to keep counts per peer (also because the other processes are feeding new data all the time).
Likely the only way to get approximate counts is by walking the table as-it-is, and to get accurate counts you need to "lock" the table while doing that.
Not something you want to do every second to keep a dynamically updated display, like we have in v6.

If they designed it without communication between the peer-processes and the filter process(es) then I can understand why it wouldn't work. But that would be a strange way of designing it. The filter process gets the remote peer ip etc also so it's not that it just sees routes flying in without knowing where they came from.

The peer communication process sees routes coming in but does not keep a table of them to know how many unique routes there are.
The filtering process runs through the central table and applies the filters but it sees all the routes so it is "difficult" to keep counts per peer (also because the other processes are feeding new data all the time).
Likely the only way to get approximate counts is by walking the table as-it-is, and to get accurate counts you need to "lock" the table while doing that.
Not something you want to do every second to keep a dynamically updated display, like we have in v6.

There is no way to know how it is designed, and conjecture doesn’t get us any closer to a fix.

There is no way to know how it is designed, and conjecture doesn’t get us any closer to a fix.

There have been occasional descriptions by MikroTik employees of what has changed in BGP operation, and we can see what is going on in the routing table (filtered routes now appear in the table).
I am posting this only because people write "it is stupid that they do not just include a prefix counter" and while I agree with the end-result of that, I try to explain why it is not that simple.

It is perfectly fine to use the same key for multiple LACPs. We received a feature request asking for this option, I guess it was up to their network policy to use unique keys for each LACP. It was fairly easy to implement it in RouterOS, so here you go. :wink:

v7 introduces years ago (i believe more than 5 years ago) and today in 2022 it's not even finished yet, how many years actually need to make the v7 full finished anyway?

And even with unmatching keys (5 / 329) and 17 on the remote system, the bond is Running and I can ping...

Still a lot to be done.

please check the problem, error of 100% CPU X86 "management" process, it persists in 7.3 beta.

You missed this in the documentation I think:

lacp-user-key: Specifies the upper 10 bits of the port key. The lower 6 bits are automatically assigned based on individual port link speed and duplex.

So what you are seeing is correct and is the expected behavior. The lower 6 bits getting automatically assigned results in the 17 and 329.

SNMP: SNMP feed seems unstable. Monitoring tools show discontinuous flows.

*) ping - fixed socket allocation after VRF change;
cloud it fix the issue related to ticket[SUP-67221].

regards

*) ping - fixed socket allocation after VRF change;
cloud it fix the issue related to ticket[SUP-67221].

regards

No, problem described in that ticket is unrelated to VRFs

hAP AC3
installation of 7.3b34 causes bootloop (coming from 7.3b33).
Trying netinstall now to recover.

Tested prefix limit in BGP. It works but requires a manual clearing of the peering. Would be nice to have a timer and retry in future releases.

Code: Select all

[zuul@ccr2216-01.test.lab.ipa] > routing/bgp/connection/disable 0
[zuul@ccr2216-01.test.lab.ipa] > routing/bgp/connection/set input.limit-process-routes-ipv4=5000 0
[zuul@ccr2216-01.test.lab.ipa] > routing/bgp/connection/enable 0
[zuul@ccr2216-01.test.lab.ipa] > routing/bgp/session/print 
Flags: E - established 
 0   remote.address=198.18.91.254 .refused-cap-opt=no 
     local.address=198.18.91.1 
     output.last-notification=ffffffffffffffffffffffffffffffff0015030601 limit-exceeded 
[zuul@ccr2216-01.test.lab.ipa] > routing/bgp/connection/set input.limit-process-routes-ipv4=1000000 0
[zuul@ccr2216-01.test.lab.ipa] > routing/bgp/session/clear 0
flag: 
input-last-notification  limit-exceeded  output-last-notification  refused-cap-opt  stopped
flag: limit-exceeded
[zuul@ccr2216-01.test.lab.ipa] > routing/bgp/session/print 
Flags: E - established 
 0 E remote.address=198.18.91.254 .as=65101 .id=198.18.91.254 .refused-cap-opt=no .capabilities=mp,rr,role,gr,as4 .messages=227341 .bytes=22502859 .eor="" 
     local.address=198.18.91.1 .as=8675309 .id=100.127.100.101 .capabilities=mp,rr,gr,as4 .messages=1 .bytes=19 .eor="" 
     output.procid=60 .filter-chain=deny-all .last-notification=ffffffffffffffffffffffffffffffff0015030601 
     input.procid=60 .limit-process-routes=1000000 ebgp 
     hold-time=3m keepalive-time=1m uptime=34s270ms 
[zuul@ccr2216-01.test.lab.ipa] > 

So far unsuccessful with netinstall.
It installs but after reboot, still bootloop.
Already tried 7.3b34, 7.3b33, 7.2, ...

Is this just a case of ID10T user error, ...

There is a documentation page about netinstall. And it is wellknown that when you attempt it after a long time of not using it, it usually won't do what you want.
It requires experience and proficiency.

Does the Router appear automatically again in Netinstall after you reboot it? Sure you didn't change /system/routerboard/settings/boot-device to ethernet?!

There is a documentation page about netinstall. And it is wellknown that when you attempt it after a long time of not using it, it usually won't do what you want.
It requires experience and proficiency.

Good joke.
That documentation page show at the end of the process a "Reboot" button which is NOWHERE to be found on the versions I tried.
7.1 / 7.2 / 7.2.1 / 7.2rc4 / 7.3b33 / 7.3b34
Nada.

Install succeeds EACH TIME (at least that's what the tool indicates) yet after power cycle the device remains stuck in a bootloop.

Care to comment again ?

I am going to throw this towards Support ...

EDIT: I do see one difference... there is not status indicator "done". It does flip back from Installing to Ready.
So it might not install at all ? Even better then ...

Using Good Ol' Linux and CLI !! (told you I know a thing or two)
That laptop I used before, was already used several times for netinstalling Hex and MapLite, so why not now ?

the netinstall program is just a big mess.

The most frequent one is delayed NIC init after link re-establishes.

Next one is the fact netinstall exec doesn't allow to explicitly select which interface to use and this is down to MT devs indeed (if wireshark can do it, why can't netinstall as well?).

The docs on netinstall recommend taking down all network interfaces but the one you know for a fact goes to the MT box you're trying to recover. If you don't, you can't predict which interface it will use short of trawling the mess of a routing table you get with modern OSes. The last time I made a Windows box barf up its default routing table, it was over a screenful!

if wireshark can do it, why can't netinstall as well?

the netinstall program is just a big mess.

Most of times it's not a problem on device's side, it's machine hosting netinstall "server" that messes things up. The most frequent one is delayed NIC init after link re-establishes. Next one is the fact netinstall exec doesn't allow to explicitly select which interface to use and this is down to MT devs indeed (if wireshark can do it, why can't netinstall as well?). Only the third one is down to interaction between device and PC (the state where one selects packages to upload but device doesn't get or process them) ... and only with this one it's not really clear which end to blame, device or netinstall exec ... or even BOOTP. Other than that BOOTP is just fine.

control panel , network, right-click disable on everything but ethernet).
Still it did not work.

The device shows up in netinstall (so the network interface is correct, I would think ?

Both in the Windows and Linux version. I am very sure that in Linux it is easy to listen to a specific network interface instead of to a random one. [...]

a script that sets up a network namespace

What's new in 7.3beta34 (2022-Apr-20 08:23):

*) bgp - improved stability when editing BGP template;
*) ccr - added "passthrough" flag for interfaces on CCR2004-1G-2XS-PCIe;
*) dhcpv4-server - added "age" parameter for dynamic leases;
*) dhcpv4-server - fixed minor logging typo;
*) export - fixed value ID exporting that does not refer to any name;
*) fetch - fixed SFTP upload;
*) filesystem - fixed possible boot failure on RB850Gx2 and RB1100AHx2;
*) filesystem - improved long-term filesystem stability and data integrity;
*) ipsec - fixed IPsec IRQ initialization on startup on TILE;
*) leds - fixed ethernet LED behavior on wAP R ac;
*) lte - disabled extended signal info query for Telit LN940 module;
*) ospf - fixed GRE interface compatibility with OSPF;
*) ospf - improved stability when enabling or removing interface-template entries;
*) ovpn - improved stability when forwarding traffic on TILE;
*) ping - fixed socket allocation after VRF change;
*) ppp - fixed active sessions sometimes getting stuck;
*) queues - improved stability in large list of queue scenarios;
*) rb5009 - fixed 10G linking issues with Intel X520, XXV710 NICs;
*) ssh - fail non-interactive client after first invalid password;
*) supout - added IGMP-Proxy section;
*) winbox - added "Comment" parameter for BGP templates and connections;
*) winbox - made "Interface Templates" table sortable under "Routing/OSPF" menu;
*) winbox - made "MPLS Interface" table sortable under "MPLS" menu;
*) winbox - made 56 the default ping size;
*) winbox - moved "src-address-list" and "dst-address-list" parameters to "General" tab under "IPv6/Firewall" menu;
*) winbox - show correct file system type under "System/Disks" menu;

To upgrade, click "Check for updates" at /system package in your RouterOS configuration interface, or head to our download page: http://www.mikrotik.com/download

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after some problem has appeared on device

I know about that requirement and I did disable ALL other network interfaces on my laptop (control panel , network, right-click disable on everything but ethernet).
Still it did not work. The device shows up in netinstall (so the network interface is correct, I would think ? ) but "install" did nothing.
Only one single cable between ether1 of Tik and ethernet port of laptop. Where else can the communication go then ?

Wifiwave2 package causes a bootloop on this release for rb4011igs+5hacq2hnd-in

Just to confirm 7.3beta34 boot looped my audience with wifiwave2 as well.

Just to confirm 7.3beta34 boot looped my audience with wifiwave2 as well.
Same here.

only if you want to use wifiwave2 it seems?

only if you want to use wifiwave2 it seems?

Although could someone explain to me why the device does not just disable the package and boot?

Exception is the use of partitioning. When you would partition the device, copy and upgrade a partition, and it fails to boot, it would boot the old (copied) partition and you would be back without netinstall.

Exception is the use of partitioning. When you would partition the device, copy and upgrade a partition, and it fails to boot, it would boot the old (copied) partition and you would be back without netinstall.

That's a good point. That Audience has the space for a 2nd partition. We use a lot of wAPacR, so there not room for even one partition (or even the wifiwave2 package)

That's a good point. That Audience has the space for a 2nd partition. We use a lot of wAPacR, so there not room for even one partition (or even the wifiwave2 package)

No, actually partitioning on Audience is not a feasible option when running wifiwave2 package.

Using RAM disk would help (my audience is currently at stable 142MB RAM used, so around 100MB unused), but sadly RAM disk is not an option on these devices.

*) sfp - added 2.5Gbps rate for SFP+ and QSFP+ interfaces on 98DXxxxx and 98PX1012 switches (requires disabled auto-negotiation);
*) sfp - improved Q/SFP interface initialization and stability for 98DXxxxx and 98PX1012 switches;

Everyone, thank you very much for all the input regarding the configuration loss problem. For your reports in the forum and support tickets. By putting our heads together and combining all of your reports we managed to reproduce this problem and seems that we have resolved it. The fix is included in v7.3beta and, of course, if it will be proven safe (we have tested it ourselves reliably, but would like to see the feedback from beta releases), then it will be included in stable releases as well.

Please note that the upgrade happens on the old version, not the version which you try to install. So the fix applies only when you try to upgrade FROM 7.3beta37 or a later version.

Everyone, thank you very much for all the input regarding the configuration loss problem. For your reports in the forum and support tickets. By putting our heads together and combining all of your reports we managed to reproduce this problem and seems that we have resolved it. The fix is included in v7.3beta and, of course, if it will be proven safe (we have tested it ourselves reliably, but would like to see the feedback from beta releases), then it will be included in stable releases as well.

Please note that the upgrade happens on the old version, not the version which you try to install. So the fix applies only when you try to upgrade FROM 7.3beta37 or a later version.

Does that include vxlan interface mac changing on every reboot.?

By putting our heads together and combining all of your reports we managed to reproduce this problem and seems that we have resolved it.

What's new in 7.3beta37 (2022-Apr-25 15:29):
*) dot1x - improved server stability when using re-authentication;

*) system - fixed RouterOS bootup when wifiwave2 package is installed (introduced in v7.3beta34);

Unfortunately with 7.3beta37 my ARM routers with CAPsMAN active are still freezing after 3h 43m 26s of uptime... Tested with RB3011, RB4011, CRS326
So I had to deactivate CAPsMAN and configure all radios manually... :/
And even with that I still prefer to use ROS v7 because of features like VxLANs, OpenVPN+UDP and WireGuard.

Huum, are you really using CRS switches as CapsManagers? how did that work out for you?

[admin@Ros7.3b37] > /ip/firewall/mangle/add routing-table
expected end of command (line 1 column 25)

*) sfp - added 2.5Gbps rate for SFP+ and QSFP+ interfaces on 98DXxxxx and 98PX1012 switches (requires disabled auto-negotiation);

why no routing-table ??? in ROS v7.x

connecting to mikrotik ros7.3b37:

[admin@Ros7.3b37] > /ip/firewall/mangle/add routing-table
expected end of command (line 1 column 25)

question - why NO routing-table in cli???

@marlab I have the exact same issue with my hap ac2 (also arm). The device reboots every ˜3h42m. I'm still trying to find the exact cause for it. This problem started with 7.2.0; 7.1.5 was stable.
Are you absolutely sure capsman is causing this? Anything else running on this device like eoip, wireguard, ospf?

*) bridge - fixed packet marking for IP/IPv6 firewall;

Is this enough user attention for a priority boost?

viewtopic.php?t=175513