I have several of these units that were all installed 3 years ago and 2 of them are failing. It seems that when they handle heavy network traffic the leds on the ports go out and eventually the unit reboots and works again, does this sound like bad capacitors?
Definitely try replacing just the power adaptors first. Network load means CPU load, CPU load means power load, power load means power drops if the capacitors' capacity is much smaller than nominal.
- the original units are running routerOS 6.28 and the replacement units are on routerOS 6.43.12, does this impact using backup or export?
it does in terms that the newer ROS will have to convert the configuration from the old format to the new one. Upgrade from 6.28 to 6.43 includes several major changes so I wouldn't dare to do that in a single step, I would take the last release within each third 6.xx between 6.28 and 6.43 or so and upgrade the old units all the way to the 6.43.12 if you want all conversions to be done automatically and minimize the risk of incorrect conversion. Of course first do both backup
into files and download the files to a PC before starting the journey.
- i have read that backup should only be used on the same model and routerOS version so this may not be my best choice
Even worse, never restore a backup on another device than the one where it was saved, even on the same model. It includes even MAC addresses so all kinds of surprises happen when you restore it elsewhere.
- will using the /export commands be the best choice? What settings does export not include?
Yes, definitely. Use /export without hide-sensitive
and without verbose
. If you want, you may even try to import it manually section by section from 6.28 to 6.43 if you are not afraid of converting from "master port" to "bridge" this way - it's a more intellectual effort than 10 upgrades in a row.
While importing manually, it is important to properly handle the collisions before or during the process, i.e either export the default configuration of 6.43.12 and copy only commands modifying it from the exported real configuration. If you decide to import automatically, add the waiting loop for interfaces to become visible to the beginning of the exported file, there are several topics regarding this issue here.
You can see a related code in /system default-configuration print
output, but basically you get the same effect if you just place :delay 2m
to the beginning of the .rsc file.
To import the file automatically (only
if it is already in 6.43.12 format and only after adding the delay to its beginning):
- iupload the file to the RB450's disk and reboot; if it remains available after the machine comes up again, you can proceed, otherwise you have to upload it with a flash/ before the name (some models need this, I don't know whether the RB450 is one of them)
- once you know that the file survives a reboot, do /system reset-configuration keep-users=yes run-after-reset=the-name-of-your-export and "skip all the warnings"
The export doesn't contain user accounts (which cannot be exported at all) and certificates. Certificates have to be exported separately using /certificate export-certificate
; for those which belong to the machine itself and therefore include private keys, you have to provide a passphrase, otherwise the private key will not be exported (without any warning) and the export becomes useless. For pkcs12, the certificate and the key are both in a single file, for pem, each is in its own (.pem and .key).
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.