Peplink WAN Virtualisation

WAN Load Balancing, Aggregation, Bonding & Virtualisation

Whenever I talk about the WAN routing possibilities with Peplink devices for longer than five minutes I find myself wiggling the fingers on both hands in an attempt to help visualise the differences. This post aims to clarify the terms and explain the possibilities.

Link Load Balancing (a single device or one ended solution)

Link Load balancing (LLB) can occur on any multi WAN router whenever there are two or more WAN links. As the name suggests LLB load balances all outbound (and if the device supports it – inbound) network sessions across all the available links. In its most basic form (as seen on a number of products from other vendors) this is a round robin approach where the first outbound session will go out over WAN 1, the second over WAN 2 and so on – on a repeated loop.

On Peplink routers there are 7 possible algorithms:

1. Weighted Balance
   Assign more traffic to a faster link or less traffic to a connection with a bandwidth cap.
2. Priority
   Route traffic to your preferred link as long as it’s available.
3. Overflow
   Prevent traffic flow from slowing down when the connection runs out of available bandwidth.
4. Persistence
   Eliminate session termination issue for HTTPS, E-banking, and other secure websites.
5. Least Used
   Help you choose the better connection with more free bandwidth.
6. Lowest Latency
   Give you the fastest response time when using applications like online gaming.
7. Enforced
   Restrict outbound traffic to a particular connection.

I won’t go into all of the differences here as there is a handy article on the Peplink site that explains the differences. Suffice to say that in most situations (depending on the WAN connectivity) any one of these is normally sufficient.

Better together

Now the power of these algorithms is really evident when they are combined to encompass different WAN links and different networks and application protocols at the same time. Let me give an example:

Imagine a MAX HD2 installed in a rural location with the following WAN links available:

1. 3G (4Mbps/1Mbps – 320ms latency – unlimited bandwidth)
2. 4G/LTE (12Mbps/2.5Mbps – 250ms latency – limited to 8GB/month)
3. DSL – (0.8Mbps / 0.2Mbps – 20ms Latency – unlimited bandwidth)
4. VSAT – (20Mbps / 2Mbps – 800ms latency – limited to 30Gb month)

As you can see there are lots of different types of connections and all of these could be from different ISPs. They all have different bandwidth availability, latency values and some have monthly bandwidth limits too. Now imagine that the end user is a heavy internet consumer, someone like me in my home with multiple PC’s, smart phones, tablets, smart TVs etc. Although we could simply load balance connections automatically across all available links it wouldn’t make best use of the link characteristics on a per application basis.

Lets imagine some example Apps in this scenario:

• General internet access (news websites, facebook etc) from any device
• iPlayer and other video streaming services from the Smart TV
• VoIP handsets using SIP to connect me to the office.

So how might I manage application access to these WANs?

• I’d want my Smart TV to use the vSAT connection for streaming video since the high latency doesn’t matter I just need bandwidth, but when I near my bandwidth cap I want to use 4G since that has enough bandwidth to stream HD video.
• I’d want my VoIP handsets to use the DSL since bandwidth doesn’t matter for that but latency does. If the DSL is not available I want to use the next lowest latency link.
• My general internet access would be best using the cellular 4G link since that has relatively high bandwidth and comparatively low latency but when I reach my monthly bandwidth allowance (or when it gets congested) I want to use the 3G link.

The power of Peplink outbound policies and custom rules really helps here since we can combine sets of these load balancing rules to fulfil these usage scenarios – and as you can see on the link, build complicated rule sets to manage almost any WAN / Application combination requirement really easily using the drag and drop interface.

Aggregation is a potential result of Link Load balancing – but not always.

So we have made the best possible use of the links in this scenario using custom Link Load Balancing rules, and since we have multiple LAN side devices all doing different things we are potentially consuming bandwidth on all WAN links simultaneously (with WAN failover too) and so many people call this Link Aggregation as all available bandwidth on all WAN links is potentially available to the LAN side clients (with failover).

Well that might be true in some cases, and certainly it can be true when using an application that is latency insensitive that doesn’t mind being routed out over different WAN links – but these applications are few and far between. Any access to a SSL encrypted website for example will not like the WAN IP changing when load balancing does it thing, and in fact a default Peplink rule is in place out of the box to keep all outbound SSL sessions from a single client tied to a single WAN link to make things like Banking sites and facebook work well.

The Session Limitation

The underlying reason here is that when an application on a LAN client connects out over the internet it sets up an IP based session as the transport for the data.
A session has a defined start and end point of an IP and port number, and if the IP address at one end of the session changes (due to load balancing for example) then the current session ends and a new one has to be created using the new public IP of the new WAN link in use. Some protocols cope very well with this – and have been designed with this possibility in mind, but most have not.
What this means then is that the only way an application can generally use multiple WAN links at the same time is if it can create and communicate across multiple IP sessions simultaneously.

Load balancing session limitation example

Consider the HD2 with its WAN links and outbound rules above. If I am connected to it with my PC and run an internet speed test what results would I see? Well so long as I have data allowance available on it, my session with speedtest.net would go out over the 4G/LTE link and I would expect to see speed test results that were close to the bandwidth availability on this link of 12Mbps down & 2.5Mbps up. If I ran this test repeatedly that is the most amount of bandwidth I would expect to see. However if I were to run two speed tests simultaneously then I would see one test achieving 12/2.5Mbps and the second achieving 4/1Mbps as the second test (which has its own separate session) would overflow to the 3G link.

WAN Bonding (a two ended solution) – the single session enabler

If you want a single session to be able to use bandwidth from multiple connections then you need to use a technology that Bonds the available WAN links. Link bonding is not new at all – I first used it back when ISDN was all the rage for internet access and multiple 64k ISDN channels could be bonded together to give you 128K, 256k or 512k of blistering fast internet speed (well that’s how if felt back then).

Nowadays you can get link bonded broadband using DSL circuits from a number of ISPs that follow a similar physical set-up. The norm is to see point to point dry copper lines that physically terminate into dedicated modem/routing hardware at the point of installation (your home or business) and at the ISPs Point of Presence.

There are a number of limitations here though. Since link bonding (which works on the session data at the packet level) splits a session’s traffic up and squirts it down multiple physical connections, for it to make sense at the other end the ISP has to have specialist hardware that can take the traffic from these physical links and put it all back together again. That means that generally if you use Link bonding you are limited to using links from a single ISP and all of those links need to be of the same type. Its also generally expensive since its a specialist configuration using specialist hardware – something ISPs have to charge more for due to the increased overheads.

An alternative to Link bonding is VPN bonding. This is what Peplink’s SpeedFusion bonding technology does to bond WAN links of different types from different providers. VPN bonding between a pair of routers using multiple WAN links works by creating multiple VPN tunnels from each WAN link on the source device to all of the WAN links on the destination device. A sessions traffic from a source device is then split across all of the available tunnels at a packet level and then reconstructed at the destination device.

Abstracting the links into VPN tunnels has a number of benefits. Firstly because its VPN based, almost any WAN link can be used – whether that’s a fixed line service (like DSL, cable or fiber) or a wireless service (like cellular 3G/4G/LTE or even wifi). Secondly its ISP agnostic, you can use different ISPs for all WAN links at both ends with the underlying VPN connections tunnelling out across the internet. Thirdly you can add additional WAN links (and so bandwidth) as required, and this bandwidth can be from pretty much any type of connection (so long as its IP routeable so a VPN tunnel can be made over it).

Naturally it has limitations too and those are worth mentioning. Just like link bonding, there is a packet overhead to identify packets as they are split across the available WAN links so that they can be reconstructed at the remote device in the right order. This combined with the additional VPN protocol overhead (eg for security & encryption) means that 20/30% of the available bandwidth is consumed in the bonding process. Just like Link bonding, VPN bonding is latency sensitive since all packets are rearranged in order at the remote device so if a packet has travelled over a higher latency link to get there then the remote device has to wait for it before it can pass data on to the next hop.

Even with those limitations though, VPN bonding can be very sucessful, and Peplinks SpeedFusion VPN bonding is used by customers all over the world to deliver high speed, highly available site to site links and wide area networks.

WAN Link Virtualisation

So what exactly is WAN link virtualisation and why should you care about it? WAN virtualisation (or virtualization if you prefer) is the next natural step of WAN development, it is the ability to create a logical bonded point to point WAN link between two or more locations quickly and easily using whatever underlying physical links are available.

At it’s core, WAN Link Virtualisation is the monitoring and management of multiple disparate physical WAN links from multiple ISPs (and the way traffic flows across them), to create a single, highly available, high bandwidth logical network connection.

It’s what you should use to replace or augment your existing MPLS WAN infrastructure, it’s how you can get a secure high bandwidth resilient enterprise network connection into a moving vehicle, it’s how you can save 10’s and sometimes 100’s of thousands of pounds a year in ISP charges for single expensive high bandwidth internet connections backed by SLAs.

By combining the best attributes of all and any available internet connectivity at a location – be that bandwidth, reliability or connection mediums, WAN virtualisation enables and simplifies their use in combination to create a low cost, easy to manage WAN. As anyone currently using it will tell you, its the future of affordable, reliable WAN infrastructures.

Peplink WAN Virtualisation

Peplink WAN virtualisation is the combination of physical routers that can connect to multiple fixed and mobile technologies (DSL, fiber, cable, MPLS, Cellular, WiFi, Satellite) with software technology such as SpeedFusion VPN bonding, advanced Link Load balancing algorithms and InControl – the cloud based monitoring and management platform. Together these solutions can provide a fully virtualised WAN.