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.

How It Fits Into the Network

The AX series operates can operate in Layer 3 (route-path) and Layer 2 (bridge path) modes.  In Bridging mode the A10 works in both standard Layer-2 path (two VLANs, the AX2200 bridging the two) and the multi-armed mode, where the servers plug directly into the AX2200’s switch ports.

In Layer-3 mode, the AX2200 can work in either one-armed mode (VIPs and real servers on the same subnet) or two-armed mode (VIPs and real servers on different subnets).  Half-NAT (where the client’s true source IP address is preserved) and full-NAT (all connections appear to come from the load balancer) are supported, with the ability to insert the real source IP in an HTTP header if necessary.

The unit cannot operate in both Layer 2 and Layer 3 modes, however, so it’s either one or the other.

Networking

The AX2200 has 16 copper Gigabit Ethernet ports, with 4 additional fiber ports.  These ports support 802.1Q VLAN trunking, so you can run multiple VLANs if needed.  There’s also an additional management Gigabit Ethernet port, which can have its own default gateway configured (separate from the rest of the box, which comes in handy for a management network) as well a pretty typical serial port.

Physical

Physically, the box is substantial.  It’s quite sturdy and heavy with a 2U form factor that is fairly deep.  There are two AC inputs on the back for power redundancy, and if both aren’t plugged in, there’s an alarm that goes off.   There’s an alarm disable switch, but it must be used every time the unit is powered on with only one power source.

The box has a hard drive installed, as well as a flash drive, each holding two firmware images.  This allows you to upgrade one, while having the other as a backup in case something goes awry.

Configuration

One of the nice aspects of the A10s is that if you’re familiar with load balancing concepts in general, you’ll be able to quickly adapt to the A10.  They don’t diverge too much from standard SLB/ADC terminology and concepts, which comes in handy.

The CLI is Cisco-esque in nature, and follows most of the Cisco IOS syntax with a few exceptions (i.e. the “enable” command to enable an interface instead of “no shutdown”).  If you’re used to Cisco, the command line shouldn’t be a problem.

The WUI (Web User Interface) is an evolution from the 1.x release, not a revolution.  Most of the same basic concepts are there, some are just expanded upon more.  There’s more liberal use of the template concept, allowing for things like rate limiting, cookie persistence, and other configuration templating.

On the whole, I found I could add a VIP with a few real servers in under a few minutes via the WUI.  It’s quite responsive and easy to navigate.

Advanced Features

One of the A-list features of the A10 is its content control language, originally named aRules (somewhat familiar to another content control language, F5’s iRules).  They’ve changed the named to aFleX, although it’s still the same language.

New to the 2.0 release is aXAPI, an XML API for controlling the AX devices remotely.  You can use various URLs and XML to monitor and configure via your own home-grown methods to automate tasks such as adding real servers or downing a global site.

Another nice feature that the A10 has (and had since the 1.x release) is the ability to do selective source-NATing.   This addresses one of the most common issues that comes up, which is the “same subnet” problem (more on this in another post).

With selective SNAT, you create an ACL that matches any subnets that you want to be SNAT’d (typically the same network the servers are on, so they can connect to the VIP).

For example, let’s say your servers are on the subnet 192.168.1.0/24.  Without doing SNAT, you can connect to your VIP from any IP address except the server subnet. You apply the ACL so that anything from 192.168.1.0/24 gets SNAT’d, while everyone else connects in from their true source.  You get the best of both worlds.

A10 isn’t the only vendor that offers selective SNAT, but there aren’t many that do.

Virtualization

The 2.0 release also includes an implementation of virtualization.  You can create various partitions that allow different users to have control over their resources.

If you have control of a partition, resources aren’t assigned to you per say.  You grab a resource, such as an IP address for a VIP and that IP becomes “yours”.  When that IP is in your partition, other partitions can’t use or modify it.  Same thing with real servers; other partitions can’t disable/enable your real servers.

Currently, there’s no ability to restrict resources (such as bandwidth, connections per second , access to physical ports or VLANs, etc.) although you can limit the number of aFleX rules (just not how much CPU resources the rules take up).

It’s not quite full virtualization in the IBM LPAR/VMware mold, and vendors like Cisco (with their ACE) allow for a greater degree of virtualization.  However, the A10 implementation does offer some benefits to organizations looking to partition users.

Conclusion

Overall, like the AX2000 review before it, I found the AX2200 with the new firmware to be a very capable box.  It certainly has the features necessary to run with the big boys in the Enterprise market.

Coyote Point has announced today a new series of application delivery controllers/load balancers, the GX series.  Coyote Point was kind enough to provide me with an evaluation box of their flagship product, the Equalizer 650GX.

Configuration

The GX series comes with version 8.5 of the Equalizer code, an update from the 8.0 code released earlier in 2008.  Look-and-feel wise, there’s not much difference from the 8.0 release, which itself was a pretty major facelift  from the 7.x code base.

Configuration is pretty straight-forward, and the addition of user-friendly (and meaningful) configuration wizards make the Coyote Point. Terminology is a bit different than what you may be used to, such as Virtual Cluster as opposed to VIP or Virtual Server, and “quiesce”, which means the server is active, but not taking any new connections.

Plotting

One of the additions in the 8.5 release is the ability to do plots.  CPU utilization and memory utilization of the system are handy, but the L7 and L4 metrics aren’t all that useful.  Currently the graph continues to climb, since it’s just counting the number of events that have occurred (in this case, the number of Layer 7 connections processed).  It would be better if they were a rate, a function of events occurring in a given time period (such as connections per second).

Plotting a handy and welcome utility, especially when rates are added.

Attention Span

The Equalizers have, for a while now, had the ability to configure the attention span.  By configuring the Virtual Cluster option “once only”, the Coyote Point would only look at the first HTTP request header in a TCP stream.  By deselecting that option, the Coyote Point would pay attention to every HTTP request header.   Coyote Point is one of the only (if not the only) value market vendor that has this ability:  KEMP and Barracuda (as far as I know) do not.

Sliders

Another difference from 8.0 is the introduction of sliders. In the screenshot below, you can see the sliders are used to select variables in the load balancing algorithm for a virtual cluster.

Not a terribly big deal, but they can help make configuration easier to eyeball, as well as give some perspective to make the interface more user friendly.   The sliders haven’t made it into all the sections where it might make sense, and I suspect they’ll be added as updates get made to the 8.5 code.

Compression

Coyote Point is fairly unique in the load balancing world in that in addition to SSL offload cards, the Coyote Point also has a compression offload card (most vendors use the general processor to do compression).

Compression as a feature works by interception an object (such as an HTML file or text file) sent from the server to the client.  The Equalizer will compress that object, and forward it to the client as a compressed object.

When a browser makes a request for an object, the browser informs the server if it can support compressed objects.  The server (or in this case, Coyote Point) will not send a compressed object to a browser that doesn’t ask for it.  Because of this, compression is a great zero-risk feature to turn on (OK, as close to zero risk as you get in the load balancer world).

By using compression, you can greatly reduce the among of bandwidth you send to the Internet, as well as increase the page load times of your users (especially those who have poor connectivity to your site, such as dial up or International clients).

Objects such as HTML, XML, text, Word documents, etc., can benefit from compression (JPGs, which are already compressed, not so much). The types of objects subject to compression is user-definable on a per-VIP basis, and the defaults are perfectly acceptable.

GX versus si Platform

The E350GX replaces the E350si, the E450GX replaces the E450si, and the 650GX replaces the E650si.  The E250si remains unchanged with the exception of a price drop (to $2,495), and still is Layer 4-only.

Performance-wise, Coyote Point claims improvements across the board.  I’m reporting them below as they were given to me by Coyote Point.  I do not have the capability of verifying any of these numbers.

The GX uses faster hardware under the hood, so all GX models claim performance increases (in terms of throughput, connection rate, and SSL).  For instance, the E650si claimed about 800 Mbps of overall throughput, while the E650GX claims about 1.3 Gbps.

The GX platform drops all 10/100 ports in favor of going all Gigabit Ethernet.  Everything from the 350GX to the 650GX is pure Gigabit 10/100/1000 ports.  This is important, because the main benefit of Gigabit isn’t necessarily to push 800 Mbps of traffic, it’s to push 101 Mbps of traffic.

The new Xcel-II SSL offload card boast 8,500 SSL TPS on the 450GX and 14,000 SSL TPS on the 650GX. The E350GX is software SSL only, and maxes out at 500 TPS.

Hardware

Physically, the box is similar to its predecessors, with a 1U form factor and ports accessible on the front.  The shell is a fairly reflective metal, and has a good solid feel to it.   Physically, they’re similar to the previous Equalizer “si” generation, although the glowing red logo has been updated to a paw.   The E650GX includes 22 Gigabit Ethernet ports.

Switchports

On previous iterations of the Equalizer platform, the boxes had fixed port assignments.  You were either on the Internal network or the External network.   You would use one of those two networks or both, depending on weather you were using a two-subnet configuration or a one-subnet configuration.

With the GX line, you’re actually able to change what network the ports are to be assigned to through the GUI.

Topology

As with the previous generation of Equalizers, there are several ways that they can be deployed in a given network.  There are the standard one-armed and two-armed configurations (one Layer 3 network or two Layer 3 networks, respectively).  Since the Equalizers are also Ethernet switches, the direct plug-in method is also available, where you plug servers directly into the Equalizers.

The one-armed and two-armed configurations are pretty common in the value market, and they allow you to keep your servers plugged into whatever switch you’re currently using.  The server plug-in method is good to leverage if you don’t have a network switch, and is often seen in the switch-based products like Foundry’s ServerIron or Nortel’s Alteon.

In my testing, I use a simple flat one-armed network, where the servers and virtual IPs were on the same subnet, while keeping  the servers plugged into my regular Layer 2 infrastructure.

VMWare Integration

The 8.5 code also boasts the ability to integrate with VMware.  Depending upon traffic and server load levels, the Equalizer would be able to reboot, spin-up, or spin-down a Virtual Machine.  I lack a VMware server farm, so I don’t have the ability to test these features.

Bottom Line

The E650GX lists for $14,395 (double that for a redundant pair).   This is on the high-end of the value market, and Coyote Point by its very existence makes a very compelling argument for the existence of a mid-market, one that exists between the value and enterprise markets.

I found the feature set to be strong, and the user interface to be exceptional.  It’s definitely worth a look, and an addition to your short-list of vendors.

KEMP LoadMaster 1500

KEMP is a member of the value market vendors, and their LM-1500 is what put them on the map. Released in late 2005, the $2,500 price tag gained it a lot of fans. At the time, it was the only Layer 7 load balancer at that price range (a few more have introduced products at that price).

The LM-1500 has been reviewed before, but they’ve got some new code coming out that introduces some new functionality (including caching and compression), and they were kind enough to send me over a box with the soon-to-be-released code. (If you have a product you’d like to see reviewed on lbdigest.com, feel free to contact me [tony at lb digest dot com]).

Getting Started

The LM-1500 can be initially configured through either the VGA port with a USB keyboard, or through the serial port.  After it’s given an IP address, the rest of the configuration is done through a web interface.  There’s also a way to configure from the start with a web interface, as it comes up with a 192.168.1.100 IP automatically.

Administration

There is a command line interface, but virtually all of what you need to do can be best done through the web interface.  One of the nice touches they’ve added is the “download root certificate”, which installs a trusted CA cert on your browser to get rid of the annoying but ubiquitous self-signed certificate warning.

Creating a Virtual Service (VIP) is pretty straight-forward.  Give it an IP address and port, select your options (L7, cookies, etc.), and so on. There’s also configuration options for a “sorry server” (if non of your regular servers are up, the LM will send traffic to a sorry server, which can have a some sort of “sorry, we’re not working right now page”.

There’s also a handy stats section, reporting on the various performance metrics of the device.  Most of these metrics are also available through SNMP (for PRTG/MRTG, etc.).

App Delivery Features

The LM-1500 does the standard Layer 4 load balancing, as well as the more advanced cookie-based persistence and web switching.  The only drawback is that you cannot do both web switching and cookie-based persistence at the same time.

There are quite a few options available to a virtual service configuration, including transparency (full-NAT or half-NAT), health checking, and a “sorry server”, for when all the servers in your main web app farm goes down.

SSL certificate management works well as well, making it pretty easy to add/remove/change SSL certificates assigned to virtual servers. The LoadMaster automatically installs a self-signed certificate when you turn on SSL termination, and gives you the option to install CA certs and intermediate certs.  The LoadMaster 1500 does not include an RSA SSL ASIC, however (see the box section for more specifics).

Network Architecture

As I’ve said before in other reviews, one of the aspects missing in in a lot of reviews is how the product fits into the network, so I make a point to include some details.

The LM-1500 operates only in Layer-3 route-path mode, it cannot be used as a Layer-2 bridge-path load balancer.  You must either use the LM-1500 as the default gateway, or use it in non-transparent mode.   One of the easiest ways to put an LM-1500 into a network is the one-armed mode, where the Virtual Service IPs (VIPs) and the real servers all sit on the same subnet.

The LM-1500 also works well in two-armed mode, which is typically when you have the Virtual Service IPs on a public subnet and the real servers on a private RFC1918 address space (such as 192.168.x.x).

The Box

The box itself is of solid metal construction, and doesn’t look or feel “cheap”.  The bright gold is unmistakable, and in addition to being prominent in a data center, it would probably keep me safe on my late night training runs.

Stat-wise, the system is powered by a VIA Eden chip, with 512 MB of RAM which is more than sufficient for this class of system.  On-board storage is solid-state flash, so there are no moving parts (other than a fan) and the system boots very quickly.

There are three 10/100 Fast Ethernet interfaces, each operating in routed mode (the LoadMasters don’t do bridged) so each interface would each be on a different subnet.

The system boasts on on-board SSL chip, however the chip only does the symmetric “bulk” encryption algorithm AES.  Most of the heavy lifting in an SSL connection is done on the asymmetric RSA operations when an SSL connection is established.  While the AES bulk encryption would help tremendously in long lasting download-type connections, it’s of little use for rapid-fire of short lived connections, which is what most web connections are.

Caching and Compression

The newest addition to the LM-1500 (and the other LoadMaster models) is the addition of caching and compression as well as web application firewall abilities.

In its initial deployment, there’s not much you can configure with the caching and compression, other than turning it on or off per virtual service.  I was able to verify that cached objects came from the LoadMaster, and not the server.

With the LoadMaster, compression is actually another method of caching.  Instead of the on-the-fly compression that most other products do, objects are cached by the LoadMaster, and compressable objects are compressed once in the cache.  This doesn’t get you the benefits of on-the-fly compression for dynamic web pages, but it’s much easier on the CPU (there’s no compression ASIC on the LM-1500).

For compression, I used the simple apache.gif file that comes with the Apache distribution.  Normally, it’s 2410 bytes.

Content-Type: image/gif
Content-Length: 2410

Turning on compression, and I see the LoadMaster send back a gzip’d image.

Content-Type: image/gif
Content-Encoding: gzip
Content-Length: 1795

That’s a slight decrease, but not really a fair test since there’s not a lot to compress.  So to give a better test, I saved the main page of lbdigest.com, and the HTML file came out to about 38K.  I put it up as a static page on my test server, and accessed it through my browser.

 Content-Length: 38180

Turning on compression, I accessed the page again:

 Content-Encoding: gzip
 Content-Length: 11041

From 38k to 11k, that’s more than a 3 to 1 compression ratio on the main page.  Not too shabby.  If your clients were on a 56k dialup line, or connecting from a PC in say Bali, Indonesia, that 3 to 1 savings could mean a much faster page load.

With caching and compression, your mileage may vary quite a bit, depending on the nature of your users and the nature of your content.  It could help tremendously, or it could end up slowing your site down significantly, so it’s something that’s best to test first (this is true for any product that does caching).

Wish List:

My wish list would be the ability to exclude/include file extensions (no PHP, yes on JPG, etc.) and some better reporting of cache and compression statistics.

IPS/Web Application Firewall

Another new addition to the LoadMaster is the addition of IPS/WAF (Web Application Firewall) capabilities (the only other value market product to have this capability is the Barracuda, which I have not personally tested).  The LoadMaster uses SNORT-compatible rules (you can get a limited set for free at snort.org) in order to catch malicious requests.  For instance, try to go to “/etc/passwd” (http://domain.com/etc/passwd) as the URI, and the connection will be blocked at the LoadMaster, and won’t be forwarded to the server. Reporting is a basic with this first release as well, with blocked requests being reported through SYSLOG.

08-01-2008 10:10:39 Invalid URL '/etc/passwd' - WEB-MISC /etc/passwd

Having a web application firewall is part of the new PCI-DSS recommendations.

Wish List:

The ability to pull automatic updates and the ability to get your subscription through KEMP (rather than finding SNORT rules on your own) would be my wishlist for this feature.

Conclusion

Overall, this is a very solid release.  The new features (caching, compression, WAF) are going to be very handy for the SMB.  They are a bit sparse in their configuration, but work quite well as a first release.  The same code will run on all of the LoadMaster line, with the only difference is that the LM-2500 and up have SSL accelerator cards (for the RSA heavy lifting, not just AES).

Availability of the new release will be in the next few weeks.

Functionally speaking, the 7.2 Coyote Point Web UI (or WUI) was always functional.  However, aesthetically speaking the 7.2 interface was a little rough around the edges.  Perfectly functional for what you needed to do, just a little utilitarian.

With the release of 8.0.0, they cleaned a lot of that up, and putting the entire package into a more aesthetically pleasing interface.

One of the nicest additions with the 8.0 is on the main page, which now shows performance metrics (Layer-4 and Layer-7).  In 7.2, these metrics were available, just a few clicks from the main page.  Having them front and center is a welcome addition.

There is now an AJAX-style wizard for adding virtual clusters (virtual services) and servers.  This is demonstrated in a quick look video, available below.

The 8.0.0 isn’t all looks, it also brings about some new functionality, including integration into VMWare server farms, support for the new e650si monster platform (21-port Gigabit Ethernet web switch), as well as support for a new line of acceleration cards, which they call “Xcel2″, which boosts the available SSL TPS.

I don’t have a mega VMWare server farm, so I was unable to test this new functionality, but it’s interesting as I start to see more and more virtualization beyond testing and development (my test web server is actually Ubuntu in Microsoft VirtualPC 2007).

Overall, the 8.0 is a significant upgrade for the Coyote Point line.  You can check out what Coyote Point has to offer at http://www.coyotepoint.com.

Founded by Lee Chen, co-founder of Foundry Networks, A10 Networks first came out with a network ID product called IDsentrie. They then entered into the load balancing fray with the introduction their AX series of application delivery/load balancing in January of ’07, and have been aggressively going after the enterprise ADC (application delivery controller)/load balancer market since.

I got my hands on an A10 AX2000 recently, and gave it a look-see.

Setup and Configuration

Setup was pretty simple, and despite this not being a terribly good habit, I was able to get the system up and running without really looking at the manual. It’s not a dramatic departure from other similar products in terms of configuration, and that’s a good thing.

They follow the fairly common load balancer abstraction objects of virtual server/service, service group, and real server. In addition, they make heavy use of profiles (cookie profile, HTTP profile, etc.) which are applied to various VIP/group/real server parameters. They have the basics pretty much right in terms of making their configurations relatively easy.

I put together a little demonstration video for configuring a simple one-server load balancing setup, which you can view below.

If you’re curious as to the network setup I used for this video, here’s a diagram:

Network Implementation

One of the biggest issues with actually implementing any load balancing product is to figure out how it fits into a given infrastructure. For the AX2000, I was able to set it up successfully both two-armed mode (VIPs and real servers on separate subnets) and one-armed mode (VIPs and real servers on the same subnet). Both modes worked with transparency (source IP is preserved) and non-transparency (source IP is obfuscated).

I was also able to set up load balancing in bridge-path mode, where traffic is forced through the load balancing on the way out by being in the Layer 2 path of traffic. Bridge-path isn’t new in the load balancing world (Alteons and other application switches have done this for a while), but it is interesting that the AX2000 supports this as bridge-path had largely fallen out of favor. One of the main benefits to bridge-path is that you don’t have to worry about setting the default gateway of servers to the load balancer (and still keeping the source IP address of the clients intact in the server logs), since you’re forcing traffic back through the load balancer by virtue of it’s place in the Layer 2 infrastructure.

When operating in Layer 2 bridge-path mode, the AX2000 acts like a switch. However, it does not participate in STP (spanning-tree protocol) and instead it runs its own redundancy protocol so that only one device in an HA pair forwards Layer 2 frames. This is fortunate, as few things strike fear into the heart of network administrator quite like the words “spanning-tree protocol”.

Physical

Physically, the AX2000 was heavier and more substantial than I had expected. The AX2000 model I reviewed had dual power supplies, and the case itself was of very solid metal construction.

High-End Features

One high-end feature of the AX series is the aRules control language. Based on Tcl, they’re similar to F5′s iRules (in terms of function and syntax) and allow for more granular control of HTTP traffic, both HTTP headers and HTTP content. The primary advantage of control languages is the ability to provide tighter integration and functionality to the application sitting on the server, and the primary disadvantage is the ability to provide tighter integration and functionality to the application. It’s a two-edged sword, and that’s where the value of an active user community really comes into play.

While the aRules do give a greater degree of control over traffic, they do have some catching up to do with F5′s iRules in terms of functionality and in terms of a community developed around that feature. That said, there are enterprise products that have been around for years that haven’t come up with their own control language. A10 came out with theirs before they hit birthday number one.

A handy tool that A10 includes is an aRuleEditor for Windows. You can create aRules with any text editor, but the aRuleEditor has syntax highlighting as well as all the functions available in a drop-down menu.

Performance

My apartment has many comforts, but among them is not the ability to push Gigabits of Layer 7 traffic, so I did not test the performance of this box. A10 Networks did commission the Tolly Group to test their boxes for performance, and you can find results on A10′s website for the AX2100 and AX3200 models.

List price for the AX2000 box with 5,000 SSL CPS (SSL acceleration is turned on by default, no additional licenses are required), 8 copper Gigabit ports, and 2 fiber Gigabit ports is $16,995. Double that for redundancy, of course.

Overall Impressions

From what I’ve seen, this is a very solid box. The feature set is there, the performance is there (at least according to the Tolly Group), and the company itself seems to be track. Probably the most impressive aspect of it is that in a little over a year, they’ve put out a solid product with more features than products that have been out for years. They’ve got some catching up to do before they reach feature parity with F5, but they’re doing pretty good so far.

If you’re a vendor and you’ve got a product you’d like reviewed at lbdigest.com, drop me a line, and we’ll see what we can do.