Speedfusion across a load balancing intermediary

Background
A cascaded system, with

  • a MAX HD2 IP67 (two cellular (Verizon) and one WAN (the Transit Duo) connections).
  • a MAX Transit Duo with two cellular (Verizon, Visible) connections. The outbound rule for the Transit has an even load balancing across the two cellular connections.

The HD2 IP67 has a SpeedFusion connection to a Balance 380 (HW6) hub employing all three connections (2xCellular, 1xWAN).

Observation:
The SpeedFusion connection from the HD2 to the B380 seems to employ only one of the two cellular connections of the intermediary Transit (cellular 1) with none of the traffic being across the second cellular connection on the Transit…

Question:
Given that the Transit is simply an intermediary, how does the set-up for the SF connection from the HD2 to the B280 decide which (if not both) of the Transit connections to employ? And is there a way to spread the tunnel across both connections, or otherwise influence the setup and the SF traffic?

Hi Zegor,

The outbound policy on the MAX Transit Duo should dictate which cellular connection is being used.
This behaviour could be caused by a session persistence outbound policy.
Is the load balancing outbound policy the only rule on the MAX Transit Duo?

With only a weighted Balance outbound policy in place I would expect the Transit to use both of its cellular WAN’s

Update: Thinking about this, I did not answer this correctly earlier, your SpeedFusion connection from the HD2 to your B380 is only one ongoing session and would therefore only use 1 of the WAN connections of the Transit at the time.

1 Like

Yes. Use Speedfusion on the Transit to bond the two cellular connections, then the HD2 will be able to use the bonded tunnel as transport for its own Speedfusion VPN traffic.

1 Like

To establish a SpeedFusion connection that runs (at least in part) on top of an intermediary SpeedFusion connection seems to be at odds with my understanding from an earlier conversation: An additional speedfusion connection across an existing speedfusion connection - #2 by MartinLangmaid.

Please advise.

Thanks.

Z

I can see where the confusion lies - I have updated that response.

In this case then we have the following:

  1. IP67 creating a bonded Speedfusion tunnel using dual cellular and wired WAN
  2. A Transit Duo on the WAN of #1, since the IP67 HD2 will only ever look to create a single tunnel between itself and the hub #3 on its own wired WAN, only one cellular WAN on the transit will ever be used for Speedfusion traffic.
  3. The Hub device that has three connections coming from the IP67 HD2
  4. The Speedfusion tunnel being connected over the three WANs of the IP67 HD2

What I am suggesting is this topology:

Where once again the hub has three active connections coming into it from the IP67 HD2 which are the transport for the Speedfusion tunnel, but instead of the third tunnel passing direct from IP67 HD2 WAN to Transit to the Hub, the transit is now bonding its cellular connections via an intermediary Fusionhub.

There are limitations of course to this approach but it would work functionally.

Given the choice though, I would replace the Transit Duo with a CAT 18 Transit as this would likely provide more throughput that a Transit Duo and it simplifies the routing.

2 Likes

@MartinLangmaid, thanks for a clearly articulated and illustrated explanation. I was hoping (against hope) that there was something to be done with the architecture where the two SpeedFusion connections had a common (hub) endpoint. Alas…

The second architecture (with the intermediary Transit) was a student exercise in carrier cap management - to spread the usage across multiple modems with minimal user device attention to what’s going on, while retaining SpeedFusion security and other goodies.

Cheers,

Z

1 Like