FIrepower with ASA Instance - Cluster vs HA Failover

[malhotra_suneet]

FIRPOWER 4120

Cisco Adaptive Security Appliance Software Version 9.8(4)
Firepower Extensible Operating System Version 2.2(2.53)
Device Manager Version 7.8(2)

I am currently working on ASA migration from a ASA-Service Module on 6500 to Firepower 4100

I have been able to cable and deploy the Firepower chassis (just a pair in the lab) and even deployed ASA as a standalone instance.

However, I need to have redundancy and in my existing setup I have HA failover groups (not clustered - I don't think it supports clustering)

Now I need to have redundancy for my new environment which is 2xFirepower 4100s with ASA instances (one on each), and wanted to know if Clustering is preferred over HA Failover and why ? Any caveats ?

Also, if I deploy clustered ASA instance, can I connect the Cluster link (port-channel 48) directly between the 2 chassis (instead of connecting it to the switch ?)

I hope you'll find this message interesting and would help me out a little bit here,

Thanks again

Suneet

@Marvin Rhoads 

[Marvin Rhoads · Accepted solution]

The only time clustering tends to make sense is when you have throughput requirements that exceed what you can get with  single appliances. Your ASA on 4120 is already going to have many multiples of the throughput the ASASM had. Generally it's used in clusters of 4 or more. A 2-device cluster typically doesn't make sense since the clustering overhead removes most of the throughput benefit of adding in the second appliance (e.g cluster throughput around 120% that of a single appliance). You also add complexity, introduce additional dependencies on neighboring device configurations and move onto a less-widely deployed and tested feature set.

[malhotra_suneet]

Thank you Marvin for the quick response. The information is very helpful.

[malhotra_suneet]

---

@Marvin Rhoads wrote:

The only time clustering tends to make sense is when you have throughput requirements that exceed what you can get with  single appliances. Your ASA on 4120 is already going to have many multiples of the throughput the ASASM had. Generally it's used in clusters of 4 or more. A 2-device cluster typically doesn't make sense since the clustering overhead removes most of the throughput benefit of adding in the second appliance (e.g cluster throughput around 120% that of a single appliance). You also add complexity, introduce additional dependencies on neighboring device configurations and move onto a less-widely deployed and tested feature set.

---

---

@Marvin Rhoads wrote:

The only time clustering tends to make sense is when you have throughput requirements that exceed what you can get with  single appliances. Your ASA on 4120 is already going to have many multiples of the throughput the ASASM had. Generally it's used in clusters of 4 or more. A 2-device cluster typically doesn't make sense since the clustering overhead removes most of the throughput benefit of adding in the second appliance (e.g cluster throughput around 120% that of a single appliance). You also add complexity, introduce additional dependencies on neighboring device configurations and move onto a less-widely deployed and tested feature set.

---

Hi @Marvin Rhoads 

Quick question for you, in case of HA/Failover (and not clustered) environment on a Firepower 4120 with ASA instance on it, do I deploy a "standalone" asa instance and then maybe create a dedicated "data" ethercahnnel on the firepower to use it as a failover llink ? and in this case how do I make use of state link for my HA pair ?

[Marvin Rhoads]

You don't need to separate the state and failover links onto separate physical links. Probably 80% or more of the ASA A/S pairs I have seen only use a single link. That link is most commonly a short Ethernet jumper between the two appliances which are installed adjacent to each other.

You could create a 2-link Etherchannel and use it for both purposes. I don't know that I've ever seen anyone do this; but I've only seen a couple hundred HA pairs. It should work though.