We are just starting out with using these Mikrotik Cube60SA APs with Cube60 stations. We had a fairly simple setup in the lab, multiple client stations connecting to a single AP. We simulated interference events by turning off either the wlan1 or wlan60-1 interface on the client, and the connectivity always remained up; switchover to the main 60GHz radio was confirmed by watching the interface traffic’s stats – after bringing up the wlan60-1 traffic automatically switched back to that main radio.
But now that it’s out in the field, that’s not what we’re seeing. We had to replace an AP, and its connected station reconnected to the new AP, BUT. It reconnected to both radios, BUT all traffic was now being sent over the (slower) 5GHz radio. It didn’t cut back over to the wlan60 channels until we physically turned off the wlan1 radio on the AP.
The configurations are quite fairly simple, so it’s easily possible that something important got missed. How can we get the traffic to be prioritized onto the wlan60-1 radio when that link is connected and up?
Don’t use add bridge=bridge interface=all on the station. Add the wlan60-1 and wlan1 interfaces explicitly and set the spanning tree path cost to favour the 60G interface, also make sure that the AP itself or something upstream is the root bridge.
What you’re saying is, on the AP:
/interface bridge
set priority=0x8000 (or some relatively low number) for the bridge named “bridge”
On the Stations, similarly but
/interface bridge
set priority=0x9000 (or some relatively higher number) on the bridge named “bridge”
/interface bridge port
add bridge=bridge comment=defconf interface=ether1
add bridge=bridge interface=wlan60-1 path-cost=10
add bridge=bridge interface=wlan1 path-cost=20
(and remove the “interface=all” entry altogether)
Assuming I have the numbers relatively correct (ie. smaller where they should be smaller), there shouldn’t be further changes to the config?
Apparently, not quite. On the AP side, I also needed to change the “priority” in “/interface bridge port” for something larger than that being applied to the “wlan60-station-X” interfaces. That seems to get a value of “0x80” from somewhere unknown, so I set the priority on “wlan1” to 0x90.
Weirdly, it seems that this is only relevant when we changed the AP device to another (ie. from the temporary “cube” to the updated “cubeSA” version). It’s still behaving exactly as I’d expect in the lab, the switchover being automatic.
I think I’m in the deep end here with regards to fixing this. But I think I worked out how to do it though.
Apparently in order to not have to be physically at the remote station’s location, it’s VERY tricky to remove that “all” from the “/interface bridge port” section, or else you immediately lock yourself out from any remote connectivity to the device. This is what I did, using the uncommon semicolon on the cmdline and being very VERY careful in my typing:
/interface bridge port
print
(make note of the “all” entry, in my case it was number “1”)
remove 1 ; add interface=wlan1 bridge=path-cost=20 ; add interface=wlan60-1 bridge=bridge path-cost=10
I would say that it’s best to use the “autocompletion” feature of the cmdline as much as possible in order to help eliminate any tpyos here.
priority which is part of the STP “Bridge port ID” is the least significant of the selectors in the election process, “Root port path cost” is the most significant calculated from the sum of the path-cost values and usually the simplest adjustment to make to influence the active path.
Unfortunately Mikrotik to do not set path-cost based on interface speed per the standards unlike most other network equipment vendors, if they did the higher speed interface would automatically be assigned a lower path cost and become the preferred path.
The default station bridge priority of 0x8000 would be fine - you just need lower values on the AP, e.g. 0x6000, and/or main network gateway, e.g. 0x2000.
You can use MAC-telnet or MAC-Winbox if on the same L2 network, e.g. MAC-telnet from the AP, to access devices without loosing connectivity when the interface is removed from the bridge. As ever safe mode can get you out of sticky situations.