right now the configs is as follows, the 10.10.5.0 address are for management only, and the are on the interfaces vlan 50 on both routers. it is not the issue.
I understand this is not the issue, but to get rid of the actual issue, the configuration of the SXTs has to be changed. And since an SXT only has a single Ethernet port, it is important not to lose access to the SXTs, as the reset button is hard to reach on them and it's even not a button but just contact pads. So if you've got an USB to serial converter and easy access to both devices, you can take a risk, otherwise you have to be very careful.
My ether1 on both MK have vlan 10, 50, 310 as its sub interface.
and ether1,wlan1, vlan 10,50,310 are all members of bridge_trunk.
In the Cisco way of thinking, think about each SXT as about a separate switch interconnected with a separate router, except that their interconnection cable is a virtual one. So no VLAN subinterfaces to be used at ether1 or wlan1, these are switchports, not router ports. And then there is another switchport, named the same like the bridge (switch), and to it an interface of the router is connected, unfortunately also named the same like the bridge (switch). See
this post for more details.
Whilst VLAN 50, which you intend to use for management access to the SXTs, has to be in trunk mode (tagged) at ether1 (and, for simplicity, also on wlan1) because that's how it is configured at the Cisco boxes, there are two ways how to handle it between the router part of the SXT and the bridge part of it:
- you can keep VLAN 50 as a trunk (tagged) one on the router-facing port of the bridge, and attach a subinterface to the switch-facing port of the router. In this case, the native VLAN will stay 1 on that port,
- you can set VLAN 50 as a native VLAN on the router-facing port of the bridge, and attach the IP configuration to the switch-facing interface of the router (i.e. no subinterface).
The above works with
vlan-filtering set to
yes on the bridge; with
vlan-filtering=no, the switch acts as a dumb one, unable to tag/untag frames, just blindly forwarding them verbatim. But in this mode, it
seems that the tagged frames are not accepted by the wireless interfaces.
So one possible target configuration of the bridges, VLANs and IP addresses at both SXTs is:
/interface bridge
add name=bridge protocol-mode=none vlan-filtering=yes
/interface vlan
add name=bridge.50 interface=bridge vlan-id=50
/interface bridge vlan
add bridge=bridge vlan-ids=10 tagged=ether1,wlan1
add bridge=bridge vlan-ids=50 tagged=bridge,ether1,wlan1
add bridge=bridge vlan-ids=310 tagged=ether1,wlan1
/interface bridge port
add bridge=bridge interface=ether1
add bridge=bridge interface=wlan1
/ip address
add address=10.10.5.4/27 interface=bridge.50
But to reach this target state, you need to do some intermediate steps if you cannot connect to both SXTs using a serial console.
Even if you can reach both devices via ethernet, i.e. you don't need to reach the "remote" one via the wireless link, you have to be careful - at first place, attach addresses from different subnets to bridge itself (to manage the SXTs from a PC connected directly to the SXT's ethernet port) and to the VLAN "subinterface" (to manage SXTs from a PC connected to an access port to VLAN 50 on some Cisco). Addresses from same subnet on different interfaces will cause trouble.
So unless you'll configure using an USB serial cable, describe which SXT will be "local" and which will be "remote" (or whether you have them in the same room so far so both are "local", to get the proper sequence of configuration steps.