Any plans to add “eap-identity” to Winbox as well? :)

What are the MT product that support e-Sim? or this is just preparation for the future release?

• You can still kill the router (all links on the bridge will go down and then come back)

• Performance in both directions is stable. (Client X <-> Client Y)

*) ip-service - show all TCP/UDP connections on the system (additional fixes);
*) ip-service - show all TCP/UDP ports on system, including ports in containers (additional fixes);

*) ip-service - show all TCP/UDP connections on the system (additional fixes);
*) ip-service - show all TCP/UDP ports on system, including ports in containers (additional fixes);

Where do I see these values?

In IP/Services.

In IP/Services.

You can choose to understand what they meant to say or you can choose to get lost in translation.

e50ug can't accessed after upgrade from 7.19beta8

What are the MT product that support e-Sim? or this is just preparation for the future release?

What's a physical eSIM?

What's a physical eSIM?

A piece of cardboard with QR code on it i guess:)

*) ip-service - show all TCP/UDP connections on the system (additional fixes);
*) ip-service - show all TCP/UDP ports on system, including ports in containers (additional fixes);

Please re-read changelog - one entry is about "connections" and one about "ports" or, as you prefer - "listeners".

This is actually pretty nice. Did not know physical eSIM is a thing!

Looks like you pushed a release candidate (beta) to production. Probably not the smartest move.

Looks like you pushed a release candidate (beta) to production. Probably not the smartest move.

Just reporting. That issue has been present in RouterOS on CCR2116 since at least 7.12.1 along with few others (like for example ipsec crashing after opening installed-sa tab in winbox).

Looks like you pushed a release candidate (beta) to production. Probably not the smartest move.

Just reporting. That issue has been present in RouterOS on CCR2116 since at least 7.12.1 along with few others (like for example ipsec crashing after opening installed-sa tab in winbox).

*) ipsec - fixed system failure on MMIPS devices when using IPsec services;

Looks like you pushed a release candidate (beta) to production. Probably not the smartest move.

*) ip-service - show all TCP/UDP connections on the system (additional fixes);
*) ip-service - show all TCP/UDP ports on system, including ports in containers (additional fixes);

Please re-read changelog - one entry is about "connections" and one about "ports" or, as you prefer - "listeners".

*) ip-service - show all TCP/UDP connections on the system (additional fixes);
*) ip-service - show all TCP/UDP ports on system, including ports in containers (additional fixes);

Please re-read changelog - one entry is about "connections" and one about "ports" or, as you prefer - "listeners".

On an AP running nothing but wireless, dhcp keeps popping up as a dynamic port (server), what's the reason there if it's not configured?

No smartypants, connections have the connection flag, this one doesn't.

We’ve had no stability issues whatsoever with either WireGuard or IPsec for a long time now. IPsec parallel throughput with hardware offload on the high-end models is really solid, with no noticeable drop in performance as long as you stay within the recommended connection limits. The only limitation is the lack of VTI support, though that’s mostly a matter of configuration.

I thought I was the only one noticing a performance drop in Wireguard

I thought I was the only one noticing a performance drop in Wireguard

Since WireGuard relies entirely on software-based encryption (ChaCha20), speed is limited by the endpoint with the weakest CPU. It’s good for home setups and out-of-band management for a single connection, but for VPN concentrators where high throughput and scalability are required, IPsec with hardware offload is still the only practical option.

Since WireGuard relies entirely on software-based encryption (ChaCha20), speed is limited by the endpoint with the weakest CPU. It’s good for home setups and out-of-band management for a single connection, but for VPN concentrators where high throughput and scalability are required, IPsec with hardware offload is still the only practical option.

Not exactly: https://esim.me/

I don't agree with this. If you want to say, "vpn concentrators where high throughput and scalability are required, ipsec with offload is the only practical solution on RouterOS" maybe that is true. But if we are talking hardware/software solutions outside of what Mikrotik provides etc, then this certainly isn't the case. Additionally, I believe @federalbr is indicating there IS a performance drop similar to what I have tested and shown in my post above whereas you were saying that you have not seen any Wireguard performance regressions.

I don't agree with this. If you want to say, "vpn concentrators where high throughput and scalability are required, ipsec with offload is the only practical solution on RouterOS" maybe that is true. But if we are talking hardware/software solutions outside of what Mikrotik provides etc, then this certainly isn't the case. Additionally, I believe @federalbr is indicating there IS a performance drop similar to what I have tested and shown in my post above whereas you were saying that you have not seen any Wireguard performance regressions.

My comment was specifically in the context of Mikrotik ROS, where IPsec provides hardware offload. WireGuard with multiple connections on the same platform is very limited since it's CPU-bound, and that applies also to all platforms and architectures on the market.

To make WireGuard perform well with multiple connections, you need massive CPU power (just look at the VPN providers). So yeah, performance will obviously vary depending on hardware, software and traffic patterns.

Bottom line: WireGuard is perfect for the advanced home user and OOB management, but not really an option when it comes to scalability. Anyone suggesting otherwise hasn’t run it in production or high-demand environments. But that’s another discussion.

As for @federalbr’s point, I'm not denying that performance issues actually can occur, just noting that in our use cases we haven’t observed any regressions at all, and we have plenty of OOB connections that are monitored 24/7.

So if you’re sure about the performance regressions, gather some facts and open a ticket with support. Just saying it feels slow isn’t going to cut it.

Since WireGuard relies entirely on software-based encryption (ChaCha20), speed is limited by the endpoint with the weakest CPU. It’s good for home setups and out-of-band management for a single connection, but for VPN concentrators where high throughput and scalability are required, IPsec with hardware offload is still the only practical option.

Again, OT! Please start a separate thread and I’ll respond there, alright?

Anyway, just to spice up the debate before the new thread: 256 full-speed IPsec tunnels with almost no CPU impact equal, at most, 5–10 full-speed WireGuard tunnels with 100% CPU consumption on a CCR2216. And that’s a fact!

e50ug can't accessed after upgrade from 7.19beta8

Send us supout rif file and details on the issue.

As per normis they are working hard on ROSE features/stability on 7.19 and 7.20 so I guess no progress on routing,switching and hwoffload features I hope I'm mistaken

This is a silly comment. It's not like they only have five guys that work on all of RouterOS.

Some developers work on ROSE and containers. Some work on BGP, OSPF, ISIS, MPLS, etc.

Not sure if anybody else is seeing this behaviour, but since updating to this release from 7.18.2 my devices that as a rule connect to 5g on the same SSID are now only connecting to 2.4g across the same SSID. After downgrading and reloading the previous saved config, all is well again. stuff is prefering the faster 5g again.

yes using FT and steering

I upgraded my RDS2216 to 7.19rc1 for some disk testing. Built-in SMB is still bad for some reason. It works fine on 7.17, but throughput on 7.18-7.19 are horrifically slow.

on 7.19rc1 something called 'fileman' is reading everything on the disk for some reason

Built-in SMB is still bad for some reason. It works fine on 7.17, but throughput on 7.18-7.19 are horrifically slow.

Not sure if anybody else is seeing this behaviour, but since updating to this release from 7.18.2 my devices that as a rule connect to 5g on the same SSID are now only connecting to 2.4g across the same SSID. After downgrading and reloading the previous saved config, all is well again. stuff is prefering the faster 5g again.

yes using FT and steering

any specific devices, or just all of them?
The only 2 devices i ever had issues with (with Multiple Vendors Wi-Fi) was my Xiaomi 12 Pro and Samsung Galaxy S8+

For the record we are talking about iphones and google pixel.

Some more questions:
Should or could i use both an access list entry and multi-password-group for the same client?
And when yes, in wich order is this processed?
And wich comment it used or could you combine the comments in the registration list?

regards

I am sure many of us are anxious to hear if the BGP changes made in 7.19 put this release as a candidate for folks still holding at 7.15.3. I know pe1chl has mentioned the various BGP problems within 7.16 and forward ROS versions. He has been patiently encouraging developers to address them. I continue to wait on the sidelines. BGP stability is crucial to our network and many others, I suspect.

I am sure many of us are anxious to hear if the BGP changes made in 7.19 put this release as a candidate for folks still holding at 7.15.3. I know pe1chl has mentioned the various BGP problems within 7.16 and forward ROS versions. He has been patiently encouraging developers to address them. I continue to wait on the sidelines. BGP stability is crucial to our network and many others, I suspect.

it seems that iot-related-features and "adlists" is more important than bgp which is fundamentally broken in 7.x and we keep waiting like ...let's dont say like what.
we consider switching to a VM with bird of opnsense and frr package for our AS, since we can't keep up with 7.x anymore.
It's a pity when mikrotik announces rose and enterprise hardware and giving more attention to silly features and not in features related to the hardware they are producing.
no meaning anymore on to this.
I can't understand your priorities but I am disappointed by far with your feature schedule.

Another issue on 7.19rc1, device mode does not work properly. You can't update the mode as the command is broken. Device-mode print only works if you CTRL-C after running the command.

What is completely broken in BGP?

That does not qualify as "completely broken".

That does not qualify as "completely broken".

@mrz most of the people here buy high-end devices from you guys from switch to router and we expect that it will work properly if there was a bug we expect that each bug was fairly treated even though it was hard to fix don't assume always that it was a config issue or user error, we notice that your developer want to fix those area that only interest them, we buy RouterOS to forward or switch packet not as a Storage device, with this direction you are forcing us out and let us dry but our hands our tied because we can't simply throw investment we have in the device and people that's my sour graping at least on my end

I already said this here many times don't take this as negative instead use this as an opportunity to fix or enhance your product try to address the issue of your customers instead of evading them. By not addressing this or continue to deny the existence of the bug it would be a deterrent on MikroTik good name

That does not qualify as "completely broken".

What is completely broken in BGP?

When the content of the route table is incorrect (in winbox), I have found that it is sometimes fixed when winbox is closed and re-opened. That also helps when garbage is displayed in the "Immediate Gateway" column.

Have you seen that problem where in the session the number of prefixes remains at 0 even though the number of received messages increases as normal?
Here that only happens after some uptime (and restart of a session), not immediately after boot.

It was mentioned several times, there is an issue that winbox may not refresh tables. Hit F5 or use CLI for monitoring.

I had not noticed that before, but I pulled up one of my borders and found this interesting. For all of my peers with redundant connections, the secondary router (that has most recently reconnected) shows a dissimilar number of prefixes received, despite being configured identically.

Stability issues should be already solved in v7.19rc,

I had not noticed that before, but I pulled up one of my borders and found this interesting. For all of my peers with redundant connections, the secondary router (that has most recently reconnected) shows a dissimilar number of prefixes received, despite being configured identically.

Yes, that is what I mean.
And it is not cosmetic. When the other connection fails, you are without failover routes and need to close/re-open the second session to get them back (which when the other side is MikroTik takes 1 minute due to another bug).

The CCR is already in its 2nd generation. Even in the 1st generation, I was running my business with some issues, and now in the 2nd generation with v7, the situation isn't exactly better.

That does not qualify as "completely broken".

..CUT..
I salute pe1chl for his persistence and continued posts on this forum related to these BGP problems.

..CUT..
I salute pe1chl for his persistence and continued posts on this forum related to these BGP problems.

+1

Have you seen that problem where in the session the number of prefixes remains at 0 even though the number of received messages increases as normal?
Here that only happens after some uptime (and restart of a session), not immediately after boot.

I had not noticed that before, but I pulled up one of my borders and found this interesting. For all of my peers with redundant connections, the secondary router (that has most recently reconnected) shows a dissimilar number of prefixes received, despite being configured identically.

That does not qualify as "completely broken".

I believe Normis was the first to use "completely broken"; I do not think it was by a forum user specific to BGP in this thread. A more accurate phrase would be "completely unusable".

It appears that if the router is already receiving routes from another router in the same AS, that it won't even count and list any of those same routes as received from a second router in that source AS (hence the "0" or "1"). The second router is most definitely advertising them.

• First of all, BGP is not a typical "hobby" routing protocol.

• Second, stable BGP is a must have in a serious routing product.

• Third, we need good configuration examples, or help from support if there is a configuration issue. If there is no correct configuration examples then nobody can help on the forum either.

• If we have good/usable config examples, we can have better works with less mistakes.

• It is not necessary to cover all of config possibilities, but we need basic building blocks, especially for BGP where a lot of things changed in the last few major versions.

... we can't provide a public administration or government with equipment that doesn't work.

The CCR is already in its 2nd generation. Even in the 1st generation, I was running my business with some issues, and now in the 2nd generation with v7, the situation isn't exactly better.

Well, my experience with v6 was very good, and I still have it running on a lot of routers in the hobby network.
I never would have switched the company network to v7 when the currently used hardware (CCR2004 and RB5009) would not require it...
I would be very happy when there was an optional package to have the original v6 auto-routing in v7.
For my use-cases (not full table internet routing but routing in a smaller network with 20 (work) to 1000 (hobby) routes on a partial mesh network) the old routing was fine and at least it was fully stable without those 'That does not qualify as "completely broken"' bugs... and there was no performance problem. The "new routing engine" has brought us nothing useful, and the configuration is "more complicated" as well (no problem for the company network but not so good for the hobby network).

Instead of focusing on core routing functionality, we get ROSE...
And no, just because other developers may be working on ROSE does not mean that it doesn't affect routing. It does. Resources (human and money) are being spent on frivolous stuff instead of networking.

Instead of focusing on core routing functionality, we get ROSE...
And no, just because other developers may be working on ROSE does not mean that it doesn't affect routing. It does. Resources (human and money) are being spent on frivolous stuff instead of networking.

I doubt that's an accurate assessment of Mikrotik's state of affairs--to be fair, one can walk and chew gum at the same time. And given how bare-bones the capabilities of ROSE are vs. what's available out there, I seriously doubt they have devoted that many resources to it. Let's face it, the RDS2216 feels more like a "let's test the waters and see how the market reacts" effort more than anything else. It's essentially a CCR2216 with a less capable switch chip and less ports to lower costs, with md and smbd running in the background to do some basic storage stuff.

And at the risk of rubbing you the wrong way even further, for many of us, 7.x has proven to be vastly superior to 6.x in many ways. YMMV I guess.

*) dhcpv4/v6-client - added check-gateway parameter;

Indeed, discussed often. But IMHO these release topics are some variant of /dev/null. You can write until this topic gets locked for discussion. What a waste of words.

You probably do very basic stuff in v7 if you think that's vastly superior to v6.
The only actual feature worth using v7 for, is Wireguard.

If MikroTIk opened up real support, or paid support like other vendors -- this can help. Ubiqu*F* is now offering paid support..... also their release of v9 is very nice and forward progress. This all might be a precursor to them leaving the consumer market and focusing on pro/enterprise.

@MikroTik could you somehow update the wireguard sources? based on your GPL handed out ̶f̶o̶r̶ ̶7̶.̶1̶9̶r̶c̶ you're using code untouched from 5 years ago. more exactly it's stuck at this point: https://github.com/WireGuard/wireguard- ... 49e940b479
A fast look over the changes in those years I've found this: https://github.com/WireGuard/wireguard- ... c6214ccf7a
Among other changes it had in FIVE YEARS.
Shame.
That is, if you actually provided the recent sources, and not some old archive that you just hand out on request. That would be another can of worms.

*) route - added options to set dynamic-in and connected-in chains in /routing/settings;

/routing/settings/set <tab>
connected-in-chain     dynamic-in-chain     single-process   

UI and routing is like oil and water, they just don’t mix.

@MikroTik could you somehow update the wireguard sources?

Yes, it would really help to have RouterOS v7 use more recent wireguard sources - it would improve performance considerably.

Yes, it would really help to have RouterOS v7 use more recent wireguard sources - it would improve performance considerably.

Summary code

| Date       | Kernel | Summary
+------------+--------+------------------------------------------------------------
| 2021-02-14 | 5.11   | Lock-free p/p single-list queues with ~90% lower memory p/p,
|            |        | reduced CPU contention, latency and improved p/p scaling
| 2021-02-14 | 5.11   | Improved crypto support for ARM with/without NEON/SIMD and
|            |        | for x86 SSE2/SSSE3/AVX
| 2021-06-27 | 5.13   | Switched compiler flags from -O3 to -O2 for improved stability
| 2023-08-27 | 6.5    | CPU affinity fix for encryption threads. Faster round-robin
|            |        | across cores with better latency and load balance
| 2025-01-21 | 6.13   | Adding Big TCP (GSO) with ~15% throughput boost on TCP streams
| 2025 WIP   | 6.15   | GRO-based NIC offload similar to IPsec ESP hardware offload (beta)

To address this further:

It appears that if the router is already receiving routes from another router in the same AS, that it won't even count and list any of those same routes as received from a second router in that source AS (hence the "0" or "1"). The second router is most definitely advertising them. This isn't an iBGP issue as you can see that one of the peers with two routers is an eBGP peer.

I would think the receiving router should list all of them, even if it adds an "Fb" for filtered or just "b" for BGP.

Both BGP sessions terminate on the same local and remote router though, maybe it's only triggered when it receives routes from a different router with the same ASN? Or only after one of the links flap? I had an issue recently on v7.14.3 where after a link flapped about 20% of the routes were missing in the routing table even though they were being advertised by the peer.

The routes over L2TP/IPsec are set to local-pref 90 using filters.
Usually after boot the pref 90 routes appear in the table, all prefix counts are the same on the 4 tunnels at each branch, but after a route flap they often do not come back.
But unfortunately when the main internet connection that transports the GRE and GRE6 tunnel goes down, the backup is via L2TP and its routes are not installed in the table.

Have they not released the Chateau LTE12 (2025) with 32MB ?

Have You tested without the filters? May help to narrow down WHERE the problem is.

/routing filter rule
add chain=pref-90 comment="low pref for backup paths" disabled=no rule="set bgp-local-pref 90;"
add chain=pref-90 disabled=no rule="jump input;"

That isn't possible. The filters are required to force the routing over the fiber/vdsl connection instead of over 4G with limited bundle.
When that disturbs the BGP functioning there is a bug.

Weirdly enough I do not seem to have this issue. I have an RB4011 with an LHG60 and NB19 link to the same tower, each with their own BGP session (but same local/remote ASN) and prefix counts are identical for both sessions.

Both BGP sessions terminate on the same local and remote router though, maybe it's only triggered when it receives routes from a different router with the same ASN? Or only after one of the links flap? I had an issue recently on v7.14.3 where after a link flapped about 20% of the routes were missing in the routing table even though they were being advertised by the peer.

That isn't possible. The filters are required to force the routing over the fiber/vdsl connection instead of over 4G with limited bundle.
When that disturbs the BGP functioning there is a bug.

I use this exactly thing on my DN42 filters. Never noticed a problem, but then again it's a very particular one - and getting different number of routes from different peers is the expected behavior there.
I'll take a look here, with my setup. Maybe I'm affected and never noticed? Maybe I'm not affected, and we can run a differential to narrow it down?

EDIT: Although I don't use two connections from the same router... may be a factor too.

That isn't possible. The filters are required to force the routing over the fiber/vdsl connection instead of over 4G with limited bundle.
When that disturbs the BGP functioning there is a bug.

I use this exactly thing on my DN42 filters. Never noticed a problem, but then again it's a very particular one - and getting different number of routes from different peers is the expected behavior there.

Have they not released the Chateau LTE12 (2025) with 32MB ?

Yes, Mikrotik released a Chateau LTE12 (2025). https://mikrotik.com/product/chateau_lte12_2025
What do you want to tell me? I should replace my existing Chateau with the "2025 refresh"? This can only be a cost factor - but why should anyone buy Chateau LTE12 (2025) with legacy wireless (instead of Chateau LTE18 AX)? Or does this ship with wifi-qcom-ac already? But even then: it is 2025. Nobody should buy new devices with 802.11ac only. At least in Western Europe.

But the flash issue applies to my cap ac as well. There is no "cap ac (2025)" with 32MB flash right now. But my cap ac still has some "room" as it is acting as a dumb CAP.

Sometimes I think that it just won't store more than a certain number of routes to each destination, but I cannot find a consistent number for that. Sometimes it accepts 2, sometimes 3, but I need at least 4 but preferably 5.

 > /ipv6/route/print where dst-address=fd42:d42:d42:53::/64 
Flags: D - DYNAMIC; A - ACTIVE; b - BGP
Columns: DST-ADDRESS, GATEWAY, DISTANCE
    DST-ADDRESS           GATEWAY                 DISTANCE
DAb fd42:d42:d42:53::/64  fd86:bad:11b7:23::1           20
D b fd42:d42:d42:53::/64  fd22:ad17:8e8d:10::111        20
D b fd42:d42:d42:53::/64  fd22:ad17:8e8d:10::105        20
D b fd42:d42:d42:53::/64  fdb1:e72a:343d::9             20
D b fd42:d42:d42:53::/64  fd22:ad17:8e8d:10::11d        20

 > /ipv6/route/print where dst-address=fd42:d42:d42:54::/64  
Flags: D - DYNAMIC; A - ACTIVE; b - BGP
Columns: DST-ADDRESS, GATEWAY, DISTANCE
    DST-ADDRESS           GATEWAY                 DISTANCE
D b fd42:d42:d42:54::/64  fd86:bad:11b7:23::1           20
D b fd42:d42:d42:54::/64  fd22:ad17:8e8d:10::111        20
D b fd42:d42:d42:54::/64  fd22:ad17:8e8d:10::117        20
D b fd42:d42:d42:54::/64  fd22:ad17:8e8d:10::105        20
DAb fd42:d42:d42:54::/64  fdb1:e72a:343d::9             20
D b fd42:d42:d42:54::/64  fd22:ad17:8e8d:10::11d        20

Do you have a different local-pref on some of the routes?

Yes, Mikrotik released a Chateau LTE12 (2025). https://mikrotik.com/product/chateau_lte12_2025
What do you want to tell me? I should replace my existing Chateau with the "2025 refresh"? This can only be a cost factor - but why should anyone buy Chateau LTE12 (2025) with legacy wireless (instead of Chateau LTE18 AX)? Or does this ship with wifi-qcom-ac already? But even then: it is 2025. Nobody should buy new devices with 802.11ac only. At least in Western Europe.

But the flash issue applies to my cap ac as well. There is no "cap ac (2025)" with 32MB flash right now. But my cap ac still has some "room" as it is acting as a dumb CAP.

I think your flogging a dead horse is what I'm trying to say.
In other news, my WiFi problem with RC1 appears to be fixed in RC2.

Do you have a different local-pref on some of the routes?

local-pref, no. I use bgp-local-pref only.

bgp-local-pref is used in bgp filters to apply it to a route received via BGP, but once it ends up in the routing table it is called local-pref.

add chain=DN42PeerAmericaDoNorteLeste comment="Pega-tudo dos sem-regiao (14)" disabled=no rule="if (not bgp-communities any-list RegiaoOrigem) {set bgp-local-pref 500; jump DN42EntradaSanidade}"
add chain=DN42PeerAmericaDoNorteLeste comment="Am\E9rica do Norte Leste -> Pacifico (13)" disabled=no rule="if (bgp-communities any 64511:53) {set bgp-local-pref 5838; jump DN42EntradaSanidade}"
add chain=DN42PeerAmericaDoNorteLeste comment="Am\E9rica do Norte Leste -> Asia Sudeste (11)" disabled=no rule="if (bgp-communities any 64511:51) {set bgp-local-pref 6238; jump DN42EntradaSanidade}"
add chain=DN42PeerAmericaDoNorteLeste comment="Am\E9rica do Norte Leste -> Asia Leste (12)" disabled=no rule="if (bgp-communities any 64511:52) {set bgp-local-pref 6238; jump DN42EntradaSanidade}"
add chain=DN42PeerAmericaDoNorteLeste comment="Am\E9rica do Norte Leste -> Asia Sul (10)" disabled=no rule="if (bgp-communities any 64511:50) {set bgp-local-pref 6738; jump DN42EntradaSanidade}"
add chain=DN42PeerAmericaDoNorteLeste comment="Am\E9rica do Norte Leste -> Africa do Sul (09)" disabled=no rule="if (bgp-communities any 64511:49) {set bgp-local-pref 6863; jump DN42EntradaSanidade}"
add chain=DN42PeerAmericaDoNorteLeste comment="Am\E9rica do Norte Leste -> Africa do Norte (08)" disabled=no rule="if (bgp-communities any 64511:48) {set bgp-local-pref 7913; jump DN42EntradaSanidade}"
add chain=DN42PeerAmericaDoNorteLeste comment="Am\E9rica do Norte Leste -> Am\E9rica do Sul Oeste (07)" disabled=no rule="if (bgp-communities any 64511:47) {set bgp-local-pref 8288; jump DN42EntradaSanidade}"
add chain=DN42PeerAmericaDoNorteLeste comment="Am\E9rica do Norte Leste -> Europa (01)" disabled=no rule="if (bgp-communities any 64511:41) {set bgp-local-pref 8438; jump DN42EntradaSanidade}"
add chain=DN42PeerAmericaDoNorteLeste comment="Am\E9rica do Norte Leste -> Am\E9rica do Sul Leste (06)" disabled=no rule="if (bgp-communities any 64511:46) {set bgp-local-pref 8513; jump DN42EntradaSanidade}"
add chain=DN42PeerAmericaDoNorteLeste comment="Am\E9rica do Norte Leste -> Am\E9rica do Norte Oeste (05)" disabled=no rule="if (bgp-communities any 64511:44) {set bgp-local-pref 8988; jump DN42EntradaSanidade}"
add chain=DN42PeerAmericaDoNorteLeste comment="Am\E9rica do Norte Leste -> Am\E9rica Central" disabled=no rule="if (bgp-communities any 64511:45) {set bgp-local-pref 9263; jump DN42EntradaSanidade}"
add chain=DN42PeerAmericaDoNorteLeste comment="Am\E9rica do Norte Leste -> Am\E9rica do Norte Centro (04)" disabled=no rule="if (bgp-communities any 64511:43) {set bgp-local-pref 9488; jump DN42EntradaSanidade}"
add chain=DN42PeerAmericaDoNorteLeste comment="Am\E9rica do Norte Leste -> Am\E9rica do Norte Leste (02)" disabled=no rule="if (bgp-communities any 64511:42) {set bgp-local-pref 9988; jump DN42EntradaSanidade}"

Question about DNS Adlist.
I use a file for blocking addresses, that is created by a script. The script downloads data from several sources and removes repeated addresses. This file is then uploaded to the router and added to the blocking list.
Screenshot_Adlist.png or Screenshot_Adlist_noSSL.png


There are two problems with this:
1. after the router is rebooted, this file of data for blocking is not automatically read. you must manually perform an action to upload from the file.
2. an error line appears periodically. even though I don't have any line with http data download.
Screenshot_Error.png

7.x has proven to be vastly superior to 6.x in many ways.

Never said it was vastly superior

@MT
Minor issue (RB5009UPr+S+):

/interface/ethernet> monitor ether1 once
name: ether1
status: link-ok
auto-negotiation: done
rate: 2.5Gbps
full-duplex: yes
tx-flow-control: no
rx-flow-control: no
supported: 10M-baseT-half
10M-baseT-full
100M-baseT-half
100M-baseT-full
1G-baseT-half
1G-baseT-full
2.5G-baseT
advertising: 10M-baseT-half
10M-baseT-full
100M-baseT-half
100M-baseT-full
1G-baseT-half
1G-baseT-full
2.5G-baseT
link-partner-advertising: 10M-baseT-half
10M-baseT-full
100M-baseT-half
100M-baseT-full
1G-baseT-full
this line doesn't appear "2.5G-baseT"
with this connection 2.5Gbps

I dont know why the "Canvas" forum theme does not show the quote-author. The polsilver theme does it correctly. I always found this so confusing not knowing who is quoted actually. Can Mikrotik forum admins fix this?

2025-05-09_10-12.png

2025-05-09_10-13.png

7.x has proven to be vastly superior to 6.x in many ways.

Never said it was vastly superior

🤦‍♂️

I said it was vastly superior *for many of us*, *in many ways* and I made it clear *ymmv*, multiple times. You shortened my quote, italicized vastly, and purposely took my words out of context to make it sound I was making a generic/universal statement, which was not the intent. I even provided examples as to why it was better from my standpoint.

But hey, I’ll restate what I wrote to keep all the closeted keyboard warriors on this forum happy => 7.x may not be for everyone, but it proved to be vastly superior for many of us. Again, ymmv. And if you don’t like it, 6.49 is still kicking and alive, and on LTS.

And no, you cannot use v6. I guess you haven't bought a MikroTik product since the first CCR2004, for which you could apparently accept a downgrade in functionality (ie v7) for it to just work without crashing every two minutes. In that sense if you squint your eyes enough, v7 maybe superior to some hurt wallets, yes.

And no, you cannot use v6. I guess you haven't bought a MikroTik product since the first CCR2004

I guess you haven't bought a MikroTik product since the first CCR2004

hAP ax2 and ax3 - everything seems fine (wifi).

Using CAPsMAN?

Wireless seems to be broken is this version, CAP ax and WAP ax with RB5009 running CAPsMAN.

Some devices refuse to connect at all, some connect for 30 mins then disconnect and refuse to connect again. 5Ghz seems to stop for no reason and reboot AP's fix issues for a short period.

Intel(R) Wi-Fi 6 AX201 160MHz really struggle

Anyone else having issues with this version and wireless, no noticeable issue with 7.16.2