Hi,
It just took me about 4 hours to recover from my upgrade to 6.48 on my RouterBoard 450G.
I have a configuration in which my WAN is connected via ether1, an adm net via ether2, the lan via ether3 and ether4 and ether5 is a VLAN tagged port for all of them. So I have VLANs, bridges and stuff. This is how my config looks like:
When I upgraded to 6.48, the router LAN and ADM interfaces worked but WAN did not work. After some time I found out that the upgrade messed up the config completely. All of a sudden there is a bridge1 with comment "Created from master port". In "Quick Start" (although I don't use it) it can be seen that suddenly the WAN IP and the LAN IP is missing.
The VLAN interfaces are now members of this unwanted "bridge1" device which previosly were member of ether1.
Here are the screenshots that I too from the upgraded system:
It's totally messed up so I had no choice than downgrading to 6.38.7. As an added bonus, this endeavor made my OpenWRT metarouter (including its entire configuration image) vanish, instead leaving a RouterOS metarouter with the same name behind.
Why is this update failing and how can I upgrade without loosing the configuration?
Why does 6.38 to 6.48.1 upgrade destroy my router and how can I avoid it?
You do not have the required permissions to view the files attached to this post.
Re: Why does 6.38 to 6.48.1 upgrade destroy my router and how can I avoid it?
The problem is that from version v6.41.0 onward there was the introduction of new bridge concept that removed the master/slave on ethernet ports.
This was documented in the release notes https://mikrotik.com/download/changelogs for v6.41.0.
At that point a script was made available to migrate old config into this new concept, which is what happened in your case when you jumped from an old and prior to 6.41.0 version into the latest v6.48.1.
So unless you start thinking at how to migrate into this new concept, otherwise you will have to stay on v6.38 on that router to avoid such issues.
Moving from v6.38 to v6.48 was a big jump (with lot of changes in between) to be done in one shot, without reading the release notes to see what was going to happen.
This was documented in the release notes https://mikrotik.com/download/changelogs for v6.41.0.
At that point a script was made available to migrate old config into this new concept, which is what happened in your case when you jumped from an old and prior to 6.41.0 version into the latest v6.48.1.
So unless you start thinking at how to migrate into this new concept, otherwise you will have to stay on v6.38 on that router to avoid such issues.
Moving from v6.38 to v6.48 was a big jump (with lot of changes in between) to be done in one shot, without reading the release notes to see what was going to happen.
Re: Why does 6.38 to 6.48.1 upgrade destroy my router and how can I avoid it?
For complex setups the replacement of master-port configuration with a hardware-offloaded bridge is not handled well by the upgrade process, as in your case. It isn't clear what your original setup was as there is a br-lan and a br-wan, but all five switch ports are configured for hardware VLAN switching which would be associated with a single master port. It will be a case of studying the implications of the new style configuration to see what changes would be needed for your implementation.
Not sure why the metarouter would be mangled, there may have been other major changes mentioned in the changelog which triggered this.
Where there is a big jump in versions it may be worth upgrading in steps to the version just prior to a major change (so 6.40.9 was the last before the master-port removal in 6.41, for example) and repeating if OK. Always make both a .backup, you can downgrade the firmware and restore the .backup if things go badly, and a .rsc, from /export file=somefilename which can be imported on other versions (sometimes requires tweaks as items and/or parameters change between versions)
Hopefully your existing setup has no access from either the outside or untrusted local devices as there are serious vulnerabilities in that firmware allowing the Mikrotik to be easily compromised.
Not sure why the metarouter would be mangled, there may have been other major changes mentioned in the changelog which triggered this.
Where there is a big jump in versions it may be worth upgrading in steps to the version just prior to a major change (so 6.40.9 was the last before the master-port removal in 6.41, for example) and repeating if OK. Always make both a .backup, you can downgrade the firmware and restore the .backup if things go badly, and a .rsc, from /export file=somefilename which can be imported on other versions (sometimes requires tweaks as items and/or parameters change between versions)
Hopefully your existing setup has no access from either the outside or untrusted local devices as there are serious vulnerabilities in that firmware allowing the Mikrotik to be easily compromised.
Re: Why does 6.38 to 6.48.1 upgrade destroy my router and how can I avoid it?
Thank you, that makes sense!The problem is that from version v6.41.0 onward there was the introduction of new bridge concept that removed the master/slave on ethernet ports.
This was documented in the release notes https://mikrotik.com/download/changelogs for v6.41.0.
At that point a script was made available to migrate old config into this new concept, which is what happened in your case when you jumped from an old and prior to 6.41.0 version into the latest v6.48.1.
So unless you start thinking at how to migrate into this new concept, otherwise you will have to stay on v6.38 on that router to avoid such issues.
Moving from v6.38 to v6.48 was a big jump (with lot of changes in between) to be done in one shot, without reading the release notes to see what was going to happen.
Got it.
That's not good news.
I have set up this box on a remote site I do not visit regularly and it's critical infrastructure.
So I'd like to avoid fiddling too deep with basic config like vlan, bridge etc.
I did this setup 8 years ago or so so I do not remember all the details. But br-lan and br-wan are bridges for WAN and internal LAN interfaces. Bridgde ports should be a) normal network ports b) VLAN tagged network ports c) various things like vif, sit or VPNs.For complex setups the replacement of master-port configuration with a hardware-offloaded bridge is not handled well by the upgrade process, as in your case. It isn't clear what your original setup was as there is a br-lan and a br-wan, but all five switch ports are configured for hardware VLAN switching which would be associated with a single master port. It will be a case of studying the implications of the new style configuration to see what changes would be needed for your implementation.
The way how I did it so far was:
I configured the switch using the port master method such that ether1=wan, ether2=adm, ether3=lan, ether4=lan, ether5=all (with VLAN tags):
Code: Select all
[admin@ugate] /interface ethernet switch port> print
Flags: I - invalid
# NAME SWITCH VLAN-MODE VLAN-HEADER DEFAULT-VLAN-ID
0 ether1 switch1 secure always-strip 3
1 ether2 switch1 secure always-strip 1
2 ether3 switch1 secure always-strip 2
3 ether4 switch1 secure always-strip 2
4 ether5 switch1 secure add-if-missing 0
5 switch1-cpu switch1 secure add-if-missing 0
[admin@ugate] /interface ethernet switch vlan> print
Flags: X - disabled, I - invalid
# SWITCH VLAN-ID PORTS
0 switch1 3 switch1-cpu
ether1
ether5
1 switch1 2 switch1-cpu
ether3
ether4
ether5
2 switch1 1 switch1-cpu
ether2
ether5
The adm interface is not bridged (it has its IP assigned directly) but for WAN and LAN I created a dedicated bridge br-wan and br-lan so that I can bridge other things like VPNs, vif etc:
Code: Select all
[admin@ugate] /interface bridge> print
Flags: X - disabled, R - running
0 R name="br-lan" mtu=auto actual-mtu=1500 l2mtu=1516 arp=enabled
arp-timeout=auto mac-address=E4:8D:8C:18:D5:A1 protocol-mode=rstp
priority=0x8000 auto-mac=yes admin-mac=00:00:00:00:00:00
max-message-age=20s forward-delay=15s transmit-hold-count=6
ageing-time=5m
1 R name="br-wan" mtu=auto actual-mtu=1500 l2mtu=1516 arp=enabled
arp-timeout=auto mac-address=E4:8D:8C:18:D5:A1 protocol-mode=rstp
priority=0x8000 auto-mac=yes admin-mac=00:00:00:00:00:00
max-message-age=20s forward-delay=15s transmit-hold-count=6
ageing-time=5m
[admin@ugate] /interface bridge> port print
Flags: X - disabled, I - inactive, D - dynamic
# INTERFACE BRIDGE PRIORITY PATH-COST HORIZON
0 vlan-wan br-wan 0x80 10 none
1 vlan-lan br-lan 0x80 10 none
2 I *13 br-wan 0x80 10 none
3 I *15 br-lan 0x80 10 none
4 vif1 br-lan 0x80 10 none
[admin@ugate] /interface bridge>
Code: Select all
[admin@ugate] /interface bridge> /ip addr print
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 10.7.1.3/24 10.7.1.0 vlan-adm
1 192.168.200.254/24 192.168.200.0 br-lan
2 73.93.102.170/29 73.93.102.168 br-wan
Does that make sense? Now my question would be: How can I migrate this to the new setup?
I do not understand how I would implement this with the new additional bridge as opposed to two separate bridges (which should be separate L2 networks!)
Thanks, as a first step I'll jump to 6.40.9.Where there is a big jump in versions it may be worth upgrading in steps to the version just prior to a major change (so 6.40.9 was the last before the master-port removal in 6.41, for example) and repeating if OK. Always make both a .backup, you can downgrade the firmware and restore the .backup if things go badly, and a .rsc, from /export file=somefilename which can be imported on other versions (sometimes requires tweaks as items and/or parameters change between versions)
Thanks for the tip with the rsc file, that I had missing.
Do you know how I can back up the image of the OpenWRT meta router? As I said, it just disappeared (have to set it up from scratch :( ) and I do not see any ways to save the image.
Thanks a lot!!
Re: Why does 6.38 to 6.48.1 upgrade destroy my router and how can I avoid it?
I don't think you have much option other than reorganising the bridge/VLAN setup. You could just convert from master-port to bridge and leave the VLAN interfaces attached to other bridges setup, except there are many pitfalls see https://wiki.mikrotik.com/wiki/Manual:L ... figuration especially points 6 to 8. Many of these exist even with the master-port setup, they were just not well documented.
Back when converting configurations with master-port setups I created a new bridge, moved the main interface plus attached references (VLANs, IP addresses, DHCP clients/servers, firewall interface names, etc.) before the upgrade to reduce who much the inbuilt conversion process had to do.
I always use safe mode when running sets of commands to adjust the remote configs which could result in things going badly wrong. As you don't have that option for firmware upgrades bench testing on backup hardware can uncover unexpected behaviour, and for really critical devices it may be better to configure an identical device and just swap them during a scheduled site visit.
Hopefully this device has not had its web UI or Winbox exposed to the general internet (i.e. remote admin access restricted by address lists or by using VPNs), otherwise it will almost certainly have been compromised and need a complete wipe with netinstall to remove all traces.
Assuming you don't require full wirespeed switching between the two LAN ports and trunk port (ether3/4/5) the simplest solution would be to have a single VLAN-aware bridge - this disables the hardware switching between ports, but other than the path mentioned all traffic has to be processed by the CPU in any case.
I've not used metarouter much, or for ages, mostly as it isn't supported on many of the newer Mikrotik architectures (ARM, MMIPS, TILE). There is this viewtopic.php?t=76972#p387564 in the forums, there may be other posts if you search the forum.
Back when converting configurations with master-port setups I created a new bridge, moved the main interface plus attached references (VLANs, IP addresses, DHCP clients/servers, firewall interface names, etc.) before the upgrade to reduce who much the inbuilt conversion process had to do.
I always use safe mode when running sets of commands to adjust the remote configs which could result in things going badly wrong. As you don't have that option for firmware upgrades bench testing on backup hardware can uncover unexpected behaviour, and for really critical devices it may be better to configure an identical device and just swap them during a scheduled site visit.
Hopefully this device has not had its web UI or Winbox exposed to the general internet (i.e. remote admin access restricted by address lists or by using VPNs), otherwise it will almost certainly have been compromised and need a complete wipe with netinstall to remove all traces.
Assuming you don't require full wirespeed switching between the two LAN ports and trunk port (ether3/4/5) the simplest solution would be to have a single VLAN-aware bridge - this disables the hardware switching between ports, but other than the path mentioned all traffic has to be processed by the CPU in any case.
I've not used metarouter much, or for ages, mostly as it isn't supported on many of the newer Mikrotik architectures (ARM, MMIPS, TILE). There is this viewtopic.php?t=76972#p387564 in the forums, there may be other posts if you search the forum.
Who is online
Users browsing this forum: erlinden and 26 guests