"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:
Configure the ASAs first
Declare cluster mode
Declare cluster group config
Configure switches for port channels
Configure ASAs for port channels
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!