ASA Clustering – An Overview

In ASA 9.0, Cisco introduced the BORG cube for ASA’s. ASA Clustering. This power play brings back a competitive angle to a platform under siege by Juniper’s SRX series. We know there are big players in the High End Firewall space and this post is an introduction to clustering on the ASA. Maybe the SRX and ASA gap might close a little.

Cluster consists of up to 8 ASA’s acting as a single cohesive unit. This impact on the ASA works on scale. This scales on a multiplier of total nodes x 0.7. Performance scaling sits at 70% combined throughput, 60% maximum connections, 50% connections per second which is important to add into your design.

The example used is a ASA5585-X SSP-40. It can handle 10Gbps of firewall traffic.

10Gbps * 8 ASAs / 0.7 = 56Gbps

The cluster group works in a master slave scenario. This is done through priority and is very similar to stack master or HSRP elections. The steps are as follows. Broadcast every three seconds with an election request. Higher priority units respond (priority 1-100; 1 is highest) and after 45 seconds if no one else higher responds then it is the master. A tied priority falls back to unit name then serial number to determine status. A later joining higher priority device will not seize master status. It will wait until elected.

Owner – Recipeint of the connection. Maintains TCP state. Connections only have a single owner.
Director – An ASA that handles owner look up requests from forwarders. This role also handles backup flow control. Directors are chosen based on the hash of the SRC/DST IP addresses and TCP ports send from an Owner.
ForwarderA forwader unit passes packets to the owner. It can look at the SYN cookie to determine the flow Owner. Quick transactions such as ICMP or DNS look ups a query is not sent. The flow is looked up by the director.

Image copyright of Cisco Systems (c) 2013

Here you can see the SYN packet originating from the client and is sent to an ASA. The ASA this is sent to becomes the owner. The owner flow is created, encoded into a SYN cookie, and forwarding the packet on-wards.

SYN-ACK is sent back originating from the server. Case in point it is delivered to another ASA. This is known as the forwarder ASA. Due to it not being the owner it decodes the SYN cookie and passes the flow to the owner. A SYN-ACK is forwarded onto the client. The director has a state update sent to it and records state information and performs the role of backup flow owner. Subsequent packets sent to the forwarder are passed onto the owner. If a SYN-ACK is sent to a different forwarder a query is sent to the director. This determines the owner and establishes a flow. All state changes for flow results in an owner to director state update.

NAT on the cluster is sphincter twitching. Due to the nature of Rx/Tx NAT packets can be sent to different ASAs in the cluster, NAT can have different IP addresses and ports. If a NAT packet arrives back that is not a connection owner, the cluster control link is used to send the packet to the owner. Therefore there is a LOT of traffic send across cluster control links.

Caveats of NAT and clusters are worth noting. No Proxy ARP, interface PAT, no static PAT for FTP and VOIP. Say Goodbye to round-robin too.

The master unit will look at the NAT pool and pre-distribute addresses across the cluster. If a cluster member has run out of addresses and does not have any addresses left the connection is dropped. Dynamic NAT translations are managed by the master unit. This table is then replicated to other units. If a translation is required and not in the table then the Master unit is queried. The slave unit owns the connection.

The aforementioned cluster control link is important. Getting the sizing right can make a very large difference to the stability of the cluster. From experience I would recommended utilizing your Ten gig interfaces for this use. Considerations such as NAT are important in sizing as poor design can impact performance. Cluster control links are discussed in depth on the Clustering guide but it should be enough to cover firewall throughput. The example used of Cisco is a ASA5585-X SSP-60 which has around 14Gbps of throughput. It is recommended to use 2 x Ten Gigabit Interfaces to run the cluster control.

ASA Clusters add many benefits to a data center design. It is extremely important and I cannot stress this enough that testing fail-over and flows are important. Knowing why you are clustering and not doing it for pure bandwidth is important. You don’t wanna be the fastest car and be extremely unreliable! Understanding the cluster configuration and how it works as a cohesive technology can add huge amounts of benefits to your security solution.


3 thoughts on “ASA Clustering – An Overview”

  1. i am trying to make clustring lab on GNs 3

    is there is any testing serial number to enable it on ASA

Leave a Reply

Your email address will not be published. Required fields are marked *