Dynamic SF Tunnels (Dynamic VPN)

product
speedfusion

#1

Hi.

Is there a plan to support something like “dynamic VPN” in the future?

The idea would be to permit generate direct SF tunnels on demand between remote sites to serve as a shortcut and avoid extra bandwidth consumption on the central hub. (SF Bonding is great but customer always want more efficiency)

I understand that we can use different route costs between peers, so we can use a shorter route in a fully meshed topology, but it also demands to use big balance models because of the amount limits in speedfusion peers.

Also, in a dynamic VPN environment we could use smaller devices (BPL-210) at remote branches with the main SF tunnel to central office and the option to create 1 or 4 more tunnels directly to other remote branches… This way we can have a star topology supported with direct tunnels with spokes when needed.

Thanks.
Héctor


#2

@hcardenas

Would you able to further elaborate this ? You only need the backup tunnel start connect when the primary tunnels is down ?


#3

We aren’t looking this feature as redundancy but as bandwidth efficiency.

Redundancy is very well covered with “WAN Smoothing” and “Disaster Recovery” option in a star topology, by the way this last one feature is great and works perfectly.

Below a very basic architecture to explain it:

image

It would be nice to be able to set-up one SF tunnel from Peer B to Central Office and leave the second tunnel of the BPL-210 available to create the SF shortcut on demand to another peer.

With the “On demand” term I mean to an automatic process that allow Peers to know other peer´s networks and its public IPs addresses, so they can create the tunnel when a request arrives internally from their LAN. For example: An IP Phone from network B wants to call an IP Phone from network C, the B210 from Peer B receives this request and create a SF to B210 from Peer C. Both Balance (B and C) already had the current and necessary data spread by the central Balance/FusionHub to create the tunnel.

Perhaps in a 3-peer scenario it doesn’t make sense, but it would in a larger architecture.