v7.18beta [testing] is released!

jbl42 · Wed Jan 29, 2025 4:07 pm

We actually don't know what kind of "abuse by vendor" can come out of this device-mode can of worms. They can even force the override of user-defined settings of device-mode on every subsequent upgrade - if they want to get rid of more customers...

The whole auto-enabled device mode is a misguided attempt to fight things like several past issues with poorly configured ROS devices turned into bot-nets and used for DOS attacks.
While main reason for this to happen is a good part of MTs target market lacks skills, resources and sometimes attitude to properly configure internet exposed devices.

Now some folks will avoid updating to >=7.17 because they understandably want to avoid risking to lock up remote devices in a way requiring someone to travel to the site. And maybe even climb up a pole. Leading to ROS devices running intentionally on outdated versions.
And if someone figures out a pattern to trigger the obscure "flagged" mode, there will be an easy way to DOS Mikrotik devices.

Device mode might have it's applications, but force-enabling it on remote SW updates for existing productions devices is a more than questionable idea.
It's a classic example of "we need to do something so we do something allowing us to claim we did something".

infabo · Wed Jan 29, 2025 4:44 pm

Why is device-mode even being discussed in this 7.18beta topic? As far as I can see, there hasn’t been a single changelog item related to device-mode in 7.18. It would make more sense to discuss this in the 7.17 thread or in a dedicated topic.

A separate, well-focused discussion with significant attention and engagement is likely to catch MikroTik’s attention more effectively than scattered comments within release threads. The discussions during the 7.17 beta were productive and positive, and the community feedback helped refine the most problematic aspects of the initial device-mode implementation.

buset1974 · Wed Jan 29, 2025 5:24 pm

anyone has successfully experience implement MPLS-VPN6 (6vpe) on v7?
is it works?

thx

jbl42 · Wed Jan 29, 2025 7:04 pm

Why is device-mode even being discussed in this 7.18beta topic? As far as I can see, there hasn’t been a single changelog item related to device-mode in 7.18. It would make more sense to discuss this in the 7.17 thread or in a dedicated topic.

A separate, well-focused discussion with significant attention and engagement is likely to catch MikroTik’s attention more effectively than scattered comments within release threads. The discussions during the 7.17 beta were productive and positive, and the community feedback helped refine the most problematic aspects of the initial device-mode implementation.

Pretty obvious
A) Devicemode shows up if updating lab devices from <=7.16 to 7.18beta for testing, so its natural such observations end up here
B) We still hope MT reconsiders this for 7.18 so we can update our devices to 7.18 once released without risking to get locked out and drive a few hours

pe1chl · Wed Jan 29, 2025 7:35 pm

I am still hoping for a solution where defconf for the firewall can be applied to an existing router... some command that removes the firewall config and reloads it from defconf, if only as a commandline script.
So far none of changes in firewall defconf was ever applied when upgrading ROS. So I don't see this one coming either.

To be clear: I am NOT suggesting that defconf be applied when upgrading RouterOS.
What I am suggesting is that there should be a command that the admin can issue and that resets the firewall settings to the defconf for the currently running version of RouterOS.
Entirely by their own request. Not automatic, and maybe after a confirmation similar to what you get when doing reset-configuration.
Except it will reset only the firewall.

Larsa · Wed Jan 29, 2025 7:43 pm

I think it’s a pretty good idea for a lot of reasons.

Amm0 · Wed Jan 29, 2025 8:16 pm

To be clear: I am NOT suggesting that defconf be applied when upgrading RouterOS. [...] Entirely by their own request. [...]
Except it will reset only the firewall.

I think it’s a pretty good idea for a lot of reasons.

+1 - I love the idea. I feel like the default firewall keeps improving, so it be good to re-refresh just that. Perhaps even on device without a default configuration to add a "standard" one - MANUALLY.

Also help with branding/netinstall custom defconfs... since a firewall should be included, it actually be better to be able to do some "/ip/firewall/reset-to-default", instead of adding the default by copy-and-paste to custom defconf.

armandfumal · Wed Jan 29, 2025 9:38 pm

since 7.16 I cannot use skin designer, profile is created on disk but not present in other parts...
Is it a way to use it ?
do I miss something ?

teslasystems · Wed Jan 29, 2025 11:26 pm

What I am suggesting is that there should be a command that the admin can issue and that resets the firewall settings to the defconf for the currently running version of RouterOS.

+1 I'm also supporting this great idea.

fischerdouglas · Wed Jan 29, 2025 11:41 pm

anyone has successfully experience implement MPLS-VPN6 (6vpe) on v7?
is it works?

thx

After testing on almost every version since "I don't even remember".
After spending a lot and a lot of time.
After having results like "It seems to work... Ooow, wait...hummm dammit"

Frequently the issues ar in the iBGP keeping NLRI and recursive next-hop.

I didn't have the strength to do this test 7.18beta2 so far.

I have a virtual Lab running on 7.17, during this week I'm intended to upgrade to test it.

clambert · Thu Jan 30, 2025 7:09 am

anyone has successfully experience implement MPLS-VPN6 (6vpe) on v7?
is it works?

thx

We are interested in using it, but the current state of implementation is useless to us because it does not support operation on an IPv4 backbone.

bajodel · Thu Jan 30, 2025 7:44 am

..[cut]..
The suggestion I am making may seem very disruptive, but it is actually a development trend and not an innovation.
Basically, the idea is that all RouteOS features expose the possibility of sending the events of these features to a hook manager.
And from this hook manager, scripts can be invoked so that the user can do what he needs to do.
..[cut]..

I love it! I hope MT guys do the same ;)

oreggin · Thu Jan 30, 2025 9:56 am

anyone has successfully experience implement MPLS-VPN6 (6vpe) on v7?
is it works?

thx

It worked for me over IPv6 till 7.16.x.
In 7.17 and 7.18 there is a bug, which destroys almost all of the IPv4 RIB, DHCP default route is disappearing, so I disabled VPNv6 everywhere because it made almost all of our remote CPEs unreachable. I built a test setup for MT support and waiting them to investigate.

fischerdouglas · Thu Jan 30, 2025 6:00 pm

anyone has successfully experience implement MPLS-VPN6 (6vpe) on v7?
is it works?

thx
We are interested in using it, but the current state of implementation is useless to us because it does not support operation on an IPv4 backbone.

You mean 6PE and 6VPE, right?
Same here!

In my opinion, it is related to the long absence of VRF as it is now. With its own loopback allowing leaks across VRFs, and etc...
This exposure of real loopbacks is pretty recent, right? 7.14?

oreggin · Thu Jan 30, 2025 6:10 pm

You mean 6PE and 6VPE, right?

IIRC 6PE is not supported yet, only 6VPE over IPv6. VPNv6 routes exchanging over IPv4 BGP session too, but the nexthop encoding is incorrect and/or IPv6 route over IPv4 nexthop is not supported.

diamuxin · Thu Jan 30, 2025 9:16 pm

Hi,

What is the position of Fasttrack rules in the IPv6 firewall?

/ipv6 firewall filter
add action=fasttrack-connection chain=forward comment="Enable FastTracked v6 traffic" connection-state=established,related
add action=accept chain=forward comment="accept established,related,untracked" connection-state=established,related,untracked

pe1chl · Thu Jan 30, 2025 9:37 pm

You can display the defconf using: /system/default-configuration/print

diamuxin · Thu Jan 30, 2025 10:11 pm

You can display the defconf using: /system/default-configuration/print

The fasttrack rule does not exist in the default configuration (you have to create it), it is not clear to me in which position it should go.

/ipv6 firewall {                                                                                                                          >
                       address-list add list=bad_ipv6 address=::/128 comment="defconf: unspecified address"                                                    >
                       address-list add list=bad_ipv6 address=::1 comment="defconf: lo"                                                                        >
                       address-list add list=bad_ipv6 address=fec0::/10 comment="defconf: site-local"                                                          >
                       address-list add list=bad_ipv6 address=::ffff:0:0/96 comment="defconf: ipv4-mapped"                                                     >
                       address-list add list=bad_ipv6 address=::/96 comment="defconf: ipv4 compat"                                                             >
                       address-list add list=bad_ipv6 address=100::/64 comment="defconf: discard only "                                                        >
                       address-list add list=bad_ipv6 address=2001:db8::/32 comment="defconf: documentation"                                                   >
                       address-list add list=bad_ipv6 address=2001:10::/28 comment="defconf: ORCHID"                                                           >
                       address-list add list=bad_ipv6 address=3ffe::/16 comment="defconf: 6bone"                                                               >
                       filter add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untrack>
                       filter add chain=input action=drop connection-state=invalid comment="defconf: drop invalid"                                             >
                       filter add chain=input action=accept protocol=icmpv6 comment="defconf: accept ICMPv6"                                                   >
                       filter add chain=input action=accept protocol=udp dst-port=33434-33534 comment="defconf: accept UDP traceroute"                         >
                       filter add chain=input action=accept protocol=udp dst-port=546 src-address=fe80::/10 comment="defconf: accept DHCPv6-Client prefix deleg>
                       filter add chain=input action=accept protocol=udp dst-port=500,4500 comment="defconf: accept IKE"                                       >
                       filter add chain=input action=accept protocol=ipsec-ah comment="defconf: accept ipsec AH"                                               >
                       filter add chain=input action=accept protocol=ipsec-esp comment="defconf: accept ipsec ESP"                                             >
                       filter add chain=input action=accept ipsec-policy=in,ipsec comment="defconf: accept all that matches ipsec policy"                      >
                       filter add chain=input action=drop in-interface-list=!LAN comment="defconf: drop everything else not coming from LAN"                   >
                       filter add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untra>
                       filter add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"                                           >
                       filter add chain=forward action=drop src-address-list=bad_ipv6 comment="defconf: drop packets with bad src ipv6"                        >
                       filter add chain=forward action=drop dst-address-list=bad_ipv6 comment="defconf: drop packets with bad dst ipv6"                        >
                       filter add chain=forward action=drop protocol=icmpv6 hop-limit=equal:1 comment="defconf: rfc4890 drop hop-limit=1"                      >
                       filter add chain=forward action=accept protocol=icmpv6 comment="defconf: accept ICMPv6"                                                 >
                       filter add chain=forward action=accept protocol=139 comment="defconf: accept HIP"                                                       >
                       filter add chain=forward action=accept protocol=udp dst-port=500,4500 comment="defconf: accept IKE"                                     >
                       filter add chain=forward action=accept protocol=ipsec-ah comment="defconf: accept ipsec AH"                                             >
                       filter add chain=forward action=accept protocol=ipsec-esp comment="defconf: accept ipsec ESP"                                           >
                       filter add chain=forward action=accept ipsec-policy=in,ipsec comment="defconf: accept all that matches ipsec policy"                    >
                       filter add chain=forward action=drop in-interface-list=!LAN comment="defconf: drop everything else not coming from LAN"                 >
                     }

pe1chl · Thu Jan 30, 2025 10:19 pm

You can compare the ipv4 firewall....

fischerdouglas · Fri Jan 31, 2025 12:19 am

You mean 6PE and 6VPE, right?
IIRC 6PE is not supported yet, only 6VPE over IPv6. VPNv6 routes exchanging over IPv4 BGP session too, but the nexthop encoding is incorrect and/or IPv6 route over IPv4 nexthop is not supported.

But the next hop for real is (or should be) the RT and the associated Label.
If you sniff the BGP messages on the route exchange, it is correct.

I believe the problem is actually on VRF and RT+Label, and on VRF(RT) Lookups.

Are you using the per-vrf label allocation?
/routing bgp vpn add label-allocation-policy=per-vrf

oreggin · Fri Jan 31, 2025 7:17 am

IIRC 6PE is not supported yet, only 6VPE over IPv6. VPNv6 routes exchanging over IPv4 BGP session too, but the nexthop encoding is incorrect and/or IPv6 route over IPv4 nexthop is not supported.
But the next hop for real is (or should be) the RT and the associated Label.
If you sniff the BGP messages on the route exchange, it is correct.

I believe the problem is actually on VRF and RT+Label, and on VRF(RT) Lookups.

Are you using the per-vrf label allocation?
/routing bgp vpn add label-allocation-policy=per-vrf

I have an LxVPN lab with RoS7 too, and it has two VRFs, one of is using per-vrf, another is per-prefix to testing both. When I digged into it deeper some months ago, IIRC mrz from MT said on this forum that, its because of lack of support of "IPv6 route over IPv4 nexthop". Only "IPv4 route over IPv6 nextop" is supported in kernel, which they selected for RoS7. Similar issue is exists in FFRouting but there the nexthop encoding is incorrect: https://github.com/FRRouting/frr/issues/4661

That should be seen, IPv6 route over IPv4, what is cisco and others do, is a hack, a necessary evil.

Fortunately we have IOS-XR boxes which is the only cisco OS that supports VPNv6 over IPv6 and it can forward VPNv6 traffic between IPv6 MT CPEs and VPNv6 over IPv4 backbone. Now the ball is on MT's side to fix the issues around VPNv6.

pi0 · Fri Jan 31, 2025 10:57 am

First of all, amazing release! L3HW and IPv6 FastTrack were much needed and worked well on my RB5009, achieving 4Gb WAN speed.

However, I have a strange issue. Has anyone else experienced new ND issues? Apple devices randomly lose IPv6 connectivity, and LAN devices receive adversed IPv6 addresses from all VLANs. Everything was fine until the latest 7.17 update and broke in 7.18-beta

pe1chl · Fri Jan 31, 2025 12:27 pm

The "LAN devices receive adversed IPv6 addresses from all VLANs" is that referring to Windows devices that are on ports with tagged VLANs present?
As that is a Windows bug, has nothing to do with RouterOS.

mkx · Fri Jan 31, 2025 2:22 pm

You can display the defconf using: /system/default-configuration/print
The fasttrack rule does not exist in the default configuration (you have to create it), it is not clear to me in which position it should go.

If you follow advice by @pe1chl, you'll place it as the very first rule in chain=forward, above this rule:

filter add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"

BTW, when you listed default config, your terminal windows wasn't wide enough, some rules were clipped on the right side (the above written one as well).

diamuxin · Fri Jan 31, 2025 4:36 pm

The fasttrack rule does not exist in the default configuration (you have to create it), it is not clear to me in which position it should go.
If you follow advice by @pe1chl, you'll place it as the very first rule in chain=forward, above this rule:
Code: Select all
filter add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
BTW, when you listed default config, your terminal windows wasn't wide enough, some rules were clipped on the right side (the above written one as well).

Ok, thanks!

pe1chl · Fri Jan 31, 2025 4:37 pm

BTW, when you listed default config, your terminal windows wasn't wide enough, some rules were clipped on the right side (the above written one as well).

Well, an irritating problem in printing default-configuration is that it does not wrap the lines and the lines are very long.
So you need to print with arg file=outputfile and then download the outputfile.txt to have a complete default-configuration.

Even then I first thought that the fasttrack rule for ipv6 was already there, but it seems it is not, that still has to happen.
But it is there for ip (v4) so that can be used as a guide.

Fri Jan 31, 2025 6:09 pm

What's new in 7.18beta4 (2025-Jan-31 15:46):

*) bridge - fixed endless MAC update loop (introduced in v7.17);
*) chr/x86 - fixed error message on bootup;
*) cloud - added file-share feature (additional fixes);
*) console - added dsv.remap to :serialize command to unpack array of maps from print as-value (additional fixes);
*) defconf - added IPv6 FastTrack configuration;
*) dhcpv4-server - fixed framed-route removal;
*) dhcpv4-server - fixed lease assigning when server address is not bind to server interface (introduced in v7.17);
*) fetch - fixed IPv6 handling in URL (introduced in v7.18beta2);
*) file - improved handling of filesystems with many files (additional fixes);
*) hotspot - fixed an issue where extra "flash/" is added to html-directory for devices with flash folders (introduced in v7.17);
*) igmp-proxy - fixed multicast routing after upstream interface flaps (introduced in v7.17);
*) ipsec - fixed chacha20 poly1305 proposal;
*) ipv6 - added routing FastPath support (enabled by default) (additional fixes);
*) ipv6 - fixed configuration loss due to conflicting settings after upgrade (introduced in v7.17);
*) l3hw - added initial HW offloading for VXLAN on compatible switches (additional fixes);
*) log - added CEF format support for remote logging (additional fixes);
*) lte - added basic support for Quectel RG255C-GL modem in "at+qcfg="usbnet",0" USB composition;
*) lte - added initial eSIM management support (CLI only) (additional fixes);
*) lte - reduced SIM slot switchover time for modems with AT control channel;
*) net - added initial support for automatic multicast tunneling (AMT) interface (additional fixes);
*) ovpn - added requirement for server name when exporting configuration;
*) poe-out - fixed invalid poe-in status detection for RB5009 (introduced in v7.18beta2);
*) port - improved handling of USB device plug/unplug events;
*) ppc - fixed HW encryption (introduced in v7.17);
*) queue - improved system stability when many simple queues are added (introduced in v7.17);
*) resolver - fixed static FQDN resolving (introduced in v7.17);
*) routerboot - improved stability for IPQ8072 ("/system routerboard upgrade" required);
*) smb - fixed connection issues with clients using older SMB versions (introduced in v7.17);
*) supout - added IPv6 settings section;
*) switch - improvements to certain switch operations (port disable, shaper and switch initialization) (additional fixes);
*) vxlan - added IPv6 FastPath support;
*) vxlan - fixed unset for "group" and "interface" properties;
*) vxlan - replaced the "inherit" with "auto" option for dont-fragment property (new default);
*) wifi-qcom - fixed potentially lowered throughput for station interfaces if channel.width property is set (introduced in v7.18beta2);
*) winbox - fixed locked input fields when creating new certificate template;
*) winbox - show warning messages for static DNS entries;
*) x86 - fixed "unsupported speed" warning (additional fixes);

pe1chl · Fri Jan 31, 2025 6:54 pm

Settings for neighbor discover LLDP are lost on upgrade to 7.18beta2.
E.g.:

/ip neighbor discovery-settings
set discover-interface-list=discover lldp-mac-phy-config=yes \
    lldp-med-net-policy-vlan=16

After upgrade they can be re-applied and still work.

Jotne · Fri Jan 31, 2025 7:03 pm

There are some minor change in the CEF logs:

7.18beta4

2025-01-31T17:53:06.615+0100 hAP-test CEF:0|MikroTik|hAP ac^2|7.18beta4 (testing)|10|system,info|Low|dvchost=hAP-test dvc=10.10.10.14 msg=

7.18beta2

2025-01-31T17:50:00.133+0100 RB951 CEF:0|MikroTik|RB951Ui-2HnD|7.18beta2 (testing)|65|dns|Unknown|msg=

beta4 do have two new fields. dvchost and dvc. As I can see the dvc-host is are already present after the clock, so no need stuff two times.
For Splunk using key=value helps for auto extraction.

What does the number 10 and 65 mean?

pe1chl · Fri Jan 31, 2025 7:09 pm

The number after the version string is the "deviceEventClassId" which is supposed to be a unique ID of each message.
However, the numbers 10 and 65 are probably not that, it looks like this is still to be implemented...

Amm0 · Fri Jan 31, 2025 7:29 pm

Maybe there just re-using topic id/hash for now, IDK. There are 104 topics FWIW.

@normis was hopeful earlier:

More CEF features are in development for the next betas

But some unique "log id" has long been missing... so hope that is part is included.

buset1974 · Fri Jan 31, 2025 7:50 pm

You mean 6PE and 6VPE, right?
IIRC 6PE is not supported yet, only 6VPE over IPv6. VPNv6 routes exchanging over IPv4 BGP session too, but the nexthop encoding is incorrect and/or IPv6 route over IPv4 nexthop is not supported.

i dont see any vpnv6 and send-label parameters available in bgp.
so i think 6VPE and 6PE cannot run on MT v6 & v7

so MT when will you implement 6VPE and 6PE ?

thx

pe1chl · Fri Jan 31, 2025 7:52 pm

Calm down! Let them debug and finish BASIC FUNCTIONALITY in BGP before starting such things...

Jotne · Fri Jan 31, 2025 7:59 pm

The number after the version string is the "deviceEventClassId" which is supposed to be a unique ID of each message.
However, the numbers 10 and 65 are probably not that, it looks like this is still to be implemented...

Ok that would be nice for long message that may be splitt to multiple messages.

irghost · Fri Jan 31, 2025 8:19 pm

I encountered an issue while testing VPNv6 in a CE-PE scenario.
Issue Details:

I configured fc00:101::1/126 on ether1 (PE router), which belongs to vrf-CE1.
After adding this IPv6 prefix, /ipv6/route/ hangs, and the connected route for fc00:101::/126 does not appear in /ipv6/route/ under vrf-CE1 table.
The CE router is unable to ping fc00:101::1.
Running the export command results in the error:

    #error exporting '/ipv6/route' (timeout)

CPU usage spikes significantly.
All router IDs under /routing/id become invalid.

Workaround:

Changing the prefix length from /126 to /64 resolves the issue.

It appears that MikroTik RouterOS struggles with certain IPv6 subnet sizes in a VRF environment. Could you confirm if this is a known issue, and if there's any fix or workaround available?

Thank you.

CTassisF · Fri Jan 31, 2025 8:44 pm

/file/print is still very buggy in beta4 when there are lots of files and/or multiple disks:

[cesar@RB5009] > /file/print 
 # NAME     TYPE       SIZE LAST-MODIFIED
 0 hotspot  directory       2025-01-31 14:08:36
invalid request
[cesar@RB5009] >

Also, I wish RouterOS would return to <= v7.17 behavior when files in container store were hidden.

pe1chl · Fri Jan 31, 2025 9:05 pm

The number after the version string is the "deviceEventClassId" which is supposed to be a unique ID of each message.
However, the numbers 10 and 65 are probably not that, it looks like this is still to be implemented...
Ok that would be nice for long message that may be splitt to multiple messages.

It is not to identify the individual message instances, like a sequence number, but to identify each different message that is issued under the same topic. E.g under "dhcp info" there may be a "dhcp de-assigned IP for MAC" and a "dhcp assigned IP for MAC" and these two would have a different ID. But all the "dhcp de-assigned IP for MAC" (for different IP and MAC, at different times) would have the same ID.

About multiple messages: there are cases where messages are needlessly split into many multiples. It mainly happens with debug messages. E.g. enabling "ipsec" messages results in a seamlessly endless output of messages each with a single variable or parameter. That makes it difficult to use, especially because the relation to something like a peer IP address is completely lost.
More of the small parts should be put in a single message that starts with a meaningful heading that includes session identifying information like a peer IP.

irghost · Fri Jan 31, 2025 9:56 pm

mikrotik does not Support BGP VPNv6 over IPv4 MPLS LDP transport?

[admin@PE2] >  /routing/route/print where afi=vpn6
Flags: U - UNREACHABLE; b - BGP
Columns: DST-ADDRESS, GATEWAY, AFI, DISTANCE, SCOPE, TARGET-SCOPE
   DST-ADDRESS              GATEWAY          AFI   DISTANCE  SCOPE  TARGET-SCOPE
Ub 2001:db8::/48&65000:105  ::ffff:10.0.0.1  vpn6       200     40            30
Ub fc00:101::/64&65000:100  ::ffff:10.0.0.1  vpn6       200     40            30
Ub fc00:101::/64&65000:101  ::ffff:10.0.0.1  vpn6       200     40            30

fischerdouglas · Sat Feb 01, 2025 12:09 am

Changing the prefix length from /126 to /64 resolves the issue.

It appears that MikroTik RouterOS struggles with certain IPv6 subnet sizes in a VRF environment. Could you confirm if this is a known issue, and if there's any fix or workaround available?

Did you reproduce this issue on a hardware-based scenario (device with switchchip) or on a virtual machine?

The reason for the question is because that characteristic looks like some very old issues on some experienced hardware-based vendors related to binary threes, longest prefix match, and TCAM limited resources.
On docs of HW offload of MikroTik I remember something like "more specific are preferred to go to off-load".
A possibility issue could be that:
- IPv6 smaller than /64 route + Route Target marker fits on tuple limit of TCAM on switch chip.
- but IPv6 longer than /64 when added the Route Target marker exceeds the tuple limit.

If this is in a software-based scenario... This probably doesn't apply.

P.S.: When I was writing this, I felt in 2008 and dealing IPv6 firmware upgrades of some Cisco routers.

fischerdouglas · Sat Feb 01, 2025 12:19 am

Also, I wish RouterOS would return to <= v7.17 behavior when files in container store were hidden.

Would a type of permission per user-group like:
"allow-to-read-files-inside-containers=[yes|no]"
not be enough to solve your need?

Note: This is just a suggested alternative in case hiding the internal files again is impossible.

CTassisF · Sat Feb 01, 2025 12:54 am

Would a type of permission per user-group like:
"allow-to-read-files-inside-containers=[yes|no]"
not be enough to solve your need?

Note: This is just a suggested alternative in case hiding the internal files again is impossible.

I don't think there needs to be a permission for that.

It could be a flag in /file/print (like /file/print show-container-store=yes) or a permanent setting in /file/settings (which does not exist right now).

irghost · Sat Feb 01, 2025 1:08 am

Changing the prefix length from /126 to /64 resolves the issue.

It appears that MikroTik RouterOS struggles with certain IPv6 subnet sizes in a VRF environment. Could you confirm if this is a known issue, and if there's any fix or workaround available?
Did you reproduce this issue on a hardware-based scenario (device with switchchip) or on a virtual machine?

The reason for the question is because that characteristic looks like some very old issues on some experienced hardware-based vendors related to binary threes, longest prefix match, and TCAM limited resources.
On docs of HW offload of MikroTik I remember something like "more specific are preferred to go to off-load".
A possibility issue could be that:
- IPv6 smaller than /64 route + Route Target marker fits on tuple limit of TCAM on switch chip.
- but IPv6 longer than /64 when added the Route Target marker exceeds the tuple limit.

If this is in a software-based scenario... This probably doesn't apply.

P.S.: When I was writing this, I felt in 2008 and dealing IPv6 firmware upgrades of some Cisco routers.

I tested this in a virtualized environment using EVE-NG, so hardware offload and TCAM limitations should not apply in this case. Since the issue occurs in a purely software-based scenario, it seems more likely to be a RouterOS bug rather than a hardware limitation.

teslasystems · Sat Feb 01, 2025 4:31 am

/file/print is still very buggy in beta4 when there are lots of files and/or multiple disks:

This will never change, if they won't revise their file management mechanism.
What if you have 100K files on SMB share for example? After adding a disk, it will start to scan a WHOLE structure and create a huge load on your network for a very long time. And if you reboot, this process will begin again.

There should be completely new mechanism. In WinBox there should be a file manager with abiliy to browse between folders without scanning a whole file structure. Same in CLI, if you issue /file print command, it should only show a content in a root directory (or another directory if you specify it in "where").

Without this, working with large amount of files is impossible.

clambert · Sat Feb 01, 2025 7:07 am

mikrotik does not Support BGP VPNv6 over IPv4 MPLS LDP transport?

Unfortunately not yet.

oreggin · Sat Feb 01, 2025 8:38 am

mikrotik does not Support BGP VPNv6 over IPv4 MPLS LDP transport?

[admin@PE2] >  /routing/route/print where afi=vpn6
Flags: U - UNREACHABLE; b - BGP
Columns: DST-ADDRESS, GATEWAY, AFI, DISTANCE, SCOPE, TARGET-SCOPE
   DST-ADDRESS              GATEWAY          AFI   DISTANCE  SCOPE  TARGET-SCOPE
Ub 2001:db8::/48&65000:105  ::ffff:10.0.0.1  vpn6       200     40            30
Ub fc00:101::/64&65000:100  ::ffff:10.0.0.1  vpn6       200     40            30
Ub fc00:101::/64&65000:101  ::ffff:10.0.0.1  vpn6       200     40            30

Pls read the forum, not just posting.
viewtopic.php?p=1122915#p1122915

buset1974 · Sat Feb 01, 2025 10:39 am

well, i double check again, MT hide vpn6 option from winbox, it can be set using cli.

thx

Jotne · Sat Feb 01, 2025 11:35 am

Would it be possible to add serial to the CEF logs? I do it by adding prefix to all logs. This works but has to be added manually to each rule.
So instead of this:

2025-02-01T09:49:13.642+0100 hAP-test CEF:0|MikroTik|hAP ac^2|7.18beta4 (testing)|65|dns|Unknown|dvchost=hAP-test dvc=192.168.10.14 msg=serial\=BEED0B3AAAAA MikroTik: done query: #21 upgrade.mikrotik.com 159.148.147.251

To some like this (dvchost also removed since its already in start of the logs

2025-02-01T09:49:13.642+0100 hAP-test CEF:0|MikroTik|hAP ac^2|7.18beta4 (testing)|BEED0B3AAAAA|65|dns|Unknown|dvc=192.168.10.14 msg=done query: #21 upgrade.mikrotik.com 159.148.147.251

This way I do not need the prefix at all. We need serial number in the Splunk logs to make sure its a unique unit. You may at some time change your main router to another model keeping the name. This will mess stuff up since its not the same router any more.

Since not all MikroTik do has serial, I did just made the script so it sets a random number. This may be handled better by MikroTik to give it an unique ID.

:do {
	:set serial ([/system routerboard get serial-number])
} on-error={
	:set serial ([:rndstr from=ABCDEF0123456 length=12])
}

pe1chl · Sat Feb 01, 2025 12:01 pm

When you have a special need to have a serial number in messages, why don't you add it to the device identity of your devices?
So instead of hAP-test you call it hAP-test-E1548DC8753B

rextended · Sat Feb 01, 2025 12:48 pm

@Jotne
if board-name ~ "x86" use [/system license get software-id]
if board-name ~ "CHR" use [/system license get system-id]
on other cases use [/system routerboard get serial-number]

or simply: [/int eth get ([find]->0) orig-mac-address] since at least all RouterBOARD have one ethernet interface...

rextended · Sat Feb 01, 2025 12:50 pm

When you have a special need to have a serial number in messages, why don't you add it to the device identity of your devices?
So instead of hAP-test you call it hAP-test-E1548DC8753B

Exactly, is wrong call all the devices "hAP ac^2".
Every single device on my network have different names.
When I replace the device, the new still have the same name, so, not worry about serials....

pi0 · Sat Feb 01, 2025 1:14 pm

The "LAN devices receive advertised IPv6 addresses from all VLANs" is that referring to Windows devices that are on ports with tagged VLANs present.
As that is a Windows bug, has nothing to do with RouterOS.

Thanks for the reply. The issue is not with Windows I have it with both Linux containers and Raspberypi directly connected to the router + other devices showing strange beahvior.

My setup looks something like this:

Router (RB5009) <==(tagged)==> CRS309 <==(untagged)==> Lan ports, Wifi AP, IoT AP, VMs (KVM connected to intel SFP+)
Router (RB5009) <==(untagged with PVID)==> raspberry pi

* VLAN filtering is enabled on both router and switch with vlan-tagged only admission + ingress filter and IGMP snooping on both bridges and both devices on the latest 7.18-beta4

It seems RA is somehow STILL leaking between VLANs. I can see leaked in Linux dev (that is connected via untagged access port, it is only supposed to get :3: one):

inet6 2a02:***:3:**/128 scope global dynamic noprefixroute
inet6 2a02:***:3:**/64 scope global dynamic noprefixroute
inet6 2a02:***:1:**/64 scope global deprecated dynamic noprefixroute
inet6 2a02:***:0:**/64 scope global deprecated dynamic noprefixroute
inet6 2a02:***:2:**/64 scope global deprecated dynamic noprefixroute

(the prefixes are assigned from a /48 pool each for a VLAN. routeros assigned 0,1,2,3)

Apple devices seem to behave strangely. They randomly activate ipv6 or not and sometimes lose it shortly (I guess because wrong packets are still being leaked.

(it might not be exactly related to this beta release but only reporting here as just having this issue. if it is more appropriate to make a new discussion I can do)

mkx · Sat Feb 01, 2025 1:20 pm

... IGMP snooping on both bridges and both devices on the latest 7.18-beta4

RAs are multicast ... so IGMP snooping might be playing foul game here. Try to disable it to see if that's the case.

pe1chl · Sat Feb 01, 2025 1:33 pm

it certainly is related to the configuration as I have a similar network (IPv6 with different /64 on tagged VLANs) running without issue.
so make a new topic including /export of bridge and ipv6.

Jotne · Sat Feb 01, 2025 3:52 pm

Every single device on my network have different names.
When I replace the device, the new still have the same name, so, not worry about serials....

If you for example handles a big customer, he uses the city name as the router name.
Then at a time later you add another customer with the same naming idea. Serial number will be unique all time.
Not this happens often, but I have seen it in my life ;)

Jotne · Sat Feb 01, 2025 3:53 pm

@Jotne
if board-name ~ "x86" use [/system license get software-id]
if board-name ~ "CHR" use [/system license get system-id]
on other cases use [/system routerboard get serial-number]

or simply: [/int eth get ([find]->0) orig-mac-address] since at least all RouterBOARD have one ethernet interface...

Thanks for the tip, will look inn to it :)

buset1974 · Sat Feb 01, 2025 4:03 pm

mikrotik does not Support BGP VPNv6 over IPv4 MPLS LDP transport?

[admin@PE2] >  /routing/route/print where afi=vpn6
Flags: U - UNREACHABLE; b - BGP
Columns: DST-ADDRESS, GATEWAY, AFI, DISTANCE, SCOPE, TARGET-SCOPE
   DST-ADDRESS              GATEWAY          AFI   DISTANCE  SCOPE  TARGET-SCOPE
Ub 2001:db8::/48&65000:105  ::ffff:10.0.0.1  vpn6       200     40            30
Ub fc00:101::/64&65000:100  ::ffff:10.0.0.1  vpn6       200     40            30
Ub fc00:101::/64&65000:101  ::ffff:10.0.0.1  vpn6       200     40            30

Pls read the forum, not just posting.
viewtopic.php?p=1122915#p1122915

Hi oreggin,

you're right that 6vpe silently/partially supported at least until v7.16.2, but i still have problems below.
i got this error on P which also act as RR

[admin@P-01] > /routing/route/print where bgp afi=vpn6
Flags: U - UNREACHABLE; b - BGP; H - HW-OFFLOADED
Columns: DST-ADDRESS, GATEWAY, AFI, DISTANCE, SCOPE, TARGET-SCOPE
DST-ADDRESS GATEWAY AFI DISTANCE SCOPE TARGET-SCOPE
UbH 2001:f20:10c::1:1/128&1:1 ::ffff:172.17.1.1 vpn6 200 40 30
UbH 2001:f20:10c::1:2/128&1:1 ::ffff:172.17.1.2 vpn6 200 40 30
UbH 2001:f20:10c:0:10:0:1:0/112&1:1 ::ffff:172.17.1.1 vpn6 200 40 30
UbH 2001:f20:10c:0:10:0:2:0/112&1:1 ::ffff:172.17.1.2 vpn6 200 40 30

all next-hop gateway were unreachable
have u succeeded running 6vpe?

could you give any clue what happen?
should i add something on OSPF?

anyway i've also try running the same configuration on v7.17.1 and v7.18.x it's going worst, router became hung, ospf were not stable.

thx

clambert · Sat Feb 01, 2025 4:16 pm

The routes appear unreachable because you are running VPNv6 over IPv4 infrastructure, which is not yet supported on RouterOS.

Jotne · Sat Feb 01, 2025 5:16 pm

Updated script to get serial from different systems:

:local boardName [/system resource get board-name]
:local serial na
:if ($boardName = "CHR") do={
	:set serial [/system license get system-id]
} else= {
	:local arch [/system resource get architecture-name]

	:if ($arch = "x86_64") do={
		:set serial [/system license get software-id]
	} else={
		:set serial ([/system routerboard get serial-number])
	}
}

irghost · Sat Feb 01, 2025 6:15 pm

Pls read the forum, not just posting.
viewtopic.php?p=1122915#p1122915
Hi oreggin,

you're right that 6vpe silently/partially supported at least until v7.16.2, but i still have problems below.
i got this error on P which also act as RR

[admin@P-01] > /routing/route/print where bgp afi=vpn6
Flags: U - UNREACHABLE; b - BGP; H - HW-OFFLOADED
Columns: DST-ADDRESS, GATEWAY, AFI, DISTANCE, SCOPE, TARGET-SCOPE
DST-ADDRESS GATEWAY AFI DISTANCE SCOPE TARGET-SCOPE
UbH 2001:f20:10c::1:1/128&1:1 ::ffff:172.17.1.1 vpn6 200 40 30
UbH 2001:f20:10c::1:2/128&1:1 ::ffff:172.17.1.2 vpn6 200 40 30
UbH 2001:f20:10c:0:10:0:1:0/112&1:1 ::ffff:172.17.1.1 vpn6 200 40 30
UbH 2001:f20:10c:0:10:0:2:0/112&1:1 ::ffff:172.17.1.2 vpn6 200 40 30

all next-hop gateway were unreachable
have u succeeded running 6vpe?

could you give any clue what happen?
should i add something on OSPF?

anyway i've also try running the same configuration on v7.17.1 and v7.18.x it's going worst, router became hung, ospf were not stable.

thx

try this

viewtopic.php?p=1123124#p1123050

change prefix to /64

tim427 · Sat Feb 01, 2025 8:40 pm

Oh perfect! IPv6 is getting some love!

Would be extra nice if BGP IPv6 sessions could be monitored via SNMP and not only IPv4 :)

oreggin · Mon Feb 03, 2025 10:13 am

try this

viewtopic.php?p=1123124#p1123050

change prefix to /64

buset1974 trying an unsupported feature but I think you catch a bug with this prefix length.

In my labs (VM and physical), locally connected IPv6 prefixes was /112 on loopbacks (bridges) and this triggered a bug. If prefixes are /64 or for example /62, there is no crash but unfortunately the routing itself doesn't work anyway:

[oreggin@rtr1.CPE] > /routing/route/print where afi=vpn6 
Flags: A - ACTIVE; b - BGP, y - BGP-MPLS-VPN
Columns: DST-ADDRESS, GATEWAY, AFI, DISTANCE, SCOPE, TARGET-SCOPE, IMMEDIATE-GW
   DST-ADDRESS                 GATEWAY               AFI   DISTANCE  SCOPE  TARGET-SCOPE  IMMEDIATE-GW                   
Ay b00b:10:11:10::/62&65530:1  Loopback_VRF_A@VRF_A  vpn6       200     40            10  Loopback_VRF_A                 
Ab b00b:10:12:11::/64&65530:1  b00b::10:0:10:12      vpn6       200     40            30  fe80::20c:42ff:fe53:1491%ether2
Ab b00b:10:13:11::/64&65530:1  b00b::10:0:10:13      vpn6       200     40            30  fe80::20c:42ff:fe53:1491%ether2
Ay b00b:10:11:12::/64&65530:2  Loopback_VRF_B@VRF_B  vpn6       200     40            10  Loopback_VRF_B                 
Ab b00b:10:12:12::/64&65530:2  b00b::10:0:10:12      vpn6       200     40            30  fe80::20c:42ff:fe53:1491%ether2
Ab b00b:10:13:12::/64&65530:2  b00b::10:0:10:13      vpn6       200     40            30  fe80::20c:42ff:fe53:1491%ether2

Routes are only in BGP table and not in L3VPN RIB, except locally connected routes.

oreggin · Mon Feb 03, 2025 12:55 pm

Routes are only in BGP table and not in L3VPN RIB, except locally connected routes.

I must correct myself, in RIB routes are there:

[oreggin@rtr1.CPE] > /ip/route/print where bgp-mpls-vpn   
Flags: D - DYNAMIC; A - ACTIVE; y - BGP-MPLS-VPN
Columns: DST-ADDRESS, GATEWAY, DISTANCE
    DST-ADDRESS    GATEWAY     DISTANCE
DAy 10.0.12.8/29   10.0.10.12       200
DAy 10.0.12.16/29  10.0.10.13       200
DAy 10.0.11.8/29   10.0.10.12       200
DAy 10.0.11.16/29  10.0.10.13       200
[oreggin@rtr1.CPE] > /ipv6/route/print where bgp-mpls-vpn 
Flags: D - DYNAMIC; A - ACTIVE; y - BGP-MPLS-VPN
Columns: DST-ADDRESS, GATEWAY, DISTANCE
    DST-ADDRESS         GATEWAY           DISTANCE
DAy b00b:10:12:12::/64  b00b::10:0:10:12       200
DAy b00b:10:13:12::/64  b00b::10:0:10:13       200
DAy b00b:10:12:11::/64  b00b::10:0:10:12       200
DAy b00b:10:13:11::/64  b00b::10:0:10:13       200

Difference is IPv4 nexhops has implicit-null and has active remote label, IPv6 nexthops are inactive and has no implicit-null in MPLS FWD table:

[oreggin@rtr1.CPE] > /mpls/forwarding-table/print 
Flags: L - LDP, P - VPN, V - VPLS
Columns: LABEL, VRF, PREFIX, NEXTHOPS, VPLS
 #   LABEL  VRF    PREFIX              NEXTHOPS                                                  VPLS  
 0 P    32  VRF_A                                                                                      
 1 P    33  VRF_B  b00b:10:11:12::/64                                                                  
 2 P    34  VRF_B  10.0.12.0/29                                                                        
 3 L    40  main   b00b::10:0:10:1     { nh=fe80::20c:42ff:fe53:1491%ether2; interface=ether2 }        
 4 L    41  main   b00b::10:0:10:12    { nh=fe80::20c:42ff:fe53:1491%ether2; interface=ether2 }        
 5 L    42  main   b00b::10:0:10:13    { nh=fe80::20c:42ff:fe53:1491%ether2; interface=ether2 }        
 6 L    37  main   10.0.10.1           { label=impl-null; nh=10.0.0.25; interface=ether2 }             
 7 L    38  main   10.0.10.12          { label=17; nh=10.0.0.25; interface=ether2 }                    
 8 L    39  main   10.0.10.13          { label=18; nh=10.0.0.25; interface=ether2 }                    
 9 L    35  main   10.0.0.0/30         { label=impl-null; nh=10.0.0.25; interface=ether2 }             
10 L    36  main   10.0.1.0/30         { label=impl-null; nh=10.0.0.25; interface=ether2 }             
11 V    29                                                                                       vpls13
12 V    28                                                                                       vpls14
[oreggin@rtr1.CPE] > /mpls/ldp/remote-mapping/print 
Flags: I - INACTIVE; D - DYNAMIC
Columns: VRF, DST-ADDRESS, NEXTHOP, LABEL, PEER
 #    VRF   DST-ADDRESS       NEXTHOP    LABEL      PEER       
 0 ID main  b00b::10:0:10:11             19         10.0.10.1:0
 1 ID main  ::1                          impl-null  10.0.10.1:0
 2 ID main  b00b::10:0:10:1              impl-null  10.0.10.1:0
 3 ID main  b00b::10:0:10:12             20         10.0.10.1:0
 4 ID main  b00b::10:0:10:13             21         10.0.10.1:0
 5 ID main  10.0.10.11                   16         10.0.10.1:0
 6  D main  10.0.10.1         10.0.0.25  impl-null  10.0.10.1:0
 7  D main  10.0.10.12        10.0.0.25  17         10.0.10.1:0
 8  D main  10.0.10.13        10.0.0.25  18         10.0.10.1:0
 9 ID main  10.0.0.24/30                 impl-null  10.0.10.1:0
10  D main  10.0.0.0/30       10.0.0.25  impl-null  10.0.10.1:0
11  D main  10.0.1.0/30       10.0.0.25  impl-null  10.0.10.1:0

fischerdouglas · Mon Feb 03, 2025 12:59 pm

unfortunately the routing itself doesn't work anyway:

Routes are only in BGP table and not in L3VPN RIB, except locally connected routes.

Exactly the conclusion I felt!

And I'll say more... The beeps on my "guess-o-meter" indicate that this has to do with a route recursing to a destination that is not in the FIB.
In this case a label, which is represented by a RD/RT. And what's more interesting... A label that works for IPv4 but not for IPv6.

I haven't had the time and patience to test this new testing version yet. But I believe that if you do tests with "Next-Hop-Self" or use static routes and try to manipulate the NLRI in the route import filters, I imagine that this L3VPN v6 over LDPv4 scenario can work.

I still believe that all of this may be related to this united-but-separate way of displaying IPv4, IPv6, MPLS, etc. routes.
In the MikroTik world, "What is RIB?", "What is FIB?", "Are FIBv4 and FIBv6 united or separate?".

buset1974 · Mon Feb 03, 2025 1:07 pm

mikrotik does not Support BGP VPNv6 over IPv4 MPLS LDP transport?

[admin@PE2] >  /routing/route/print where afi=vpn6
Flags: U - UNREACHABLE; b - BGP
Columns: DST-ADDRESS, GATEWAY, AFI, DISTANCE, SCOPE, TARGET-SCOPE
   DST-ADDRESS              GATEWAY          AFI   DISTANCE  SCOPE  TARGET-SCOPE
Ub 2001:db8::/48&65000:105  ::ffff:10.0.0.1  vpn6       200     40            30
Ub fc00:101::/64&65000:100  ::ffff:10.0.0.1  vpn6       200     40            30
Ub fc00:101::/64&65000:101  ::ffff:10.0.0.1  vpn6       200     40            30

Pls read the forum, not just posting.
viewtopic.php?p=1122915#p1122915

hi oreggin

it's seem that you also got U = unreachable status for vpnv6 next-hop
any trick to make it active?

fischerdouglas · Mon Feb 03, 2025 1:35 pm

In Cisco there is "vrf upgrade cli multi af mode common policies"
Seems that the equivalent to that is missing in RouterOS.

Today, in RouterOS v7, exists the objects:

/ip/vrf/
/routing/table/
/routing/bgp/vpn/

The meaning of all those has some intersection, but only /routing/bgp/vpn/ allows some definition of label bahavior in "label-allocation-policy".
Shouldn't the Label-related attribute definition be in /ip/vrf/ or /routing/table/ ?
The way it is defined today, it seems that there is no possibility of having a Label linked to a VRF if you are not using BGP.

From where I can see it seems that this addition to "main-only" things is affecting the definition of where underlay and overlay begin and end.

clambert · Mon Feb 03, 2025 2:36 pm

I haven't had the time and patience to test this new testing version yet. But I believe that if you do tests with "Next-Hop-Self" or use static routes and try to manipulate the NLRI in the route import filters, I imagine that this L3VPN v6 over LDPv4 scenario can work.

@fischerdouglas, How do you think VPNv6 could work over IPv4 infra?

oreggin · Mon Feb 03, 2025 3:27 pm

it's seem that you also got U = unreachable status for vpnv6 next-hop

Where did you see them unreachable?

any trick to make it active?

Yes, as I mentioned, you MUST use IPv6 BGP neighborship and IPv6 IGP + LDPv6, but won't work with latest stable/testing releases. IIRC last worked with 7.17beta2 or 7.16.x

mrz · Mon Feb 03, 2025 4:58 pm

In Cisco there is "vrf upgrade cli multi af mode common policies"
Seems that the equivalent to that is missing in RouterOS.

Today, in RouterOS v7, exists the objects:

/ip/vrf/

/routing/table/

/routing/bgp/vpn/

The meaning of all those has some intersection, but only /routing/bgp/vpn/ allows some definition of label bahavior in "label-allocation-policy".
Shouldn't the Label-related attribute definition be in /ip/vrf/ or /routing/table/ ?
The way it is defined today, it seems that there is no possibility of having a Label linked to a VRF if you are not using BGP.

From where I can see it seems that this addition to "main-only" things is affecting the definition of where underlay and overlay begin and end.

Because only BGP allocates and distributes labels for VPN routes.

mrz · Mon Feb 03, 2025 5:00 pm

Pls read the forum, not just posting.
viewtopic.php?p=1122915#p1122915
hi oreggin

it's seem that you also got U = unreachable status for vpnv6 next-hop
any trick to make it active?

Currently IPv4 mapped gateways cannot be resolved. You have to change the gateway to valid ipv6 address with routing filters.

buset1974 · Mon Feb 03, 2025 7:57 pm

it's seem that you also got U = unreachable status for vpnv6 next-hop
Where did you see them unreachable?
any trick to make it active?
Yes, as I mentioned, you MUST use IPv6 BGP neighborship and IPv6 IGP + LDPv6, but won't work with latest stable/testing releases. IIRC last worked with 7.17beta2 or 7.16.x

Flags: U - UNREACHABLE; b - BGP
Ub 2001:db8::/48&65000:105 ::ffff:10.0.0.1 vpn6 200 40 30

oreggin · Mon Feb 03, 2025 8:03 pm

Currently IPv4 mapped gateways cannot be resolved. You have to change the gateway to valid ipv6 address with routing filters.

It means it could works without LDPv6? LDPv6 is problematic in interop environment.

Edit: however we would be happy if VPNv6 over IPv6 worked stably.

oreggin · Mon Feb 03, 2025 8:05 pm

Where did you see them unreachable?

Yes, as I mentioned, you MUST use IPv6 BGP neighborship and IPv6 IGP + LDPv6, but won't work with latest stable/testing releases. IIRC last worked with 7.17beta2 or 7.16.x
Flags: U - UNREACHABLE; b - BGP
Ub 2001:db8::/48&65000:105 ::ffff:10.0.0.1 vpn6 200 40 30

viewtopic.php?p=1123531#p1123531
Which row contains "U"nreachable flag?

buset1974 · Mon Feb 03, 2025 8:31 pm

Flags: U - UNREACHABLE; b - BGP
Ub 2001:db8::/48&65000:105 ::ffff:10.0.0.1 vpn6 200 40 30
viewtopic.php?p=1123531#p1123531
Which row contains "U"nreachable flag?

Ub 2001:db8::/48&65000:105 ::ffff:10.0.0.1 vpn6 200 40 30

buset1974 · Mon Feb 03, 2025 8:32 pm

viewtopic.php?p=1123531#p1123531
Which row contains "U"nreachable flag?
-U- b 2001:db8::/48&65000:105 ::ffff:10.0.0.1 vpn6 200 40 30

oreggin · Mon Feb 03, 2025 9:04 pm

-U- b 2001:db8::/48&65000:105 ::ffff:10.0.0.1 vpn6 200 40 30

This is in your RIB, not in mine. You wrote: " it's seem that you also got U = unreachable status for vpnv6 next-hop", but I haven't got because I use native IPv6 datapath for VPNv6. That's why VPNv6 routes are active in my RIB. I hope all clear now :-)

netwpl · Mon Feb 03, 2025 9:12 pm

How this works? Has someone tried already?
Code: Select all
*)  cloud - added file-share feature;

I enabled it, or at least I thought, but doesn't work. It says running, and looked based on BTH's relay service to share files over internet.

/ip/cloud/file-share/settings/print
                enabled: yes                                                                         
               dns-name: <sn>.routingthecloud.net                                            
                 status: running                                                                     
             relay-rtts: EUR1 (ip4: 166.163ms, ip6: timeout)                                         
                         USA1 (ip4: 70.25ms, ip6: timeout)                                           
      relay-ipv4-status: connected (region: USA1 ip: <public ipv4> rtt: 70.25ms reachable: directly )
      relay-ipv6-status: testing rtt                                                                 
          relay-regions: EUR1                                                                        
                         USA1                                                                        
       relay-addressess: <public ipv4>                                                                
                         <public ipv4>.                                                               
  relay-addressess-ipv6: 2a02::<...>                                                          
                         2602::<...>                                                            
            certificate: <sn>.routingthecloud.net

Additionally it does a dynamic firewall rule to allow 443 from anywhere, and generates some HTTPS URLs in /ip/cloud/file-server – which I presume are how you use it — but those didn't work and returned a 404 from the router with a file-share enable:

/ip/cloud/file-share/print detail 
Flags: X - disabled; I - invalid 
 0    path=/ allow-uploads=yes expires=never key="UaN<keys>hs1" 
      url="https://9b<sn>.routingthecloud.net/s/UaN<keys>hs1" 
      direct-url="https://9b<sn>.routingthecloud.net/s/Ua<keys>hs1?dl" downloads=0

With "9b<sn>.routingthecloud.net" address resolves to my router's WAN IP address.

And, did find another bug when trying /ip/cloud/export - it fails to export config for the new /ip/cloud/file-share. (Thus the "print" output above.)

under ip cloud i had to click update force once again and then it has worked. u can also try to replace the domain name with your static ip (if u have one).

buset1974 · Mon Feb 03, 2025 9:22 pm

-U- b 2001:db8::/48&65000:105 ::ffff:10.0.0.1 vpn6 200 40 30
This is in your RIB, not in mine. You wrote: " it's seem that you also got U = unreachable status for vpnv6 next-hop", but I haven't got because I use native IPv6 datapath for VPNv6. That's why VPNv6 routes are active in my RIB. I hope all clear now :-)

my bad i think it a @irqhost RIB. It's not my RIB either.

buset1974 · Mon Feb 03, 2025 9:23 pm

hi oreggin

it's seem that you also got U = unreachable status for vpnv6 next-hop
any trick to make it active?
Currently IPv4 mapped gateways cannot be resolved. You have to change the gateway to valid ipv6 address with routing filters.

Any ETA or in what major version it will resolved mrz?

thx

irghost · Tue Feb 04, 2025 12:00 am

I haven't had the time and patience to test this new testing version yet. But I believe that if you do tests with "Next-Hop-Self" or use static routes and try to manipulate the NLRI in the route import filters, I imagine that this L3VPN v6 over LDPv4 scenario can work.
@fischerdouglas, How do you think VPNv6 could work over IPv4 infra?

Mikrotik support answer "Currently no it is not possible"

eider · Tue Feb 04, 2025 1:13 am

*) lte - lte monitor, show CQI when modem reports it as 0 - undetectable, no RX/down-link resource block assigned to modem by provider;
*) lte - removed nonexistent CQI reading for EC200A-EU modem;

FG621-EA seems to be now showing empty value for CQI, which is definitely bogus and should be hidden.

WinBox_2025-02-04_00-10-54.png

4lphanumeric · Tue Feb 04, 2025 3:59 am

RB750r2. Missing bad-block on /system/resource/print

felixka · Tue Feb 04, 2025 6:31 am

My SmokePing shows a +1ms in latency difference since updating to 7.18. That's consistent across all targets. Not a big deal, but it certainly stands out in the graph and exactly coincides with me doing the update.

pe1chl · Tue Feb 04, 2025 11:17 am

My SmokePing shows a +1ms in latency difference since updating to 7.18. That's consistent across all targets. Not a big deal, but it certainly stands out in the graph and exactly coincides with me doing the update.

Useless comment when you do not mention compared to what previous version!
Maybe you upgraded from 6.49?

ivicask · Tue Feb 04, 2025 3:04 pm

On small setup with HAP AX3 as capsman and 2x CAP AX when i updated AX3 to 7.18.beta4 one of CAPs automatically upgraded to 7.18.beta4 but other identical one complains about this:

G01718@D4:01:C3:C1:8B:BE%*9 upgrade request failed, no file (zerotier-7.18beta4-arm64.npk)

There is no zerotier on it or it was ever installed and both caps are 100% identical(reseted to cap mode via button)

felixka · Tue Feb 04, 2025 3:05 pm

My SmokePing shows a +1ms in latency difference since updating to 7.18. That's consistent across all targets. Not a big deal, but it certainly stands out in the graph and exactly coincides with me doing the update.
Useless comment when you do not mention compared to what previous version!
Maybe you upgraded from 6.49?

I upgraded from 7.17.

erlinden · Tue Feb 04, 2025 3:46 pm

There is no zerotier on it or it was ever installed and both caps are 100% identical(reseted to cap mode via button)

I have never seen all these packages. AFAIK it shouldn't be there. Could it be that the CAP requires a reboot?
Looks to me like you installed all packages that are of the "Extra packages".

Documentation:
https://help.mikrotik.com/docs/spaces/R ... thpackages

Uninstall: "schedule package to be removed from the router. That will take place during the reboot."

Edit: Thanks @holvoetn!

baragoon · Tue Feb 04, 2025 3:49 pm

What does this checkbox do?

erlinden · Tue Feb 04, 2025 3:51 pm

What does this checkbox do?

According to the documentation:

auto-link-local (yes | no; Default: yes)
If newly created address is manual link-local address this setting allows to override dynamically created IPv6 link-local address.

https://help.mikrotik.com/docs/spaces/R ... Addressing

Tue Feb 04, 2025 4:13 pm

There is no zerotier on it or it was ever installed and both caps are 100% identical(reseted to cap mode via button)
I have never seen all these packages. AFAIK it shouldn't be there. Could it be that the CAP requires a reboot?
Looks to me like you installed all packages that are of the "Extra packages".

Documentation:
https://help.mikrotik.com/docs/spaces/R ... thpackages

Uninstall: "schedule package to be removed from the router. That will take place during the reboot."

New behavior of 7.18 after upgrade.
First time a list will be shown of all possible packages for your device so you can easily activate from there if needed.
You can see from the screenshot all are disabled except for ROS and wifi-qcom.

But it shouldn't complain about zerotier not being present if it wasn't there to begin with.

kiler129 · Tue Feb 04, 2025 4:40 pm

I am still hoping for a solution where defconf for the firewall can be applied to an existing router... some command that removes the firewall config and reloads it from defconf, if only as a commandline script.

This can be done very easily - just print defconf and apply what you need. But this sounds more like not understanding ROS itself and hoping for some magic sauce to come in defconf (which by itself is a crutch).

---

The IPv6 FT appears to be very stable and useful! Great job MT. However, the device-mode REALLY needs some more baking. A simple thing like setting auto-upgrade=yes for routerboard is now broken (we have this in our default config) and requires physical access to the device. The same applies to lowering frequency on some devices... I get locking down downgrades but locking down boot options and things related to firmware for network devices often not easily accessible and on masts? Come on... it has been multiple decades for some of us and we don't need training wheels. This only alienates advanced users, who are the primary MT userbase.

teslasystems · Tue Feb 04, 2025 5:02 pm

Just curious, why 'Orig./Repl. Rate' and 'Orig./Repl. Bytes' fields are available in IPv4 connections, but not available in IPv6 connections?

pe1chl · Tue Feb 04, 2025 5:37 pm

I am still hoping for a solution where defconf for the firewall can be applied to an existing router... some command that removes the firewall config and reloads it from defconf, if only as a commandline script.
This can be done very easily - just print defconf and apply what you need. But this sounds more like not understanding ROS itself and hoping for some magic sauce to come in defconf (which by itself is a crutch).

It is intended precisely for that: people who know enough to destroy the firewall but not enough to repair it using cut/paste from the defconf.
(which is made unnecessarily difficult by the way the output of /system/default-configuration/print is formatted)

It would already be helpful when there was a separate script output by e.g. /system/default-firewall/print, in a way that can be cut/paste.
That script could be called as a subroutine of the /system/default-configuration/print script so it would not cost much more space.

baragoon · Tue Feb 04, 2025 5:46 pm

According to the documentation:

auto-link-local (yes | no; Default: yes)
If newly created address is manual link-local address this setting allows to override dynamically created IPv6 link-local address.

https://help.mikrotik.com/docs/spaces/R ... Addressing

when auto-link local is disabled in the ipv6 settings this checkbox (enabled) doesn't create a link-local address when adding Global ipv6 addr,
when chechbox is disabled - then error displayed: selected address is not link local

little bit confusing

maxten · Wed Feb 05, 2025 8:33 am

*) sfp - improved system stability with some GPON modules for CCR2004 and CCR2116 devices;
I have Alcatel-Lucent GPON module installed in the SFP+ port in RB5009. But the SFP information can only be processed when whole system being powered up, If I reboot the router, the SFP info cannot be display in the winbox/web/terminal(all sfp info is left as blank). The only recovery way is to shutdown -> re-powered again.

Wed Feb 05, 2025 3:43 pm

It would already be helpful when there was a separate script output by e.g. /system/default-firewall/print, in a way that can be cut/paste.

That’s why I established my defconf collection. Cut and paste from any that’s close enough to your use case.

Wed Feb 05, 2025 3:44 pm

Sorry if I did misunderstand something that you are trying to do, but, if you disable LL addresses globally, then, if you need to use global addresses, then you should add LL also manually.

Here is an example. Am I missing something what is not working for you?

[admin@MikroTik] > :put [/ipv6/settings/get disable-link-local-address ]
true
[admin@MikroTik] > ipv6/address/export
/ipv6 address
add address=2001:db8::1 interface=ether2
add address=fe80::84d8:a861:1 advertise=no auto-link-local=no interface=ether2

According to the documentation:

auto-link-local (yes | no; Default: yes)
If newly created address is manual link-local address this setting allows to override dynamically created IPv6 link-local address.

https://help.mikrotik.com/docs/spaces/R ... Addressing
when auto-link local is disabled in the ipv6 settings this checkbox (enabled) doesn't create a link-local address when adding Global ipv6 addr,
when chechbox is disabled - then error displayed: selected address is not link local

little bit confusing

baragoon · Wed Feb 05, 2025 3:58 pm

Sorry if I did misunderstand something that you are trying to do, but, if you disable LL addresses globally, then, if you need to use global addresses, then you should add LL also manually.

Here is an example. Am I missing something what is not working for you?
Code: Select all
[admin@MikroTik] > :put [/ipv6/settings/get disable-link-local-address ]
true
[admin@MikroTik] > ipv6/address/export
/ipv6 address
add address=2001:db8::1 interface=ether2
add address=fe80::84d8:a861:1 advertise=no auto-link-local=no interface=ether2

Hi strods,
Sure, I understand that if LL are disabled globally, and if I need LL on some interface I should add it manually.
I don't understand the purpose of this (auto-link-local) checkbox.

what is the difference?

/ipv6 address export
add address=fe80::1 advertise=no interface=bridge
add address=fe80::2 advertise=no auto-link-local=no interface=bridge

/ipv6 address print detail 
Flags: X - disabled, I - invalid; D - dynamic; G - global, L - link-local; S - slave; d - deprecated 
 0  D    address=::1/128 from-pool="" interface=lo actual-interface=lo eui-64=no advertise=no no-dad=no auto-link-local=yes 

 1   L   address=fe80::1/64 from-pool="" interface=bridge actual-interface=bridge eui-64=no advertise=no no-dad=no auto-link-local=yes 

 2   L   address=fe80::2/64 from-pool="" interface=bridge actual-interface=bridge eui-64=no advertise=no no-dad=no auto-link-local=no

Njumaen · Wed Feb 05, 2025 4:11 pm

Can you please make wireguard's AllowedIPs configuarble???

This below is nice but not the right choice for every situation, especially when you need a split tunnel!

[Peer]
PublicKey = .......
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = .......

pe1chl · Wed Feb 05, 2025 4:18 pm

It would already be helpful when there was a separate script output by e.g. /system/default-firewall/print, in a way that can be cut/paste.
That’s why I established my defconf collection. Cut and paste from any that’s close enough to your use case.

Yeah, but what we need is something local to the router, so that the user can cut/paste the correct config for his router and his version of RouterOS.
Mainly to upgrade the firewall to the state-of-the-art after upgrading RouterOS, and to restore firewalls damaged after viewing Youtube videos by clueless people that think they can educate others...
Just some button to click or command to enter that will do a partial reset of the config.

lombokbiru · Wed Feb 05, 2025 5:46 pm

*) x86 - fixed "unsupported speed" warning (additional fixes);

nice, Solved my problem on quad port SFP 1G - i82576-F4

pidro · Wed Feb 05, 2025 11:30 pm

I really like the eSIM support and works great, however it's not complete as only the following 3 parameter can be used
interface - the interface for which the eSIM profile will be enabled.
matching-id - an activation code token. Example: matching-id=ABCD10EFGHI5KL6M
sm-dp-plus - SM-DP+ server hostname
There should be a 4th parameter for the "Confirmation Code" which is an optional parameter but if the mobile operator using it itis mandatory to use to provision the eSIM

Amm0 · Thu Feb 06, 2025 2:51 am

I really like the eSIM support and works great,

@Mikrotik, Is there a list of modems modules that the eSIM feature works on?

stathismes · Thu Feb 06, 2025 9:32 am

SUP-177102 still awaiting support on the VRRP connection sync track issue. Please fix this! Without it we can't have fully redundant routers.

rpingar · Thu Feb 06, 2025 10:31 am

we are testing 7.18beta4 on a x86 border router, and it gets a lot of HoldTimer expired ERROR on IPV6 ibgp connections.
something wrong about it, issue not present in 7.17 and earlier versions.

The issue seems not present on arm64 platform.

regards

spippan · Thu Feb 06, 2025 12:01 pm

note on container settings in v7.18beta4

had to change the Registry URL from "https://registry-1.docker.io/v2/" --> to --> "https://registry-1.docker.io"
now i can pull containers again

mobyfab · Thu Feb 06, 2025 1:16 pm

GPON issue got even worse on CCR2116.
7.17 crashes within a week, but 7.18 crashes withing a day or two.
I have a ticket but I'm not getting any updates.

Thu Feb 06, 2025 3:33 pm

From the discussion in beta and rc topics I already internalized this device mode thing

but , after seen the blocking of some features, I don't understand why leave enabled socks feature which was previously exploited on vulnerable devices

Smokeshow · Thu Feb 06, 2025 5:17 pm

MPLS Traffic Eng Tunnel Path is still broken in winbox / webui;

Screenshot 2025-02-06 081544.png

nmt1900 · Thu Feb 06, 2025 7:53 pm

From the discussion in beta and rc topics I already internalized this device mode thing

but , after seen the blocking of some features, I don't understand why leave enabled socks feature which was previously exploited on vulnerable devices

One might wonder about zerotier as well - it can be a handy way to exploit compromised devices

pe1chl · Thu Feb 06, 2025 8:22 pm

But zerotier has an associated device-mode flag!

guipoletto · Thu Feb 06, 2025 8:28 pm

[/quote]
One might wonder about zerotier as well - it can be a handy way to exploit compromised devices
[/quote]

Why not drink the whole kool-aid and advocate for airgapped networks, the most secure form of network?
or maybe only allow local management via Serial Ports
or even take ayay Serial access, since it can be considered a "side-channel", and therefore an attack vector?

this thing is getting so out of hand it's difficult to even treat seriously

more importantly, once i truck-roll over the whole network and apply

/sys/device-mode/update routerboard=yes traffic-gen=yes install-any-version=y partitions=yes container=y mode=advanced flagging-enabled=no

enerywhere

will Mikrotik propagate future flags in device-mode based on existing flags?

or i will be expected to be in a perpetual state of truck-rolling and manually touching reset-buttons across the network?
(everytime someone invents a new "security" reason to destroy functionality?)

pe1chl · Thu Feb 06, 2025 8:41 pm

I think there should be an additional device-mode flag (e.g. named device-mode) which you can enable once and for all to skip all future device-mode flag additions (i.e. automatically enable them).

pospanko · Thu Feb 06, 2025 9:05 pm

firewall - increased maximum connection tracking entry count based on device total RAM size;

Will this finally make CCR1072 have more connections then 1.048.576 and throwing connection table full error?

nmt1900 · Thu Feb 06, 2025 9:46 pm

more importantly, once i truck-roll over the whole network and apply
Code: Select all
/sys/device-mode/update routerboard=yes traffic-gen=yes install-any-version=y partitions=yes container=y mode=advanced flagging-enabled=no
enerywhere

will Mikrotik propagate future flags in device-mode based on existing flags?

or i will be expected to be in a perpetual state of truck-rolling and manually touching reset-buttons across the network?
(everytime someone invents a new "security" reason to destroy functionality?)

That's the point - we don't know and they do not want to tell us...

infabo · Fri Feb 07, 2025 12:05 am

If you ask me, it would have been preferable to enhance the flagging mechanism rather than restricting previously available features by default. But now it is here to stay I guess.

ConradPino · Fri Feb 07, 2025 2:49 am

... But now it is here to stay I guess.

IMO that's giving up too easily.
Let's be clear; MikroTik meets customer's needs or MikroTik loses customers. Like it or not, in a free market, the customer always prevails.
The only real question is how much pain does MikroTik inflict on users and in turn experience before MikroTik changes direction or goes under?

Fri Feb 07, 2025 3:28 am

... But now it is here to stay I guess.
IMO that's giving up too easily.
Let's be clear; MikroTik meets customer's needs or MikroTik loses customers. Like it or not, in a free market, the customer always prevails.
The only real question is how much pain does MikroTik inflict on users and in turn experience before MikroTik changes direction or goes under?

I understand your discomfort/annoyance with the situation,but i think This situation has other facets, Mikrotik has periodically been targeted by the media in a somewhat exaggerated way, about compromised devices being used in attacks by malicious actors, that put a heavy pressure on MikroTik to take strong measures, is not a trivial situation, recent news arised about the posibility of the US considering banning TP-Link routers over cybersecurity risks, In the face of such a disastrous possibility, generating discomfort/annoyance to users can become a lesser evil.

And in some way, as users, facing the inconveniences of this situation can be our contribution to improving security and supporting the brand that has provided us with versatile and affordable solutions for years, so that it can continue to do so.

In IT in general this is not the first time a new security feature causes some inconvenience, with many brands of equipment and services.

In a world as connected as today's, new security threats emerge and some previous problems that already existed without much impact now are becoming much more serious problems that require new measures to mitigate them

ConradPino · Fri Feb 07, 2025 3:43 am

i understand your discomfort/annoyance with the situation,but i think This situation has other facets, Mikrotik has periodically been targeted by the media in a somewhat exaggerated way, about compromised devices being used in attacks by malicious actors, that put a heavy pressure on MikroTik to take strong measures, is not a trivial situation, recent news arised about the posibility of the US considering banning TP-Link routers over cybersecurity risks, In the face of such a disastrous possibility, generating discomfort/annoyance to users can become a lesser evil.

And in some way, as users, facing the inconveniences of this situation can be our contribution to improving security and supporting the brand that has provided us with versatile and affordable solutions for years, so that it can continue to do so.

IMO such arguments are relevant only to users with physical access to deployed devices and totally in applicable to customers who must roll trucks with such constraints.

Care to make a wager about which market has greater sales volume? Well that is exactly the wager MakroTik is making right now with our collective future! I want MakroTik alive and thriving!!

guipoletto · Fri Feb 07, 2025 3:49 am

I understand your discomfort/annoyance with the situation,but i think This situation has other facets, Mikrotik has periodically been targeted by the media in a somewhat exaggerated way, about compromised devices being used in attacks by malicious actors, that put a heavy pressure on MikroTik to take strong measures, is not a trivial situation, recent news arised about the posibility of the US considering banning TP-Link routers over cybersecurity risks, In the face of such a disastrous possibility, generating discomfort/annoyance to users can become a lesser evil.

And in some way, as users, facing the inconveniences of this situation can be our contribution to improving security and supporting the brand that has provided us with versatile and affordable solutions for years, so that it can continue to do so.

In IT in general this is not the first time a new security feature causes some inconvenience, with many brands of equipment and services.

In a world as connected as today's, new security threats emerge and some previous problems that already existed without much impact now are becoming much more serious problems that require new measures to mitigate them

I can sense the idea that someone from some agency whispered in mikrotiks ears "fix it or be regulated"

and they came up with this complete overkill bazooka "solution" to shoot their customer's foots with

at least they can point and claim that *someone is doing *something

But the practical side is that now we have *remotelly managed* network assets, that *cannot be remotelly managed*
and not only that, but also the very real prospect of *future* functionality being caged behind "device mode" flags, requiring physical intervention, *AGAIN*

the current implementation also breaks default-config on netinstall, flashfig, and branding-bootstrapped-defaults

ConradPino · Fri Feb 07, 2025 5:06 am

I can sense the idea that someone from some agency whispered in mikrotiks ears "fix it or be regulated"
and they came up with this complete overkill bazooka "solution" to shoot their customer's foots with
at least they can point and claim that *someone is doing *something

But the practical side is that now we have *remotelly managed* network assets, that *cannot be remotelly managed*
and not only that, but also the very real prospect of *future* functionality being caged behind "device mode" flags, requiring physical intervention, *AGAIN*

the current implementation also breaks default-config on netinstall, flashfig, and branding-bootstrapped-defaults

I can easily believe such whispers are in play, in which case, MikroTik should disclose the issues driving unpopular choices and enlist customers to design better solutions.

I worry the commercial remote deployment truck roll required market is too valuable to lose without seriously damaging MikroTik's future.

oreggin · Fri Feb 07, 2025 9:51 am

I can sense the idea that someone from some agency whispered in mikrotiks ears "fix it or be regulated"
and they came up with this complete overkill bazooka "solution" to shoot their customer's foots with
at least they can point and claim that *someone is doing *something

But the practical side is that now we have *remotelly managed* network assets, that *cannot be remotelly managed*
and not only that, but also the very real prospect of *future* functionality being caged behind "device mode" flags, requiring physical intervention, *AGAIN*

the current implementation also breaks default-config on netinstall, flashfig, and branding-bootstrapped-defaults
I can easily believe such whispers are in play, in which case, MikroTik should disclose the issues driving unpopular choices and enlist customers to design better solutions.

I worry the commercial remote deployment truck roll required market is too valuable to lose without seriously damaging MikroTik's future.

MTik should proactively prevent this types of incidents.
Current form of device-mode will kill MTik devices out most of enterprise environment as it is simply too expensive allocate button-pusher staff for every device/site. What will remain? Home users, whom sitting on their devices; and brave admins whom let their devices runs, without upgrade to the landmine field. If 7.16.2 has a zeroday vulnerability, MTik didn't solve anything, but kill itself. But, again, insulting fair admins with device-mode, while most of home users never upgrade their devices is nonsense.

KozmoNaut · Fri Feb 07, 2025 10:07 am

All devices upgraded from versions <7.17 will be put in the Enterprise/Advanced device-mode, with only traffic-gen, container, install-any-version, partitions and routerboard (minus auto-upgrade) disabled. No physical access needed unless you want to enable one of those specific features. Have you even upgraded a device and seen how it works?

Only devices that come with >=7.17 out of the box will be in one of the more restricted modes, and I damn well hope you do at least a bit of configuration on brand new devices before you roll them out.

You're whipping up a storm of completely misplaced outrage. Honestly just take a breath and acknowledge that Mikrotik cannot just stand by when there is media and governmental attention on the fact that their devices have been used in botnets and DDoS attacks.

Fri Feb 07, 2025 11:20 am

I really like the eSIM support and works great, however it's not complete as only the following 3 parameter can be used
interface - the interface for which the eSIM profile will be enabled.
matching-id - an activation code token. Example: matching-id=ABCD10EFGHI5KL6M
sm-dp-plus - SM-DP+ server hostname
There should be a 4th parameter for the "Confirmation Code" which is an optional parameter but if the mobile operator using it itis mandatory to use to provision the eSIM

Hello pidro, do you have an eSIM that requires the Confirmation code? Can you please contact us at support@mikrotik.com?

oreggin · Fri Feb 07, 2025 11:41 am

Have you even upgraded a device and seen how it works?

Yes, I have a lot, but please be less arrogant. We are just trying to prevent MTik from driving full throttle into the abyss.

I damn well hope you do at least a bit of configuration on brand new devices before you roll them out.

I will, but at most at my home. I won't place MTik devices in production at a far site and I don't recommend it to anyone.

You're whipping up a storm of completely misplaced outrage. Honestly just take a breath and acknowledge that Mikrotik cannot just stand by when there is media and governmental attention on the fact that their devices have been used in botnets and DDoS attacks.

We agree to disagree. You and those like you maybe didn't read other forum topics, where MTik users/admins listed a lot of problematic scenarios, to which the manufacturer did not respond in any meaningful way, or not at all, just repeatedly asking, "what scenario cause problem", we answered most of them with compelling arguments, and that's all, no reaction.
The quality of software development and/or a more thoughtful featureset placing into devices might be more helpful for the vendor as for customers also. The problem is when the management/development shifting to the sandboxer side, when more feature comes into new releases than bugs fixed.

I have no magic ball, I don't know what my company/customers needs after some years. What should I do? Enable everything at initial, and disable flagging to prevent the router locking itself? If so, what is the plus what device-mode adds? Or disable everything what I don't need at the install time?

This is a fight of two types of customers. On the one side, there are users whom like playing in sandbox without consequences. On the other side there are admins whom like to operate at a stable and predictable environment, because they are responsible for the services, and the cost of device-mode are getting too high for them.
Sorry for the long post.

teslasystems · Fri Feb 07, 2025 11:51 am

This has some severe issues with file handling... I have scripts failing that can not remove an existing file.

Still investigating, can not tell exactly what conditions have to be met. 🤨

Theoretically, it could be related to corrupted system files on a flash. I had similar crazy behavior with routes some time ago. Only Netinstall helped.

mkx · Fri Feb 07, 2025 12:17 pm

... read other forum topics, where MTik users/admins listed a lot of problematic scenarios, to which the manufacturer did not respond in any meaningful way, or not at all, just repeatedly asking, "what scenario cause problem", we answered most of them with compelling arguments, and that's all, no reaction.

Not entirely true. While the MT reaction you're describing was indeed at first, later they changed default device-mode settings (when upgrading device from pre-7.17). So bringing up the same complaints now is not fair (and is actually spreading FUD). Assess the situation with new device-mode settings and only complain if something breaks for you with stable 7.17.x releases.

Also bitching about what else will MT break in the future is counter-productive as well. We don't know what MT might break in the future, they might even surprise us by not breaking anything in next few years (at least not on the device-mode front). I hope they learned the lession ...

KozmoNaut · Fri Feb 07, 2025 12:39 pm

Have you even upgraded a device and seen how it works?
Yes, I have a lot, but please be less arrogant. We are just trying to prevent MTik from driving full throttle into the abyss.

There is the unwarranted hyperbole again, please don't make personal attacks.

Every time Mikrotik makes an important change, a certain segment of users go into complete uproar, but then a few months pass and they realize that there wasn't any reason for such a reaction.

We agree to disagree. You and those like you maybe didn't read other forum topics, where MTik users/admins listed a lot of problematic scenarios, to which the manufacturer did not respond in any meaningful way, or not at all, just repeatedly asking, "what scenario cause problem", we answered most of them with compelling arguments, and that's all, no reaction.

Don't make assumptions based on this account's registration date. I read most threads in the main sub forums, so please don't accuse me of not paying attention.

I've read the complaints and misunderstandings about device-mode, as well as similar uproars in the past.

What I've seen is replies from Mikrotik employees taking input and feedback, and requesting support tickets detailing the issues that users face. And a few RouterOS versions later, they are usually addressed with a fix or a change. What they do not do, because they cannot, is provide instant fixes.

They listened to concerns about device-mode and made a sensible change to devices being upgraded from previous versions. It's rather counterproductive to keep bringing up obsolete complaints that are no longer applicable.

I have no magic ball, I don't know what my company/customers needs after some years. What should I do?

Keep up to date with announcements and changelogs, identify and prioritize changes that would require attention and possible action from you, and always test before deploying to production devices.

This is a fight of two types of customers. On the one side, there are users whom like playing in sandbox without consequences. On the other side there are admins whom like to operate at a stable and predictable environment, because they are responsible for the services, and the cost of device-mode are getting too high for them.
Sorry for the long post.

This a flawed argument. It's not "users playing in a sandbox" versus "admins who know best and want no limitations".

The real dichotomy is between security and convenience, and I would say that you and other making similar arguments clearly value convenience.

But simply put, security has to be paramount in networking. It obviously ties everything together, so the potential for breaches and exploits is huge. That is the cold hard reality, but in my experience far too many network admins think security is just an annoyance and a hurdle that gets in their way and should minimised or eliminated whenever possible.

I've worked in security for a long time, in close corporation with CISOs, network architects, active directory, cloud, you name it.

Let me give you an example for when I need to connect to the servers of the system for which I am the architect:

Connect to our VPN with 2-factor authentication
Login to my PC
Connect to our NOC with 2-factor authentication
Login to PAM solution
Select the appropriate credentials
Provide a reason, generally an incident or change ticket, which gets verified automatically
Start session, which is recorded

Provided request reasons and recorded sessions are sampled and audited regularly. Yes, this adds more steps than if you trust people to do the right thing and always be responsible, but the cost of a breach is so much higher and more damaging than a bit of inconvenience. Especially when you will be hit by penalties from your customers afterwards, or even EU-level fines of several % of gross revenue.

From an experienced security professional's point of view, what Mikrotik have implemented with device-mode is completely sensible and honestly quite mild security measures, that I have to say were long overdue.

As professionals, we have to keep up and adapt. Never stop learning.

oreggin · Fri Feb 07, 2025 1:06 pm

Maybe my bad, but there's no reason to posting, because you won't read it, or if you do, you won't interpret it, so you'll give irrelevant answers for what I didn't wrote, sometimes in an inappropriate tone, respect for the exception. Sorry for generating this, we return to more serious manufacturers.
Kind Regards!

Larsa · Fri Feb 07, 2025 1:23 pm

@oreggin, if you're looking for advanced MPLS/BGP solutions, you’ll probably need to consider other brands—but that also comes with additional costs. Since this is just a user forum, if you have a serious business case, you might want to contact MikroTik directly at sales@mikrotik.com or support@mikrotik.com.

Fri Feb 07, 2025 1:58 pm

As professionals, we have to keep up and adapt. Never stop learning.

good point !!!

Fri Feb 07, 2025 2:23 pm

You can leave dynamic LL addresses on globally and add single manual LL address and select this checkbox which will override just a single LL address for this particular interface.

Sorry if I did misunderstand something that you are trying to do, but, if you disable LL addresses globally, then, if you need to use global addresses, then you should add LL also manually.

Here is an example. Am I missing something what is not working for you?
Code: Select all
[admin@MikroTik] > :put [/ipv6/settings/get disable-link-local-address ]
true
[admin@MikroTik] > ipv6/address/export
/ipv6 address
add address=2001:db8::1 interface=ether2
add address=fe80::84d8:a861:1 advertise=no auto-link-local=no interface=ether2
Hi strods,
Sure, I understand that if LL are disabled globally, and if I need LL on some interface I should add it manually.
I don't understand the purpose of this (auto-link-local) checkbox.

what is the difference?
Code: Select all
/ipv6 address export
add address=fe80::1 advertise=no interface=bridge
add address=fe80::2 advertise=no auto-link-local=no interface=bridge
Code: Select all
/ipv6 address print detail 
Flags: X - disabled, I - invalid; D - dynamic; G - global, L - link-local; S - slave; d - deprecated 
 0  D    address=::1/128 from-pool="" interface=lo actual-interface=lo eui-64=no advertise=no no-dad=no auto-link-local=yes 

 1   L   address=fe80::1/64 from-pool="" interface=bridge actual-interface=bridge eui-64=no advertise=no no-dad=no auto-link-local=yes 

 2   L   address=fe80::2/64 from-pool="" interface=bridge actual-interface=bridge eui-64=no advertise=no no-dad=no auto-link-local=no

pe1chl · Fri Feb 07, 2025 2:26 pm

IMO such arguments are relevant only to users with physical access to deployed devices and totally in applicable to customers who must roll trucks with such constraints.

Care to make a wager about which market has greater sales volume?

Well, when we look at newly introduced devices and the kind of features that are added in the past couple of years, and the areas of RouterOS that receive little attention when bugs are reported, it looks like MikroTik is shifting from the "small ISP and businesses with private networks" into the "ISP-provided home routers for the general consumer" market.
There is probably much more money to be made there.

But for "us" it is unfortunate because there is already plenty of choice in the consumer market, and precisely that kind of usage where you want advanced configurability, VPN tunnels, BGP routing etc was a perfect fit for MikroTik. And for WiFi we shopped elsewhere.

Instead of (or in addition to) device-mode, they should have opted to have a default auto-upgrade mechanism for firmware.
The new features that protect the user from attackers will not be available on exactly the devices that were the victim of that, because those users never upgrade firmware.
When we get routers from the local ISPs here, made by companies like AVM or similar, they all come by default with auto firmware upgrade enabled.
You can turn that off when you are the technical user that knows better. But the 99% of users that are not, will receive their upgrades, offering the maker the opportunity to fix bad problems.
MikroTik does not have that so they are dependent on users doing manual upgrade or ISPs configuring dedicated scripts or TR069 for that.

baragoon · Fri Feb 07, 2025 4:14 pm

You can leave dynamic LL addresses on globally and add single manual LL address and select this checkbox which will override just a single LL address for this particular interface.

gotcha, thank you!

ConradPino · Fri Feb 07, 2025 4:57 pm

All devices upgraded from versions <7.17 will be put in the Enterprise/Advanced device-mode, with only traffic-gen, container, install-any-version, partitions and routerboard (minus auto-upgrade) disabled. No physical access needed unless you want to enable one of those specific features. Have you even upgraded a device and seen how it works?

Only devices that come with >=7.17 out of the box will be in one of the more restricted modes, and I damn well hope you do at least a bit of configuration on brand new devices before you roll them out.

You're whipping up a storm of completely misplaced outrage. Honestly just take a breath and acknowledge that Mikrotik cannot just stand by when there is media and governmental attention on the fact that their devices have been used in botnets and DDoS attacks.

I have read all your posts and see some good points but this one oversteps boundaries:

Have you even upgraded a device and seen how it works?
- Presumptuous: many can't afford keeping idle equipment on hand.
- Slanderous: characterizes others motivation as unwilling to try.
You're whipping up a storm of completely misplaced outrage. - Telling another's story is presumptuous and slanderous.

Not lets be clear, I just committed the exact same sins to make clear the tone we use characterizing others really matters.

The above suggests to me MikroTik is still forcing <7.17 user into a lesser technical position without prior notice or consent. I'm sure MikroTik has reasons but I've not seen them make a compelling case so far. Finally, "I want" or "I don't want" require no justifications as both are simple value judgments and therefore idiosyncratic.

ConradPino · Fri Feb 07, 2025 5:53 pm

The quality of software development and/or a more thoughtful featureset placing into devices might be more helpful for the vendor as for customers also. The problem is when the management/development shifting to the sandboxer side, when more feature comes into new releases than bugs fixed.

My gravest concern is the bugs appear to be racing ahead while MikroTik focus appears to be features first. I prefer a substantial separation such that upgrade decisions don't require extensive research to locate regressions affecting specific product models which IMO is a big burden to place on busy end users.

This is a fight of two types of customers. On the one side, there are users whom like playing in sandbox without consequences. On the other side there are admins whom like to operate at a stable and predictable environment, because they are responsible for the services, and the cost of device-mode are getting too high for them.

I suggest "fight" is an overstatement and prefer "competing interests" which is the normal and typical condition in the real world.

At this time risk averse MikroTik users must be MikroTik forum entrails readers as MikroTik doesn't make RouterOS defects obvious in simple manner and designated place where simple manner means within 10 minutes RouterOS version can be correlated to product model to find correlated open bugs together with mitigations, if any, and an upgrade or wait recommendation.

Fri Feb 07, 2025 6:00 pm

What's new in 7.18beta5 (2025-Feb-07 12:25):

*) device-mode - do not allow changing CPU frequency if "routerboard" is not allowed by device mode (introduced in v7.17);
*) device-mode - fixed feature and mode update via power-reset on PPC devices;
*) dhcpv4-client - allow selecting to which routing tables add default route (additional fixes);
*) disk - allow to add swap space without container package;
*) disk - fixed showing free space on tmpfs (introduced in v7.17);
*) disk - improved system stability when SMB interface list is used (introduced in v7.17);
*) dns - do not show warning messages for DNS static entries when they are not needed;
*) file - fixed missing meta information from special files such as packages (introduced in v7.18beta2);
*) file - hide store directories, such as container (introduced in v7.18beta2);
*) sfp - improved system stability with some GPON modules for CCR2004 and CCR2116 devices (additional fixes);
*) snmp - added "mtxrAlarmSocketStatus" OID to MIKROTIK-MIB;
*) switch - allow entering IPv6 netmask for switch rules (CLI only);
*) switch - fixed dynamic switch rules created by dot1x server (introduced in v7.17);
*) switch - fixed issues with inactive hardware-offloaded bond ports;
*) switch - improved egress-rate on QSFP28 ports;
*) system - fixed a potential memory leak that occurred when resetting states after an error;

Amm0 · Fri Feb 07, 2025 6:14 pm

I really like the eSIM support and works great, however it's not complete as only the following 3 parameter can be used
Hello pidro, do you have an eSIM that requires the Confirmation code? Can you please contact us at support@mikrotik.com?

Do I have to ask support to even know modems eSIM commands works on?

I guess I can... but geez this should be published somewhere.
I asked this question about eSIM a few times before when the commands started appearing. Above suggest they work in some modem...now which who knows....

pidro · Fri Feb 07, 2025 6:32 pm

Hi,

I sent a test eSIM and they tested it. This is what I got back at the end.
"Hello,

We tested the confirmation-code parameter and it seems to work, we will add this option in the next beta release. I deleted the esim profile after provisioning it.

Thank you,

Emīls T."

Not sure if this update contains the fix and I can't test it at the moment.
I'm using with a 5ber eSIM and recently ordered couple more and turned out 5ber did some changes so there new eSIM no longer working
https://github.com/creamlike1024/EasyLPAC/issues/22 so do not buy 5ber eSIM. About the built in eSIM in the modems when I tried it last time, I failed and Quectel is not really helpful. Mikrotik maybe able to force though as the are a big customer of them.

msilcher · Fri Feb 07, 2025 7:00 pm

What's new in 7.18beta5 (2025-Feb-07 12:25):

*) dhcpv4-client - allow selecting to which routing tables add default route (additional fixes);

Very welcome!! A long-awaited feature :)

It would be nice to allow multiple "routing tables selection" and per routing table "default route distance" settings. This would allow an easy failover setup based on multiple DHCP connections with 2 or more routing tables.
This is actually only possible with static routes but it is not flexible -> https://help.mikrotik.com/docs/spaces/R ... WAN+Backup

pe1chl · Fri Feb 07, 2025 7:06 pm

I have a CHR "free" which I have used a since quite a while for v7 testing and where I always install the betas first.
Since this week (when updating to beta4) I found that it has logged:

system,error,critical could not save configuration changes, not enough storage space available.

and indeed the disk (256MB) is completely full.
When I reboot it, the space is again as normal (22MB used).
When I wanted to install beta5 it again had used a lot of space (84MB free) but the update installed OK, however after reboot the disk was full again.
I cannot find what fills the space, there is nothing under Files and no script or similar that would use space.
The only thing special is that it is not connected to internet so maybe it is doing something to verify its license state?

Edit: It seems erratic. Sometimes it fills the disk, sometimes not, but when not it still writes over 5000 sectors per hour on a router that sits idle.

Amm0 · Fri Feb 07, 2025 7:11 pm

Re "new eSIM support"... (and @pidro - my complaints were more toward MT - point being distilling forum posts that should be in docs is annoying)

- Not sure if this update contains the fix and I can't test it at the moment.
- I'm using with a 5ber eSIM [...] turned out 5ber did some changes so there new eSIM no longer working [...] so do not buy 5ber eSIM.
- About the built in eSIM in the modems when I tried it last time, I failed [...] Quectel is not really helpful.
- Mikrotik maybe able to force though as the are a big customer of them.

My frustration is that a few paragraphs of "official" text on some of these topics would go a long way. I have hundreds of LTE devices, so yeah eSIM be nice feature... but I can only guess at what exactly the eSIM commands do. I get they handling talking to some eUICC LPA - in some form - but that can be implemented in physical SIM/JavaCard (i.e. 5ber), hardware, or in modem modules themselves.

Maybe just me, but I like to have a plan for future. But Mikrotik likes playing hide-and-seek with information and likes surprise – sometimes bad (device-mode) and sometimes good (file-share, scripting). A few paragraphs of text on some of these topics would go a long way. Mikrotik is really bad at that it seems. Like there already should have been some "A note to our customers about device-mode" on their website. Or on LTE, they seem to fail to regularly update the "Peripherals" page (https://help.mikrotik.com/docs/spaces/R ... eripherals) with new information – in fact it look roughly same as 10 years ago - eSIM should be at least noted "In 7.18beta, eSIM works with x", someplace.

eider · Fri Feb 07, 2025 7:56 pm

It would be nice to allow multiple "routing tables selection" and per routing table "default route distance" settings. This would allow an easy failover setup based on multiple DHCP connections with 2 or more routing tables.
This is actually only possible with static routes but it is not flexible -> https://help.mikrotik.com/docs/spaces/R ... WAN+Backup

This can be easily achieved with a script creating static route entries, so I don't think it's a priority feature to anyone and honestly only works on best-effort basis anyway. For example, one of my ISP cable modems advertises fake DHCP lease with management IP (192.168.100.0/24) when link is down, so I have to be clever and do

:if ([:len ($"lease-options"->"6")]) do {

if I want my failover to work :>

pe1chl · Fri Feb 07, 2025 8:04 pm

What's new in 7.18beta5 (2025-Feb-07 12:25):

*) dhcpv4-client - allow selecting to which routing tables add default route (additional fixes);
Very welcome!! A long-awaited feature :)

It would be nice to allow multiple "routing tables selection" and per routing table "default route distance" settings. This would allow an easy failover setup based on multiple DHCP connections with 2 or more routing tables.

What would be REALLY useful is a way to configure en extra routing table with automatic import of "connected" routes from the main table, preferably via an interface list. That would make it so much easier to use secondary routing tables!
As it is now, a secondary routing table starts completely empty so it cannot even route traffic to local interfaces. Let alone distribute routes via an autorouting protocol. One always has to make manual copies of connected routes into the secondary table, which is easily forgotten or causes problems when changing IP adresses, either manually or via DHCP.

However when I tried to make a feature request for this, my explanation was apparently not understood and they tried to convince me that what I want is a VRF, not multiple routing tables.
However, VRF is not versatile enough for what I want, e.g. load balancing, overlay networks, etc. Not customer isolation.

eider · Fri Feb 07, 2025 8:11 pm

However when I tried to make a feature request for this, my explanation was apparently not understood and they tried to convince me that what I want is a VRF, not multiple routing tables.
However, VRF is not versatile enough for what I want, e.g. load balancing, overlay networks, etc. Not customer isolation.

They were right. You can combine (not replace!) your current routing table approach with VRF and use route leaking to achieve this (see https://help.mikrotik.com/docs/spaces/R ... uteleaking).

pe1chl · Fri Feb 07, 2025 8:16 pm

I do not see how such a messy and convoluted workaround would be the best solution to have connected routes in a second routing table...
I don't want to associate a routing table with interfaces, that is not the goal.

eider · Fri Feb 07, 2025 8:27 pm

My frustration is that a few paragraphs of "official" text on some of these topics would go a long way. I have hundreds of LTE devices, so yeah eSIM be nice feature... but I can only guess at what exactly the eSIM commands do. I get they handling talking to some eUICC LPA - in some form - but that can be implemented in physical SIM/JavaCard (i.e. 5ber), hardware, or in modem modules themselves.

I do not believe eSIM functionality is intended for any of the current devices and are likely aimed at future 5G devices.

I can confirm to you that none of the modems sold separately by MikroTik (that is, R11e-LTE, R11e-LTE6, R11e-4G, R11eL-EC200A-EU, R11eL-FG621-EA) support it.
As far as integrated modems go, RG502Q-EA and RG520F-EU on 5G end do not support it, and similarly, neither of EG12-EA, EG18-EA, EG06-A on LTE-A end support it either.

If you wish to test this functionality, you will need to equip yourself with some other modem that supports it.
---

but I can only guess at what exactly the eSIM commands do

They do exactly what they advertise to do. Configure and provision new eUICC. Typically this would begin with opening channel to ISD-R via AT command.

Fri Feb 07, 2025 8:47 pm

If you wish to test this functionality, you will need to equip yourself with some other modem that supports it.

And some other supported modems are ... brand/model ?

And that's the point Amm0 is making. We don't know.

Fri Feb 07, 2025 9:40 pm

On small setup with HAP AX3 as capsman and 2x CAP AX when i updated AX3 to 7.18.beta4 one of CAPs automatically upgraded to 7.18.beta4 but other identical one complains about this:
Code: Select all
G01718@D4:01:C3:C1:8B:BE%*9 upgrade request failed, no file (zerotier-7.18beta4-arm64.npk)
There is no zerotier on it or it was ever installed and both caps are 100% identical(reseted to cap mode via button)

Confirmed !
Used the same approach to upgrade from beta4 to beta5 via RB5009 capsman controller and 1 wap AX gave me this error. The other did not (neither did AX2 nor AX Lite).
I made supout file of the device and created a support ticket.
SUP-178777

TonyJr · Fri Feb 07, 2025 10:21 pm

Could somebody please post the default firewall entries for IPv4 and IPv6, as of 7.18beta5.

Fri Feb 07, 2025 10:26 pm

Here you go:

                     /ip firewall nat add chain=srcnat out-interface-list=WAN ipsec-policy=out,none action=masquerade comment="defconf: masquerade"                                  
                     /ip firewall {                                                                                                                                                  
                       filter add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"                   
                       filter add chain=input action=drop connection-state=invalid comment="defconf: drop invalid"                                                                   
                       filter add chain=input action=accept protocol=icmp comment="defconf: accept ICMP"                                                                             
                       filter add chain=input action=accept dst-address=127.0.0.1 comment="defconf: accept to local loopback (for CAPsMAN)"                                          
                       filter add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN"                                                     
                       filter add chain=forward action=accept ipsec-policy=in,ipsec comment="defconf: accept in ipsec policy"                                                        
                       filter add chain=forward action=accept ipsec-policy=out,ipsec comment="defconf: accept out ipsec policy"                                                      
                       filter add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack"                                        
                       filter add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related, untracked"                
                       filter add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"                                                                 
                       filter add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN comment="defconf: drop all from WAN not DSTNATed"
                     }                                                                                                                                                               
                     /ipv6 firewall {                                                                                                                                                
                       address-list add list=bad_ipv6 address=::/128 comment="defconf: unspecified address"                                                                          
                       address-list add list=bad_ipv6 address=::1 comment="defconf: lo"                                                                                              
                       address-list add list=bad_ipv6 address=fec0::/10 comment="defconf: site-local"                                                                                
                       address-list add list=bad_ipv6 address=::ffff:0:0/96 comment="defconf: ipv4-mapped"                                                                           
                       address-list add list=bad_ipv6 address=::/96 comment="defconf: ipv4 compat"                                                                                   
                       address-list add list=bad_ipv6 address=100::/64 comment="defconf: discard only "                                                                              
                       address-list add list=bad_ipv6 address=2001:db8::/32 comment="defconf: documentation"                                                                         
                       address-list add list=bad_ipv6 address=2001:10::/28 comment="defconf: ORCHID"                                                                                 
                       address-list add list=bad_ipv6 address=3ffe::/16 comment="defconf: 6bone"                                                                                     
                       filter add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"                   
                       filter add chain=input action=drop connection-state=invalid comment="defconf: drop invalid"                                                                   
                       filter add chain=input action=accept protocol=icmpv6 comment="defconf: accept ICMPv6"                                                                         
                       filter add chain=input action=accept protocol=udp dst-port=33434-33534 comment="defconf: accept UDP traceroute"                                               
                       filter add chain=input action=accept protocol=udp dst-port=546 src-address=fe80::/10 comment="defconf: accept DHCPv6-Client prefix delegation."               
                       filter add chain=input action=accept protocol=udp dst-port=500,4500 comment="defconf: accept IKE"                                                             
                       filter add chain=input action=accept protocol=ipsec-ah comment="defconf: accept ipsec AH"                                                                     
                       filter add chain=input action=accept protocol=ipsec-esp comment="defconf: accept ipsec ESP"                                                                   
                       filter add chain=input action=accept ipsec-policy=in,ipsec comment="defconf: accept all that matches ipsec policy"                                            
                       filter add chain=input action=drop in-interface-list=!LAN comment="defconf: drop everything else not coming from LAN"                                         
                       filter add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack6"                                       
                       filter add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"                 
                       filter add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"                                                                 
                       filter add chain=forward action=drop src-address-list=bad_ipv6 comment="defconf: drop packets with bad src ipv6"                                              
                       filter add chain=forward action=drop dst-address-list=bad_ipv6 comment="defconf: drop packets with bad dst ipv6"                                              
                       filter add chain=forward action=drop protocol=icmpv6 hop-limit=equal:1 comment="defconf: rfc4890 drop hop-limit=1"                                            
                       filter add chain=forward action=accept protocol=icmpv6 comment="defconf: accept ICMPv6"                                                                       
                       filter add chain=forward action=accept protocol=139 comment="defconf: accept HIP"                                                                             
                       filter add chain=forward action=accept protocol=udp dst-port=500,4500 comment="defconf: accept IKE"                                                           
                       filter add chain=forward action=accept protocol=ipsec-ah comment="defconf: accept ipsec AH"                                                                   
                       filter add chain=forward action=accept protocol=ipsec-esp comment="defconf: accept ipsec ESP"                                                                 
                       filter add chain=forward action=accept ipsec-policy=in,ipsec comment="defconf: accept all that matches ipsec policy"                                          
                       filter add chain=forward action=drop in-interface-list=!LAN comment="defconf: drop everything else not coming from LAN"                                       
                     }

TonyJr · Fri Feb 07, 2025 10:28 pm

Here you go:

                     /ip firewall nat add chain=srcnat out-interface-list=WAN ipsec-policy=out,none action=masquerade comment="defconf: masquerade"                                  
                     /ip firewall {                                                                                                                                                  
                       filter add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"                   
                       filter add chain=input action=drop connection-state=invalid comment="defconf: drop invalid"                                                                   
                       filter add chain=input action=accept protocol=icmp comment="defconf: accept ICMP"                                                                             
                       filter add chain=input action=accept dst-address=127.0.0.1 comment="defconf: accept to local loopback (for CAPsMAN)"                                          
                       filter add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN"                                                     
                       filter add chain=forward action=accept ipsec-policy=in,ipsec comment="defconf: accept in ipsec policy"                                                        
                       filter add chain=forward action=accept ipsec-policy=out,ipsec comment="defconf: accept out ipsec policy"                                                      
                       filter add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack"                                        
                       filter add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related, untracked"                
                       filter add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"                                                                 
                       filter add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN comment="defconf: drop all from WAN not DSTNATed"
                     }                                                                                                                                                               
                     /ipv6 firewall {                                                                                                                                                
                       address-list add list=bad_ipv6 address=::/128 comment="defconf: unspecified address"                                                                          
                       address-list add list=bad_ipv6 address=::1 comment="defconf: lo"                                                                                              
                       address-list add list=bad_ipv6 address=fec0::/10 comment="defconf: site-local"                                                                                
                       address-list add list=bad_ipv6 address=::ffff:0:0/96 comment="defconf: ipv4-mapped"                                                                           
                       address-list add list=bad_ipv6 address=::/96 comment="defconf: ipv4 compat"                                                                                   
                       address-list add list=bad_ipv6 address=100::/64 comment="defconf: discard only "                                                                              
                       address-list add list=bad_ipv6 address=2001:db8::/32 comment="defconf: documentation"                                                                         
                       address-list add list=bad_ipv6 address=2001:10::/28 comment="defconf: ORCHID"                                                                                 
                       address-list add list=bad_ipv6 address=3ffe::/16 comment="defconf: 6bone"                                                                                     
                       filter add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"                   
                       filter add chain=input action=drop connection-state=invalid comment="defconf: drop invalid"                                                                   
                       filter add chain=input action=accept protocol=icmpv6 comment="defconf: accept ICMPv6"                                                                         
                       filter add chain=input action=accept protocol=udp dst-port=33434-33534 comment="defconf: accept UDP traceroute"                                               
                       filter add chain=input action=accept protocol=udp dst-port=546 src-address=fe80::/10 comment="defconf: accept DHCPv6-Client prefix delegation."               
                       filter add chain=input action=accept protocol=udp dst-port=500,4500 comment="defconf: accept IKE"                                                             
                       filter add chain=input action=accept protocol=ipsec-ah comment="defconf: accept ipsec AH"                                                                     
                       filter add chain=input action=accept protocol=ipsec-esp comment="defconf: accept ipsec ESP"                                                                   
                       filter add chain=input action=accept ipsec-policy=in,ipsec comment="defconf: accept all that matches ipsec policy"                                            
                       filter add chain=input action=drop in-interface-list=!LAN comment="defconf: drop everything else not coming from LAN"                                         
                       filter add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack6"                                       
                       filter add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"                 
                       filter add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"                                                                 
                       filter add chain=forward action=drop src-address-list=bad_ipv6 comment="defconf: drop packets with bad src ipv6"                                              
                       filter add chain=forward action=drop dst-address-list=bad_ipv6 comment="defconf: drop packets with bad dst ipv6"                                              
                       filter add chain=forward action=drop protocol=icmpv6 hop-limit=equal:1 comment="defconf: rfc4890 drop hop-limit=1"                                            
                       filter add chain=forward action=accept protocol=icmpv6 comment="defconf: accept ICMPv6"                                                                       
                       filter add chain=forward action=accept protocol=139 comment="defconf: accept HIP"                                                                             
                       filter add chain=forward action=accept protocol=udp dst-port=500,4500 comment="defconf: accept IKE"                                                           
                       filter add chain=forward action=accept protocol=ipsec-ah comment="defconf: accept ipsec AH"                                                                   
                       filter add chain=forward action=accept protocol=ipsec-esp comment="defconf: accept ipsec ESP"                                                                 
                       filter add chain=forward action=accept ipsec-policy=in,ipsec comment="defconf: accept all that matches ipsec policy"                                          
                       filter add chain=forward action=drop in-interface-list=!LAN comment="defconf: drop everything else not coming from LAN"                                       
                     }

Many thanks!

Jotne · Fri Feb 07, 2025 10:34 pm

What's new in 7.18beta5 (2025-Feb-07 12:25):

No new fix to the logging, waiting:)
Router name are listed double and I do not syslog severity info , should be 0 to 7

2025-02-07T21:37:56.975+0100 Test-OVA CEF:0|MikroTik|x86 VMware, Inc. VMware Virtual Platform|7.18beta5 (testing)|10|system,info|Low|dvchost=Test-OVA dvc=192.168.22.11 msg=.....

Amm0 · Fri Feb 07, 2025 11:23 pm

I have hundreds of LTE devices
I do not believe

Well you don't know then do you? No need to believe - someone knows. Do they not sell things to customers who have questions?

If they spend weeks developing a feature, is too much for Mikrotik to say something. There are physical SIM card that contain a working eUICC (using JavaCard or something) and that could be how its implemented/supports - so possible could work on older models. All depends on implementation, not the CLI interface.

Maybe I'll ruin the surprise, but there look to be newer LTE models... but we'd only from random Twitter post, that someone happened to repost on the forum: viewtopic.php?t=213245#p1114487

So annoying.

eider · Sat Feb 08, 2025 12:19 am

And some other supported modems are ... brand/model ?

There are thousands of models out there. It is not MikroTik's job to direct you to their spec sheet, especially for something that they do not sell or even support (beyond best-case effort of generic driver). If you need to find one, go browse Fibocom or Quectel product sheets and look for chipsets that support eSIM - simple as that.

Amm0 · Sat Feb 08, 2025 12:48 am

And some other supported modems are ... brand/model ?
It is not MikroTik's job to direct you to their spec sheet

Since this is the beta thread... questions and feedback should be encouraged — without insulting comments from others. I made the points I want to make about eSIM — it was feedback to Mikrotik, not you. I like Mikrotik and their products & making suggestion for improvement in communication. If you think I'm "lazy", I don't care.

Anyway... different topic...

I came here to actually report about file-share. I've done a bit of testing of it & I think it's going to be a very useful feature.

Overall, file-share worked well, both in direct mode and via the proxy. I've mainly been testing in proxy-mode* since I want the https REST server working. And using it to copy scripts from my desktop to test router, without scp/etc. So I know the "Allow Uploads" works. :) If anyone's curious on how it works, without the spiff website, using command-line `curl`, I wrote that part up here: viewtopic.php?t=214555 .

My main issues come when sharing a single file... (which improved since beta2, so still oddities in beta4).

- "File Direct Url" should use the single file as part of the URL. While the link works, what happens is the filename is the "File Share Key" without extension (so the file cannot be opened by type). Adding the file the url does work, but it should be cut-and-paste from the Direct Url

- You can set the "Allow Uploads" when you have a single file, but the UI does not show an upload button when enabled. The idea being you might want to REPLACE a single shared file.

- After upgrade to beta5, my /ip/service/https was in "I" invalid state. Disabling and enabling the HTTPS service, didn't fix the invalid. I disabled all the /ip/cloud/file-share, and then disable and re-enabled HTTPS... and that worked to bring things back. I do have IP restricts set on /ip/service/https, so maybe that confused something. Anyway, the confused relationship (or perhaps just inversed?) with /ip/service/https and file-share is a bit confusing.

On the positive side,

- Liked how the web UI changed to a "icon view" when it was only a single — nice touch. (*other than upload button getting lost)

- Since I had to use "Inspect" of the file-share's webpage, to figure out file-share used "multipart/form-data" encoding. I took a peek at the HTML page... absolutely loved the minimalist/framework-less implementation - no libraries, just plain JavaScript!

My only enhancements be...

- While the CLI in /ip/cloud/file-share/settings/print tells the proxy vs not proxy. This is not obvious to most folks I'd imagine but effect troubleshoot... So file-share "status" should be in the webfig/winbox UI too. Also, the IP > Cloud dialog box is kinda odd now, since it shows ALL the BTH stuff on the "main" screen, while nothing about file-share. Basically IMO /ip/cloud/file-share/settings should appear as a top-level tab in winbox4, along with the BTH one (which has 3). Or perhaps the BTH should be also moved to a separate dialog to keep main IP > Cloud dialog "cleaner" or just pure status. Dunno... Anyway some thought should be given to look-and-feel on the "main" /ip/cloud screen ... now that it's getting more stuff under it ;).

- And, want some user-level control on proxy mode or direct mode - the automatic switch based /ip/services REST is kinda weird and should be controllable in some way. Perhaps some master switches in /ip/services is kinda where you configure the router's port listeners, dunno...

- TLS is so critical for many things now... and while kinda esoteric file-share has nifty support for automatically dealing with certificates. Poor /certificate/enable-ssl-certificate requires a complicated dance to deal with LE's HTTP auth (port 80) and the whole renewal is manual process repeats that pain. But, boy, /ip/cloud/file-share has all that down it seems... while "enable-ssl-certificate" is still – after years – a rather complex affair that likely detours TLS usage on webfig/IPSec/etc. Lots of places use TLS in RouterOS....

- Along same line, CORS support for REST API is still missing – that others could build nifty SPAs using REST, like file-share.

Anyway, generally, good work on file-share.

eider · Sat Feb 08, 2025 1:32 am

On the note of above, can we please separate cloud package from routeros? Devices like wAP do not need cloud or file share support (on what? that 16M of FLASH or 128M of RAM, maybe? or maybe user is expected to solder to USB pads on PCB?). I'm not gonna ask you to separate SMB/NFS/Btrfs support since that's all done in kernel modules and complicates your codebase (though would provide much needed space on devices with 16M FLASH storage, not like they're gonna be mounting any Btrfs disks anyway), but Cloud is just your code that can be separated easily and with how its growing in size, it might be about time to do it. I was quiet when you added BTH because it's mostly a wrapper on top of WG interface, but if you have plans to introduce even more functionality that is not re-using code from base then it needs to happen, period.

Ideally you'd keep it pre-installed on new devices of course, so that users get full access to it without having to install any additional packages (though it would seem you have made some good progress on that front in this version with ability to download packages from ROS itself).

volga629 · Sat Feb 08, 2025 5:18 am

About HW VXLAN.

Supported devices are ones that support L3HW offloaded fasttrack/NAT: CRS309-1G-8S+, CRS317-1G-16S+, CRS312-4C+8XG, CRS326-24S+2Q+, CRS326-4C+20G+2Q+, CRS354-48G/P-4S+2Q+, CRS504-4XQ, CRS510-8XS-2XQ, CRS518-16XS-2XQ, CRS520-4XS-16XQ, CCR2116-12G-4S+, CCR2216-1G-12XS-2XQ.

The main goal for v7.18 is to introduce basic VXLAN data-plane support. This allows you to set up static one-to-one mappings between VLANs and VXLANs in vlan-filtering bridge.

A configuration example (using static routing, but could be done through ospf,bgp):
sfp-sfpplus1 - upstream (underlay) interface
sfp-sfpplus3 - bridged port for untagged VLAN 10
sfp-sfpplus4 - bridged port for untagged VLAN 20
vxlan-1010 - overlay port for untagged VLAN 10
vxlan-1020 - overlay port for untagged VLAN 20
Code: Select all
/interface bridge
add name=bridge1 vlan-filtering=yes
/interface vxlan
add bridge=bridge1 bridge-pvid=10 local-address=192.168.1.1 name=vxlan-1010 vni=1010
add bridge=bridge1 bridge-pvid=20 local-address=192.168.1.1 name=vxlan-1020 vni=1020
/interface bridge port
add bridge=bridge1 interface=sfp-sfpplus3 pvid=10
add bridge=bridge1 interface=sfp-sfpplus4 pvid=20
/interface vxlan vteps
add interface=vxlan-1010 remote-ip=192.168.1.2
add interface=vxlan-1020 remote-ip=192.168.1.2
/ip address
add address=192.168.1.1 interface=lo network=192.168.1.1
add address=192.168.10.10/24 interface=sfp-sfpplus1 network=192.168.10.0
/ip route
add dst-address=192.168.1.2 gateway=192.168.10.20
/interface ethernet switch
set 0 l3-hw-offloading=yes
At this point, some known features are not yet implemented.

Underlay (routing encapsulated VXLAN packets):
1. VTEPs are not supported over ECMP
2. VTEPs are not supported over bond, VLAN interface
3. VTEPs cannot operate within VRFs
4. VTEPs are not supported with IPv6

Overlay (forwarding between Ethernet and VXLAN):
1. VLAN tagging over VXLAN is not supported
2. Routing between different VXLAN VNIs is not supported
3. VTEPs are isolated, and there is no mechanism to control "horizon" between them

These things will be mentioned in our help documentation page shortly.

Let us know what VXLAN-related features you need, this could help us prioritize development. Also, work on EVPN has started, but would like to hear from you about the most important capabilities and how you imagined they would look like in RouterOS.

I can offer all my technical knowledge for VXLAN and L2VPN EVPN family (quite some). I am having really hard time get static VXLAN running between 2 CHR in different cloud providers. Version 7.17. I am not sure if there any limitation. All underlay is running, I can ping loopback's. Overlay VXLAN is not forwarding traffic.

I think most common use case for EVPN family will be

East West stretch between leafs for internal any cast gateway

EVPN VXLAN Centralized Default Gateway

Cisco example

# Anycast Gateway MAC, identically configured on all VTEPs
fabric forwarding anycast-gateway-mac 0002.0002.0002

# Distributed IP Anycast Gateway (SVI)
# Gateway IP address needs to be identically configured on all VTEPs
interface vlan 201
  no shutdown
  vrf member Green
  ip address 192.168.1.254/24
  fabric forwarding mode anycast-gateway

KozmoNaut · Sat Feb 08, 2025 11:17 am

The above suggests to me MikroTik is still forcing <7.17 user into a lesser technical position without prior notice or consent. I'm sure MikroTik has reasons but I've not seen them make a compelling case so far. Finally, "I want" or "I don't want" require no justifications as both are simple value judgments and therefore idiosyncratic.

You are presumably a professional.

Professionally maintaining a system that other people use is different than running a home router and a couple of APs. That includes never installing updates without reading the changelogs, identifying possible critical changes and reading the relevant documentation. In case of doubts you contact your vendor for clarification (and not by accusing them on all kinds of things on their public forums).

And then you test the deployment and poke at the new changes before you make a decision to roll out in production. If any issues are identified, you contact your vendor and hold back on the roll-out.

What I've seen are people far to eager to install updates on production systems the second they get the notification and then complain when something changes that they could have read in the changelog and documentation.

pe1chl · Sat Feb 08, 2025 11:23 am

On the note of above, can we please separate cloud package from routeros?

Well, I really think that all applications should be separated in packages, not only that but also stuff like proxy, smb, hotspot, etc.
But as far as I understand the architecture there is some overhead for having a package, and thus the situation in a 16MB flash device where all the packages are loaded by default there will be even less available space.
Of course joe the average user will never remove the packages they do not need, so on average the situation will become worse.
However, now that adding a package has been made much easier (finally!) it might be possible to deliver the devices without such packages installed and direct the users to install them as needed. And on upgrades there could be some logic to install optional packages only when they had been configured at the time they were part of the base package.

rextended · Sat Feb 08, 2025 1:23 pm

(moved bottom)
viewtopic.php?p=1125322#p1125322

mkx · Sat Feb 08, 2025 1:45 pm

But as far as I understand the architecture there is some overhead for having a package, and thus the situation in a 16MB flash device where all the packages are loaded by default there will be even less available space.
Of course joe the average user will never remove the packages they do not need, so on average the situation will become worse.

I disagree ... it's about defining (MT's job with input from us, users) basic set of functionality, expected to be run by flash space constrained devices. And that should be included in base package, the rest should be in separate packages.

If device has plenty of storage (e.g. 128MB+), then a few 100kB (or whatever the package overhead) of increased usage doesn't matter that much. On the other hand inclusion of certain kernel modules and user space binaries (e.g. smb, nfs, BGP, etc.) to base package does eat into precious little storage on devices where those functions are not used. And I don't buy the "it's part of kernel, userland is neglectable" fame ... kernel modules can be installed by packages as well, userland is never neglectable. For example: BTRFS module on kernel 5.10 on x86-64 machine is hefty 3MB file ... yes, on ROS it's likely a bit smaller, but even 300kB spent on 16MB flash device with no need for BTRFS ever is outrageous (BTW, most wireless drivers in same kernel are much less tgan 1MB in size ... just to put things into perspective)

Yes, there will be people trying to use e.g. hAP ac2 (or CRS317) as NAS server, but most users will use it as intended (hAP ac2 as wireless router: no NAS, no routing protocols; CRS317 as switch: no NAS and no routing protocols). And mentioned two devices illustrate clearly why wifi/wireless drivers should not be part of base package ... CRS without wifi drivers can afford additional package with routing services and should still leave some flash free.
But should we all suffer because of a fraction of users who want to squeeze last drop of juice out of their underpowered devices? I think not, everything has its limits, sometimes one simply has to purchase a better device. And it's up to MT to decide about intended usage ... and hopefully stick to it during entire device lifetime, it doesn't resonate well for MT to decide that e.g. hAP ac2 is no longer a wireless router (instead it should be either simple AP or wired router).

infabo · Sat Feb 08, 2025 2:31 pm

It would already be sufficient if the 16MB devices (and there are quite a few of them) don’t run out of storage soon. The shrinking trend is once again noticeable with version 7.17 onwards.

pe1chl · Sat Feb 08, 2025 4:26 pm

Well of course it would be possible to have different routeros base packages, where the kernel modules and userland code for a lot of features are or are not present. I don't see the typical hAP ac2 user use stuff like MPLS, for example.
I can understand why MPLS would be difficult to keep in a separate package (it was in v6...) but should not be a problem as compile-time option.
It should be doable to group a number of "home" and "business" features and make 3 RouterOS versions out of them. (home, business, both)
And then at some point in time, the 16MB hardware would no longer be able to run the "both" version.

teslasystems · Sat Feb 08, 2025 4:44 pm

On "16MB" devices (like hAP lite) much bigger issue is RAM. I was unable to normally use my hAP lite on v7 with standard config and additional WireGuard tunnel. It was working by itself for a short period, but when you try to connect via WinBox and do something, CPU jumps to 100% and everything stops working. After some time it goes to reboot. On v6 it runs flawlessly, but there is no WireGuard.

mkx · Sat Feb 08, 2025 5:17 pm

On "16MB" devices (like hAP lite) much bigger issue is RAM.

There are two distinct types of 16MB flash devices:

generally base-line devices, such as hAP lite ... which lack RAM and fast CPU. However, as long as their CPU architecture is not ARM (hAP lite has SMIPS), those 16MB are not as tight (packages occupy a little less space)
generally decently modern devices (e.g. hAP ac2 or CRS317) with plenty of RAM and decent CPU resources. Which due to being ARM, use more of 16MB flash and cause configuration loss or other bad problems.

Your use case, with all due respect, falls into "device abuse" category. But with hAP ac2 and CRS317 (and several other devices) the flash size gets limiting factor even when using device in line with intended purposes.

teslasystems · Sat Feb 08, 2025 6:28 pm

Your use case, with all due respect, falls into "device abuse" category.

Where is abuse here? It was using default config. I've only added WireGuard for being able to control it remotely and transfer files sometimes. But even without WG it was barely working and it was hard to just log in. After reporting to support, they've improved behavior a little bit (MT, thanks), but anyway, it's far from ideal. It worked perfectly on v6 with IPSec instead of WG, but tunnel speed was twice slower compared to WG.

Amm0 · Sat Feb 08, 2025 6:37 pm

On that device, IPSec is hardware offloaded, while WG requires CPU... Question be how well does the IPSec config on v6 work when used as-is on v7 - that be more apples-to-apples test, given IPSec offloading.

But no doubt RouterOS v7 uses more RAM than v6. And I'm sure more optimization is possible in v7.

On "16MB" devices (like hAP lite) much bigger issue is RAM.
There are two distinct types of 16MB flash devices:

I add severity of issue as dimension in RAM vs flash debate. The lack of flash causes device upgrades to fail, while lack of RAM is trying too much on too small a device. I like the new file-share feature, and may try on 16MB thing - but I'm not playing using it on deployed fleet of wAPacR/hAPac2/etc (and can't on MIPSBE things). On newer hardware eventually. So the flash issue is a bigger one, since broken routers in field are costly in my case.

Issue today is I really do not want to have to pick between security and potential outages due flash issue on upgrade with these older 16MB devices. I'm fine without file-share etc on them. Between the FUD around "device-mode" and borked upgrades on 16MB flash... it is just going to cause folks to NOT upgrade & we're back at unpatched system with vulnerabilities down the road.

teslasystems · Sat Feb 08, 2025 6:41 pm

On that device, IPSec is hardware offloaded, while WG requires CPU...

Hardware offloading on hAP lite??? No, it's not :)

Amm0 · Sat Feb 08, 2025 6:49 pm

On that device, IPSec is hardware offloaded, while WG requires CPU...
Hardware offloading on hAP lite??? No, it's not :)

True. My bad! I thought complaints were on hAPac2... My main point was changing two things at same time, makes it hard to judge which is the bigger performance issue. i.e. V6+IPSec vs. V7+WG

mkx · Sat Feb 08, 2025 7:05 pm

Your use case, with all due respect, falls into "device abuse" category.
Where is abuse here? It was using default config. I've only added WireGuard ...

This. It's a lite, for Deity's sake.

mkx · Sat Feb 08, 2025 7:12 pm

makes it hard to judge which is the bigger performance issue. i.e. V6+IPSec vs. V7+WG

For RAM I'd say WG definitely ... because IPsec is part of ROS since ages and I'm sure they did whatever possible to reduce its memory footprint. I don't think they put the same amount of energy into WG so far.

I'm not saying anything about CPU utilization, but probably WG fares better (everybody's saying how WG is lighter on CPU than just about anything else, including CPU-driven IPsec).

eider · Sat Feb 08, 2025 7:54 pm

It would already be sufficient if the 16MB devices (and there are quite a few of them) don’t run out of storage soon. The shrinking trend is once again noticeable with version 7.17 onwards.

Thanks to file sharing, the growth between 7.17 and 7.18beta5 is about 120KiB. On a device that fits base + wifi-qcom-ac and minimalistic config with about 200KiB to spare (on 7.18beta5), this is worrying. On a device that wasn't netinstalled and upgraded from factory v6 (as new wAP still came with v6 from factory in 2024 it seems) this free space might be more like 140KiB. Two more updates like this and the device reaches definitive end-of-life. And it's not like these devices are old either, MikroTik has released devices with 16M storage in 2024 (see https://mikrotik.com/product/wap_ac_lte_kit24).

We need separation of packages like cloud for these ARM-based devices that are meant to be pure APs and come with 16M storage now and we need it badly, because users are suffering and unable to use their devices already.

I understand why MikroTik decided to abandon v6 model of dependent packages, but the growth rate of v7 has been unsustainable recently and I do not see easy way out if they want to continue cramming all the features into base ROS package. Really struggling how MikroTik gonna stick to their "5 years of upgrades after purchase date" for some of devices released in 2024, because they are already failing on user's desks unable to take any config changes as they ran out of space!

Larsa · Sat Feb 08, 2025 8:30 pm

For RAM I'd say WG definitely ... because IPsec is part of ROS since ages and I'm sure they did whatever possible to reduce its memory footprint. I don't think they put the same amount of energy into WG so far. I'm not saying anything about CPU utilization, but probably WG fares better (everybody's saying how WG is lighter on CPU than just about anything else, including CPU-driven IPsec).

WireGuard is a part of the kernel since 5.6 and IPsec has been around since 2.6. Depending on the architecture, WireGuard (wireguard.ko) is about 100–150 KB, while IPsec, with its ~20 modules (xfrm_*.ko, esp*.ko, ah*.ko, etc.) handling tunneling, authentication, encryption, and compression, adds up to over 1 MB.

For a single tunnel and software-based IPsec, WireGuard is always faster and easier on the CPU. IPsec with hardware acceleration is an order of magnitude faster and more efficient, especially when running multiple tunnels, where WireGuard would likely max out a CPU with just one.

nclmrc · Sun Feb 09, 2025 12:32 am

note on container settings in v7.18beta4

had to change the Registry URL from "https://registry-1.docker.io/v2/" --> to --> "https://registry-1.docker.io"
now i can pull containers again

In beta5 pull container from https://registry-1.docker.io doesn't work

itimo01 · Sun Feb 09, 2025 1:14 am

note on container settings in v7.18beta4

had to change the Registry URL from "https://registry-1.docker.io/v2/" --> to --> "https://registry-1.docker.io"
now i can pull containers again
In beta5 pull container from https://registry-1.docker.io doesn't work

I'm using https://registry.hub.docker.com as you're supposed to according to some sources (including Podman).
Works great.

Amm0 · Sun Feb 09, 2025 2:43 am

In beta5 pull container from https://registry-1.docker.io doesn't work
I'm using https://registry.hub.docker.com as you're supposed to according to some sources (including Podman).
Works great.

Mikrotik has changed their mind a few times, so registry-1.docker.io was in docs at some point. FWIW, I think they're making changes, in this 7.18...

*) container - add default registry-url=https: //lscr.io;

They have also made subtle changes over several version... so whether you use a "fully qualified" path, with/without - like adding :latest or :stable yourself – can also effect whether it pulls an image, not just registry-url=. Hopefully there trying to clean up /container's pull because it often very picky (and/or appears not to work as a result). I don't know if changing to lscr.io will help, since never used their images — but DockerHub is full of containers not well suited to running in /container.

pe1chl · Sun Feb 09, 2025 11:54 am

(as new wAP still came with v6 from factory in 2024 it seems)

Really struggling how MikroTik gonna stick to their "5 years of upgrades after purchase date" for some of devices released in 2024, because they are already failing on user's desks unable to take any config changes as they ran out of space!

I think that refers to updates made to the software that came with the device. E.g. last week there was another v6 update.
You are presumed to run the (updated version of) the firmware that came with the device, which apparently is v6 for the wAP, and upgrades to v7 and more so to wifi-qcom-ac are "at your own risk".
(I think Normis specifically mentioned the latter here on the forum in one of the recent v7 release topics where people were complaining about hAP ac2 space shortage after they installed wifi-qcom-ac)

Around the time when "wireless" was split off from the main package, I had serious space issues on the hAP ac2 as well, but they were resolved. Apparently the memory map was changed, maybe a reserved area for the boot code was made smaller, or something like that. They apparently still spend considerable effort to keep everything in 16MB.
(we can only imagine when back in the days when 128MB was the normal flash size, they would have evolved to 512MB or 1GB on all devices... it would have been easy to provide a lot more functionality at a lot less developer effort)

pekr · Sun Feb 09, 2025 12:50 pm

For RAM I'd say WG definitely ... because IPsec is part of ROS since ages and I'm sure they did whatever possible to reduce its memory footprint. I don't think they put the same amount of energy into WG so far. I'm not saying anything about CPU utilization, but probably WG fares better (everybody's saying how WG is lighter on CPU than just about anything else, including CPU-driven IPsec).

WireGuard is a part of the kernel since 5.6 and IPsec has been around since 2.6. Depending on the architecture, WireGuard (wireguard.ko) is about 100–150 KB, while IPsec, with its ~20 modules (xfrm_*.ko, esp*.ko, ah*.ko, etc.) handling tunneling, authentication, encryption, and compression, adds up to over 1 MB.

For a single tunnel and software-based IPsec, WireGuard is always faster and easier on the CPU. IPsec with hardware acceleration is an order of magnitude faster and more efficient, especially when running multiple tunnels, where WireGuard would likely max out a CPU with just one.

IPSEC is a real configuration / maintanance PITA anyway, and as such should be eradicated from the planet Earth. :-) All of our branches are WG based nowadays, apart from central connection.The route to future is given and inevitable anyway. On the client side, our admins use WG tunnels as opposed to the Azure VPN ones based upon the OpenVPN protocol. The response latency is almos halved, ditto for loading times of a comples forms with under the 200 requests. WG is simply set-and-forget.

Genereally, MT should put sufficient resources into their HW. Then significant part of this thread would not be by full of complaints about the hw insufficient resources. How much more would the device cost doubling the resources anyway?

itimo01 · Sun Feb 09, 2025 1:41 pm

and as such should be eradicated from the planet Earth.

Well, I don't agree with you. There are many benefits to using IPSec over WireGuard.
Including HW-Accel. And Phase2 has many benefits.

Larsa · Sun Feb 09, 2025 1:45 pm

WireGuard works well for monitoring and management, but it’s not the best choice for large-scale operations that require many connections and high throughput. In these cases, IPSec is the only real option.

If someone finds IPSec tricky to set up, it’s likely more a matter of experience and expertise.

@pekt: There is no hardware support for WireGuard (ChaCha20) on any platform or brand.

teslasystems · Sun Feb 09, 2025 2:03 pm

Well, in numbers it looks like that for hAP lite, if someone is curious :)

WG 7.17rc3 ~40 Mbit/s
WG 7.18beta5 ~42 Mbit/s
Yes, on the latest beta it's about few megabits faster, so they are probably making some improvements.

IPSec (aes256/sha1) 7.18beta5 ~20 Mbit/s
IPSec (aes256/sha1) 6.49.18 ~23 Mbit/s
ROS v6 is little bit faster with IPSec.

gabacho4 · Sun Feb 09, 2025 3:00 pm

That isn't surprising since the hap lite doesn't have ipsec hw acceleration. I think it's been well established that, in those cases, wireguard is better (at least for a single tunnel) since chacha20 is easier on the CPU than traditional AES. The hap lite is also anemic and wouldn't be the device one would use in a situation where you needed many tunnels.

Edit: you forgot to include the percent of CPU use during those tests.

merkkg · Sun Feb 09, 2025 3:41 pm

That isn't surprising since the hap lite doesn't have ipsec hw acceleration. I think it's been well established that, in those cases, wireguard is better (at least for a single tunnel) since chacha20 is easier on the CPU than traditional AES. The hap lite is also anemic and wouldn't be the device one would use in a situation where you needed many tunnels.

Edit: you forgot to include the percent of CPU use during those tests.

I think his point is that with every update things are improving and we almost getting to ROS performance at least with that test.

It wasn't anything about CPU etc just results on each revision of ROS

teslasystems · Sun Feb 09, 2025 4:20 pm

The main idea was to show the difference in throughput between WG and IPSec, and that v7 is heavier for this router than v6.
BTW, MT once said that they don't recommend to use v7 on devices with <64 MB RAM...

CPU usage was 100% in every test, I thought it's obvious for such a weak router. And it seems to be the main limiting factor.

eider · Sun Feb 09, 2025 9:24 pm

I think that refers to updates made to the software that came with the device. E.g. last week there was another v6 update.
You are presumed to run the (updated version of) the firmware that came with the device, which apparently is v6 for the wAP, and upgrades to v7 and more so to wifi-qcom-ac are "at your own risk".
(I think Normis specifically mentioned the latter here on the forum in one of the recent v7 release topics where people were complaining about hAP ac2 space shortage after they installed wifi-qcom-ac)

Sadly for MikroTik, the linked above wAP ac LTE kit (2024) is marked as having "RouterOS v7" for OS, so at least these refresh devices do come with v7 and so must support v7 for 5 years. It's also worth to note here that the refresh kit does not change base hardware. The wAPGR-5HacD2HnD (newest revision being r3) that was at some point sold standalone and is still being sold with v6 in legacy R11e-LTE6 kit variant, just the modem was replaced from R11e-LTE to R11eL-EC200A-EU.

CGGXANNX · Sun Feb 09, 2025 10:00 pm

Regarding wifi-qcom-ac: I don't understand why they don't split it into two separate versions:

One for IPQ4018/4019-only devices (like the hAP ac²/ac³, wAP ac, cAP ac, Chateau, etc...), most of them with only 16MB flash.

And the current package for devices like the Audience which has both chips (but that device has 128MB storage) or devices with only QCA9984 like RB4011iGS+5HacQ2HnD-IN (512MB NAND).

Not shipping the firmware for QCA9984 in a package built for the IPQ 401x-only devices would reduce the package's size by 530KB (compressed size):

wifi-qcom-ac-firmware.png

That's a lot for the hAP ac²! And maybe even more can be removed from the other folders.

eider · Sun Feb 09, 2025 10:45 pm

I don't see it as a viable solution currently. Complicates which package is supported by which platform even more than current situation. Maybe some system where wireless package is .xnpk container with lot of smaller .npk which get automatically extracted in memory and only specific necessary ones are installed? That way user (and package update) only ever downloads one package and all hard stuff is abstracted away. This also doesn't break the fact current system relies on .npk and their signatures.

More than anything though, splitting base system feels like a requirement either way. I'm not talking about serious splitting like in v6 era, but the cloud and file management features should be separate, just like rose-storage, gps or iot already is.

CGGXANNX · Sun Feb 09, 2025 11:08 pm

I mean MikroTik creates an additional package wifi-ipq-ac.npk for instance, which they can generate automatically from wifi-qcom-ac, because it's just a SquashFS file with one directory content removed.

Currently when you upgrade from 7.12.x to 7.13+, the main routeros package is upgraded to routeros and wireless.npk. You have to read the documentation (or the forum) to know to remove wireless and install wifi-qcom-ac instead. It's not done automatically at all. Which means the documentation only needs to be updated to mention wifi-qcom-ac for Audience and RB4011, and wifi-ipq-ac for all the other devices. From now on, owners of hAP ac² after upgrading from 7.12.x will install wifi-ipq-ac after reading the docs (and don't need to care about wifi-qcom-ac at all).

For the users who already did the manual upgrade to wifi-qcom-ac. If they do nothing, upgrades to future versions will still pull the upgraded version of wifi-qcom-ac, and it's still compatible, until the point when they are no longer able to (because routeros or wifi-qcom-ac have become too bloated). Those users will then look in the docs or ask the forum and will be told to replace wifi-qcom-ac with wifi-ipq-ac and regain 530KB.

guipoletto · Mon Feb 10, 2025 5:48 am

I don't see it as a viable solution currently.

v7.18 introduced "automagic" package fetch from "cloud / remote server"
All available packages appear "greyed", and "enable" auto-fetches and installs .npk

So we are not that far off (technically), from being capable of further dismembering big packages into more platform-specific

Mainly, Mikrotik would have to decide how much granularity they're willing to support, versus support calls from confused users
That second part could be mitigated by only showing compatible drivers for that specific arch/board

Another further optimisation, would be to not carry all routerboot updates, for all $boards in $arch, every version
we could have designated bootloader-updating "golden releases", and other "general releases", where bootloader upate could be still done via a manual .fwf download
or even a new "booatloader" .nps, with dynamic "decompress-use-delete" in RAM

CGGXANNX · Mon Feb 10, 2025 9:32 am

And 38KB in the main package can be freed by getting rid of the two .woff2 font files that came with the new webfig interface in 7.17. The fonts are low quality and blurry (bad/no hinting) anyway, Here is a screenshot comparison between the MT font (the .woff2 files) and the system fonts (frees up 38KB from routeros.npk):

webfig-font-2.png

mkx · Mon Feb 10, 2025 11:29 am

All available packages appear "greyed", and "enable" auto-fetches and installs .npk

So we are not that far off (technically), from being capable of further dismembering big packages into more platform-specific

From user's perspective, seeing list of available optional packages on device itself is huge step in right direction. The way it was done until now (downloading separate ZIP file, extracting wanted package, uploading it to device, rebooting) was very error prone ... one had to select correct architecture and exactly correct version (matching installed version).

IMO the only remaining reason not to have pretty granular packaging is the package overhead ... which is only relevant on devices with tight flash space where higher granularity is actually required due to inadequate flash space in the first place and those devices wouldn't have many packages installed anyway.

So I'm optimistic to see packaging go in direction of high granularity, the same as we've seen in v6.

pe1chl · Mon Feb 10, 2025 11:48 am

Regarding wifi-qcom-ac: I don't understand why they don't split it into two separate versions:

That already happened. We now have wifi-qcom and wifi-qcom-ac. Before that, there was no chance to install on 16MB devices.
But maybe the wifi-qcom-ac should instead be two other packages.
Unfortunately each such step makes the upgrade/downgrade situation more tricky, we have seen this in the past as well when optional wireless packages were introduced and later renamed or dropped.

pe1chl · Mon Feb 10, 2025 11:49 am

From user's perspective, seeing list of available optional packages on device itself is huge step in right direction. The way it was done until now (downloading separate ZIP file, extracting wanted package, uploading it to device, rebooting) was very error prone ... one had to select correct architecture and exactly correct version (matching installed version).

It is many years ago that I first suggested that (together with dropping the combined package in v6)... I am very happy that it has finally been implemented.
(and a bit dismayed that some people see it as a bug)

mkx · Mon Feb 10, 2025 11:59 am

Regarding wifi-qcom-ac: I don't understand why they don't split it into two separate versions:
That already happened. We now have wifi-qcom and wifi-qcom-ac. Before that, there was no chance to install on 16MB devices.

It was (again) bad decision by MT to split wifiwave2 package into "AC" and "newer" packages ... instead of splitting it into "16MB AC" and "all of them". It was perfectly possible to install the pre-7.13 wifiwave2 package in Audience (even in parallel / on top of legacy wireless) and radios worked fine (and on hAP ac3 IIRC), so the need for split was only for 16MB flash devices.

Sometimes I get impression that MT decisions are "over thought" and "too conceptual" instead of being "engineering" decisions. Yes, "engineering" decisions are sometimes too partial, but they generally work very well ... while "academic" (conceptual, ...) decisions might look great but often lack practical usability.

mozerd · Mon Feb 10, 2025 1:03 pm

Sometimes I get impression that MT decisions are "over thought" and "too conceptual" instead of being "engineering" decisions. Yes, "engineering" decisions are sometimes too partial, but they generally work very well ... while "academic" (conceptual, ...) decisions might look great but often lack practical usability.

100% CORRECT 100% ...

victorbayas · Mon Feb 10, 2025 2:52 pm

For add default fasttrak when up from betaX to beta5 just paste this on terminal. New installed devices, or resetted, are already ready.
Code: Select all
{
/ipv6 fire filter
remove [find where comment="defconf: fasttrack6"]
add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack6"
:local idone [find where comment="defconf: fasttrack6"]
:local idtwo [find where comment="defconf: accept established,related,untracked" and chain=forward]
:put $idone
:put $idtwo
move $idone destination=$idtwo
}
For full default firewall rules:
viewtopic.php?p=1124805#p856824

Thanks!

rextended · Mon Feb 10, 2025 3:35 pm

I correct the description, it is misleading...

To add default fasttrak when updating from ANY v7 previous version, just paste this into the terminal
(barring arbitrary changes to the default configuration already made).
New devices netinstalled with beta4 and later, or restored with default configuration on beta4 and later, are already ready.

{
/ipv6 fire filter
remove [find where comment="defconf: fasttrack6"]
add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack6"
:local idone [find where comment="defconf: fasttrack6"]
:local idtwo [find where comment="defconf: accept established,related,untracked" and chain=forward]
:put $idone
:put $idtwo
move $idone destination=$idtwo
}

For full default firewall rules:
viewtopic.php?p=1124805#p856824

infabo · Mon Feb 10, 2025 4:07 pm

It was (again) bad decision by MT to split wifiwave2 package into "AC" and "newer" packages ... instead of splitting it into "16MB AC" and "all of them". It was perfectly possible to install the pre-7.13 wifiwave2 package in Audience (even in parallel / on top of legacy wireless) and radios worked fine (and on hAP ac3 IIRC), so the need for split was only for 16MB flash devices.

Sometimes I get impression that MT decisions are "over thought" and "too conceptual" instead of being "engineering" decisions. Yes, "engineering" decisions are sometimes too partial, but they generally work very well ... while "academic" (conceptual, ...) decisions might look great but often lack practical usability.

I find this criticism unfair toward Mikrotik. It is neither "overthought" nor "over-conceptualized," nor should it be viewed negatively in any way. If anything, the approach was not thought through thoroughly enough. Likewise, a "16MB AC" package plus "the rest" would also be a short-sighted solution (number of supported chipsets growing). Having 128MB of flash storage does not mean that space should be used wastefully. Why should I install 30MB of unnecessary wifi drivers when I only need the driver for a single chipset on my device? At some point, the "rest" package will become so large that users with 64MB partitions will run into storage issues.

Ullinator · Mon Feb 10, 2025 6:06 pm

*) dhcpv4-client - allow selecting to which routing tables add default route (additional fixes);

Please, please, the same for PPPoE and DHCPv6 Client!!!
That would be great for DUAL-ISP setups and regular changing IP´s / Prefixes as here in Germany :-)

Amm0 · Mon Feb 10, 2025 7:24 pm

*) dhcpv4-client - allow selecting to which routing tables add default route (additional fixes);
[...] That would be great for DUAL-ISP setups and regular changing IP [...]

I'm still looking for a "Check Gateway" option in /ip/dhcp-client as that's ALSO needed for "DUAL-ISP" setups too. While script can solve... setting the basic check-gateway=ping should be an option in DHCP client, since using a script add fragility for something important like DHCP (i.e. one error in a DHCP script, or version breaks something in scripts, etc.... then no WAN route). And, FWIW, even detect-internet wouldn't save a bad script, since you do have a DHCP client already...so it's rules ain't not help here