4G WAN: Bonding vs Load Balancing
Bonding vs Load Balancing
There are two approaches to combining multiple SIMs: Bonding and Load Balancing. We generally recommend bonding, but there are scenarios where Load Balancing can be a useful solution. Here is a description of the two approaches.
Bonding or Load Balancing?
There are two approaches to combining multiple SIMs: bonding and load balancing. We generally recommend bonding for reliability, but there are scenarios where load balancing can be a useful solution. Generally, you would opt for:
Bonding when you require
- Latency-sensitive applications
- Connection to the corporate network
Load balancing when
- You are accessing internet-delivered applications
- You are not running applications that are sensitive to packet loss or latency
- You don’t require high speed access to a corporate network
- Or perhaps you don’t have the time to install a hub in your own data centre or the desire to use a provider’s hub
Bonded solutions take individual connections and combine them to form a single aggregated connection.
Reliability: By using multiple links at once to split the traffic flow across each in real time, you can re-transmit dropped packets instantly via another active channel. This makes it ideal for applications that are sensitive to packet loss or latency.
Monitoring: Bonding allows the use of mechanisms to monitor the performance of each channel in terms of speed, latency and packet loss. This means Quality of Service (QoS) can be configured according to this data, for example not sending voice down a channel that has exceeded a pre-defined latency threshold.
Performance: When a VPN is required for corporate connectivity, bonding allows each channel to form its own tunnel while the bonding protocols split the traffic up across all the active channels, meaning all of them are used for the VPN traffic. This allows for instant failover and no packet loss.
Traffic flow: Because all traffic is sent through the bonded tunnel to the central hub before breaking out, it can influence native internet performance. The encryption overhead of the VPN can also impede performance.
Low performing channels: The bond is only as good as the worst performing channel. For example, if you have four channels – three running a 4G service and one running a 3G service – the bond will run at the speed and latency capacity of the 3G service.
Compatibility: Because bonding is not an open standard, different MSPs will have their own approach to doing this, which is usually proprietary to their equipment and common standards for VPN such as IPSEC cannot be used. This means that you’ll likely to have to use the same MSP for both core and site devices.
Performance: 4G routers commonly auto-tune their bonded connections with a priority on reliability and minimum packet loss, rather than on performance. We sometimes find we need to tune the settings to achieve the right balance between reliability and performance.
With load balancing, traffic is distributed across a number of connections. Unlike bonding, these connections remain separate and you do not need a hub in a Data Centre to bond these connections together.
Local internet performance: You can split traffic evenly, or even by specific channels, in order to prioritise critical users and activities over non-critical. As an example, you could give corporate users 95% of available bandwidth and guest Wi-Fi only 5%. Because breakout occurs locally, you’re also not met with the overheads of bonding protocols or encryption for VPN.
Compatibility: Load balancing supports open standards such as IPSEC when setting up VPNs. This means that existing equipment can more likely be used and services do not need to be run through the same MSP. While the VPN itself will only run on one active channel at a time, it can be set to auto-failover between channels should the link fail.
Failover isn’t instant: While the service improves local internet speed, it is not ideal if pure corporate connectivity is required via a VPN. Though a VPN connection will fail over to a second channel if the connection is interrupted, this will not be instant – resulting in a noticeable outage and packet loss.
Performance: Because traffic is only running over one tunnel, it cannot take advantage of the additional bandwidth available on other active channels.
Outages and packet loss: If you have packet loss or latency-sensitive applications running over your corporate connection, load balancing is not ideal as you’ll only have one active channel with a failover time period. There are also no mechanisms to monitor latency and packet loss, meaning the connection is not intelligent enough to switch between channels when one is degraded.