Fusion Hub Second WAN

Product Discussion Feature Requests
1

Will there ever be a second WAN connection option for a Fuision Hub? While the balance units may be able to support good WAN throughput overall it’s a rediculously expensive proposition to get a PepVPN link at 1G or 1G+. 1G connections are super common now and even at business pricing for symmetric 1G fiber can be had for <$500/mo.

This means the only current devices that can do Encrypted PepVPN at 1Gbps is the Balance 2500 or the EPX. Not exactly cost effective solutions. Intel QAT technology in the Atom Series 2000, 3000 and quite a few other chips is more than capable of handling this type of performance. QAT can accelerate IPSec, OpenVPN and Wireguard offloading the AES-CBC processing to the specialized instruction sets. I’ve used similar hardware to build Routing devices in the past giving high cryptographic performance. Especially in scenarios where Mobile Data connections aren’t needed, but high throughput is.

Please tell me you’re considering something this direction. The fusion hub would be a no brainer. License by capacity or by tunnel. We can provide the hardware fairly easily for deployment using a SFF supermicro server or something similar at a much lower pricepoint than 13-18K, which is a non-starter for many clients.

3 Likes
2

It’s too quiet around here. Not even crickets permeate the silence.

3

Hi Wayne,

I think there is some merit to this request for the reasons laid out.

Obviously, the target for a FusionHub is to be a VM using virtual network sources. While there’s multiple ways to virtually map networks and bond them, it would be beneficial to have multiple and drive outgoing policies as well depending on WAN. Not only for redundancy, but also general load balancing.

1+ for this idea absolutely.

@AdamSteadman what’s your thoughts here?

4

+1 for redundancy/standby wan , but also still holding my breath for a virtual balance.

2 Likes
5

I OK. I’ll bite.

Like you, I want a virtual Balance.
Every single year I ask all the right people in Peplink for a virtual balance.

I’m not quite as brazen as your - ‘I like your stuff but you don’t know what you’re doing when it comes to hardware for the masses, so let me build a cheaper product’ approach. :slight_smile: but I am close to that. I’m super focused on the datacenter angle.

I actually want to use it in virtual datacenters where I can’t run B2500’s because I can’t co-locate hardware but lets be honest if I could use a virtual balance I’m going to build a Frankenstein routing monster with 100gb SFPs just for fun.

And yes, I’d likely install it on a mini PC like the Gowin R86S and make a kick ass home router with 10Gb SFPs for a few hundred dollars.

This idea of homebrew Peplink is not revolutionary.
Back in 2005 you could actually download ‘Peplink Debian’ to build your own Managed Adaptive Network Gateway Appliance (that’s what Manga stands for of course) and Peplink actively encouraged us engineers to buy their hardware and build on top. If you know where to look you can still find v1.8 of the Peplink firmware on the internet:

image.png

But I digress. The question is why won’t Peplink do a mult-wan virtual appliance. In my opinion, that is linked to retaining brand / user experience control and why Peplink stopped doing the Peplink OS and software dev kit back in the early 2000’s.

Brand / user experience because they will get calls from angry customers who will be all negative online about Peplink because some muppet corner cutting ‘Partner’ has installed a virtual balance appliance on an under powered NUC running ESXi and stuffed it in a hot cabinet where it overheats and CPU throttles and as far as the customer is concerned they have bought a Peplink appliance and its not fit for purpose.

And why did they stop doing the very cool homebrew OS? Because the level of support overhead required to help others use their tech on 3rd party hardware is nuts.

Now hardware compatibility is less of an issue today with Proxmox and KVM and others that are mature and a lot of us have significant virtual hosting hardware investments ready and up for the challenge, but there will be a massive increase in support overhead anyway.

I was still in Peplink when FusionHub launched (I actually built the first web page and designed the logos for it) and I remember how crazy things got almost immediately. So many questions about performance and configuration options and approaches to using it.

Imagine the level of support we are all going to ask for if we start using a virtual balance in production and how upskilled Peplink support will need to get in modern virtualisation platforms to be able to assist and track down issues…

But. That said. They really should sell a virtual balance appliance. Maybe restrict it’s sale to Authorized Solution Providers at the start to limit support exposure. Other networking vendors have virtual appliances licensed as you suggest by capacity - its not a new idea and it is the way the industry is going.

The worry will be that it cannibalizes the big balance product sales but I don’t think it would really. I suspect there are big new markets and use cases out there that a virtual balance would open and I know there are lots of organisations who will always want to buy a physical balance appliance over a virtual one.

So I will continue to, twice a year, ask for a virtual balance.

And I do expect to one day have one, just perhaps not yet…

6 Likes
6

Hi Martin,

Excellent feedback and very constructive too - generally a well-balanced reason why and why not.

It would be genuinely a useful product that would furthermore enhance the reason “Why Peplink?”.

The reason why not > Support, absolutely agree here and it would be a huge cost with little benefit so an exclusive product for certain certified partners only.

Let’s see if Peplink don’t do something this year :slight_smile:

2 Likes
7

@MartinLangmaid
You nailed it with this statement!

Let’s be the first to ask peplink to create a program for some of their partners: "“Authorized Virtual Peplink Solution Provider” Only sold under experienced partners that can provide the same level of experience expected from the hardware. It’s a win for everyone , deploy where we can’t co-locate equipment and sell without having to ship hardware 1/2 way around the world.

BTW we use proxmox in our datacenters with Ceph storage/cluster and 100gb switching interconnecting our cluster and it works great! It’s crazy to have to dedicate space in our colos for 710s, sdx-pro, epx , when we don’t require any cellular or hardware specific requirements.
Also when we run in google east/west we can’t do any complex routing that we do in our colos so it’s extremely frustrating.

BTW how do the peplink demos run? It’s it just a simulation?

2 Likes
8

I think @MartinLangmaid has covered my thoughts very well :slight_smile:

I do think that as we do more and more with speedfusion especially with the choice of end user wans available (Starlink etc) there should be more features available on the virtual appliance.

I would like more WAN IP address too

2 Likes
9

Martin,

Let me take a second and thank you for such a well thought out comment. It’s always nice when someone takes the time to bring both constructive criticism and a wealth of knowledge to a topic.

Personally while the interest in building a 100Gbe virtual peplink would be kind of cool. My plans for this are a bit more Datacenter side focused. What I really want is to be able to co-locate multiple clients on the same fusion hub, but be able to isolate them to a private VRF from wan to lan.

In our environment as a MSP we have multiple clients that we sell both SD-WAN based access as well as a MPLS replacement like SD-TRANSPORT. We have several datacenters we run these from. In the virtual fusion hub side currently the vrf limits you to only hub style routing. You can’t have a separate WAN and LAN for each client into their own isolated environment. With Secondary WAN and vLAN for the local side we could achieve consolidation. But right now the only thing we can consolidate on is the SD-WAN side fusion hubs. For transport, every client needs its own separate transport hub. For a few clients it’s not an issue to spin up a separate fusion hub. But when you’re dealing with hundreds of clients it’s a bit more frustrating that you’re now eating up resources and having to manage and maintain 100s of different fusion hubs

For example, on the SDWAN side I can consolidate over 100 client devices into a single fusion hub using 4vCPU and 8gb of ram. But now on the transport side I’m dedicating 1vCPU and 4GB of ram to every single fusion hub. Lets say I need 25 of them to support the same 100 devices which may have multiple sites. So now I need 25vCPU and 100GB of ram just to accomplish the same task.

In our datacenters the physical appliances like the SDX and the EPX just don’t make sense. We use BGP for routing and if we were to lose a rack or heaven forbid an entire datacenter. The migration to a DR rack or a DR site is fairly straightfoward. We’ve even been testing BGP based failovers for client SDWAN connections via PepVPN using BGP route metrics using dual tunnels for much faster failover and recovery between primary and DR sites.

We’ve even considered using Peplink’s own SDWAN based product. But that’s a non-start for us because of the lack of static IP addressing. We have clients with requirements for static IPv4 addressing due to vendor restrictions.

So for us and our use case a virtual fusion hub, or virtual balance device that ticks those boxes would be a welcome addition. Right now our consolidation solution requires finding clients with non overlapping subnets then using route isolation and ACL’s to prevent crosstalk. Not very manageable at scale.

3 Likes
10

Great thread and points.