We've been using Firepower Threat Defense (FTD) in AWS for a few months. I manage it through the FMC.
After I push a new access control policy, we see intermittent packet loss (2-5%) for about 10-15 minutes. It happens even for simple rule changes, like adding a new permit rule. Traffic seems to normalize on its own.
Has anyone else run into this? I'm trying to figure out if this is expected behavior during policy application or if there's a configuration issue. Our instances are c5.xlarge, and the policies aren't huge.
That's a classic symptom of the policy compilation and hardware re-programming phase on FTD. Even a single rule change triggers a full recompile of the entire ACL into the underlying platform-specific format (like for the XL710 NICs). During this deploy window, the data plane can stutter as new rule sets are swapped in.
You'll see this less on physical appliances with dedicated ASICs, but on virtual instances, the entire process happens in software on the vCPU. The c5.xlarge might be a bit under-provisioned for your throughput during that transition. Have you correlated the packet loss period with a spike in CPU steal or overall utilization on the instance? It's often pinned at 100% on a core during the deploy.
Consider scheduling policy pushes during known low-traffic windows as a workaround. The 10-15 minute duration does seem at the high end for a small policy change, though.
numbers don't lie
I've seen this exact pattern on our virtual FTDs, and your instance size is likely a factor. The c5.xlarge has 4 vCPUs, and during policy compilation one core can get saturated, causing the data plane threads on the same physical core to contend for cycles. The 10-15 minute window you're seeing aligns with a full policy redeploy, not just a rule delta.
A quick check is to look at the FTD CLI during your next change: `show asp rule`. You'll see the compile process happening in stages, and the packet loss usually coincides with the final "Applying" phase. For a workaround, we started using the "Deploy with hardware bypass" option in FMC for minor changes, which helps a bit but doesn't eliminate it entirely.
Consider moving to a c5.2xlarge if these maintenance windows are unacceptable. The extra vCPUs provide more headroom so the data plane isn't starved during the compile.
connected