Last year, I upgraded my Vodafone cable connection to Vodafone FibreX installation, and then installed a Mikrotik RB750Gr3 (hEX) router as the home gateway. That installation was on RouterOS 6.40.3, which was the latest at the time.

After a bit of configuration tweaking (showing in updates notes in the original blog post, the Mikrotik RB750Gr3 (hEX) worked pretty well. The main issue was that periodically the IPv4 DHCP session would get stuck for an extended period in a "Renewing" or "Rebinding" state, which seems to have been a later 6.xx release issue.

The Mikrotik RouterOS changelog for 6.42.2 (released last week, 2018-05-17) included the very exciting line:

*) dhcpv4-client - fixed DHCP client stuck in renewing state;

which sounded like it might fix this issue, so I wanted to upgrade.

However there was also another major change introduced with 6.41:

Important note!!! Backup before upgrade!
RouterOS (v6.40rc36-rc40 and) v6.41rc1+ contains new bridge
implementation that supports hardware offloading (hw-offload).

This update will convert all interface "master-port" configuration
into new bridge configuration, and eliminate "master-port" option
as such.

Bridge will handle all Layer2 forwarding and the use of switch-chip
(hw-offload) will be automatically turned on based on appropriate
conditions.

The rest of RouterOS Switch specific configuration remains untouched
in usual menus for now.

Please, note that downgrading to previous RouterOS versions will
not restore "master-port" configuration, so use backups to restore
configuration on downgrade.

which was the main reason I had delayed upgrading from 6.40.3 while other travel was going on. (I was aware of various attacks on Mikrotik default platforms, but I'd deliberately turned off most services, and implemented a strict firewall to minimise those risks.)

I implemented this upgrade over the weekend, and eventually got a working configuration again -- but it did not happen automatically, and required several configuration changes made via mac-telnet to make it work at all let alone equivalent to the older configuration. While investigating what was needed to make it work, I found limited documentation available, so I wanted to document what was required to make it work again.

At a basic level the configuration changes are:

  • The interface ethernet master-port=NNN option is now gone, which means there's no direct way to just group switch ports together on Mikrotik Routerboards -- you have to use a interface bridge instead.

  • The interface bridge port functionality has a hw=yes option available, while enables that port to try use the switch chip for hardware acceleration if the bridge features required are simple enough that the switch chip can do it.

So for a simple switch usage like my "group lan ports together in hardware" there is equivalent functionality, but it is not immediately obvious how to make it work -- and changes are required in many other places that reference the interfaces.

Doing the RouterOS upgrade is the same as usual, but for this particular upgrade there's a high likely hood of your "LAN" interfaces no longer working correctly until you make more configuration changes (at least if you have something different from the Mikrotik RouterOS out of the box defaults), so I'd suggest making sure that mac-telnet also works for you (I used MAC-Telnet from Mac OS X 10.11 which I compiled myself).

The basic upgrade is then:

  • Make sure mac-telnet logins work for you, as well as ssh logins, to the Mikrotik

  • Log into Mikrotik

  • Export configuration: /export name=mikrotik-rb750gr3-config.rsc

  • Download a copy of the mikrotik-rb750gr3-config.rsc to your desktop for reference (you will need to search it for LAN interface names later), eg, scp A.B.C.D:mikrotik-rb750gr3-config.rsc .

  • Download the appropriate version of RouterOS (eg, mmips for the RB750Gr3 / hEX)

  • Verify the checksums for the downloaded file against the checksums link in the download page

  • Upload the routeros-mmips-6.42.3.npk file to the router, eg, scp routeros-mmips-6.42.3.npk A.B.C.D:

  • Log into the Mikrotik, and do a soft reboot (the upgrade happens during the restart cycle only, so a power cycle will not trigger it): /system reboot

  • Wait for the "beep" start of boot and "beep beep" fully booted indications (which for a software upgrade take 1-2 minutes to arrive; much longer than for a normal reboot).

If you are lucky, ssh logins to the Mikrotik will work again, and you will be able to reach the Internet. That indicates most/all of the conversion was done automatically.

If not, like me, you may find that you cannot reach the Mikrotik via ssh or ping, nor can you reach the Internet, in which case manual config changes will be required. At this point you will be very glad you tested mac-telnet access in advance.

To fix things up to work with 6.41+ (eg, 6.42.3) in the same way as before:

  • Mac-telnet into the Mikrotik and log in. While there, verify that your Internet connection did actually come up, eg:

    /ip dhcp-client print detail
/ipv6 dhcp-client print detail
/ping IP-ON-INTERNET

  • Check if a bridge got automatically created, and if not, you will need to create one:

    /interface bridge print
/interface bridge add name=lan

  • Make sure the bridge is created without spanning tree enabled (ie, no STP/RSTP/MSTP) as the switch chip cannot handle that, and so using those features will force slow software switching. The default mode is RSTP, which will turn off hardware switching on several chipsets, including the RB750Gr3/hEX one.

    /interface bridge set protocol-mode=none
/interface bridge settings set allow-fast-path=yes

    (The switch chipset in some higher end models can support RSTP in the switch chip, in which case the default protocol-mode=rstp might be okay on those models. But it took me a long time to figure out that protocol-mode=none was essential on the RB750Gr3/hEX to get hardware acceleration back.)

  • Add each LAN ethernet port into the bridge, and update their comments to match:

    /interface bridge port add bridge=lan interface=ether2
/interface bridge port add bridge=lan interface=ether3
/interface bridge port add bridge=lan interface=ether4
/interface set ether2 comment="LAN (bridged)"
/interface set ether3 comment="LAN (bridged)"
/interface set ether4 comment="LAN (bridged)"

    Note that adding ports into the bridge will change those ports around in a way that will break the existing connections, so you may have to abandon your first mac-telnet session and start a new one at one point in that process. That was a bit disconcerting, but expected from mac-telnet in other situations. Fortunately it reconnected easily.

  • At this point, doing:

    /interface bridge port print

    should show "yes" in the "HW" column (to indicate they are capable of hardware acceleration) and a leading "H" in each line to indicate hardware acceleration is actually being used. Eg,

    [ewen@naos-rb750gr3] > /interface bridge port print 
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload 
 #     INTERFACE     BRIDGE        HW  PVID PR  PATH-COST INTERNA...    HORIZON
 0   H ether2        lan           yes    1 0x         10         10       none
 1   H ether3        lan           yes    1 0x         10         10       none
 2   H ether4        lan           yes    1 0x         10         10       none
[ewen@naos-rb750gr3] >

  • Update all the firewall rules that refer to ether2 (the old LAN switch master-port) to refer to the new bridge interface. You can find the affected rules by doing:

    /ip firewall filter print
/ipv6 firewall filter print

    and looking for red comment text like:

     34 I  ;;; in/out-interface matcher not possible when interface (ether2) is slave - use master instead (lan)

    where the "I" means the rule is "invalid", and thus being ignored (hence no access via ssh or to the Internet). Something like:

    /ip firewall filter print where invalid
/ipv6 firewall filter print where invalid

    might help.

    Find the affected rule numbers, and note if they are in-interface=ether2 or out-interface=ether2 and then update the in-interface=... or out-interface=... parts of the rules with something like:

    /ip firewall filter set 14,24,25,26,34 in-interface=lan
/ip firewall filter set 28,49,50 out-interface=lan
/ipv6 firewall filter set 21,22,23,37,38,45 in-interface=lan
/ipv6 firewall filter set 33,40,47,57,58,59 out-interface=lan

  • At this stage you should be able to ssh back into the Mikrotik again, and reach the Internet. Test that works.

  • It would be a good idea to make another config export at this point, and download that, as a work in progress:

    /export name=rb750gr3-6.42.3-partially-working.rsc

    as then you can search that for stray references to ether2.

  • Clean up the stray references to ether2 that you can find, by replacing them with the lan bridge interface. I found:

    /ipv6 address set 0 interface=lan
/ipv6 nd set 1 interface=lan
/ip address set 0 interface=lan
/interface list member set 0 interface=lan
/interface list member add list=mactel interface=lan

    plus some references in /system script entries I had created, which needed updating, and a need to remove ether2, ether3 and ether4 from /interface list member. Amongst other things this moves the actual IPs over to the lan bridge interface (which on IPv6 assigns another prefix from the pool; on IPv4 there will be a short service interruption as the LAN IP moves).

    You might want to search for ether3 and ether4 as well; in my case I only found those in /interface list member (tidied up above), and in the /interface bridge port configuration (which obviously needs to stay).

  • Test ssh, and mac-telnet, to the Mikrotik work. Test access to the Internet.

  • Assuming it looks good, I'd suggest rebooting the router again to make sure everything starts cleanly:

    /system reboot

    and re-testing access again.

  • If that is also good, explicitly upgrade the Mikrotik RouterBoard firmware:

    /system routerboard upgrade
/system reboot

    and check access again after rebooting. At this point:

    /system resource print
/system routerboard print

    should (as of 6.42.3) show version 6.42.3 as the active version (for both; older Mikrotik had a different numbering scheme for the RouterBoard firmware, but recently they moved to using the same numbering system for both).

Hopefully at this point you are both on the latest RouterOS/Firmware and have a working configuration and have hardware acceleration on the LAN (switch) bridge again. The upgrade process definitely could have been simpler/more automated, particularly for a "minor" version upgrade. But I am glad that mac-telnet worked, and that Mikrotik did provide a warning that this was a non-trivial upgrade (even if that warning is now increasingly buried down in the changelog...).