Please note to use the FireBrick 105 for bonding, you need to purchase the optional Bonding feature, and possibly the Profiles, Tunnels, or Extras features.
Bonding allows you to combine multiple links (e.g. multiple ADSL lines), to effectively give you a single higher bandwidth link (fat pipe). There are many ways of doing this, such as link-layer (e.g. MPPP), IP-layer packet-by-packet, or session-by-session (the latter is often referred to as load sharing).
Bonding is becoming increasingly popular with the advent of low cost, widely available, ADSL or Cable broadband. A single ADSL connection is often not fast or reliable enough for many businesses, who have traditionally used expensive leased line connections. However, by bonding multiple ADSL connections, you may achieve your required bandwidth and reliability for a fraction of the cost of a leased line.
Link-Layer is what some people traditionally think of when you mention Bonding. It has been used for years to bond multiple ISDN channels (channel bonding), for example. It works at the link protocol level (e.g. PPP for ADSL), effectively providing you with a single IP connection.
There are currently some ISPs who offer multi-link PPP (MPPP) bonding on ADSL. However, it does mean you have to use an ISP capable of supporting this (it requires specialist equipment at their end), and all your ADSL connections must be from the same ISP.
We believe there are no real advantages to link-layer for most users, and there are more options and flexibility when bonding or load sharing at the IP (Internet Protocol) level, for example using a FireBrick.
This is where individual IP packets are sent through individual internet connections, but the packets are shared over your multiple connections, using a suitable router such as the FireBrick.
The sending end has to decide which internet connection to send each packet over. This is easy for uplink traffic (for example your FireBrick can just send packets up each connection in turn, using Uplink Bonding), but it gets more difficult for downlink traffic, as the sending (remote) end will just use a target IP address that is routed to one of your connections. There are two obvious solutions to this, one is to use Downlink Load Sharing, the other is to use another FireBrick at the far end (see Tunnel Bonding).
This is where individual sessions are assigned to individual internet connections, such as with Downlink Load Sharing. Most businesses will have many simultaneous users, creating many simultaneous sessions, so by simply sharing the sessions over the multiple connections you can normally make full use of the bandwidth available. A single session cannot use more than the bandwidth of a single connection, but this is rarely a problem.
Lets say you have 4 ADSL connections. The FireBrick will simply route each outgoing packet out over each ADSL line in turn. This will share the load evenly over the 4 connections, giving you around 1Mbps uplink bandwidth.
Because this is simply a routing function, it has no affect on the source or target IP address of each packet, simply the route by which it goes. Therefore it causes no confusion at the far end, which will simply reply to the source IP address.
With uplink bonding, although outgoing packets are spread over multiple connections, the replies will all come in on the connection associated with the IP address of the originating machine. FireBrick Downlink Load Sharing uses NAT (network address translation) to control which connection replies come back on. Each outgoing session will be assigned to a particular connection, by having its source address translated to an address on that connection.
This is ideal for most offices, where there are many users, and most sessions are initiated locally (e.g. web browsing, downloading files, etc.).
As mentioned earlier, the sending end has to decide which connection to send a packet down. So what can be better than a FireBrick at each end of your multiple connections? This typically involves getting an ISP to host the 2nd FireBrick (both Watchfront Internet and Andrews & Arnold Ltd can do this).
Create FireBrick tunnels over each connection, and then bond these tunnels. This means that traffic in both directions is shared evenly over the connections, without using NAT, and regardless of which end the sessions are initiated.
Lets say you have 4 ADSL connections, and one suddenly fails. Normally, whatever traffic was routed over that connection would simply be lost. However the FireBrick can monitor the health of each connection, and if one fails it can automatically redistribute all traffic over the remaining connections, so everything can carry on as normal, albeit with reduced bandwidth.
With Tunnel Bonding this happens in around 5 seconds, otherwise using ping profiles it takes around 20 seconds.
This makes your connection a lot more resilient to failure than a single connection. Leased lines are typically more reliable than ADSL, and will generally be repaired quicker, but with bonded ADSL you can get the same or better reliability.
Packet re-ordering is when a stream of packets arrive at the far end not in the order they were sent, normally because some packets have taken a different route and overtaken other packets. It is something that happens over the internet at large (multiple routes are intrinsic to how the internet works), and protocols generally cope pretty well.
However we have found that some Voice-over-IP (VoIP) get upset, even though they shouldn't, resulting in some audio breakup. This can be exacerbated when bonding multiple connections, especially when the connections are dissimilar (e.g. different ISPs), so the FireBrick has the ability to restrict VoIP traffic to a single connection to avoid this.
There are two options:-
With Downlink Load Sharing, the FireBrick uses weighted routing, which allows you to configure the percentage of traffic that is assigned to each line (in this example 80%/20%).
If one of the lines fails, the FireBrick will automatically recalculate the load sharing on the remaining lines.
The uplink is not a problem as ADSL is usually 256kbps regardless of downlink capacity.
Uplink Bonding and Downlink Load Sharing, with up to 4 ADSL lines, is an excellent solution for this. Your users will typically create many simultaneous outgoing sessions, which will share nicely across the lines, and the bulk of your traffic will be download, which suits the asymmetric nature of ADSL. Four 2Mbps lines will give you an aggregate of around 8Mbps downlink and 1Mbps uplink, at a fraction of the cost of an equivalent leased line.
Many businesses find that a 2Mbps ADSL connection is fine for their downlink requirements, but the 256kbps uplink is not enough, either because they use Voice-over-IP (VoIP) a lot, or they host servers for remote downloads, branch offices, teleworkers, etc.. In this instance the Uplink Bonding feature is ideal. Simply buy up to 3 extra ADSL connections (cheap 500kbps ones will do), and configure the FireBrick to share uplink traffic over the multiple connections.
If you are running public-facing web servers at the end of an ADSL line, the bulk of the traffic will be outgoing (uplink). This does not suit ADSL, which is asymmetric with only 256kbps uplink capacity. Again, Uplink Bonding, combined with up to four 500kbps ADSL lines, is your friend. All requests will come in on the line associated with the published IP address of your server, but replies will be shared over the ADSL lines, providing up to 1Mbps uplink.
In addition, if you have multiple web servers, the FireBrick can do weighted mapping for load sharing between the servers.
The problem with connecting two offices by ADSL is that traffic in both directions is limited to the uplink capacity (256kbps) of ADSL - what is downlink for one is uplink for the other, and vice versa. A better solution is to use multiple ADSL connections, a FireBrick at each office, and use Tunnel Bonding - create tunnels between the firebricks over each of the ADSL lines, and then bond the tunnels. Four 500kbps ADSL lines at each office would give 1Mbps in each direction, eight lines would give 2Mbps, etc.
Another advantage of this approach is that you are automatically creating a VPN (Virtual Private Network) between the offices, protected from the internet at large.
If you are uploading a large file, then Uplink Bonding, with multiple ADSL lines, is ideal. If you are downloading a large file, Downlink Load Sharing is not ideal because each session is confined to a single ADSL line. Tunnel Bonding is a better solution, because a single download session can use the true aggregate of all the lines (up to 6Mbps).