Guys,
Can anyone please provide me with the config for a simple managed switch please?
Static managed IP address
DHCP provided from the WAN router on port 1
All ports as switch and able to reach each other, and receive DHCP from the WAN router via port 1
Nothing else, no WiFi etc.
Thank you in advance
With or without VLAN ?
Since you mention managed switch, I assume with VLAN.
The De Facto VLAN bible, see section on switch.
http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1
If without:
remove all firewall and NAT rules
put all ports as member of bridge
remove all interface lists
put dhcp client on bridge
Done.
/interface bridge
add ingress-filtering=no name=bridgeSwitch vlan-filtering=no
/interface list
add name=TRUSTED
/interface bridge port
add bridge=bridgeSwitch interface=ether1
add bridge=bridgeSwitch interface=ether2
add bridge=bridgeSwitch interface=ether3
add bridge=bridgeSwitch interface=ether4
add bridge=bridgeSwitch interface=ether5
/interface list member
add interface=bridgeSwitch list=TRUSTED
/ip address
add address=192.168.0.X/24 interface=bridgeSwitch network=192.168.0.0
/ip neighbor discovery-settings
set discover-interface-list=TRUSTED
/ip dns
set allow-remote-requests=yes servers=192.168.0.1
/ip route
add dst-address=0.0.0.0/0 gateway=192.168.0.1 routing-table=main
/tool mac-server
set allowed-interface-list=none
/tool mac-server mac-winbox
set allowed-interface-list=TRUSTED
Assuming 192.168.0.0/24 is your lan subnet.
Instead of using dhcp client you can set the fixed LANIP of the switch on the router network ( best bet is to put the switch outside the IP pool of the upstream router )
or you can forget the address and use IP DHCP client as noted above
Thanks you guys 
I finally got it working.
The issue appears to be that I was accepting a default config with a lot of extra stuff in it.
I cleared the config and followed the steps that you’ve outlined and now everything is working.
Thanks again!
@anav
Now that the OP issue is solved, can we talk of the absolute minimum configuration?
In my perverted mind it would be:
/interface bridge
add admin-mac=<tt:uu:vv:xx:yy:zz> admin-mac=no name=bridge1
/interface bridge port
add bridge=bridge1 interface=all
/ip dhcp client
add disabled=no interface=bridge1
/system clock
set time-zone-name=<your location>
I have this one as an experiment on a hAp Lite (running 6.49.17) and it seems to work just fine (I have also the wireless interface set as station-pseudo-bridge and - disabled - the pwr-line interface).
I understand that having the categorization as interface list TRUSTED (and limiting winbox to it) and adding the single ports to the bridge is only a preparation for further modifications, but not really-really needed.
From what I understand the /system clock setting that I have is only needed (or is it not?) because on the dhcp client I have use-peer-ntp=yes (default).
I don’t really know if these settings are correct, but the device gets the right date/time automatically.
On the dhcp client I also have use-peer-dns=yes (default) and (again I don’t know if that is the key setting) I have no issues, so the:
/ip dns
set allow-remote-requests=yes servers=192.168.0.1
maybe is not really-really needed?
On the other hand, if the dhcp client is not used, I presume it would be needed some explicit ntp settings to have the right date/time.
What is the reason for:
/tool mac-server
set allowed-interface-list=none
since the:
/tool mac-server mac-winbox
set allowed-interface-list=TRUSTED
what is the effect in practice?
The last question is easiest … imagine someone connecting to your router via its mac address only? Is that acceptable?
No, the only access via mac address should be via winbox since its encrypted. Now if one doesnt change default winbox port, cant help that.
Not perverted and probably fine if you do it successfully.
The additional bits allow an MT device to be discovered on a network of MT devices.
The other bits ensure that the admin if residing on the device directly or any other user follows only the paths directed.
It has no effect on what I call the transparent users ( flowing in and out of ports due to vlans ).
I see now, that prevents telnet connections, thanks 
.(I wish the good Mikrotik guys had called it “/tool mac-server telnet”)
But the moment the device has an IP address one can still connect via browser/webfig?
I.e. is there a need for a firewall rule like:
/ip firewall filter add chain=input src-address=X.Y.Z..0/24 action=drop protocol=tcp dst-port=80
to prevent it?
Or there is some other way? (that one would only work form the local lan, a source address of 0.0.0.0/0 is possible?)
What about the:
/ip dns
set allow-remote-requests=yes servers=192.168.0.1
is this needed only when a static address is assigned to the bridge or when using the DHCP client the use-peer-dns=yes is enough? (or possibly both are not needed atall since the device is (should be) a L2 switch)? 
Another way, maybe more efficient than the firewall rule, would be adding “Available From” addresses at the service level:
/ip service set www,www-ssl address=X.Y.Z..0/24
What about the:
/ip dns
set allow-remote-requests=yes servers=192.168.0.1
>
> is this needed only when a static address is assigned to the bridge or when using the DHCP client the use-peer-dns=yes is enough? (or possibly both are not needed atall since the device is (should be) a L2 switch)? > :question:
This is needed for the switch itself in order to provide the Internet connectivity. The switch will be able to connect to the MikroTik cloud for time updates or connect to package update servers for enabling _/system package update check-for-updates_ functionality. 3 settings are needed in manual configuration: an IP address, a DNS server and a default route. If DHCP client is enabled for the bridge, all 3 can be received automatically (with _use-peer-dns=yes_ and _add-default-route=yes_).
What you don't want is _allow-remote-requests=yes_ as that will enable DNS caching server on the switch.Thank you , so one should go for the:
https://help.mikrotik.com/docs/spaces/ROS/pages/328229/IP+Services
way and disable services, to prevent access from anything but Winbox, then, if I get it right, the none in mac-server has in practice the same effect as disabling the telnet service, but this latter seems “cleaner” to me .
I was able to connect to the device using /tool/mac-telnet with the settings below. So disabling telnet service in IP Services does not disable mac-telnet. It’s a different kind of telnet
The /tool/mac-server set allowed-interface-list=none is recommended measure to increase the security of the device:
https://help.mikrotik.com/docs/spaces/ROS/pages/328353/Securing+your+router
No idea I always turn off all services except winbox and sometimes ssh.
Ah, ok, I thought that mac-telnet was dependent on telnet service, good to know that it Is instead completely independent and thus must be restricted separately.