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.

Ecessa Launches Secure WAN Link Controllers with Integrated Firewall and VPN GatewayNew Shield

Plymouth, MN -March 10, 2009 – Ecessa (formerly Astrocom), a leader in affordable WAN link controllers for small-to-medium sized enterprises (SME), has announced its new product family of affordable WAN Link Controllers that brings greater security and WAN link control to the SME market. The new ShieldLink family includes a built-in firewall and Virtual Private Network (VPN) gateway along with increased flexibility in defining access control. These features are integrated in one network device to provide SMEs with greater functionality and reliability to manage Internet traffic and maintain websites more effectively without the high costs of other WAN offerings.

By providing more integrated features targeting security, businesses save costs on implementing, managing and maintaining several new networking products, while maximizing secure and reliable 100% Internet traffic uptime. With the integrated VPN gateway feature, ShieldLink creates virtual tunnels that enable secure communications between sites by encrypting user traffic over the Internet using the strong security of IPsec. The VPN capability also provides flexibility in securing communications between remote telecommuters and the main office, regardless of location.

ShieldLink’s integrated firewall enhances access to networks with new security feature sets, and increased flexibility in defining access control. ShieldLink defines three classes (WANs, DMZ and LANs) of network interfaces for handling various network traffic zones. Preventing network intrusion to private networks by inspecting traffic passing through it (both inbound and outbound), ShieldLink regulates the flow of traffic within determined zones. For example, the Internet is a zone with no trust, while the LAN is a zone with higher trust. A demilitarized zone (DMZ), located between the Internet and the LAN, is an intermediate level of trust.

“Ecessa has always been focused on the SME market, with a clear understanding of these specific customers’ business and IT requirements for managing their WAN infrastructure,” states Ron Thomas, president and CEO of Ecessa. “ShieldLink is the most recent example of how Ecessa continues to offer many enterprise-class features at a price point affordable to the SME market. This is extremely important when IT departments are looking to do more with less cost and resources.”

Other ShieldLink capabilities include intelligently and efficiently distributing traffic among multiple, diverse network links and link aggregation (multi-homing); automated inbound and outbound load balancing and failover; site failover and fallback, redundancy, and traffic shaping. ShieldLink allocates Internet traffic across several links and uses bandwidth aggregation to maintain several links separately. With the ShieldLink channel bonding feature, multiple and diverse WAN links (i.e. cable, xDSL, T1, wireless, etc.) are combined into one large network connection to provide greater available bandwidth and reliability for large file transfers. Additionally, ShieldLink provides IT administrators with greater control, by allowing them to easily adapt to network changes based on an optimization layer within the WAN.

ShieldLink is available immediately in several configurations: 100, 250 for single sites and 55, 200, 250EHQ for multiple sites. ShieldLink can be purchased as a stand-alone secure WAN link controller, or as an add-on (software/firmware) module for existing Ecessa PowerLink products.

About Ecessa

Ecessa (formerly Astrocom) is a leader in affordable WAN link controllers for WAN and ISP link aggregation, automated load balancing, failover and network security tailored to meet the needs of small-to-medium sized enterprises (SME) that rely on the Internet for e-commerce and business-critical application delivery. Ecessa helps SMEs rapidly grow their business with 24/7 network high-availability, optimized WAN performance, flexible scalability and secure access – while streamlining IT costs.

At one-third the cost of other competing products, Ecessa’s PowerLink and ShieldLink deliver industry leading price/performance value. Ecessa optimizes WAN traffic for organizations of all types who wish to improve network and application performance and eliminate downtime for business-critical, time-sensitive applications.

Ecessa uses multi-homing to connect a single LAN or WAN to multiple ISPs; enables quality-of-service (QoS) to prioritize network traffic that ensures the best possible bandwidth is always available to applications, especially during periods of congestion; and uses link load balancing and automatic failover to direct traffic to WAN links with the optimum bandwidth and cost-efficiencies.

Over 6,000 companies rely on Ecessa to cost-effectively ensure that each application has the appropriate Internet bandwidth and availability needed to support user and business requirements. The company is headquartered in Plymouth, MN. For more information, visit www.ecessa.com, or call us at 1-800-669-6242.

###

Link load balancing (sometimes called WAN controllers and half a dozen other terms) is taking several non-carrier grade Internet connections with various prociders (such as DSL or Cable) and combining them for scaling and redundancy.

There are several vendors in the space, and in the next few days I’ll be putting up related material.  Link load balancing will also be covered in the lbwiki.