Designing Reliable FortiGate HA with Cisco C9300: A/A vs A/P, HSRP and Failover Pitfalls

In modern enterprise edge design, pairing a FortiGate HA cluster with a Cisco Catalyst 9300 core is common practice. On paper, the architecture appears straightforward: ISP → FortiGate HA → C9300 StackWise → Access Layer.

In production, however, reliability is determined not by topology diagrams, but by failover behavior under stress.

This guide dissects the real engineering considerations behind building a predictable, testable, and failure-resilient integration between FortiGate HA and Cisco C9300 — covering A/A vs A/P mode selection, HSRP interaction, MAC behavior, LACP design, and validation strategy.

• Part 1: Typical Enterprise Topology – Where Complexity Hides
• Part 2: Active-Active vs Active-Passive – Capacity vs Resilience
• Part 3: Integrating FortiGate HA with Cisco HSRP
• Part 4: Layer 2 Behavior – MAC, CAM, GARP, LACP
• Part 5: Pre-Production Validation Checklist
• Part 6: Hardware Compatibility in Multi-Vendor HA
• FAQ: FortiGate HA and Cisco C9300 Design

Part 1: Typical Enterprise Topology – Where Complexity Hides

A common deployment looks like this:

• Dual ISPs into FortiGate HA pair
• FortiGate inside interfaces uplink to a Cisco C9300 StackWise core
• SVIs on the C9300 running HSRP
• Dynamic routing (EIGRP/OSPF) between firewall and core
• Aggregated LACP uplinks

Each individual component is stable on its own. The complexity arises in the interaction layers:

• Firewall HA failover timing
• HSRP preemption behavior
• CAM table updates
• LACP renegotiation
• Dynamic routing convergence

Most outages occur not because HA failed — but because adjacent systems reacted unpredictably to that failover.

Part 2: Active-Active vs Active-Passive – Capacity vs True Resilience

There is a persistent myth that FortiGate Active-Active (A/A) doubles throughput by splitting traffic evenly.

The Reality of A/A

In FortiGate clustering:

• All sessions are initially owned by the primary unit
• UTM inspection may be delegated to the secondary
• Standard firewall traffic remains primarily handled by the primary

A/A is not symmetrical load balancing. It is session-owner based distribution.

If both nodes operate at 60% utilization during steady state, a single unit failure forces 120% load onto the remaining device — triggering conserve mode, session drops, or complete perimeter instability.

Why 90% of Enterprises Should Use A/P

Active-Passive (A/P):

• Ensures the secondary can always handle 100% of load
• Eliminates asymmetric inspection complexity
• Simplifies troubleshooting
• Avoids state-ownership confusion

High availability is not a performance strategy. It is a disaster strategy.

Part 3: Integrating FortiGate HA with Cisco HSRP – Control Plane Race Conditions

Split-Brain Risk

If HA heartbeat links traverse the core switches and fail independently, both FortiGates may assume primary role. This results in duplicate virtual MACs, duplicate IPs, and traffic blackholing.

Best practice:

• Use dedicated, direct heartbeat links
• Configure secondary heartbeat paths
• Never pass HA heartbeat through production switching fabric

HSRP Preemption Conflicts

If HSRP preempts before FortiGate completes HA negotiation, gateway roles may oscillate.

Align timers carefully and avoid simultaneous reconvergence events.

Interface Monitoring Example

Example CLI configuration to enable interface monitoring on FortiGate:

config system ha
    set monitor port1 port2
end

If the active uplink fails, this forces a cluster failover instead of silently blackholing traffic.

Part 4: Layer 2 Behavior – MAC, CAM, GARP, and Port-Channel Design

Virtual MAC and Gratuitous ARP

In A/P mode, both FortiGates share the same virtual MAC. Upon failover, the new primary sends Gratuitous ARP (GARP) to update Cisco CAM tables.

Sometimes switches do not flush CAM tables immediately, causing temporary traffic loss.

link-failed-signal Example

Example CLI command to enable link-failed-signal:

config system ha
    set link-failed-signal enable
end

This forces a brief link drop on the old primary, triggering immediate CAM flush.

LACP and MAC Flapping Risks

• Use LACP (802.3ad) on both FortiGate and Cisco Port-Channel
• Distribute links across different C9300 stack members
• Validate behavior during single-member reboot

When StackWise member reboots, traffic should degrade gracefully — not trigger firewall failover.

Part 5: Pre-Production Validation Checklist

Never deploy HA without controlled failure testing.

• HA Heartbeat Isolation Test
• LACP Member Failure Test
• Active-Passive Failover Test
• Stateful Session Pickup Test
• Dynamic Routing Stability Test

Example command to verify MAC table movement on Cisco:

show mac address-table

High availability is proven in failure — not in uptime.

Part 6: Hardware Compatibility in Multi-Vendor HA

Many HA failures are not configuration problems — they are hardware interaction problems.

• Non-validated SFP modules causing link renegotiation
• StackWise version mismatch
• FortiOS minor version inconsistencies
• Optics instability under failover burst traffic
• Delays sourcing matched HA units

In multi-vendor architectures combining Cisco core infrastructure and Fortinet perimeter security, ensuring hardware compatibility and rapid availability of identical HA units is just as critical as configuration accuracy. Enterprises often reduce procurement and compatibility risks by working with experienced infrastructure suppliers such as Router-switch, who understand cross-vendor validation and synchronized HA hardware requirements.

FAQ: FortiGate HA and Cisco C9300 Design

Q1.Should I use Active-Active mode for higher throughput?

In most enterprise environments, Active-Passive is preferred because it guarantees full capacity during failure and avoids asymmetric session ownership complexity.

Q2.Why does traffic sometimes drop during failover?

Temporary drops are usually caused by CAM table update delays, GARP processing timing, or LACP renegotiation events.

Q3.How many packets should drop during a healthy failover?

In a properly tuned environment with link-failed-signal enabled, packet loss should typically be limited to 1–3 packets.