can anyone explain?
I have rb5009 and 7.20.8 long term, I upgraded to 7.21.4 long term. will the "*) ethernet - change default L2MTU 1518 to 1596 for RB5009;" from 7.21 stable be applied in 7.21.4 long term? or will it be only what is specified in https://mikrotik.com/download/changelogs 7.21.4 long term? I don't understand anything.
@anav yes I opened a support ticket. They say to try 7.23beta1
I have wAP ax and after upgrade to 7.21.4 the 5ghz radio was gone, firmware was upgraded as well.
I had in logs: DefConf gen: Unable to find wifi radio data
Had to downgrade back to 7.20.8 to let it appear back, luckily it helped…
this is not working for us, rest api sessions still remain open.
As it says: "change default L2MTU" ... and changes to default settings are never applied during upgrade, they only apply when doing factory reset of configuration. If you want this setting to be applied, you'll have to do it yourself.
Other than that, as discussed already, changes described in 7.21.4 changelog are relative to 7.21.3 (which is preceding version) ... and 7.21 was forked off somewhere around 7.20rc so in theory there might be many differences (improvements) between 7.20.8 and 7.21.4, but the actual list is not easy to obtain due to how MT publishes changelogs.
My rb5009 (7.20.8) is set to 1514 for L2MTU... should I change that manually after upgrading to 7.21.4?
1514 was the default for the RB5009 until 7.21 (not 1518 like the changelog mentioned, that's a typo). You can keep that value if everything was working until now. One upside of manually editing the L2MTU to 1596 (the new default) is that the output of /export will not be cluttered by the l2mtu=1514 mention for the 9 interfaces.
I did the change on my RB5009 since 7.21rc and haven't observed any issues so far.
Now, another question: coming from, say, 7.20.8 (or an even older version), there might be several changes to the default values that you’d have to update manually if you wanted to. Is it easy to find these changes somewhere, or do you have to go through all the changelogs?
1596 is the default L2 MTU value for the chip set used used in RB5009 that was for some reason changed to 1514 in default configuration which is actually too small if you are using 802.1Q VLAN tagging (value recommended by Cisco is at least 1522). You can set the value to anything up to 9000 or more if supported by the chip, but what really matters is L3 MTU value which by default is 1500 and should be the same on all devices and hosts in your network.
So yeah you could and should IMHO change the L2 MTU value to 1596 which would actually delete it from configuration (because it is default for the hardware)...
And no you don't have to apply all versions because configuration and default values do not change unless you reset configuration in which case you will loose any changes you have made...
Normally, when the default value of some setting changes in a new version, and you upgraded your router from an older version where you've previously never made any changes to that setting, the device keeps the old setting value, and you should see them appearing in the output of /export.
That produces clutters in the /export content, and sometimes you want to get rid of those old values and use the new default. For many of such changes, you don't have to follow the changelogs, but can use @tangent's page where many of those changes are listed, with instruction on how to move to the new default:
No, 1514 was perfectly fine. It's was enough for 802.1Q VLAN plus the 8 bytes required for PPPoE MTU 1500 with RFC 4638. There was still 2 bytes left after that (1514 - 4 - 8).
L2MTU in RouterOS context is not the full ethernet frame size, the MAC addresses are not included, for example. See this video:
As there was the need to replace an aging router still running v6.49.19 with another one (a CCR1009 which also still had v6) I configured that one by cut/paste of the original router’s export, all was OK, then I selected “upgrade” to 7.21.4 but it did not go completely OK.
The router was configured with BGP peers (only our own network, not internet BGP) and after upgrade to 7.21.4 there was no Instance created, and the connections complained with “instance not active”. I created an instance named “default” and set the correct routing table, router ID and AS. In Winbox the connections now showed instance default and could be OK’d but the problem remains. In commandline the connections had instance=*0 and it could be fixed using set instance=default [find].
Apparently the new “instance” feature is not handled by the v6→v7 conversion.
@pe1chl The BGP instance not being created was already an issue in v7.20.7.
Yeah I remember when instance first appeared the upgrade within v7 also failed (i.e. BGP down after upgrade) but on my own router I think it worked OK (instance was created).
We have a network of many routers still on v6 and using BGP for routing, and such issues are a nuisance when upgrading remotely. Which gets postponed again and again because of this. I did this test to see how it would work now, because the router is now at a friend’s home and thus can be accessed when things go wrong. But usually our routers are in difficult-to-access locations like telecom towers or other tall buildings. Of course that is also why we hate device-mode.
While I appreciate the release of v7.21.4, the continued absence of delegated-ipv6-prefix support is becoming indefensible. In 2026, proper IPv6 prefix delegation shouldn't be a luxury—it’s a basic requirement for any scalable ISP operation. We need MikroTik to stop lagging behind on core networking standards that have been industry norms for years.
the question was whether 7.21.4 long term contains corrections from 7.21 stable, and to check this you can take 5009 update it to 7.21.4 long term and reset it to default and see L2 MTU.. can someone do it?
You can easily test that yourself. A 5009 can be partitioned, make 2 partitions and copy 0→1 then you can do whatever you like (upgrade, reset config etc) and afterwards you activate the other partition and reboot, it will be all the same as it was before.
It does, default L2MTU is 1596 now in 7.21.4, it was 1514 in 7.20.8.
Meaning if you do not have L2MTU set in configuration (as shown in export) it will be 1596 in 7.21.4 and it was 1514 in 7.20.8.
To find out default value you can just reset the interface configuration...
interface/ethernet/reset [ find default-name~"ether" ]
interface/ethernet/reset [ find default-name=sfp-sfpplus1 ]
interface/ethernet/export
# 2026-04-22 05:44:08 by RouterOS 7.21.4
... blank config
interface/ethernet/print detail
Flags: X - disabled, R - running; S - slave
0 S name="ether1" default-name="ether1" mtu=1500 l2mtu=1596
# on 7.20.8
interface/ethernet/export
# 2026-04-24 12:05:00 by RouterOS 7.20.8
... blank config
interface/ethernet/print detail
Flags: X - disabled, R - running; S - slave
0 RS name="ether1" default-name="ether1" mtu=1500 l2mtu=1514
What I kind of do not understand why this particular settings is so important to you, in most cases these 82 bytes are not used at all (this is just a max value) and you could always set it to whatever you need, nobody would change the code base just to steal 82 bytes from L2MTU default value...
thanks! L2 MTU setting is not important for me, it was important for me to know that 7.21.4 long term also contains changes from 7.21 stable, so the list of changes 7.21.4 long term is lying and not correct, I will create an appropriate ticket in the support service so that they correct the description on the page https://mikrotik.com/download/changelogs
Not sure what this meant:
www - improved service stability when cancelling REST API sessions;
but I upgraded my test 4011 to 7.21.4 and see no change to the situation with increasing numbers of hung REST API login sessions.
2 days after upgrade:
[jMikroTik] > /user/active/ print count-only
339