Hello.

A newbie asks perhaps a dumb question but I cannot find any post addressing this issue.( that I can decipher!)

I have set up a 60gHz Mikrotik link which delivers 330+Mbps service to my "notspot" from a FTP site 1kM away. This replaces an older 5gHz Nanobeam link which I wish to keep powered to act as a link only in the event of a failure of the 60gHz link. This is Scotland and we get very heavy rain which has shown itself to be capable of cluttering sufficiently to make the 60gHz link drop out.

I have tried running the two links in parallel but for reasons not obvious to me ( but probably blindingly obvious to you) the bandwith is reduced to that of the 5gHz. but as soon as the 5gHz link is de-activated the bandwidth jumps back to 300+ Mbps.

How do I establish my link so that the 5gHz link only activates when the 60gHz link either fails or drops below a pre-set data transmission level? Is there a "simple" answer to this?

Bottle of good Scotch whisky for the easiest to implement answer not involving enormous cost!) Thanks for reading this.
Stewpot

Could it be the powerbeam having the same IP as the 60Ghz link?

Without knowing more specifics is difficult to assess... how is the 5GHz setup? is the Powerbeam in router mode?

What happens if only the radio is turned off on the PowerBeam?

Supposing that both work simultaneously, there is no simple answer on how to implement a failover...

Easiest way could be using bonding on both routers with the 5GHz and 60GHz interfaces, and maybe using tools > traffic monitor in active/backup mode...

Thanks. Different IP addresses for each link. I will investigate bonding. At the moment the two systems are connected to the same unmanaged network switch at each location.

Is the powerbeam in router or bridge mode?

I assumed yours was a routed setup, if two unmanaged switches are connected with two links what happens is that you create a network loop and a switch disables one of the interfaces, so if the powerbeam is in bridge mode this is what is happening.

You'll need two mikrotik devices for the bonding, and bridge mode on the powerbeam. balance_alb mode could be interesting in your scenario too, see https://wiki.mikrotik.com/wiki/Manual:I ... ding_modes

Maybe I misunderstand the problem, but the obvious solution to me is OSPF. Give the 60GHz link a lower cost than the 5GHz link. The 60 will be used exclusively unless it goes out of service, whereupon the 5 will be activated. When the 60 comes back up, it will resume priority.

There should also be some kind of flapping/packet-loss detection as I would guess the 60GHz won't necessarily go down but just be (very) unstable during heavy rain.
Thie detection should also be able to detect that 60GHz is stable again and switch back to primary link.

This is Scotland and we get very heavy rain which has shown itself to be capable of cluttering sufficiently to make the 60gHz link drop out.

We have customers in Scotland using LHG60's at 1.4km and they do not drop out. The throughput drops admittedly, but they don't drop out. We assisted them with how to configure their links for optimum performance as if left to 'auto' settings you will not get the best performance these amazing products can deliver. We also have them on Bridges in the North East with link distances of 1km that suffer heavily from frequent sea fog and occasional heavy rain and again, do not drop out.

To provide failover between the two circuits, configure OSPF on a router at each end. Lower the OSPF interface distances to favour the 60GHz path and when / if that fails it will switch over to the 5GHz circuit. As soon as the 60GHz link returns, the OSPF config will switch the traffic back again over the 60GHz path.

Any form of load balancing or interface bonding runs the risk of it going at the slowest of the two, in your case the 5Ghz link.

Our contact details are below if you need any further assistance

OSPF is undoubtely the more flexible and powerful way, but requires a routed network, and didn't fit the "simple" requirement by the OP.

Going routed though is the best future-proof approach for scalability too, so even if it means a drastic revamp it will be time and money well invested.

True and a good point. But I can’t see any other way of doing failover reliably and achieve high speed without him having a router at end just as you also suggested but use L3 routing not L2 somehow. Using L2 bonding will only get you a system throughput speed of the slowest of the two links unless you’ve seen different? Also highly likely to be getting a high level of out of order packets as the 5GHz will have higher latency. For TCP it won’t be noticeable as it can cope with OOO packets. But other protocols will suffer.

OSPF is definitely the way to go in my opinion. Force the link to only use one route or the other. Not both.

RSTP maybe a solution. But if you’re going to be using a router each end to bridge and apply RSTP, you may as well configure OSPF.

Yes... as routers are required anyway definitely L3 is the optimal solution.

Using L2 bonding will only get you a system throughput speed of the slowest of the two links unless you’ve seen different?

That's why I suggested active/backup... though the problem on how to force 60GHz to be detected as failed when link suffers but doesn't drop remains... would require netwatch or traffic monitor, definitely not the cleanest implementation when OSPF is the tool to cope with link states.

though the problem on how to force 60GHz to be detected as failed when link suffers but doesn't drop remains... would require netwatch or traffic monitor, definitely not the cleanest implementation when OSPF is the tool to cope with link states.

Indeed - there is sadly no feedback about how "good" the link is - just that it is "up". Maybe apply an aggressive setting of BFD? Any packet loss = a deteriorating link = OSPF gets signalled by BFD to fail over.

Never been happy with Netwatch except for very simple "is it up/down" tasks as it does not have any soft hysteresis in the decision. Another possibility might be to create a script that examines the link quality and if it drops below a predefined threshold take some action, maybe enable a firewall rule to block OSPF hellos. In that way OSPF hellos will only be transported if the link is good enough and that becomes the signal to switch radio paths.

Only tested, never implemented OLSR, but it could be an interesting option here. Not supported by Mikrotik (in fact, almost nobody does).
My experience with 60GHz (1.6km) is stable connection, only very heavy rain&fog giving trouble 30 min twice a year. What I could see, was that link changed a lot, from good to bad to broken, and reverse. Many times during the half hour. How would OSPF react to this?
Is it possible to set OSPF to react quickly when 60GHz link is broken, and react slowly before reverting from 5GHz when 60GHz link is up again - because it might be up just for a few seconds or couple of minutes?

Is it possible to set OSPF to react quickly when 60GHz link is broken, and react slowly before reverting from 5GHz when 60GHz link is up again - because it might be up just for a few seconds or couple of minutes?

I believe it can, as already stated. "create a script that examines the link quality and if it drops below a predefined threshold take some action"

though the problem on how to force 60GHz to be detected as failed when link suffers but doesn't drop remains... would require netwatch or traffic monitor, definitely not the cleanest implementation when OSPF is the tool to cope with link states.

Indeed - there is sadly no feedback about how "good" the link is - just that it is "up". Maybe apply an aggressive setting of BFD? Any packet loss = a deteriorating link = OSPF gets signalled by BFD to fail over.

Never been happy with Netwatch except for very simple "is it up/down" tasks as it does not have any soft hysteresis in the decision. Another possibility might be to create a script that examines the link quality and if it drops below a predefined threshold take some action, maybe enable a firewall rule to block OSPF hellos. In that way OSPF hellos will only be transported if the link is good enough and that becomes the signal to switch radio paths.

I would also use caution to ensure BFD will work as desired as I have had issues with BFD on certain Mikrotik hardware.
Last I heard from support back in June of 2019: "If you are talking about BFD problems on CCRs, then at this point I would suggest not to use BFD or move to ARM routers." In further discussions they felt that BFD should work normally on CHR assuming its using virtio drivers. I tested on XenServer / XCPng and it worked as desired. BFD on CCR was very intermittent and had many false positives.

If you don't care about a 5 second failover time, the simplest would be a rapid spanning tree failover. If you are using routerboards on both sides, you can place both radio ports and a LAN port into a bridge. Under the bridge/port menu, increase the path cost on the 5GHz link on both ends. After connecting the 60 and 5, you'll see that the bridge port containing the 5Ghz radio will become an alternate port on one of the routerboards.

Then to decrease the failover time, edit the max age timer down to 00:00:05 on the bridge menu.

Technically you could use both with unequal load balancing if you use OSPF and the method outlined below. We've done this on a number of networks with a lot of success. It's certainly not the simplest way to go, but it's reliable and will use all the bandwidth available.

https://stubarea51.net/2016/10/27/wisp- ... ual-links/

Technically you could use both with unequal load balancing if you use OSPF and the method outlined below. We've done this on a number of networks with a lot of success. It's certainly not the simplest way to go, but it's reliable and will use all the bandwidth available.

https://stubarea51.net/2016/10/27/wisp- ... ual-links/

This is a clever way to utilise all your bandwidth - I've watched your presentation and will try it in the wild soon.

In the event of total link failure it will work as advertised, In the event of 60Ghz link degradation is it not going to still try and split the traffic 6:2 - would you still need a script that monitors the link (over time) and adjusts the ratio of active VLAN's ?

Does this means that one connection, such as a L2 Tunnel, could end up using only one link in each direction ? Has this been an issue and if so how to get around it ?

Again, great solution and am keen to hear more - thanks in advance