I got some strange router behavior after upgrading it from ROS6 to ROS 7 (to be strict ROS 7.7). The main problem: the router began to reboot literally every 5-20 minutes. And all in all, the operation of the device has become extremely unstable, for example, I can unsuccessfully try to configure the DHCP server until the router reboots, and after rebooting everything works (but something other may 'fall off' after the next reboot). If I downgrade the router back to ROS6 it works as good as always, but when I upgrade back to ROS7 (7.7 as well 7.8 ) it became unstable again. I tried to remove any default configurations before reinstalling the software (NetInstall used), making sure that there were no bridges left in the configuration, but this did not add much stability. Please help me understand what's wrong!

I tried to remove any default configurations before reinstalling the software (NetInstall used), making sure that there were no bridges left in the configuration, but this did not add much stability. Please help me understand what's wrong!

The risk averse method of moving from ROS v6 to ROS v7 is to export your configuration with
than copy it to your computer so you have it as a reference at hand (for Internet and WiFi setup among other things). Than Netinstall the last stable version (currently ROS v7.8 ) with selecting the discarding previous configuration option/switch, than rebuild your configuration from scratch step by step with the reference information of the exported file.

Unfortunately the default configuration on the following devices:

• RB2011iL-IN
• RB2011iL-RM
• RB2011iLS-IN
• RB2011UiAS-IN
• RB2011UiAS-RM
• RB2011UiAS-2HnD-IN
• RB3011UiAS-RM
• RB4011iGS+RM
• RB4011iGS+5HacQ2HnD-IN
• RB1100AHx4
• RB1100AHx4 Dude Edition

which have more than one switch chip is one which is mentioned as a typical Layer 2 misconfiguration in the current documentation: Bridgeing and Switching Case Studies / Layer2 misconfiguration / VLAN filtering with multiple switch chips. Upon checking the block diagram of RB2011UiAS-2HnD-IN one can see that it has two switch chips and a WLAN module too therefore from performance point of view having a single bridge with all of the ports may be suboptimal. According to the current documentation the RB2011UiAS-2HnD-IN has an Atheros 8327 and a Atheros 8227 switch chip. The two switches have different Bridge Hardware Offloading capabilities. Beside this these two chips have other differences too as described in the Bridging and Switching / Switch Chip Features as described in the documentation. Therefore to maximise the throughput you should use two separate bridges: one for the SFP and Eth1 to Eth5 ports (your Internet uplink should not be in the bridge) and another one for Eth6 to Eth10 ports while keeping in mind not to enable features on the two separate bridges that are not supported in the respective switch chip's hardware.

As a side note should you decide to implement Basic VLAN switching following the case study in the documentation than heed the warning in it:

On QCA8337 and Atheros8327 switch chips, a default vlan-header=leave-as-is property should be used. The switch chip will determine which ports are access ports by using the default-vlan-id property. The default-vlan-id should only be used on access/hybrid ports to specify which VLAN the untagged ingress traffic is assigned to.

and adapt the configuration (bridge1 should only have the Atheros8327 connected ports):

And in case of the solution for VLAN filtering with multiple switch chips adapt the solution code as following:

However please do check that switch1 is the Atheros8327 and switch2 is the Atheros8227 one before applying any of the above.
You may do the check in the terminal with the
command.

As per @hecatae 's advice disabling the LCD display increases the router's responsiveness and achievable bandwidth.

As a side note in case you receive IPv6 prefix than you may want to start using it as in case of using GUA or ULA addresses the less resource hungry stateless firewall (raw) can be used instead of the stateful (nat, filter) one which is a must in case of using NAT. Using ULA with NPT enables users with dynamically assigned IPv6 addresses/prefix to avoid the internal reconfiguration of their network each time the ISP assigns a new address/prefix. For details see: NPTv6 / RFC 6296 Support? post #32 and NPTv6 / RFC 6296 Support? post #35. Using ULA enables the convenient use of IPv6 on a LAN with the help of RouterOS' built in DNS resolver. For example to easily reach the printer on the LAN:
While we are at ISP provided (dynamic) IPv6 addresses/prefixes: the default route (router advertisement) should come from:
as the
(note the add-default-route=no in the second command).