Home > Articles > Introduction to and Design of Cisco ASA with FirePOWER Services

Introduction to and Design of Cisco ASA with FirePOWER Services

Chapter Description

In this chapter from Cisco Next-Generation Security Solutions: All-in-one Cisco ASA Firepower Services, NGIPS, and AMP, authors Omar Santos, Panos Kampanakis, and Aaron Woland provide an introduction to the Cisco ASA with FirePOWER Services solution. It also provides design guidance and best practices for deploying Cisco ASA with FirePOWER Services.

Cisco ASA FirePOWER Services and Clustering

You can configure up to 16 identical Cisco ASA appliances in a cluster to act as a combined traffic-processing system. When clustering is enabled, the Cisco ASAs preserve the benefits of failover. In a cluster, virtual IP and MAC addresses are used for first-hop redundancy.

All cluster members must have identical hardware configuration, SSP types, application modules, and interface cards.

Figure 2-19 illustrates three Cisco ASAs configured in a cluster.

Figure 2-19

Figure 2-19 Cisco ASA Cluster

In a Cisco ASA cluster, the configuration is mirrored to all members, and connection state is preserved after a single member failure.

Clustered Cisco ASA provides flow symmetry and high availability to the Cisco ASA FirePOWER module. Packets and flows are not dropped by the Cisco ASA FirePOWER module but instead are marked for “drop” or “drop with TCP reset” and sent back to the corresponding Cisco ASA. This methodology allows the Cisco ASA to clear the connection from the state tables and send TCP resets, if needed.

When clustering is configured, stateless load balancing is done via IP routing or spanned EtherChannel with the Link Aggregation Control Protocol (LACP). In addition, all Cisco ASA appliances are connected to the same subnet on each logical interface.

Figure 2-20 shows a Cisco ASA cluster configured with spanned EtherChannel.

Figure 2-20

Figure 2-20 Cisco ASA Cluster Configured with Spanned EtherChannel

You can also configure a cluster in individual interface mode. Individual interface mode is supported in Cisco ASAs configured in routed (Layer 3) mode only. It is not supported in Cisco ASAs configured in transparent (Layer 2) mode.

Figure 2-21 shows a Cisco ASA cluster configured in individual interface mode.

Figure 2-21

Figure 2-21 Cisco ASA Cluster Configured in Individual Interface Mode

In individual interface mode, the cluster master owns the virtual IP on data interfaces for management purposes only. All members get data interface IP addresses from IP address pools in the order in which they join the cluster.

Cluster Member Election

When Cisco ASAs are configured in a cluster, one member is elected as the master, and other Cisco ASAs are slaves. The master may be the first unit to join the cluster or may be based on a configured priority. A new master is elected only if the elected master fails. The master unit handles all management and centralized functions, and the configuration is locked on slaves.

Figure 2-22 illustrates the steps in the cluster master election process.

Figure 2-22

Figure 2-22 Cisco ASA Cluster Master Election Process

The following steps are illustrated in Figure 2-22:

  • Step 1. A Cisco ASA with clustering enabled boots and immediately looks for a master within the cluster.

  • Step 2. It waits 45 seconds before it receives a reply from a master. If no master is found, it assumes the role of master in the cluster.

  • Step 3. If a master already exists, the Cisco ASA assumes the role of slave and synchronizes the configuration with the master Cisco ASA.

  • Step 4. The master admits one unit at a time.

  • Step 5. The cluster slave is ready to pass traffic.

There is a virtual IP address ownership for to-the-cluster connections, and the master and slaves process all regular transit connections equally. If a master fails, management traffic and other centralized connections must be reestablished upon master failure.

How Connections Are Established and Tracked in a Cluster

This section explains how connections are established and tracked in a Cisco ASA cluster configuration.

How a New TCP Connection Is Established and Tracked in a Cluster

Figure 2-23 illustrates how a new TCP connection is established and tracked within a cluster.

Figure 2-23

Figure 2-23 A New TCP Connection in a Cisco ASA Cluster

The following steps are illustrated in Figure 2-23:

  • Step 1. A new TCP connection attempt is received from the client (TCP SYN packet).

  • Step 2. The Cisco ASA that receives the TCP SYN (connection attempt) becomes the flow owner and adds the TCP SYN cookie. It then delivers the packet to the server.

  • Step 3. The server may reply with a TCP SYN ACK (response) through another unit in the cluster.

  • Step 4. If another Cisco ASA in the cluster receives the response, it forwards the packet to the flow owner and becomes the flow forwarder.

  • Step 5. The flow owner delivers the TCP SYN to the client.

  • Step 6. The flow owner updates the flow director with the connection information.

How a New UDP-Like Connection Is Established and Tracked in a Cluster

Figure 2-24 illustrates how a new UDP or another pseudo-stateful connection is established and tracked within a cluster.

Figure 2-24

Figure 2-24 A New UDP or Another Pseudo-stateful Connection in a Cisco ASA Cluster

The following steps are illustrated in Figure 2-24:

  • Step 1. A new UDP or another pseudo-stateful connection attempt is received from the client.

  • Step 2. The Cisco ASA that receives the connection attempt queries the flow director to see if a connection already exists for that host.

  • Step 3. The Cisco ASA that received the packet becomes the flow owner if no connection was found.

  • Step 4. The packet is delivered to the server.

  • Step 5. The flow owner updates the director with the new connection information.

  • Step 6. The server responds to the client. If another Cisco ASA in the cluster receives the response, it forwards the packet to the flow owner and becomes the flow forwarder.

  • Step 7. The flow forwarder queries the director to see what Cisco ASA is the flow owner.

  • Step 8. The director updates the flow forwarder with the flow owner information.

  • Step 9. The flow forwarder forwards the server response to the flow owner.

  • Step 10. The server response is delivered to the client.

Centralized Connections in a Cluster

There are several Cisco ASA features where connections are centralized, such as VPN management, application inspection, and AAA for network access. If a feature is handled in a centralized way, the cluster master controls all the tasks.

Centralized connections decrease overall cluster performance because they increase the processing and packet forwarding required to complete the given task.

Figure 2-25 illustrates how a new centralized connection is established and tracked within a cluster.

Figure 2-25

Figure 2-25 Centralized Connections in a Cisco ASA Cluster

The following steps are illustrated in Figure 2-25:

  • Step 1. A new connection attempt is received from the client.

  • Step 2. The Cisco ASA that receives the connection attempt recognizes the centralized feature and redirects the connection attempt to the master.

  • Step 3. The master becomes the owner and delivers the packet to the server.

  • Step 4. The master updates the director with the connection information.

What Happens When the Flow Owner Fails

The Cisco ASA clustering feature provides high availability and redundancy. Figure 2-26 illustrates what happens when a flow owner fails for some reason.

Figure 2-26

Figure 2-26 Flow Owner Failure

The following steps are illustrated in Figure 2-26:

  • Step 1. A connection is already established between the client and the server.

  • Step 2. The flow owner fails. This can be because of a power failure, hardware failure, or some other event, such as a system crash.

  • Step 3. The client sends the next packet to the server, and another cluster member receives the packet.

  • Step 4. The Cisco ASA that receives the packet queries the director.

  • Step 5. The director detects that the original flow owner failed and assigns a new owner.

  • Step 6. The packet is delivered to the server.

  • Step 7. The new flow owner updates the flow director.

10. Deploying the Cisco ASA FirePOWER Services in the Internet Edge | Next Section Previous Section

There are currently no related articles. Please check back later.