Scalability and Performance

Tom Eastep

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.

2008/09/19

Table of Contents

Introduction
Host Groups
Scaling by Host Groups
Scaling by Zones
Scaling within the Shorewall Code
Improving Performance

Introduction

The performance of the shorewall start and shorewall restart commands when using Shorewall-shell is a frequent topic of questions. This article attempts to explain the scalability issues involved and to offer some tips for reducing the time required to compile a Shorewall configuration and to execute the compiled script.

Ultimately, the solution to these performance problems is to migrate to the use of Shorewall-perl if at all possible.

Host Groups

In this article, we will use the term host group to refer to a set of IP addresses accessed through a particular interface. In a Shorewall configuration, there is one host group for:

Each entry in /etc/shorewall/interfaces that contains the name of a zone in the first column.
Each entry in /etc/shorewall/hosts.

As you can see, each host group is associated with a single zone.

Scaling by Host Groups

For each host group, it is possible to attempt connections to every other host group; and if the host group has the routeback option, then it is possible for connections to be attempted from the host group to itself. So if there are H host groups defined in a Shorewall configuration, then the number of unique pairs of (source host group, destination host group) is H*H or H². In other words, the number of combinations is the square of the number of host groups and increasing the number of groups from H to H+1 adds H + H + 1 = 2H + 1 additional combinations.

Scaling by Zones

A similar scaling issue applies to Shorewall zones. If there are Z zones, then connections may be attempted from a given zone Z_n to all of the other zones (including to Z_n itself). Hence, the number of combinations is the square of the number of zones or Z².

Scaling within the Shorewall Code

Shorewall-shell is written entirely in Bourne Shell. While this allows Shorewall to run on a wide range of distributions (included embedded ones), the shell programming environment is not ideal for writing the compiler portion of Shorewall. As a consequence, the code must repeatedly perform sequential searches of lists. If a list has N elements and a sequential search is made for each of those elements, then the number of comparisons is 1 + 2 + 3 + .... + N = N * (N + 1 ) / 2. So again, we see order N² scaling.

Improving Performance

Achieving good performance boils down to three things:

Use a light-weight shell and fast hardware. Especially in the compiler, a light-weight shell such as ash or dash can provide considerable improvement over bash.
With all of the order N² scaling that is implicit in the problem being solved, it is vital to keep N small.
- If you have a large number of interfaces, use wild-cards ("+") in /etc/shorewall/interfaces and /etc/shorewall/hosts to reduce the number of host groups.
- Combine host groups with similar firewall requirements into a single zone.
Use NONE policies wherever appropriate. This helps especially in the rules activation phase of both script compilation and execution.

So while it is tempting to create lots of zones through entries in /etc/shorewall/hosts, such configurations always perform badly. In these cases, it is much better to have more rules than more zones because the performance scales linearly with the number of rules whereas it scales geometrically with the number of zones.

Another tip worth noting has to do with the use of shell variables.

Suppose that the following appears in /etc/shorewall/params:

HOSTS=<ip1>,<ip2>,<ip3>,...<ipN>

and suppose that $HOSTS appears in the SOURCE column of M ACCEPT rules. That would generate a total of N * M iptables ACCEPT rules.

The number of rules can be reduced significantly by using an action. Consider the following:

/etc/shorewall/actions:

AcceptHosts

/etc/shorewall/action.AcceptHosts:

#TARGET SOURCE          DEST            PROTO   DEST    SOURCE     ORIGINAL     RATE
#                                               PORT    PORT(S)    DEST         LIMIT
ACCEPT  $HOSTS

If the M ACCEPT rules are now replaced with M AcceptHosts rules, the total number of rules will be N + M.

Example (Accept net->fw SSH from $HOSTS):

#ACTION          SOURCE          DEST            PROTO   DEST    SOURCE          ORIGINAL        RATE            USER/
#                                                        PORT    PORT(S)         DEST            LIMIT           GROUP
AcceptHosts      net             $FW             tcp     22