How Do You Analyze Random FTD Disconnects at 90% CPU?
Short answer
B Use the Packet Capture feature on the FTD through FMC to collect real-time traffic and see why the overloaded appliance drops sessions.
Question
Network monitoring tools show that the FTD appliance utilization is peaking above 90% of total capacity. What must be done in order to further analyze this issue?
Key Takeaways
The question tests which native Firepower troubleshooting tool produces live traffic evidence for an overloaded FTD, and the trap is choosing Packet Tracer because "random" disconnects sound like a policy problem.
When users are randomly disconnected from applications through a data-center FTD whose utilization peaks above 90%, the next troubleshooting step is a real-time Packet Capture on the appliance so actual drops and resets can be inspected. This page confirms Packet Capture (B) as the answer and explains why Packet Tracer, Packet Export and the non-existent Packet Analysis feature do not fit.
Common mistake: Most learners who miss this pick Packet Tracer, reasoning that a 90% loaded appliance should not be asked to run a capture — but Packet Tracer only injects one simulated packet and never shows the real drops, retransmissions or resets driving the random disconnects.
Expert Analysis
Why the Answer Is Correct
Packet Capture (B) is the only listed tool that collects the real traffic crossing the overloaded FTD, which is exactly what "further analyze this issue" requires: you need to see whether sessions are being reset, retransmitted or silently dropped as utilization peaks above 90%. Firepower Threat Defense supports on-box captures configurable per interface with match access lists and a buffer, and the resulting pcap can be downloaded from FMC and opened in Wireshark alongside connection events. Community reasoning agrees with this reading: tanri04 explains that at 90% utilization "it is possible that the appliance is dropping packets and causing users to get disconnected," and donciga summarises the same causal chain. MB2222 adds the useful observation that because connectivity still exists and only drops randomly, capturing live traffic is what identifies the source flooding the appliance. The Packet Capture tool is therefore the correct analytic step; the valid operational concern about added CPU load is a sizing/scoping question, not a reason to substitute a simulation.
Why the Other Options Are Wrong
Option A, "Packet Export," is not a discrete FTD/FMC troubleshooting feature — export is merely the final step of a packet capture used to move a pcap off the appliance, and exporting data alone never explains why throughput is saturating. Option C, Packet Tracer, is a policy-simulation tool: as donciga put it, "Packet Tracer only injects a simulated packet and shows how policy would treat it," so it cannot reveal live drops or the effect of the 90% load, and tinyJoe makes the strongest logical objection that "If the policy prevents the connection from going through, then it should not be random, but a complete disconnection." Option D refers to a "Packet Analysis" feature that does not exist by that name on FTD; packet analysis is what an engineer performs on captured packets in a tool such as Wireshark, not an appliance feature you select. That leaves Packet Capture as the only option that both exists and produces the evidence required.
Community Comment Notes
Consensus among the commenters leans firmly to Packet Capture: tanri04's answer, Baumb's breakdown and 14a1949's comparison all land on B. The dissenting view is technically motivated rather than policy-motivated — Bbb78 argues that "with CPU 90% last thing you need is a capture" because the capture itself could push the appliance to 99%, and gc999 similarly says "we should use the least CPU loading method for investigation." That concern is legitimate in production and should be mitigated with tightly scoped, time-limited captures or capture-on-drop instead of abandoning evidence collection; bassfunk's instinct that "when i hear connections are getting dropped, i think policy" is exactly the trap the question sets, since the disconnects here are random rather than deterministic. The mixed vote total is a reminder not to treat popularity as proof, but on this scenario the live-traffic tool wins.
For the exam, remember the tool triad in FMC/FTD troubleshooting: Packet Capture (live traffic on an interface), Packet Tracer (simulated packet through the policy pipeline), and capture export/download for offline analysis in Wireshark.
Exam Strategy
Eliminate the two options that are not real Firepower feature names ("Packet Export" and "Packet Analysis") first, then decide between capture and tracer by asking whether the scenario needs live traffic or a policy simulation. Signs like load above 90%, random disconnects and packet drops always point to capture.
Frequently Asked Questions
Why is Packet Tracer not the right choice for random disconnects at 90% CPU?
Are "Packet Export" and "Packet Analysis" real FTD troubleshooting features?
Discussion 9 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 9
-
tanri04 👍 6Correct answer: B. Use the Packet Capture feature to collect real-time network traffic. In this scenario, since the FTD appliance utilization is peaking above 90% of total capacity, it is possible that the appliance is dropping packets and causing users to get disconnected from their corporate applications. To further analyze the issue, the network engineer can use the Packet Capture feature in the FTD to collect real-time network traffic and determine whether packets are being dropped, and if so, which packets are being dropped. Option A, Packet Export feature, allows you to export captured packets to an external storage device. It does not help in analyzing the issue at hand. Option C, Packet Tracer feature, is used to simulate and troubleshoot network traffic through the firewall. It does not help in capturing real-time network traffic for analysis. Option D, Packet Analysis feature, provides a way to analyze packet captures taken with the Packet Capture feature. However, before analysis can be done, packets must first be captured with the Packet Capture feature.
-
Bbb78 👍 6This is the stupidest question ever. with CPU 90% last thing you need is a capture... show resources or cpu but capture will make the CPU 99% NO real answer
-
Baumb 👍 4A. Use the Packet Export feature to save data onto external drives. -> Exporting traffic doesnt help us understanding why the traffic lets the FTD peak B. Use the Packet Capture feature to collect real-time network traffic. -> Could be, we can see what traffic is traversing the firewall by inspecting the dump in packet analysis software C. Use the Packet Tracer feature for traffic policy analysis. -> Packet Tracer does not analyze real traffic, it generates virtual traffic, so a No. D. Use the Packet Analysis feature for capturing network data. -> Packet Analysis is not a feature to capture the traffic, but instead view the traffic. Since it explicitly says capture I would say this option is not valid. So I think B is correct
-
14a1949 👍 2 Answered BUsing the Packet Tracer feature (option C) is indeed useful for traffic policy analysis. It helps you understand how traffic is being processed by the FTD appliance and can identify issues related to policy configurations. However, to specifically analyze the issue of high utilization and user disconnections, the Packet Capture feature (option B) is more appropriate. Packet Capture allows you to collect real-time network traffic data, providing detailed insights into the actual traffic patterns and potential anomalies causing the high utilization and disconnections. Both tools are valuable, but for real-time traffic analysis and identifying the root cause of performance issues, Packet Capture is the more suitable choice.
-
MB2222 👍 2It should be answer "B", since we do have client connectivity (--> randomly disconnects clients). So the identify the source that is flooding the bandwidth, etc. packet captures are a good indication to do so.
Show 4 more comments
-
donciga 👍 1 Answered BUse the Packet Capture feature to collect real-time network traffic.High utilization (>90%) on the FTD can cause packet drops, session resets, or timeouts that appear as random application disconnects. Packet Tracer only injects a simulated packet and shows how policy would treat it; it does not show live traffic or actual drops. There is no “Packet Analysis” feature by that name, and Packet Export is just a way to offload an already-captured file
-
gc999 👍 1 Answered CThey keyword here is the system is 90% overload, we should use the least CPU loading method for investigation. The first step is to use packet tracer to check if the policy is correct or not. For other option with capturing, it would not succeed and even cause impact to the system since the system is now 90% overload already.
-
tinyJoe 👍 1 Answered Bmy answer is B. Users are “randomly” disconnected, right? If the policy prevents the connection from going through, then it should not be random, but a complete disconnection.
-
bassfunk 👍 1 Answered CI would answer c. The traffic is not real but the point is to analyze the policy. When i hear connections are getting dropped, i think policy.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.