Advice on Load Balancing and Failover Routers

Sonicwall has load balancing AND failover. All buyable versions have this feature(enhanced OS needs to be purchased). The product you select is up to how big your needs are. There are good reviews on their load balancing. If your load balacing and a Link goes down you service isn't interupted at all.

Here is 1 review

www.shopping.com/xPR-Citrix_SONICWALL_01ssc5700~RD-194706116228

I see where you're coming from. I've not had any experience of those devices but load balancing would be the way to go if you can do it as you can then use both links. A simpler alternative might be to use a router and give one link a higher cost than the other, but this would only use the lower cost link with the second mouldering away as standby.

Thats right, but you can also set up policy based routing, meaning, as an internet connection, almost all sort of traffic are web, mail, and any other, so you can police the traffic flow entering the router, and exiting the router towards both external links, for example; all http outbound traffic taking link A, and all email, and other outboudn traffic taking Link B, so you can "load balance" or use both links.

Personally I like OpenBSD's PF with ALTQ (works on freebsd too). It has very human-friendly grammar/semantics and official documentation is thorough. It has every feature that you need and it's free. If you want something compact and reliable to run it on, check soekris

I was looking for a FREE Load balancing Product also. This do inbound and outbound load balancing?

OpenBSD that is.

Hi people,

There seems to be a misconception in regards to load balancing and line aggregation. Since the topic has been raised with this thread, I'd like to add my 2 cents worth.

You'll find quite a few products in the market that perform the so called 'load balancing' when infact all they do is separate packets and send them through the multiple Internet lines you might have. Personally, I don't call this load balancing as this more of a packet routing feature based on the service the packets carry (www, dns, ftp e.t.c).

Even Cisco's policy based routing can't be tagged as 'load balancing' in most cases, as your really looking for specific characteristics in your outgoing packets and then sending them through the appropriate WAN link.

In my opinion, the term 'load balancing' is found implemented correctly in server units such as HP, IBM, DELL e.t.c where you'll find two or more network cards with the same IP address (in most cases), working together to dynamically offload the traffic so no bottleneck is created at the server's network level. Take this concept and apply it to your router and you'll have 'load balancing'.

Coming to the line aggregation problem. Some time ago, I searched around the web in order to understand on how it works and what the prerequisites are for it to work. My findings and understanding on the topic are that in order to correctly aggregate the bandwidth of two or more e.g ADSL links to your ISP, both ends (you, your ISP and possible local DSLAM in this example) MUST support the aggregation feature, otherwise it is impossible to achieve.

This means that if you want to take two 4Mbit ADSL lines to your ISP and create one big fat 8Mbit line, your local equipment along with your ISP's equipment must support this feature, otherwise it is not possible.

I don't know if you guys out there agree, but I would like to hear you opinion on these topics as they are frequently discussed in forums around the globe and as I said initially, there seems to be a terrible confusion on the requirements and how they are can be implemented.


Cheers,

Chris, you are right, if you want to aggregate two or more links on a per-IP-packet basis (totally transparently to network and upper-layer protocols), so that you are able to achieve aggregation in each single connections it is just like you said, it needs to be set up in both ends. Otherwise TCP/IP wouldn't be able to keep session status, since it uses Source IP address as a unique identifier, and every protocol on top of it would collapse.

This is how IProute's TEQL works in Linux: It marks the packets with a unique identifier for each connection, sends them in a distributed way through multiple intefaces, and the other end needs to collect them and reassemble them before they can be sent to travel the regular network.

Especially for ethernet links, there is also the possibility, to aggregate a number of links within the kernel (at low level, achieving better performance and resource consumption). As Linux kernel documentation mentions, this is called "bonding" in linux, "Etherchannel" by Cisco and "Trunking" by SUN.

This is the ideal way and how an ISP would do things (hopefully ).

However, it is also possible to achieve aggregation on a per-IP-connection basis (sorry for the technically invalid term, please see PS2 at the end), meaning that connections will be routed sequentially in a round-robin (or even biased according to some ratio) fashion through different gateways. Application-layer protocols that are able to handle multi-connection transfers, like FTP, HTTP and TORRENT, will have aggregation in a single session (as long as the client supports it). Also in a network environment with multiple hosts, available bandwidth will appear practically aggregated for all applications -i.e. even though a user visiting a web page (hosted in a single HTTP server) with a common web browser will draw all data through one of the lines, two users visiting two web pages (hosted in a single HTTP server each) at the same time, will take advantage of two lines, etc-. And, in practice, because most http sessions occur over multiple tcp connections, even a single web-surfer will take advantage of both links.

This is what can be achieved with IPtable's nth match module, fwmark & iproute2 (like the example in this thread), and much more simply in FreeBSD/OpenBSD, with PF. That does not need support from both ends, because each IP connection is routed entirely through only one gateway. Perhaps there are a few applications that want to initiate multiple connections expecting to match the same address, these won't like that and will kick -but it works ok for most applications.

Coincidentally there is a possibility that I'll need to set this up for three (internet cafe) networks, of ~50 hosts each, that will go through 3 adsl/sdsl gateways (each). It has to be done some time during the summer, I'll let you know how it functions in a demanding environment, if I take the job after all -unfortunately it's not as simple as the above scenario, the owner actually wants to have all the traffic from P2P applications (kazaa, limewire, torrent, etc) and all the game traffic matched and sent through seperate gateways, which I find very tricky because neither p2p nor game traffic is easily identifiable. I'll try to convince him that it will be better if we distribute traffic to all gateways, and then try to classify & prioritize the traffic we want using Class Based Queueing. Which is not easy either, because every week there's a new game connecting to different ports which will need to be prioritized -either that or have the p2p traffic specifically de-prioritized-

PS. Bublitz, yes PF will do both inbound and outbound aggregation automatically (no other way actually), in a sense that it will route replies back through the same interface that requests were sent from. Since requests will be ballanced (in connection units), so will the replies.

PS2. At first I was curious, since IP is connectionless and any sense of session can only exist at the transport level (or higher), if that would work over connectionless transport protocols, like UDP. The answer is yes, software like IPtables and PF is smart enough to do that! It uses very advanced (and cpu intensive) connection-tracking techniques to keep state of even protocols that don't carry session information on their headers. In IPtables it can be done through the CONTRACK module, in PF it is (more) automatically done through the "keep state" argument.