Cisco Secure Firewalls : Designing for High Availability HA vs. Clustering
A complete technical guide to Active/Standby failover, horizontal clustering, geo-redundant design, VRF multi-tenancy and centralised management
- Introduction: HA vs. Clustering — Which Do You Need?
- Active/Standby High Availability (HA)
- How Active/Standby Failover Works
- HA Key Features and Requirements
- Clustering: Horizontal Scaling Up to 16 Nodes
- Cluster Sizing: Throughput, CPS and Connections
- Cluster Roles: Owner, Director, Forwarder, Backup
- Cluster Enhancements in FTD 7.6 / ASA 9.22
- Geo-Redundant Clustering Across Data Centres
- HA vs. Clustering: Side-by-Side Comparison
- Multi-Tenancy: VRF Lite and Multi-Instance
- VRF Lite (FTD 6.6+)
- Multi-Instance (Container-Based Isolation)
- FMC Domain-Based RBAC
- Internet Edge: BGP Design Options
- Access Control Policy Scale and Sizing
- Network Module Ecosystem
- Firewall Management Centre (FMC)
- Summary and Recommendations
- Frequently Asked Questions
Introduction: HA vs. Clustering — Which Do You Need?
Cisco Secure Firewall supports two distinct high availability models: traditional Active/Standby failover (HA) and full Active/Active clustering. Understanding the difference is fundamental to designing a network security architecture that meets both your performance and redundancy requirements.
In short: HA gives you redundancy; clustering gives you redundancy plus horizontal scale. The right choice depends on your throughput needs, connection table requirements, budget, and operational complexity tolerance. This guide covers both models in full technical depth, along with multi-tenancy design using Cisco Secure Firewall VRF Lite and Multi-Instance containerisation.
Active/Standby High Availability (HA)
Active/Standby HA is the simplest form of firewall redundancy. One unit (the Active) handles all traffic. The other (the Standby) mirrors configuration and flow state but does not forward traffic. When the active unit fails or a manual switchover is triggered, the standby promotes itself to active with minimal disruption.
FTD inherits ASA's proven failover infrastructure, meaning organisations migrating from Cisco ASA to FTD retain the same HA concepts and behaviours they are already familiar with.
How Active/Standby Failover Works
The two units communicate over a dedicated Failover Link (which also carries state information) and optionally a separate Stateful Failover Link for high-volume state synchronisation. The active unit sends hello packets at regular intervals; if the standby does not receive them within the configured hold time, it declares a failure and takes over.
- Both units must be identical hardware models running the same software version
- IP addresses are shared using a virtual IP — clients never notice the switchover
- TCP sessions, UDP flows, NAT translations and VPN tunnels are all synchronised
- Switchover typically completes in under 1 second for stateful failover
HA Key Features and Requirements
- Supports all NGFW/NGIPS interface modes (routed, transparent, inline, passive)
- Interface health monitoring — configurable thresholds per interface
- Snort instance health monitoring — failover triggered if fewer than 50% of Snort instances are healthy
- Zero-downtime upgrades for most application types (one unit upgraded at a time)
- Full stateful flow symmetry in both NGIPS and NGFW modes
- Supported on all Cisco Secure Firewall platforms including 1010, 1100, 1200, 2100, 3100, 4100, 4200 and 9300
- Active/Active HA also supported on ASA with multi-context mode
| Attribute | Detail |
|---|---|
| Nodes | 2 (one active, one standby) |
| Traffic forwarding | Active unit only |
| State synchronisation | Full — connections, NAT, VPN, routing |
| Switchover time | Sub-second (stateful) to a few seconds |
| Performance scaling | None — standby adds no capacity |
| Management | Single logical device in FMC |
| Best for | Basic redundancy, lower throughput requirements, simpler operations |
Clustering: Horizontal Scaling Up to 16 Nodes
Clustering combines multiple Cisco Secure Firewall appliances into a single logical device that scales performance linearly with every node added. Unlike HA, all nodes are simultaneously active, with the cluster transparently managing flow ownership, direction, and backup roles. This means adding a node adds both capacity and redundancy at the same time.
FTD fully inherits ASA's proven clustering infrastructure. The cluster appears as a single device to FMC for management and policy deployment, while load balancing is handled by the upstream switching/routing infrastructure via EtherChannel (spanned mode) or ECMP routing (individual/routed mode).
Cluster Sizing: Throughput, CPS and Connections
Cluster performance is calculated using three de-rating multipliers that account for the overhead of inter-node coordination:
| Metric | Multiplier | Reason |
|---|---|---|
| Throughput | ×0.8 (L2) or ×1.0 (L3 routing) | EtherChannel load-balancing overhead for L2; L3 ECMP can achieve full line rate |
| Connections per second (CPS) | ×0.5 | Additional tasks for flow creation, director election and state updates |
| Maximum concurrent connections | ×0.6 | Stub connection maintained on non-owner nodes for failover |
| Platform | Per-Node | 16-Node Throughput | 16-Node CPS | 16-Node Max Connections |
|---|---|---|---|---|
| 3140 | 45 Gbps / 300k CPS / 10M conn | 0.57 Tbps | 2.4M | 96M |
| 4245 | 145 Gbps / 800k CPS / 60M conn | 1.79 Tbps | 6.4M | 576M |
Example calculation for a 4-node 3140 cluster:
- Throughput: 4 × 45 Gbps × 0.8 = 144 Gbps
- CPS: 4 × 300k × 0.5 = 600k connections/sec
- Max connections: 4 × 10M × 0.6 = 24M concurrent connections
Cluster Roles: Owner, Director, Forwarder, Backup
Every flow in a cluster is managed by four distinct per-connection roles:
- Owner — the node that first received the flow; performs full inspection and maintains primary state
- Director — maintains a lightweight hash entry to redirect packets that arrive at the wrong node back to the Owner
- Forwarder — any node that receives packets for a flow it does not own; redirects via the Cluster Control Link (CCL)
- Backup — holds a copy of the Owner's connection state for seamless failover if the Owner goes down
One node per chassis also holds the Control Unit (Master) global role, responsible for cluster health, configuration sync and management plane operations.
Cluster Enhancements in FTD 7.6 / ASA 9.22
Individual Interface Mode (Routed Clustering)
FTD 7.6 and ASA 9.22 reintroduced Individual Interface Mode (also called routed clustering) for FTDv, 3100, and 4200 platforms. This was previously only available on legacy ASA hardware. In this mode:
- Each cluster node operates as an independent routing instance with its own IP addresses
- No spanned EtherChannel is required to upstream switches
- Load balancing is handled by upstream routers via ECMP, UCMP, or PBR
- Routed mode only (transparent mode is not supported in individual interface mode)
- Feature supported with multi-context mode (ASA) but not yet with Multi-Instance clustering
| Attribute | Spanned EtherChannel Mode | Individual Interface Mode |
|---|---|---|
| Layer used for traffic | Layer 2 | Layer 3 |
| Data interface IPs | Single shared IP per EtherChannel | Individual IP per node (from pool) |
| Load balancing | EtherChannel hash (upstream switch) | ECMP/UCMP/PBR (upstream router) |
| Routing modes | Routed or Transparent | Routed only |
| Supported platforms | All clustering platforms | FTDv, 3100, 4200 (FTD 7.6+) |
Scale-Out Encryption in Clustering (FTD 7.7)
FTD 7.7 introduced IPsec Cluster Offload — enabling Mobile Core Protection use cases for service providers:
- IPsec fully accelerated — offloaded to dedicated cryptographic hardware on distributed cluster members
- Distributed Control Plane for IKE and IPsec — IKE processing occurs on the node that owns the flow rather than being centralised on the Control Unit (previously a 9300-only feature)
- Cluster Hardware Redirect — CCL traffic redirected using FPGA hardware without CPU involvement, reducing latency and increasing scale
Geo-Redundant Clustering Across Data Centres
Cisco Secure Firewall supports stretched clusters across two geographically separated data centres, providing both horizontal performance scaling and site-level redundancy from a single logical firewall device.
Design Requirements
- Cluster Control Link (CCL) extended between sites at Layer 2 with <10ms RTT latency
- Single spanned EtherChannel for data traffic extends across both sites
- Underlying transport: ideally dark fibre; also tested with VPLS, VPWS, and EVPN
- Local vPC/VSS pairs at each site for switch-level redundancy
Traffic Patterns
- North-South insertion — uses LISP-based traffic localisation with Owner reassignment to keep inspection local to each site where possible
- East-West insertion — supports first-hop redundancy with VM mobility; data VLANs are not extended for North-South insertion to avoid loops and MAC/IP conflicts
HA vs. Clustering: Side-by-Side Comparison
| Feature | Active/Standby HA | Clustering (up to 16 nodes) |
|---|---|---|
| Max nodes | 2 | 16 |
| Active forwarding nodes | 1 | All nodes (16) |
| Performance scaling | None | Linear with each node added |
| Redundancy | Yes | Yes (node loss = no traffic loss) |
| Zero-downtime upgrade | Yes (rolling) | Yes (rolling per node) |
| Management | Single device in FMC | Single logical device in FMC |
| Flow symmetry | Full (all flows on active unit) | Managed by Director/Owner roles |
| Layer 2 deployment | Yes | Yes (spanned mode) |
| Layer 3 / routed deployment | Yes | Yes (individual mode, FTD 7.6+) |
| Multi-chassis | No (same chassis only) | Yes (inter-chassis clustering) |
| Geo-redundancy | No | Yes (stretched cluster) |
| Complexity | Low | Medium–High |
| Best for | Basic redundancy, lower throughput | High scale, DC, SP, MSSP |
Multi-Tenancy: VRF Lite and Multi-Instance
Cisco Secure Firewall provides three complementary layers of multi-tenancy that can be combined for maximum tenant density and isolation on a single physical platform.
VRF Lite (FTD 6.6+)
VRF Lite allows different firewall interfaces to participate in separate IP routing domains with overlapping address space. Key characteristics:
- Traffic forwarding between VRFs is possible using static routes with NAT
- FMC applies a single security policy across all VRFs — connection events are enriched with the VRF ID for visibility
- Can be combined with Multi-Instance for an additional isolation layer
- Starting FTD 7.7, FTDv supports up to 30 VRFs
| Platform | Max VRFs | Platform | Max VRFs |
|---|---|---|---|
| 1010 / 1120 | 5 | 4112 | 60 |
| 1140 / 1150 | 10 | 4115 | 80 |
| 1210CE/CP | 5 | 4125 / 4145 | 100 |
| 1220CX | 10 | 4215 / 4225 / 4245 | 100 |
| 1230 / 1240 | 10 | 9300 SM-44/48/56 | 100 |
| 1250 | 15 | FTDv | 30 |
| 3105 | 10 | ISA 3000 | 10 |
| 3110 | 15 | 2110 | 10 |
| 3120 | 25 | 2120 | 20 |
| 3130 | 50 | 2130 | 30 |
| 3140 | 100 | 2140 | 40 |
Multi-Instance (Container-Based Tenant Isolation)
Multi-Instance allows a single physical appliance or chassis module to run multiple independent FTD instances using Docker container infrastructure. Each instance has its own:
- Independent management connection to FMC (appears as a separate device)
- Independent upgrade schedule — upgrade one instance without touching others
- CPU, memory and interface resource allocation
- Security policy, routing table and VPN configuration
| Platform | Max Instances | Initial FTD Support | Management |
|---|---|---|---|
| 3110 | 3 | 7.4.1 | FMC |
| 3120 | 5 | 7.4.1 | FMC |
| 3130 | 7 | 7.4.1 | FMC |
| 3140 | 10 | 7.4.1 | FMC |
| 4115 | 7 | 6.4.0 / FXOS 2.6.1 | FMC & FXOS |
| 4125 | 10 | 6.4.0 / FXOS 2.6.1 | FMC & FXOS |
| 4145 | 14 | 6.4.0 / FXOS 2.6.1 | FMC & FXOS |
| 4215 | 10 | 7.6.0 | FMC |
| 4225 | 15 | 7.6.0 | FMC |
| 4245 | 34 | 7.6.0 | FMC |
| 9300 SM-44 | 14 | 6.3.0 / FXOS 2.3.1 | FMC & FXOS |
| 9300 SM-48 | 15 | 6.4.0 / FXOS 2.6.1 | FMC & FXOS |
| 9300 SM-56 | 18 | 6.4.0 / FXOS 2.6.1 | FMC & FXOS |
FMC Domain-Based RBAC
Firewall Management Center (FMC) supports up to 1,024 domains. Administrators only see and manage devices assigned within their domain. Granular RBAC enables separation of duties between operators — for example, allowing a tenant to manage their own firewall instances without visibility into other tenants' configurations. This is ideal for managed service providers (MSSPs) and large enterprise multi-tenant environments.
Internet Edge: BGP Design Options on Cisco Secure Firewall
Both ASA and FTD support enterprise-grade dynamic routing including RIP, OSPFv2, OSPFv3, IS-IS, EIGRP, BGP and PIM-SM multicast — making the Cisco Secure Firewall a viable internet gateway without a dedicated separate router. For SD-WAN edge deployments, this is particularly useful for consolidating security and routing functions.
Option 1: Full BGP Table
Accept full IPv4 and IPv6 routing tables (~1.3M prefixes). Requires at least 1 GB free Data Plane RAM. Memory: ~304 MB for IPv4 + ~90 MB for IPv6 + 200–300 MB buffer for route churn. Best for organisations needing optimal path selection to all destinations.
Option 2: Partial BGP Routes (AS_PATH Filter to 2–3 hops)
Filter inbound BGP to routes with AS_PATH length of 2–3 hops, resulting in 30k–200k routes. Memory drops to ~54 MB IPv4 + ~31 MB IPv6 + 80–120 MB buffer. Best for balancing granularity and resource consumption.
Option 3: Default Route Only
ISPs advertise only a default route. BGP serves as link keepalive and ECMP mechanism. Memory consumption is minimal (<1 kB). Best for simpler topologies where optimal path selection is not needed.
| Platform | Max BGP Routes Tested | Max BGP Neighbors |
|---|---|---|
| 1010 / 1100 | 5k–10k | 5 |
| 1200C / 1230–1250 | 50k | 100 |
| 3100 Series | 100k | 500 (with BFD) |
| 4100 / 4200 Series | 200k | 500 (with BFD) |
| 9300 Series | 200k | 500 (with BFD) |
Access Control Policy Scale and Sizing
FTD 7.2 introduced Optimized Group Search (OGS) by default on new deployments, enabling significantly higher policy scale at the cost of slightly reduced per-packet performance. OGS was further refined in 7.6 (hit counters, timestamps, additional corner cases) and 7.7. FMC warns administrators before deploying rulesets approaching platform limits.
| Platform | Max ACEs | UI Rules at 50 ACE/rule | UI Rules at 100 ACE/rule |
|---|---|---|---|
| 1010 / 1010E | 10,000 | 200 | 100 |
| 2110 | 60,000 | 1,200 | 600 |
| 2140 | 500,000 | 10,000 | 5,000 |
| 3140 | 4,000,000 | 80,000 | 40,000 |
| 4145 | 8,000,000 | 160,000 | 80,000 |
| 4245 | 10,000,000 | 200,000 | 100,000 |
| 9300 w/SM-56 | 9,500,000 | 190,000 | 95,000 |
Network Module Ecosystem
The 3100, 4100, 4200, and 9300 Series all support hot-swappable network expansion modules with same-kind Online Insertion and Removal (OIR). The 4200 Series offers the most advanced high-density options:
| Module SKU | Ports | Min FTD Version | Notes |
|---|---|---|---|
| FPR4K-XNM-2X400G | 2× 400G QSFP+ | 7.6 (7.7 for breakout) | Supports 4×10G, 4×25G, 200G modes in 7.7 |
| FPR4K-XNM-4X200G | 4× 200G QSFP+ | 7.4 | Supports 40G and 100G |
| FPR4K-XNM-2X100G | 2× 100G QSFP28 | 7.4 | Breakout to 4×10G, 4×25G, or 40G |
| FPR4K-XNM-8X25G | 8× 1/10/25G SFP+ | 7.4.0 | — |
| FPR4K-XNM-6X25SRF/LRF | 6× 25G Fail-to-Wire | 7.1 | Built-in optics, fixed |
| FPR4K-XNM-6X10SRF/LRF | 6× 10G Fail-to-Wire | 7.1 | SR or LR variants |
Firewall Management Centre (FMC): Centralised Management at Scale
The Cisco Firewall Management Center (FMC) provides centralised policy deployment, event management, reporting, and cluster health visibility for FTD deployments. All three hardware appliance models are available:
| Model | Max FTD Sensors | Max IPS Events | Max Flow Rate | Max Network Hosts |
|---|---|---|---|---|
| FMC 1700 | 50 | 30M | 5k FPS | 50k |
| FMC 2700 | 300 | 60M | 12k FPS | 150k |
| FMC 4700 | 1,000 | 400M | 30k FPS | 600k |
Cluster Health Dashboard (FMC 7.3+)
FMC 7.3 introduced a dedicated Cluster Health Dashboard providing:
- Per-member load statistics (CPU, memory, connections, throughput)
- Cluster member status at a glance (control unit, data units, joining/leaving)
- Aggregated and minimum/maximum metrics over a selected time period across the entire cluster
- Historical trending to detect capacity bottlenecks before they become incidents
Summary and Recommendations
The Cisco Secure Firewall portfolio provides a mature, proven set of high availability and scaling options for every tier of the enterprise. Choosing between HA and clustering comes down to scale requirements: if you need more than one firewall worth of throughput, clustering is the right choice. If you simply need redundancy, HA is simpler to operate and maintain.
| Use Case | Recommended Approach | Platform |
|---|---|---|
| Small/mid branch redundancy | Active/Standby HA | 1100, 1200, 2100 Series |
| Enterprise edge redundancy | Active/Standby HA | 3100 or 4200 Series |
| Enterprise DC high scale | Clustering (spanned or routed) | 3100 or 4200 Series |
| SP / carrier-class scale | Clustering up to 16 nodes | 9300 SM-56 or 4245 |
| Multi-site geo-redundancy | Stretched cluster | 3100, 4200, 9300 |
| Multi-tenant MSSP | Clustering + Multi-Instance + VRF + FMC RBAC | 4200 or 9300 |
| Internet edge with BGP | HA or Clustering depending on scale | 3100+ for full BGP table |
| OT/IoT with redundancy | Active/Standby HA | ISA 3000 |
For full hardware specifications and throughput numbers across all Cisco Secure Firewall models, see our companion guide: Cisco Secure Firewall Platforms: A Complete Deep Dive Guide. For Cisco ISE integration with DNA Center for identity-based policy enforcement alongside your firewall, see our comprehensive technical guide.
Frequently Asked Questions
HA (Active/Standby) provides basic redundancy — one unit handles traffic while a standby mirrors state and takes over on failure. Clustering combines up to 16 units into one logical device where all nodes are simultaneously active, providing both redundancy and linear horizontal scaling of throughput, CPS, and concurrent connections.
Up to 16 nodes. A 16-node cluster of 3140 appliances delivers up to 0.57 Tbps NGFW throughput, while a 16-node cluster of 4245 appliances reaches 1.79 Tbps. CPS scales to 2.4M (3140) or 6.4M (4245) and concurrent connections to 96M or 576M respectively.
No — all nodes in a cluster must run the same application (either all ASA or all FTD) and the same software version. However, on the 9300 chassis, different Security Modules can run different applications (ASA on one module, FTD on another) in a service chaining configuration.
VRF Lite (available from FTD 6.6) allows different firewall interfaces to belong to separate Layer 3 routing domains with overlapping IP address space. It enables multi-tenant deployments on a single firewall without dedicated hardware separation. Top-tier platforms like the 3140, 4245, and 9300 SM-56 support up to 100 VRFs.
Multi-Instance is supported on the 3100 Series (FTD 7.4.1+), 4100 Series (FTD 6.3+), 4200 Series (FTD 7.6+), and 9300 Series (FTD 6.3+). It is not supported on the 1010, 1100, 1200, or 2100 Series. The 4245 supports up to 34 instances and the 9300 SM-56 up to 18 instances.
Yes. Both ASA and FTD support full BGP (eBGP and iBGP), OSPFv2/v3, IS-IS, EIGRP, RIP, and PIM-SM multicast. The 3100, 4100, 4200, and 9300 Series have been tested with up to 200k BGP routes and 500 BGP neighbours (with BFD), making them viable internet gateway platforms.
