No surprises! Understand the main parameters on a Stateful Firewall data sheet and do a conscious selection of a device that meets the needs of your environment.
The task of selecting a stateful firewall that meets the performance needs of your network environment involves correctly understanding a set of parameters that go beyond the classic perception “the more Gbps, the better”. As a matter of fact, when taken alone, the Gbps number may be quite misleading for the evaluation of any stateful element. This happens because a network device that cares about state, forwards packets as part of connections and not on an individual basis (as routers and switches do).
This article analyzes four metrics that must be considered in conjunction whenever firewall performance is under discussion. The first two (throughput and forwarding capacity) are also relevant for routers and switches, whereas the other two (connections per second and concurrent connections) become meaningful for stateful devices.
To provide a real world illustration of the combination of such attributes, Table 1 brings a portion of the data sheet of the Cisco ASA 5585 series of security appliances.
Table 1: Summary data sheet for ASA 5585 series of security appliances
Firewall Throughput (bps)
Max Firewall Throughput (bps)
Forwarding Capacity (PPS)
Connections per Second (CPS)
To facilitate our study, Figure 1 brings a quick review of the L2 Switching and of the IP Routing processes:
L2 Switching: A switch relies on the MAC to interface associations in its MAC address table to forward Layer 2 frames. When a frame is received on one of its interfaces, the switch looks up the destination MAC address in its internal table. If the switch finds a mapping between the destination MAC and a port (distinct from the one on which the frame arrived), the switch forwards the frame only to the specified port. If no mapping exists, the frame is flooded to all outbound ports.
IP Routing: IP Routing is concerned with the choice of a path over which the IP packets, destined to a given host, will be sent. In its classic definition, IP Routing considers the destination address as the only criterion for path selection. As a reference, the main components of routing can be summarized as:
Gathering Routing Information
Installing entries in the Routing Table
Searching for the longest prefix match
Forwarding a packet on the outgoing interface, a step that includes the construction of the appropriate Layer 2 header.
The throughput attribute is measured in multiples of bits per second (bps) and is particularly important for a Layer 2 switch, a type of device that forwards frames based on the association of a destination MAC address to a physical port, as portrayed in Figure 1. This parameter is also referred to as aggregate bandwidth, which, roughly speaking, could be thought of as the volume of traffic (per second) that can be sent over each port multiplied by the number of physical ports interconnected by the switching matrix.
One limitation of the bps perspective is that, by looking at this metric alone, you cannot tell how many frames (or packets) per second are flowing through the device. You know, for instance, that a total amount of 1 Gbps can travel between ports but it is not possible to conclude anything about the average frame size:
Are you dealing with jumbo frames (~9000 bytes) or with small ones ( 64 to 90 bytes)?
In the case of small frames (say 90 bytes average), how much forwarding capacity will be necessary to fill up your 1 Gbps traffic lanes ? Does the device have this capacity?
The forwarding capacity is expressed in packets per second (PPS) and corresponds to the classic metric for evaluating router performance. After building the routing table, the router must have processing power to forward packets, irrespectively of packet size, using an output interface and next-hop combination that lead to the intended destination. Considering that, most of the time, firewalls are inserted in the network topology as Layer 3 elements, this parameter cannot be despised at all. Additionally, from the perspective of a stateful firewall, each connection might contain multiple packets. Two examples that illustrate the relationship between packets and connections are registered here:
The TCP three-way handshake process: When using TCP, before the application flow starts, at least three packets are exchanged between the communicating parties (client and server).
Large file transfers: The transfer of large files using protocols such as FTP or TFTP can involve a large quantity of packets within the same data connection.
I have witnessed many customers complaining that their firewalls were facing problems with small packets. A few of them even had the impression that their products had some kind of limitation when dealing with this category of packets. In essence, what happened in most of the situations could be described as follows:
The data sheet numbers were calculated using Jumbo Frames and expressed in Gbps.
Traffic in a real-world environment had, for instance, an IMIX-like profile (an average of 450 bytes per packet).
Considering that customers associated performance with Gbps, the disappointment was significant: a performance 20 times lower than the marketing numbers. (Just think about discovering that a claimed 30 Gbps throughput was not more than 1.5 Gbps...)
The simplified calculations registered in the following can provide a reasonable guidance for linking the PPS and Gbps values:
109 bits/second = (Y packets / second) x (3.6 x 103 bits / packet) (c)
(a), (b), and (c) yield Y ~ 278,000 packets / second, meaning that you would roughly need 278K PPS for each Gbps of IMIX Traffic.
If your deployment scenario involves smaller packets, the computations should be even more conservative. At this point an instructive exercise is to repeat the previous PPS computations using the Jumbo frames reference:
What would be the resultant forwarding capacity associated with 1 Gbps of aggregate bandwidth?
What would happen to the throughput attribute if you only had around 14,000 packets per second of maximum performance and still had to forward small packets?
Now that we described the PPS and BPS metrics, a couple of parameters that is suited for evaluating the forwarding of individual packets, it is time to shift gears to those attributes that come in to the scene when using stateful devices.
The basic operation of a stateful firewall can be described as conditional forwarding because it performs various checks before actually using its backplane to transfer a packet between the ingress and egress interfaces. To illustrate this concept, a very high-level packet flow for an ASA appliance is depicted in Figure 2. The flow chart in the figure highlights that the firewall initially verifies whether the connection already exists in its state table. On the flip side, for the case of a new connection, there are various decision points in which the packet can be dropped before the firewall actually sends it to the egress interface. Some of these dropping criteria are listed in the following:
Is there a route to the destination address of the packet?
Is the connection setup permitted by the configured Access Control List (ACL) ?
Does this packet comply with the NAT rules in place?
Does this packet pass the configured Layer 7 checks?
In the event the connection is created, the firewall will need to maintain the pertinent state information. Given that the state table has an upper bound of connections that can be held simultaneously, a new attribute comes to the spot. The Concurrent Connections variable is directly related with the amount of memory reserved for the state table an also somewhat interconnected with the CPS value. For instance, the ASA5585-SSP60 supports 10M concurrent connections and a CPS rate of 350 K ( please refer to Table 1). 10,000K connections / 350K CPS = ~28 seconds, meaning that this ASA model can accept new connections at the maximum setup rate of 350K CPS for a period of 28 seconds (without rejecting connections).
After building this distinction between stateless and stateful parameters, even though most people agree that the CPS metric is relevant, they normally complain that it is something difficult to measure. I agree that there no closed answer for this question, but there are some ways of getting a good guidance. In order to help you with this issue, two methods that might prove useful are registered below:
Practice with a tool such as Firebug (add-on to Firefox browsers shown in Figure 3) to evaluate the number of necessary connections/second to load the main web pages used by your company. As this tool informs the elapsed time, calculate the average CPS per user and, later, by knowing the desired number of simultaneous users for your site, you can find the desired CPS value. Do not forget, though, to consider the normal increase on the number of users per year and to leave some room for dealing with abnormal situations (such as Denial of Service attacks).
Use Flexible Netflow to measure connection setup rate. For TCP flows, you can, for instance, focus on aggregating ingress flows that have the SYN flag set.
This article discussed two classes of performance parameters that need to be considered when selecting a stateful firewall. Those that are shared with stateless devices (such as routers and switches) and those that are of interest for stateful elements. A good understanding of these individual metrics and their interconnections will help you on matching the information available on product data sheets with the needs of your company and being more successful on real life deployments.