Back
Lesson 2 of 6

Application Visibility and Control

Objective

In this lesson you will use the FTD/FMC elephant-flow capability to perform application visibility and Layer‑7 control for very large (elephant) application flows. You will enable the elephant-flow inspector, tune the detection thresholds, and verify that the system is configured to detect and act on heavy application flows. This matters in production because a single large application transfer (database backup, VM replication, large build artifacts) can monopolize CPU and packet-processing resources in the inspection engine; detecting and remediating such flows protects inspection capacity and preserves predictable performance for other traffic.

Real-world scenario: an enterprise data center sees nightly database replication from 10.0.1.14 to 172.16.0.1 that occasionally spikes traffic and triggers Snort CPU spikes. By enabling elephant‑flow detection and raising an automated remediation flag (bypass or throttle where supported), you can reduce inspection CPU churn and keep IPS/AV signatures operating for normal-sized flows.

Quick Recap

Refer to the topology used in Lesson 1. We reuse the same devices and addresses; no new physical devices are added in this lesson. The management/controls are done via FMC and the FTD CLI.

ASCII topology (interfaces show exact IPs used in the reference):

 [FMC mgmt] 10.0.0.1
       |
       | mgmt
       |
   [FTD mgmt] 192.168.1.77
     /     |    \
    /      |     \

[Host A]10.0.1.11 [Host B]10.0.1.14 [Server]172.16.0.1

Outside gateway 192.168.1.1

Notes:

  • FMC is at 10.0.0.1 (management/controller).
  • Hosts and servers are the endpoints that generate/receive application traffic (10.0.1.11, 10.0.1.14, 172.16.0.1).
  • Outside gateway is 192.168.1.1.

Key Concepts

Before you make changes, understand these critical concepts and how they impact packet flow and inspection:

  • Elephant flows — A flow that transfers a very large number of bytes over a short time (examples: DB replication, backups). These are detected by measuring bytes transferred over a time window. In practice, elephant flows can overwhelm a single Snort inspection instance and cause CPU spikes that degrade IPS effectiveness.

  • Detection thresholds (time and bytes) — The engine uses a time window (seconds) and a bytes threshold (MB) to classify a flow as an elephant. If a flow moves more than the bytes_threshold within time_threshold seconds, the inspector raises a mid‑flow event and flags the flow as an elephant.

  • Remediation actions (bypass / throttle) — After detection, the controller can instruct the data plane to change how the flow is treated: bypass inspection (let the flow pass uninspected) or throttle the flow (apply a QoS-like rate reduction while possibly continuing inspection). Note: not all platforms support both actions (for example, Firepower 2100 series does not support bypass/throttle).

  • Snort and verdicts — With Snort 3, the inspection engine can emit a verdict indicating a remediation (for example, a QoS flow with a reduced rate). This is carried to the data plane so the packet-processing path can implement the remediation without requiring full reassembly in the inspection engine.

  • ACP (Access Control Policy) relationship — Elephant-flow detection is surfaced in the ACP advanced options (configured in FMC’s ACP Advanced tab). The CLI provides the ability to enable/disable and tune thresholds on the device. Think of ACP as the policy container and the elephant-flow parameters as the sensor thresholds that feed into policy decisions.

Analogy: Think of elephant-flow detection like a bouncer in a nightclub. When a single group (flow) gets too large (bytes in a short time), the bouncer can either ask them to leave the inspection area (bypass) or slow down their entrance rate (throttle), preventing them from crowding the dance floor (inspection engine).

Step-by-step configuration

Each step below follows a strict pattern: what we are doing, the exact commands, explanation of their effect, a production note, and verification with expected output.

Step 1: Enable the elephant‑flow inspector

What we are doing: Turn on the elephant-flow detection feature on the device so the inspection engine will begin monitoring flows for elephant characteristics. Enabling this is the prerequisite before tuning thresholds.

> system support elephant -flow-detection enable

What just happened: The device is now configured to run the elephant-flow inspector. Internally, the inspection engine starts measuring per‑flow statistics (bytes over time) and will generate a mid‑flow event if the configured thresholds are exceeded. Enabling does not change thresholds; it only activates detection.

Real-world note: Enabling detection has a small CPU and memory cost because the engine maintains per-flow counters for flows under inspection. In high-throughput environments, ensure you have headroom or tune thresholds conservatively.

Verify:

> show elephant -flow status
Elephant flow inspector is enabled

Explanation of expected output: the single-line output confirms the inspector is active. If it reads "disabled" the feature is not active and subsequent threshold changes will not be applied.

Step 2: Set the time threshold (seconds)

What we are doing: Configure the duration (time window) used to observe bytes transferred; if the bytes threshold is exceeded within this many seconds, the flow becomes an elephant. This determines how quickly the engine should classify bursts as elephant flows.

> elephant -flow-detection time-threshold 10

What just happened: This command sets the time window to 10 seconds. From a protocol/engine perspective, the inspection module keeps a sliding observation window of 10 seconds for each tracked flow. A shorter time_threshold makes the system sensitive to short bursts; a longer value reduces sensitivity to short transfers but increases the time before remediation is triggered.

Real-world note: For database replication that transfers a lot of data steadily, a 10-second window is commonly used to catch sustained high-volume flows. For bursty application traffic, you may want a longer window to avoid false positives.

Verify:

> show elephant -flow detection -config
bytes_threshold = 1024, time_threshold = 10

Expected output explanation: The show command displays both configured bytes and time thresholds. At this stage you should see time_threshold = 10. If bytes_threshold is not yet set, it may show a default or previous value (we set it next).

Step 3: Set the bytes threshold (megabytes)

What we are doing: Configure the amount of data (in megabytes) that a flow must transfer within the time window to be considered an elephant. Together with the time threshold this defines the detection rule.

> elephant -flow-detection bytes-threshold 1024

What just happened: You have set the bytes threshold to 1024 MB (1 GB). The detection engine will classify any flow that transfers more than 1024 MB within the configured 10-second window as an elephant flow. This threshold is intentionally high to catch truly large transfers and avoid flagging normal large but legitimate user downloads.

Real-world note: In an environment with 10 Gbps links and large VM migrations, you may need a high bytes_threshold; in smaller branch links, the threshold should be lower. Tune thresholds according to your typical traffic profiles.

Verify:

> show elephant -flow detection -config
bytes_threshold = 1024, time_threshold = 10

Expected output explanation: Both fields should now reflect your configured values. If they match, the inspector will use these values for runtime detection.

Step 4: Disable (rollback) — optional rollback example

What we are doing: Demonstrate how to disable elephant-flow detection if you need to revert changes during troubleshooting or maintenance.

> system support elephant -flow-detection disable

What just happened: Disabling stops the elephant-flow inspector. The inspection engine will no longer generate elephant mid‑flow events or trigger remediation. This is useful for troubleshooting false positives or when you need to perform a capacity analysis without dynamic remediation.

Real-world note: In production, coordinate disabling with your monitoring team; disabling removes an automatic safeguard against heavy flows and can allow inspection CPU to be consumed by large transfers.

Verify:

> show elephant -flow status
Elephant flow inspector is disabled

Expected output explanation: Confirmation that the feature is off. Re-enable when you are ready to resume protection.

Step 5: Confirm platform support and ACP integration (procedural verification)

What we are doing: Confirm whether the platform supports remediation (bypass/throttle) and understand where this feature is surfaced in the policy (ACP Advanced tab).

> show elephant -flow status
Elephant flow inspector is enabled

What just happened: The device reports the state of the inspector. Reminder: remediation actions (bypass or throttle) are configured in the ACP Advanced settings in FMC; the CLI controls detection parameters. Also remember that certain platforms (for example Firepower 2100 series) do not support bypass and throttle remediations even if detection is available.

Real-world note: Always check platform capability: detection without supported remediation is still useful for alerting and capacity planning, but it will not be able to programmatically alter data-plane behavior on unsupported hardware.

Verify (FMC/ACP):

  • Use the FMC ACP Advanced tab to associate an elephant-flow remediation action with an access-control rule. (This is a GUI action; CLI tuning deals with detection thresholds.)

Important: The CLI commands configure the detector thresholds; the policy action that occurs after detection (bypass/throttle) is set in the ACP Advanced tab in FMC and may be constrained by hardware capability.

Verification checklist

  • Check 1: Elephant-flow inspector is enabled — verify with:

    > show elephant -flow status
Elephant flow inspector is enabled

  • Check 2: Time and bytes thresholds are applied — verify with:

    > show elephant -flow detection -config
bytes_threshold = 1024, time_threshold = 10

  • Check 3: ACP policy has remediation defined and platform supports the chosen remediation (verify in FMC ACP Advanced tab). If hardware does not support bypass/throttle (for example Firepower 2100), plan for alternate mitigations (alerts, traffic shaping upstream).

Common Mistakes

SymptomCauseFix
Show command still reports "disabled" after enablingTypo in the enable command (spaces/hyphens) or command executed in the wrong CLI contextRe-run the exact CLI command: system support elephant -flow-detection enable. Verify with show elephant -flow status
Too many false positives (normal flows classified as elephant)Thresholds set too low (time_threshold or bytes_threshold too small)Increase bytes_threshold or increase time_threshold to match normal traffic patterns; verify with show elephant -flow detection -config
Detection enabled but no remediation occursRemediation not configured in ACP or platform does not support bypass/throttleConfigure remediation in FMC ACP Advanced tab; if running on Firepower 2100 series, note bypass/throttle are not supported — use alerts or upstream QoS as alternatives
CLI shows thresholds but you still see CPU spikesDetection alone does not change data-plane behavior unless remediation is configured and supportedEnsure ACP remediation is set; review platform support; use monitoring dashboard to correlate CPU spikes with detected flows

Key Takeaways

  • Elephant-flow detection identifies very large Layer‑7 flows by monitoring bytes over a short time window; it helps protect the inspection engine from CPU overload by triggering remediation.
  • The CLI commands you used enable detection and tune detection parameters (time_threshold and bytes_threshold). You verified settings with show elephant -flow detection -config and show elephant -flow status.
  • Policy and remediation are separate: thresholds are configured on the device CLI, while the action (bypass/throttle) is associated via the ACP Advanced settings in FMC. Platform capability determines which remediations are available.
  • In production, tune thresholds to your environment to avoid false positives, and always validate remediation availability for your hardware — detection without viable remediation is useful for monitoring but does not automatically prevent inspection overload.

Tip: Treat elephant-flow settings as operational knobs. Use historical traffic baselining to choose bytes and time thresholds so legitimate large transfers are controlled without impacting valid business flows.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security