A hospital runs FTD in routed mode between its user VLANs and the WAN edge. The team added a QoS rule constrained to the WAN interface to police overnight backup replication, but the counters show no drops, and the backups are matched early by a prefilter rule whose action is Fastpath. Which Threat Defense QoS behavior explains the missing policing on this backup traffic?
Select an answer to reveal the explanation.
Short Explanation
Your prefilter Fastpath rule sends the backups past further processing, so QoS policing doesn’t apply. It’s like a speed camera that traffic can avoid by taking a side road.
Full Explanation
FTD QoS policing is applied to traffic that traverses the QoS processing path. A prefilter rule with the Fastpath action sends matching connections past the rest of access control, and Cisco documents that fastpathed traffic is not rate limited by QoS; therefore, the overnight backup traffic is not rate-limited and the QoS rule records no drops. The access-control-deny prerequisite misconception is wrong: denying traffic drops it, rather than making it eligible for policing, and allowed traffic can still be policed when it traverses the relevant path and matches the rule. The device-level-policy-overrides-fastpath misconception is also wrong: assigning a QoS policy to the device does not cancel the fastpath exclusion. The logging-required-for-policing misconception fails because logging is not a prerequisite for rate limiting; enabling logs alone will not apply a policer. Exam caveat: removing or narrowing the Fastpath rule (for example, changing it to Analyze) can expose the backups to QoS, but only if they then match the QoS rule’s conditions, including its WAN-interface constraint. Practical check: confirm that the backup connections match the Fastpath prefilter rule, then verify the QoS rule’s interface and match criteria before comparing its counters.