Hi everyone,

I've been running Mikrotik gear for a while, but with the new switch we have for the office, I'm trying to make sure I do things "properly". I'm attempting to follow the wiki, specifically, https://wiki.mikrotik.com/wiki/Manual:I ... figuration.
The switch I'm working with is the CRS354-48G-4S+2Q+, so where relevant I'm following the CRS3XXX pages.

My current configuration is using a bridge, and setting the IP address directly on the bridge, then ensuring the pvid of the bridge is 88, as this is the only VLAN I require management access from.
This seems to be in conflict with the wiki page which suggests that I should create a new VLAN interface in Interfaces -> VLAN, and assign the IP address of the switch to that. When I attempt to follow this as in the wiki, the switch doesn't respond to ARP on this new address. I have attempted assigning two IPs (one on bridge1, one on the vlan88 interface I created), and the old approach keeps working while the new one does not.

My questions are:
a) Is the current approach I'm using appropriate? Should I change it? I haven't noticed any problems with it as of yet, but I'd rather do this the right way than have headaches later
b) If I should not be using this approach, why would the instructions on the wiki under that section not work? From my current configuration, running the instructions from the wiki result in my switch no longer responding (or not responding on the new address):

If it helps, here is an excerpt of my current configuration (it's 48 ports, so I've stripped it down to a few example ports that should be relevant):

If you want to use CRS only as a managed switch with only one management VLAN:

1. Create single bridge
2. Add all ports in that bridge
3. For every port in the bridge configuration set PVID and type of filtering:
- admit all - for hybrid ports
- admit only VLAN tagged - for trunks
- admin untagged - for access ports
- also check the box ingress filtering
4. For now DON'T do nothing on bridge!
5. In interface menu create new VLAN interface:
- set VLAN ID
- for interface on which this VLAN should be choose bridge1 (the bridge you create in step 1)
6. Set IP address for newly created VLAN interface - this will be your management IP
7. Add default route
8. Now, go back to bridge configuration and BE SURE your configuration PC is connected to access port of the switch that belong to management VLAN!!!
9. In bridge configuration create new VLAN and:
- set VLAN ID - the same as VLAN interface you create in step 5!
- add as tagged ports "bridge1" and all trunk ports
- add as untagged ports at least access port of management VLAN you are connected to
10. Go to bridge configuration and:
- check VLAN filtering
- check Ingress filtering
- Frame types - admit only VLAN tagged
- DON'T change PVID, leave it 1, it doesn't matter and don't use VLAN 1 on access ports

Now, your switch is accessible from trunks with tagged frames with management VLAN VID and from access ports which are members of management VLAN.

You are running untagged on the switch-CPU link currently. There is an implicit "untagged=bridge1" on your bridge vlan statement by virtue of setting the pvid on the bridge itself.
If you want to run tagged on the link, then you need to set "tagged=bridge1,ether48" on the bridge vlan statement, as well as doing the 3 lines you mention for option b.
Also, you don't need to specify the untagged=ether30,ether31 for the same reason.

Be aware that it's easy to cut yourself off when doing this. Would recommend removing a port from the bridge temporarily and using that for management access (via the MAC address rather than IP address). Being connected to the bridge whilst changing the config of it is bad.

I see now looking at the wiki that it is included, though I missed it during my reading of it.

Thank you both. Adding tagged=bridge1 to the bridge VLAN has resolved the issue.

From my own experience, I once had a similar issue with VLANs on my Mikrotik gear. I followed the wiki instructions to the letter, but the switch just wouldn’t respond on the new VLAN IP.
In the end, I found that the problem was with how VLAN filtering was applied. I had to make sure that all ports on the bridge were properly tagged for the VLANs I needed, and sometimes a reboot or a reset was needed to get everything talking again. It’s a bit of a hassle, but it’s worth it to make sure everything is configured correctly.
Also, if you have any management software like Sugar Customer Relationship Management that you use for tracking configurations, it might help to keep an eye on any changes or issues.