I have a trunk from a Sisco switch to sfp-sfpplus24 in this MikroTik CRS326-24S+2Q+. In this setup and with clients connected to the cisco on vlan22 I can ping both a client (192.168.22.131) connected to the MikroTik and vlan22s IP set in the mikrotik, 192.168.22.5.
If a client in the cisco is connected to vlan11 I can NOT ping the 192.168.22.5 address for the MikroTik switch, but I can ping the clients on the MikroTik switch, for instance 192.168.22.131.
So, is it obvious what I have missed in this config blocking non vlan22 hosts on the cisco to reach the mikrotik vlan22 ip 192.168.22.5? Want to reach it for management purpose.
In summary:
Clients on vlan22 in cisco can reach mikrotik vlan22 IP, 192.168.22.5
Clients on vlan22 in cisco can reach mikrotik vlan22 clients
Clients on vlan11 in cisco can NOT reach mikrotik vlan22 IP, 192.168.22.5
Clients on vlan11 in cisco can reach mikrotik vlan22 clients
Also you have configured the bridge-to-CPU interface to be both tagged and untagged, and there is a mismatch between the bridge ports pvid= and bridge vlan untagged= settings - if you remove all of the untagged= entries these will be created dynamically from the pvid= settings.
Depending on how other devices handle traffic being unexpectedly tagged or untagged communication may not work.
Nice catch! That was it. Thanks! Oddly I cannot remote the first initial config line I had, it just refuses to remove it but might be me that’s over-tired.
Have this now and all seems to work properly, even though I assume that the first line should be removed (it I could)
Sorry to bother you about this, but I’m probably blind here. Can you point me more directly to these two? I don’t see it. I’m not used to mikrotik syntax so probably obvious and just me not seeing it.
you have configured the bridge-to-CPU interface to be both tagged and untagged
there is a mismatch between the bridge ports pvid=
The first line should be removed. Try this procedure (done via CLI):
go into /ip/route
execute command “print”
note the index number of the offending route entry. Index number is the number in first column and very lijely tge offending entry will have index numver equal to 0
execute “remove ” where is value, noted in previous step.
Ah, the route is dynamic, so you can’t remove it. The question then is what does add it? My suspicion is on “detect internet”, check if it’s enabled and set its interface list to “none”.
Will look further into that. Not sure there’s a good way to trace what’s triggering something to be dynamic…? Don’t think it’s detect internet, looks to be no interfaces with it.
You’re right, it doesn’t seem to be “detect internet”.
You may want to post (again) (complete) config of your CRS … we might be able to spot some other suspect of doing that …
Sometimes, after extensive configuration changes, things may go out of sync and actual running setup is not what config says it should be. Sometimes device reboot fixes things. Sometimes it is necessary to reset config (to factory default, I believe that with CRS that’s empty config) and to re-apply config (preferably by reapplying commands from exported text config, binary backup may contain the unwanted hidden config).
Thanks. I did a config reset and redid it. Now I don’t see it in terminal but still a dynamic route in GUI. So seems to be a bit of a mismatch of what you see in gui and terminal. But it works, so I think I’m fine with it. Thanks again.
I read the links suggested by @tdw. Not sure I’m wiser about those error spotted in config though. But since it seems to work and be stable I’ll keep it as is.
Thanks! 
Oddly I cannot remote the first initial config line I had, it just refuses to remove it but might be me that’s over-tired.