Occasionally there are posts on the Load Balancing Mailing List that bring up very interesting issues that are worthy of particular note. So, from time to time, I will be highlighting certain posts on the LB Digest.
Recently member Cihan Subasi posted an interesting question on the state of Firewall Load Balancing. The poster asked if people used external load balancing appliances, or if they used the firewall vendor’s solution.
Several people responded, and among the opinions that I share is that FWLB isn’t all that common anymore, nor is it needed.
There was a time when most firewalls were basically PCs. Even Cisco’s PIX ran on Intel/AMD chips, and they all suffered the same performance problems I mentioned in “Parsing for Precision“. They just couldn’t keep up with the traffic levels that were being imposed upon them.
Firewall Load Balancers (FWLB) came in as a solution to solve these issues. They were typically web switches (ASIC-based load balancers) from the likes of Alteon and Foundry Networks, and would allow scaling of firewall capabilities by simply adding more firewalls.
While they worked on paper, they were notoriously complicated setups, and the wiring alone was enough to make one’s head spin. So instead, many sites just split up traffic among smaller load balancers. This was architecturally inconvenient, but it was still preferable by many to FWLB.
And as time went on, two things happened: ASIC-based firewalls with the ability to do complex rules at wire-speed appeared (NetScreen, for instance), and more gradually, x86 processor speed increased to be able to handler ever increasing traffic loads, and this was supplemented by encryption acceleration/offloading hardware. One vendor in particular, Stonesoft (disclosure: I once worked for them) had a clustering component built-in; it was its own load balancer.
So, even now, FWLB isn’t all that common. Firewalls on modest hardware can handle tremendous amounts of traffic, and for the really high traffic levels, other solutions exist (ASIC, self-clustering, etc.) to handle scalability issues that are generally simpler.
That doesn’t mean it’s not in use, nor does it mean it’s not a good solution for a given infrastructure, but it’s just not common.
