Revisiting Firewall performance parameters
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
To facilitate our study, Figure 1 brings a quick review of the L2 Switching and of the IP Routing processes:
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:
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:
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:
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...)
If your deployment scenario involves smaller packets, the computations should be even more conservative.
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:
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:
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.