topic Re: Pre-Sales Engineer Question: FTD/Firepower Family (IRB Limitations in Network Security

Pre-Sales Engineer Question: FTD/Firepower Family (IRB Limitations)

BrianSekleckiGE — Wed, 29 Nov 2023 12:55:16 GMT

Sales engineer question

Assumptions: Active/Active (or Active/Standby)

Assumptions: Multi-Instance-capable

Assumptions: Routed Mode

If running an active/active (or active-standby) FTD/Firepower cluster, dual-chassis, and implementing Bridge Domains and VLANs, can a Dot1Q Trunk be passed directly between the two chassis (effectively creating a chassis-spanning software-switch that obviates the need for an an external switch)?
If so/yes, what are the limitations (E.g., does the FTD bridge domain run an STP instance? Is LACP Supported?)

The question derives from a requirement where there is exists space constraints and consolidating the Firewalling and Switching/Bridging function (with very low density port requirements) into one 1U device is highly desired.

The historical Cisco precedent here would be a Router with a standalone/independently managed Cisco Catalyst switch-module, but I haven't seen any:

* Firepower/FTD with a Catalyst (or other family) switch module except for the FTD1010 ("L2 Switch")

* Catalyst (or other family) with a Firepower/FTD module

* There do, however, seem to be quite a few options for virtualizing the Firepower/FTD, especially onto a Cisco UCS-E module (Modules which I've seen as a ASR4K / ISR module, but not as a Catalyst module)

Re: Pre-Sales Engineer Question: FTD/Firepower Family (IRB Limitations

Isabella54 — Thu, 15 Feb 2024 15:54:52 GMT

I'm exploring the possibility of creating a chassis-spanning software-switch between active/active FTD/Firepower cluster chassis using a Dot1Q Trunk. Wondering about limitations—does FTD's bridge domain run STP, and is LACP supported?

Re: Pre-Sales Engineer Question: FTD/Firepower Family (IRB Limitations

tvotna — Fri, 01 Dec 2023 14:17:45 GMT

Neither FP1010 hardware switch, nor ASA/FTD transparent mode software run STP. In both cases STP BPDUs pass through the device by default.

In case of ASA A/S failover (aka FTD HA) one unit is active and the other one is standby and doesn't forward traffic. FP1010 hardware switch is an exception to this rule. The switchports on it belong to the switch and hence are not controlled by firewall software, which means that switchports on standby can forward traffic. This in turn means that STP loop will be formed if FP1010 switchports and failover are used together and external switch STP needs to take care of it. If you don't have external switch and just want to interconnect two FP1010 switchports with a dot1q trunk, to create a bigger/redundant switch, the STP loop is unavoidable.

Also, as a side note, in case of a software switch (transparent mode firewall) it's usually recommended to block BPDUs on the firewall with ethertype ACLs to prevent external switch ports from going through STP learning phase right after the firewall switchover, which delays network convergence.

Clustering is another technology. The cluster can run in transparent or routed firewall mode and appears to the outside world as a single device. FP1k doesn't support clustering, only higher models do. In case of a cluster, spanned port-channel is formed on a few firewall chassis. This spanned port-channel runs cLACP which is a cluster LACP. The other side thinks that it talks to a single device, so STP isn't needed here.

HTH

Re: Pre-Sales Engineer Question: FTD/Firepower Family (IRB Limitations

BrianSekleckiGE — Sat, 02 Dec 2023 10:09:34 GMT

Okay; no advanced integrated bridging/switching function for now.

Until then, we can consider:

FTDv/NGFWvGuest on Cisco UCS-E module within a ASR4K
Externally virtualized (FTDv/NGFWv virtual on something compact UCS Hyperflex 2-node, etc.)
(Maybe in future?) FTD can run as Guest on Catalyst 9000 as IOS-XE/IOX Virtual Hosted APP
Clustering

Thanks for clue'ing me into Clustering feature on FirePower 4000+ (I recently learned that Fortinet also supports "Virtual Clustering" as well for distributing the CPU load of asymmetric VDOM computational load, probably based on Cisco)