How Do You Analyze Random FTD Disconnects at 90% CPU?
A network engineer is receiving reports of users randomly getting disconnected from their corporate applications which traverse the data center FTD appliance. 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?
Community Insight
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.
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.
Community Discussion (9 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
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?
Packet Tracer only injects one simulated packet to show how policy would treat it, so it cannot reveal the real drops or session resets an overloaded FTD is causing.
Are "Packet Export" and "Packet Analysis" real FTD troubleshooting features?
No. The native tools are Packet Capture and Packet Tracer in FMC; export is just the step that downloads a capture file, and packet analysis is done externally in a tool like Wireshark.