Here's the story of a brand new RB3011 I've been fighting today. There is something about this box that is not right, and I can't figure what it is.

First thing I did was to upgrade it to ROS 6.39.2.
My laptop was connected to eth3.
Then I took eth6 out of bridge and added vlans to it. A wAP ac connected to port 10 had the same vlans and by default eth10 has eth6 as master.
I setup switch -> vlan for all ports eth6-10.
Next I set eth4 and 5 master-port=none
Next I created a bridge for each of the vlans, added the vlans to the bridges, and also added eth4 and 5 to one of the bridges, and added IP addresses to each bridge
I then created dhcp servers to each bridge.
Now I could communicate with the wAP on eth10.

So far everything seemed normal.

Then I moved the cable from my laptop to eth4 - the laptop got IP in the correct rang for that port, but it could not communicate the RB3011.
I moved the cable back to eth3 and got connection to the RB within seconds. I then moved the cable to eth2 (master for eth3) and the same thing happened. I also tried eth5 with the same result. Eth6-10 was not wort trying as they were configured for vlan only.

I rebooted (unplugged power) the router. When it booted my laptop could communicate with the router from eth5. I moved it to eth3, the only port it would connect from before the reboot, but now it didn't work here. Turned out now it only wanted to connect in eth5. I let it sit in eth3 while I ate dinner, and when I came back nothing had changed.
I then found another pc. It could connect on all ports eth2-5. So I looked into the ARP table from the other pc, and could not find the problematik one. Then I looked in DHCP leases, deleted its two leases (one for eth2+3, one for eth4+5). Then ran dhcp renew, and now also the pc could connect on all 4 ports.

Now I did some configs of eth1+2+3 while the pc was connected to eth4.
Then I got to the point where I would connect a Dlink DGS-1200 to eth8. The switch had a lot of vlans configured (the same as I had on eth6+slaves) on the port I used to connect to RB3011. I got no communication between the switch and the 3011. I moved it to eth6, and still no communication between them.

Then I connected on of the untagged switch ports to eth5 at the 3011, and communication worked. So I moved the wAP from eth10 to the switch trunk port, and the wAP and switch communicated on all vlans. Hence I knew the the vlan config of the switch was ok.

Then I started adding vlans to the switchport and eth5, one by one to see where it fails. After adding all vlans, the communication still worked.
So I figured I could try the same on eth8. I set eth8 master-port=none and the plan was to add vlans one by one again. I got to 0. Switch did not communicate with eth8 on the 3011 at all, even without any vlans on the ports. Same thing on eth7.
Moving cable back to eth5 and swich-router communication was fine.

I then tested the wAP in eth7 - it worked perfectly. Tested in eth8 too - no problems at all.

So I rebooted the RB3011. It did not fix anything.

Then I ran backup and reset-configuration on the rb3011. With the factory default config everything worked - I could connect the laptop and the switch to any ports (eth2-10) on the RB3011. So I decided to restore the troublesome config from backup - and now the RB3011 works perfectly with the exact same config as before the reset. Now I can't make the RB fail at all. I'm even creating loops on the switch, on the rb, and between them. RSTP clears this out perfectly.

Does it make sense that a troublesome config is sorted by doing backup - reset - restore? Is it possible that winbox (3.11) does something to the config that is not included in the backup or restore process? Is it possible that editing/deleting some settings leaves something behind that confuses ROS? Like when I did the initial config, I did some mistakes that I corrected, - typo in bridge name, adding wrong interface to bridge, at first forgot to include switch2-cpu in the switch vlan config,... - could whatever these changes leaves behind be sorted when doing backup - reset - restore?
I feel I'm touching a bug here. Any thoughts?

I would make a backup of the config, then reset to factory and do a very simple config, then test each port. You may have inadvertently changed something in the config that killed the port. If you want a simple setup - clear the config, then set ports 2,3,4,5 to master port 1. Ports 7,8,9,10 to master port 6. Add ports 1 and 6 to a new bridge. Assign the bridge an IP. then statically assign your notebook the next IP. confirm that you can plug into each port and ping the router.

If they all work, then you have a config issue. if port 3 doesn't work, get a replacement from the vendor.

That's pretty much what I did. Hence I temporary concluded a faulty config, but what could be causing such behavior? After all the problem were first observed on ports that was unchanged from the default settings. And why is the problem impossible to replicated when config is restored from a backup? If there was a config issue, the issue should have been restored as well! And why would deleting entries from dhcp lease table solve a communication issue with a device that already has an IP assigned? Here are so many things that indicate something else than a config issue.

Very odd indeed. This is one of those times that we may just not have an answer. If I was in front of the box and was able to go through the config line-by-line, I might be able to figure it out. But I've often just found that a fresh start is a better way to deal with it.

Well, at least we've learned that the fastest way to a fresh start may be backup - reset - restore.

I had a new case of a similar subject. I had 11 vlans configured on eth5. Then I got the need for the same vlans on sfp1. I figured the fastest way to get them all in place was to do an export compact, search/replace the interface name, and run the resulting script. That was a mistake. I did not change the name of the vlans. That messed things up. After this the router did no longer respond on IP on any interfaces.
Luckily I had disabled firewall rules, so I could still log in with winbox using mac address. Then I tried the backup - reset - restore method. And it worked! After restore the router was back to where it was before I ran the troublesome script, except for one thing: the vlan interface with the same name as the first add-command of the script was no longer member of any bridge.