@netravnen
Wow - thanks for the info.
Not sure if it’s related, but
DUDE DATABASE MOVED, 2M SECTOR WRITES IN TWO DAYS. AFTER ROS UPGRADE TO v7.12?
I think I almost immediately upgraded CCR2004 to v7.12 and I noticed today that since a couple of day my dude database was moved from USB/SSD storage to my main disk causing about 2.000.000 sector writes in two days (previously was 2M in 6 month).
Now I disabled dude, moved data directory again to usb/ssd, but dude refuses to stay running; after a reboot it turn stopped and data durectory revert to main disk.
EDIT:
Upgraded Nov 12 2023 from 7.11.2 to 7.12
# 2023-11-11 22:00:00 by RouterOS 7.11.2
# software id = G8MZ-MQ11
# model = CCR2004-16G-2S+
#
# 2023-11-12 22:00:00 by RouterOS 7.12
# software id = G8MZ-MQ11
# model = CCR2004-16G-2S+
Are you sure it’s not because the slot name of USB disk changes after reboot ?
I was unable to import the public key ED25519 from my YubiKey, either via the WinBox GUI “User List” or via the terminal command
/user ssh-keys import public-key-file=flash/pub/id_ed25519_sk.pub user=my-user
It gives the error “unable to load key file (wrong format or bad passphrase)!”.
The contents of the file “id_ed25519_sk.pub” is:
sk-ssh-ed25519@openssh.com AAAAGnNrLXNzaC1lZDI1NTE5QG9wZW5zc2guY29tAAAAIAA0HdRkQwPCMwy/KxKR3A49kleuXZMvknZbU9aO0Ob2AAAAFnNzaDpZdWJpS2V5XzE4LjA4Ny43OTA= my-user@my-domain.com
I thought this update, to RouterOS v7.12, would allow the use of ED25519 keys for SSH into RouterOS.
Did I do something wrong or misunderstood “ssh - added support for user ed25519 public keys”?
As usual, you do not provide any useful info, like from what version you upgrade…
That’s expected and has been so ever since auto-upgrade is available. The reason is that .fwf files with new routerboot are part of ROS package and are only available after new ROS version gets installed. What the auto-upgrade=yes does is that it installs the new routerboot firmware right after new ROS boots for the first time (so one doesn’t have to go via System->RouterBOARD->Upgrade manually) … but an extra reboot is still necessary.
Just my 2 cents.
Can Mikrotik add a flag to reboot the router automatically just after software + firmware upgrade ?
Like:
/system routerboard settings
set auto-upgrade-reboot=yes
This will have the advantage of having only one down time (and only one operation) for the cost of a small extra down time.
In production this will be very valuable.
It really isn’t a good idea (anymore) to set automatic firmware upgrade. The reason is that the firmware version now changes every time, it is the same as the RouterOS version. But usually there is no update at all in the firmware. Update just does nothing, but it incurs a small risk of rendering the router unbootable and requiring a netinstall using the backup booter.
It is best to update the firmware once after purchase of the device, and then only when release notes indicate some firmware change is required for the particular device you are running it on.
Then you can just do a manual update and consider if you even need the change to become active rightaway, or can wait to the next reboot.
More harm can come from running a firmware version from 10 years ago, than upgrading the firmware each time automatically. I’ve seen too many MikroTik boxes in prod, running latest ROS, but firmware from 1965, and then they whine about why some SFP issue pops up or some other issues buried in the changelogs. I enforce auto-upgrade = yes as company policy, personally. But MikroTik could probably improve the user experience here, for sure.
*) ovpn - improved system stability;
So can we assume OpenVPN is in a state comparable to ROS 6 again, stability-wise? Every release after 7.6 has been horribly unstable (including numerous complete lockups) for me, for any system running even one OVPN client.
Would be awesome if I could actually try new versions again on important routers.
no
More harm can come from running a firmware version from 10 years ago, than upgrading the firmware each time automatically. I’ve seen too many MikroTik boxes in prod, running latest ROS, but firmware from 1965, and then they whine about why some SFP issue pops up or some other issues buried in the changelogs. I enforce auto-upgrade = yes as company policy, personally. But MikroTik could probably improve the user experience here, for sure.
I fully agree, we run into an issue when upgrading a CCR1009 with old firmware, after software update it never boot up, we have to do a net install.
This appends with 2 CCR1009 with old firmware and never with other CCR1009 having up to date firmware and bought at the same time.
As the firmware change every time now (at least the version), we set auto-upgrade = yes and do a reboot a minute or two after the upgrade.
Having this second reboot done automatically will be a good thing.
Of course he did not read what I wrote. I wrote “It is best to update the firmware once after purchase of the device” so you won’t have ancient firmware.
Bullshit. Buy a device today, netinstall with latest ROS and firmware. Now one year later, ROS version has changed 15 generations and firmware is 15 generations behind, and you’re back to ancient firmware.
What advice are you even giving here? I don’t see MikroTik advising customers to “run old firmware” in general. The consensus is ROS version and matching firmware versions ensures best possibility experience and stability.
I tried sha256, but it doesn’t work. I’ve tried other keys - shorter and nothing.
FRRouting 9.0.1
ipv6 ospf6 authentication key-id 1 hash-algo hmac-sha-256 key 12CBFE21AC3D4D981AD4FD32C1A28E0DBE259A1F60E35BB6C4ADECD2989432F6
RouterOS 7.12
/routing ospf interface-template set *9 area=backbone-v3 auth=sha256 auth-id=1 auth-key=12CBFE21AC3D4D981AD4FD32C1A28E0DBE259A1F60E35BB6C4ADECD2989432F6 + etc
Log:
default-v3 { version: 3 router-id: 10.***.***.1 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::****:6eff:****:c79b%ether2 } authentication failed from fe80::****:efff:fef2:****%*2 sha mismatch
@pe1chl, @DarkNate
Wrong concept for both:
The point is not to keep the old firmware forever,
but is don’t update it “instantly” when the new version comes out, without any test, automatically and without any control…
At least a waiting period of a few months and some test is recommended,
unless there is a very critical security update that do not involve _fullshift_™ CVE that start with “An authenticated user…”
I successfully imported ed25519 keys, created by openssh. The pub file starts with "ssh-ed25519 ", continues with 69 characters (the actual publuc key) and followed with key owner identification (user@host). Format of file on yubikey is obviously different and it doesn’t seem to be supported by ROS.
No in any way - see http://forum.mikrotik.com/t/v7-12-1-stable-is-released/171017/92
Just look at the 7.13beta1 changelog:
*) ovpn - improved memory allocation during key-renegotiation;
Am I the only one with conclusion, that MikroTik programmers are reimplementing existing code? I have such fears for years now.
If they would be taking the original OpenVPN source code, then they won’t have such problems - especially on the memory management level.
Thanks for input. It seems to to me that the slot is always pcie1.
As usual, I’m akways ready to reply to kind questions about useful informations needed to help me: from the previous version.
If you have any useful info, feel free to reply.
Until v7.12 in MPLS L3 env/ topology.
/routing/route/print where routing-table=xxxx or /ip/route print where routing-table=xxxx did not show any routes when /ip/vrf interfaces=none.
Interfaces must fill with some working interfaces (dummy loopback) to make it works.
we also have to enable disable the /ip/vrf after interface set/added.
in v6, as long we create /ip route vrf name ,RD, import RT , export RT and even though interfaces value “empty” routing can be received/ shown.
thx