Understanding, Configuring, & Verifying ASA Clustering

"The What?" - In this blog I will be covering ASA clustering. I intend on providing a brief general overview of ASA clustering, as well as how to configure one of the modes & perform verification.

"The Why?" - ASA clustering provides several benefits. Some of those benefits include the following:

• Ease of management: all config changes are done on master and replicated via cluster control link (CCL) to other units.

• Higher throughput: provides ability to aggregate traffic to accomplish higher throughput

• Redundancy: disaster recovery within the cluster due to unit or link failures resulting in minimal downtown

"The How?" - Now I will cover the configuration & verification portion, but first there are some important things to cover.

ASA Hardware & Software Requirements for units in a cluster:

• Same model with same DRAM. Flash does not have to be the same.

• Same software

• Same security context mode, single or multiple

• Same firewall mode, router or transparent

• New cluster members must use same SSL encryption setting as the control unit for initial cluster control link communication before configuration replication

• Same cluster, encryption licenses

Unsupported features:

• Remote Access VPN: TLS VPN, Clientless SSL VPN, and IPSec

• S2S VPN on FTD only until 6.2.3.3

• DHCP client, DHCP server, DHCP Proxy

• Advanced Application Inspection and Redirection

• CTIQBE, WAAS, MGCP, MMP, RTSP, Skinny/SCCP, H.323

• Dead Connection Detection (DCD), Botnet Traffic Filter, and WCCP

• Interfaces: Integrated Routing/Bridging (IRB), Virtual Tunnel Interface (VTI)

• Intermediate System-to-Intermediate System (IS-IS)

ASA Clustering best practices:

• Set cluster control link (CCL) MTU to 100 bytes larger than largest data interface to avoid CCL fragmentation

• A lot of problems for ASA clustering involve NAT

• Only use NAT in conjunction with clustering if needed

• Do NOT user a single interface PAT in a cluster

• Ensure CCL link throughput is equal to aggregate data throughput for worst-case scenario redirection problems

Brief overview of ASA clustering:

• Can configure up to 16 identical ASA units in a cluster

• Virtual IPs & MAC addresses are used for first-hop redundancy

• Configuration is mirrored to all members

• Stateless load balancing is performed via IP routing or etherchannel with LACP

Cluster Member Election Process:

• One member is elected as the master

• All other units are slaves

• Configuration is locked on slaves

Detailed steps for election:

• An ASA with clustering boots up & seeks a master

• The unit waits up to 45 seconds before it receives a response from potential master. If no response deeming that a master is/was found, then the unit becomes the master

• If a master exists, the unit role becomes a slave

• The slave unit pulls configuration from master

• The master ASA admits one unit at a time

• Cluster slave is ready to pass traffic

Deployment modes for ASA Clustering:

ASA Clustering different modes for load balancing:

• Spanned mode = Connects ASAs to switches. Multiple ASAs act as a single logical device when connecting to outside devices. In this scenario the switch sees the cluster as one device. The switch performs all load balancing based on port-channel load balancing.

• Individual Interface Mode = in this configuration the ASAs actually act as individual boxes. The ASAs run routing protocols. Each outside device have multiple routes to each ASA. In most deployments this mode is less used. This mechanism routes packets along multiple paths of equal cost with the goal to achieve distributed link load sharing.

Establishing & Tracking TCP connections within an ASA cluster:

• New TCP connection attempt is received from client (TCP SYN)

• The ASA that receives the connection attempt becomes the flow owner and adds the TCP SYN cookie.

• The packet is then distributed to destination

• The destination client may respond to the originating client via another ASA in the cluster

• The non-flow owner receiving the packet from the destination client forwards the response to the flow owner

• The forwarding ASA is now deemed the Flow Forwarder

• The ASA flow owner now updates the flow director with the connection info

Establishing & Tracking UDP connections within an ASA cluster:

• New TCP connection attempt is received from client

• The ASA that receives the connection attempt becomes the flow owner

• The packet is then distributed to destination

• Flow owner updates director with new connection information

• The destination client may respond to the originating client via another ASA in the cluster

• The non-flow owner receiving the packet from the destination client queries flow director to determine owner

• Flow forwarder then forwards the response to the flow owner

• Flow owner delivers response to originating client

Flow Owner Failure Workflow:

• Connection is already established, but the current flow owner fails

• Another member receives a packet and queries the director

• The director detects that the original owner has failed and assigns new owner

• The packet is then delivered as expected

• New flow owner updates the flow director

Cluster Control Link (CCL): responsible for carrying all data & control communication between cluster members to include:

• Master discovery, config replication, keepalives, interface status updates

• Centralized resource allocation

• Flow director updates & director queries

CCL Best Practices:

• Use per-unit LACP etherchannel link for redundancy and aggregation

• Bandwidth should match maximum forwarding capacity of each member

• Set MTU 100 bytes above largest data interface MTU

Now that we have a better understanding of ASA clustering I will cover an example of configuring & verifying the spanned mode. This mode is used in the majority of deployments.

ASA Clustering Building Blocks:

1. Configure the ASAs first

2. Declare cluster mode

3. Declare cluster group config

4. Configure switches for port channels

5. Configure ASAs for port channels

6. Make sure port-channels are configured as port-channel span-cluster

Building Block 1: Declaring cluster mode will trigger a device reboot & the following messages:

WARNING: Current running configuration contains commands that are incompatible with 'spanned' mode.

 - You can choose to proceed, device configuration will be cleared, and a reboot will be initiated.
 - You can use 'cluster interface-mode spanned check-details' command to list all of the running configuration elements that are incompatible with 'spanned' mode, remove these commands manually, and attempt the interface-mode change again.
 - Or you can use command 'cluster interface-mode spanned force' to force the interface-mode change without validating compatibility of the running configuration. Once the interface-mode is changed, you still need to resolve any remaining configuration conflicts in order to be able to enable clustering.

WARNING: Do you want to proceed with changing the interface-mode, clear the device configuration, and initiate a reboot?

Configuring cluster group config in spanned mode example:

ASA4:
 cluster Interface-mode spanned
!
Interface G0
 no shut
!
cluster group CIF_LAB
 local-unit ASA4
 cluster-interface g0 ip 10.0.44.4 255.255.255.0
 priority 1 --ensures master unit
 key cifelli
 enable

ASA 3:
cluster Interface-mode spanned
!
Interface G0
 no shut
!
cluster group CIF_LAB
 local-unit ASA3
 cluster-interface g0 ip 10.0.44.3 255.255.255.0
 key cifelli
 enable

Building Block 2:

Configuring port-channels on switches (brief overview example):

SW1:
vlan 10
!
Interface range Eth 0/0-1
 channel-group 10 mode active
 no shut
!
Interface Port-channel 10
 switchport mode access
 switchport access vlan 10
!
Interface Eth0/2
 switchport mode access
 switchport access vlan 10
!
Interface range Eth0/0-1
 switchport mode access
 switchport access vlan 10

SW2 example:
vlan 11
!
Interface range Eth 0/0-1
 channel-group 11 mode active
 no shut
!
Interface Port-channel 11
 switchport mode access
 switchport access vlan 11
!
Interface Eth0/2
 switchport mode access
 switchport access vlan 11
!
Interface range Eth0/0-1
 switchport mode access
 switchport access vlan 11

Building Block 3: Configure & Deploy port-channels on ASAs. Note: remember that all config changes are done on master:

Interface g1
 channel-group 10 mode active
 no shut
!
Interface g2
 channel-group 11 mode active
 no shut
!
Interface Port-channel 10
 port-channel span-cluster
 mac-address 0001.1010.AAAA
 nameif Outside
 ip address 10.10.10.10
 no shut
!
Interface Port-channel 11
 port-channel span-cluster
 mac-address 0001.1111.BBBB
 nameif Inside
 ip address 11.11.11.11 
 no shut

Note that after the initial 3 building blocks are configured you can now configure the cluster normally via the master unit.

ASA Cluster verification commands:

#show cluster info     --Shows status of all members
#show cluster history     --View cluster history
#show conn detail    --Verify flow type (director/forwarder/backup)
#show port-channel     --Verify port-channel 
#show route cluster     --Verify routing
#show cluster info trace     --Show debug info to troubleshoot
#show cluster info {conn-distribution}{packet-distribution}{loadbalance}{flow-mobility counters} --Troubleshooting & see how traffic is distributed

That wraps up this blog on Understanding, Configuring, & Verifying ASA Clustering! Cheers!