Routing Issue

RouterOS General
1

I use two interfaces in the same network, one to be reachable by an out-of-band on a dedicated untagged port and the second is used in-band. But i have issues to reach the device.
The default route should use the interface of bridge ‘bridge’ but i think it’s using ether49 instead.

My target is to make the device reachable even on misconfiguration on a dedicated port but in the same network segment.

Config Snippet:

/interface bridge
add admin-mac=**ELIDED** auto-mac=no comment=defconf \
    ingress-filtering=yes name=bridge pvid=199 vlan-filtering=yes
add name=mgmt
/interface ethernet
set [ find default-name=ether2 ] comment=core_re2
/interface list
add name=LAN
/interface bridge port
add bridge=bridge comment=defconf frame-types=admit-only-vlan-tagged \
    ingress-filtering=yes interface=ether2
add bridge=mgmt comment="OOB Management" untagged=ether49 vlan-ids=199
/interface list member
add interface=ether2 list=LAN
add interface=ether49 list=LAN
/ip address
add address=10.20.99.251/24 comment="Out-Of-Band Management" interface=\
    ether49 network=10.20.99.0
add address=10.20.99.200/24 comment="In-Band Management" interface=bridge \
    network=10.20.99.0
/ip route
add distance=1 gateway=10.20.99.1
2

Your current config is messy - the bridge named bridge has pvid 199 and 10.20.99.200 is attached to that bridge itself, so it is reachable using frames tagged with VID199 via ether2. That’s probably intended.

It seems that ether49 is or used to be a member port of bridge mgmt, but you have somehow removed too much when obfuscating the configuration, so the row of the /interface bridge port table for ether49 may be missing in the actual configuration or only in what you have posted, and the header of the /interface bridge vlan table is missing in the posted version as well. But if 10.20.99.251/24 is attached directly to ether49, ether49 should not be a member of any bridge, which makes bridge mgmt useless and the row bridge=mgmt comment=“OOB Management” untagged=ether49 vlan-ids=199 in /interface/bridge/vlan as well. Plus vlan-filtering is set to no on bridge mgmt so the VLAN-related configuration of that bridge is ignored.

Next, the thing is that if you attach addresses from the same subnet to two distinct interfaces, two routes to that subnet get added to the routing table dynamically, and from the user perspective, it is unpredictable which of them, and therefore which interface, will be actually chosen to send a packet. To control that, you may use additional routing tables and routing rules:
/routing/table
add name=via-bridge fib
add name=via-ether49 fib
/ip/route
add routing-table=via-bridge gateway=10.20.99.1%bridge
add routing-table=via-ether49 gateway=10.20.99.1%ether49
/routing/rule
add src-address=10.20.99.200 action=lookup-only-in-table table=via-bridge
add src-address=10.20.99.251 action=lookup-only-in-table table=via-ether49
This will only affect access from other subnets than 10.20.99.0/24 itself.

Unless you use check-gateway, a route stays active as long as the interface through which its gateway IP is available is up, and a bridge never goes down - even if all its member ports do. So instead of the above suggestion, you may try to put the two routes into the default routing table (main) with a different distance and use check-gateway to evenually deactivate the preferred one:
distance=1 check-gateway=ping gateway=10.20.99.1%bridge
distance=2 gateway=10.20.99.1%ether49
But it may not work as expected as I am not sure whether check-gateway takes the %interface part of the gateway parameter value into account when sending the test ping requests. And with direct gateways (located in “connected subnets”), check-gateway only works properly in ROS 7.x. And this way also only works for access from outside 10.20.99.0/24, so the solution with two routing tables seems more reliable to me.