This article represents the first in a series of reviews of a market segment known as link load balancing.   Link load balancing are a class of device that allow multiple Internet connections of an unrelated nature to be shared, load balanced, and fail over, all without using a routing protocol.  They can handle links from 56K lines all the way to Gigabit downlinks, and mix and match them to boot.

Traditionally, if you wanted an office to have multiple network connections that were both load balanced and redundant, you’d get a few T1 or Frame Relay lines and run a routing protocol such as OSPF with your ISP.  If a link went down, the routing protocol would remove the bad link from routing tables, and traffic would proceed normally with hardly a blip. This would typically require using the same service provider, limiting redundancy.

Larger organizations would have full BGP peering with their ISPs as well as portable netblocks, allowing them a great amount of flexibilty in how their various links are balanced and failed over.  But of course few organizations today qualify for portable netblocks or have the budget for a staff that can handle that configuration.

Today, the T1 line as well as frame relay connections have fallen out of favor for most offices for Internet connectivity.  Typically far less expensive, and higher capacity, are consumer-grade cable modem and DSL lines, offering bandwidth from several hundred kilobits to 50 Mbps and beyond with the new DOCSIS 3.0 cable modems.  But most cable modem and DSL service providers won’t allow any kind of routing protocols, peering, or other load balancing/redundancy.  And that’s where link load balancers come into play.

Known as traffic mangers, link load balancers, and half a dozen other terms (sort of like the great server load balancer/application delivery controller debate), they allow you to utilize multiple links at the same time (sending some user requests out one link while others go out different links) and fail over to remaining links in case of link failures.

I’ve been wanting to do a review of a product in this market segment, and Ecessa was kind enough to send me an evaluation of their ShieldLink 100 link load balancer.

Setup

With these types of devices, I’ve found there are really are two aspects to the setup:  The device itself, and the installation environment.  The vendor of course owns the responsibility for how easy/difficult it is to get the device configured.  However, the vendor only has part of the responsibility for the actual customer environment, so I’ll cover these two aspects separately.

Shield Link Setup

When initially setting up the box, you’ve got a couple of options.  You can go the serial console route, or you can use the pre-configured IP address and go in via SSH or WUI (web user interface).

Web User Interface

The WUI is the best way to get the unit up and running.  Right out of the box, the unit has a pre-configured IP address, so all you need to do is put your workstation/laptop on that network and get a link going.  From there, you can log into the WUI via HTTP or HTTPS, and get started.

For the most part, I found the WUI relatively intuative and easy to configure.  I found I could get the WAN and LAN interfaces up and running pretty quickly, and with a few tweaks I had a working configuration within 20 minutes.  It’s a bit more complicated than installing a wirless router, but I’d say it’s in the same ballpark.  I found the documentation to be good, and they had a good “getting started” section that helped.

The only issue I had with the user interface is with something called test IPs.  You can configure up to three IP addresses on each interface for the ShieldLink to test to, to help determine whether the link is actually running or not (since a link-up light would only tell you if the cable or DSL modem is turned on, and nothing about whether the link is working).  That part is great.

The bad part is that you must configure 3 testing IPs.  No more, no less.  If you try to go with anything less than 3 entries, you will get an error.

The odd thing is, you can configure the same three IPs, and it will accept it.  So as long as you have 3 IPs (even if they’re the same) you’re set.  It just wants three entries.  So while it’s great to have these testing IPs, I’d prefer their implementation be a bit more flexible.  Such as the ability to put in zero to three testing IPs, and the ability to put in a hostname instead of an IP.  For instance, putting in yahoo.com, google.com, and microsoft.com.  This saves me the step of doing an DNS lookup, and besides, the IP addresses for any of these sites could change.

Command Line

Both the SSH and serial interface use the same CLI/text menu system, and to be honest, it’s a bit rough.  It’s functional, but not really user-friendly.  And I say that as a Solaris/Linux adminstrator and Cisco Certified instructor, so I’m not afraid of a little (or a lot) of command line.

Aside from initial setup, the command line can be an important component in trouble shooting, which the text-based interface was sufficient for (some troubleshooting commands can also be done from the WUI). It’s a complete and functional text user inteface, just a bit rough around the edges.  It’d be nice to see them move towards the ncurses-style configuration menu.  Curses is a popular menu system that powers many text-based configuration products, and it’s available as open source.

Installation Environment

The other setup issue that comes up is the installation environment.  Ecessa really helps in this area by doing a pre-configuration worksheet before shipping the equipment. This is important not only for configuration of the Shield Link, but also getting a clear picture of the environment.

Still, even the best prep work can be derailed by miss-information at the installation site, which I imagine would be fairly common.  Wrong IP settings, wrong subnet masks, etc., there are many ways it can all go wrong.  Sorting through undocumented connections will probably be the toughest part of the install.

Hardware

The box itself is a pretty standard network appliance style device.  It’s powered by an AC brick and has four Fast Ethernet ports.  The ShildLink specifies 150 Mbps of throughput, but it’s more likely that an installation would be capped at 100 Mbps, as three of the four ports would be used for WAN links, while the fourth would be your local LAN.

The only drawback is that these Fast Ethernet ports don’t do auto MDI-X, which automatically detects the need for a cross-over connection and adjusts accordingly.  This means you’ll have to use a crossover Ethernet cable if you’re connecting the ShildLink to a device that also doesn’t do MDI-X (the ShieldLink comes with a crossover cable).

Link Load Balancing

The operation of link load balancing is actually two very different functions and are handled with two very different methods.  There’s outbound connection link load balancing, and inbound link load balancing.

Outbound link load balancing is done through a series of source NAT operations.  Source NATing is what your wireless router at home does.   Locally, you’ve got a home network with multiple systems, typically using the private class C network 192.168.1.0/24.   The wireless router allows them all to share the one link.  Your cable modem or DSL provider will assign you one IP address, and the connections from your laptops, PCs, and other devices on your local wireless network have their source IP address changed to that of the provider assigned IP address.  Hence the name “source NAT”.

Link load balancers operate in the same way, but instead of one external IP address, it’ll have one or more external IPs for each link that the device is load balancing.  When a user on your local network connects to a site on the Internet, any one (and only one) of those external IP addresses will be used to originate the connection.

In my test scenario, I used three Internet connections and one local LAN connection, utilizing all four ports.  The three connections all connected to my test router (a Linux box with a lot of Ethernet interfaces).  I was able to disable links, misconfigure IPs, and so forth to test the ability of the Ecessa to detect link failures.

The ShieldLink was able to detect (using the aforementioned tester IPs) link failures and adjust accordingly.  Unless I killed a link mid-download, I noticed nothing as a client.

Inbound Load Balancing

On a purely conceptual level (leaving out the device configuration), inbound link load balancing is more involved than outbound link load balancing.  First, you need to figure out which external IPs to use as your inbound contact IPs.  Most of the time you’ll only have one IP per link (such as the case with most cable and DSL connections).   Then, you set up port forwarding to forward connections on a given port to a specific server.  Finally, the ShildLink (like most other link load balancers) uses dynamic DNS to point external users to those external IPs.

It involves the Shield Link becoming a DNS server.   Let’s say at your office you have an SSL VPN device.  It was sitting on your cable modem connection with a hostname of vpn.example.com whch points to 1.1.1.1.  By installing a shield link with two additional links, you’ll have a total of three separate IP addresses, 2.2.2.2 and 3.3.3.3 (example IPs only).  Dynamic DNS on the ShieldLink is configured to rotate through the IPs, distributing the traffic evenly between them.

If the ShieldLink detects a link falure, the external IP address for the failed link is removed from the DNS rotation.

This should move most users over to active links.  It’s possible that users who don’t refresh DNS or DNS proxies that ignore TTLs that are set to 0 will be stuck on a dead link, but generally this is minimal.  It should be noted this is very similar to how GSLB (Global Server Load Balancing) works.  I was able to test this functionality, and the LinkShield 100 was able to detect a link failure, and stopped distributing the corresponding external IP.

Monitoring

There are several monitoring pages that the ShieldLink provides, including the ability to produce bandwidth usage graphs on the fly for specified periods of time.

The ShieldLink supports SNMP for monitoring as well, so you can setup PRTG/MRTG/RRDTool or what have you to graph your various link utilizations.  Graphs can’t be overstated; a comically large portion of the success of my career can be attributed to me providing easy to read graphs for my clients and higher ups.

Conclusion

This is my first dive into the realm of link load balancing.  The genre itself is a great way to provide fault tolerance and bandwidth aggregation, and the ShieldLink unit worked as a very capable product in this market.