The Call You Already Know
You get the call. "The network is slow." Or: "Users are dropping connections." Or: "Something is wrong, we don't know what." You show up, check the usual suspects. Spanning tree reconvergence. Duplex mismatch. Oversubscribed uplink. DNS resolution delays. Firewall state table exhaustion. Maybe it is a bad optic or a failing NIC.
Half the time you find the issue in the first hour. The other half, you spend days chasing intermittent symptoms that appear, disappear, and reappear with no pattern you can pin down. The monitoring tools show bandwidth within normal range. CPU and memory on the switches are fine. The ISP says the circuit is clean on their end.
What if the problem is not infrastructure at all? What if the network is under attack, and the attack is designed to look exactly like a network issue?
Why DDoS Gets Missed in Troubleshooting
When most people think of DDoS, they picture a massive flood that saturates a link and takes everything offline. That kind of attack is obvious. Bandwidth graphs go vertical, alerts fire everywhere, and the ISP calls you before you call them.
But the attacks causing the most confusion in troubleshooting engagements are not that kind. They are the ones that stay below the radar on purpose.
Low-and-slow attacks
A low-and-slow attack sends just enough traffic to degrade service without triggering volume-based alerts. A SYN flood at 5,000 packets per second against a web server will not saturate a gigabit link. It will not show up as a bandwidth spike. But it will exhaust the server's TCP connection table, causing legitimate connections to time out intermittently. The symptoms look like an application problem or a server resource issue, not a network attack.
Slowloris-style attacks are even harder to spot. They hold connections open with minimal data, consuming connection slots without generating meaningful traffic volume. Your bandwidth graphs stay flat while users report that the site loads for five seconds and then hangs.
Carpet bombing
Carpet bombing distributes attack traffic across an entire subnet. Instead of sending 1 Gbps to one IP, the attacker sends 5-10 Mbps to each of 100 IPs in a /24. No single destination trips a threshold. The aggregate traffic saturates the upstream link or router backplane, but when you look at per-host metrics, everything appears normal. You see modest increases across many hosts, which looks like organic traffic growth or a busy period.
This is the attack pattern that sends network consultants on multi-day wild goose chases through switch configs and ISP trouble tickets.
Sub-threshold volumetric attacks
Many organizations set DDoS alert thresholds based on link capacity. If the uplink is 10 Gbps, the threshold might be set at 8 Gbps. An attacker sending 2 Gbps of UDP reflection traffic stays well below that threshold, but the 2 Gbps is enough to cause packet loss on a link that normally carries 6 Gbps of legitimate traffic. The result is intermittent packet loss and latency spikes that correlate with nothing in your monitoring dashboards because the monitoring is looking at total bandwidth, not traffic composition.
Pulsing attacks
Pulsing attacks send high-intensity bursts for a few seconds, then go silent for 20-30 seconds, then burst again. The 60-second averaging window on most monitoring tools smooths out the bursts entirely. Users report intermittent connectivity problems that come and go. You run a continuous ping and see periodic packet loss that appears random. The monitoring dashboard shows clean, steady traffic because the bursts average out over the collection interval.
The common thread: these attacks produce symptoms that look like infrastructure problems because they are specifically designed to stay below the detection thresholds of conventional monitoring tools.
Symptoms That Should Trigger a DDoS Check
After years of troubleshooting network issues that turned out to be attacks, there is a set of symptoms that should immediately put DDoS on the differential diagnosis list.
- Intermittent packet loss with no infrastructure explanation: You have checked the optics, the cables, the switch ports, the ISP circuit. Everything tests clean when you look at it, but users keep reporting drops. If the packet loss appears and disappears on a semi-regular cycle, you may be looking at a pulsing attack.
- Latency spikes that do not correlate with traffic volume: Your bandwidth utilization is at 40%, but latency to certain hosts jumps from 2ms to 200ms periodically. This can indicate that a subset of traffic is attack traffic consuming processing resources on routers or firewalls even though the volume is low.
- Firewall or load balancer state table exhaustion: The device runs out of connection tracking entries despite moderate throughput. Low-and-slow attacks deliberately create half-open or idle connections that consume state table slots without generating traffic volume.
- Multiple hosts affected simultaneously with different symptoms: Server A has high CPU, Server B has TCP retransmissions, Server C has DNS resolution failures. When unrelated hosts show different failure modes at the same time, consider carpet bombing across the subnet.
- Problems that appear during specific hours and resolve on their own: Attacks are often time-limited (paid booter services run for minutes or hours). If the "network issue" appears at 2 PM and clears by 3 PM every day, that pattern is more consistent with a scheduled attack than a hardware fault.
- ISP and upstream say everything is fine on their end: This is the classic. The circuit is clean, the BGP session is stable, and the ISP cannot find a problem. That is because the attack traffic is legitimate from the ISP's perspective; it is valid IP traffic arriving at your port. They cannot see that it is malicious without deeper inspection.
What Monitoring Tools Miss (and Why)
Standard network monitoring tools are built for capacity planning and availability tracking. They are excellent at answering "how much bandwidth are we using?" and "is this device up or down?" They are not built to answer "is this traffic pattern an attack?"
Bandwidth is the wrong metric
SNMP-based monitoring pulls interface counters every 60 seconds and calculates bandwidth utilization. This is the metric most NOC dashboards display prominently. But DDoS attacks do not always show up as bandwidth spikes. A SYN flood at 50,000 packets per second generates roughly 3 Mbps of traffic. On a 10 Gbps link, that is 0.03% utilization. Your bandwidth graph will not move. But those 50,000 SYN packets per second will destroy a server's ability to accept new connections.
The metric that matters for DDoS detection is packets per second, not bits per second. Most monitoring tools do not track PPS at all, or they track it as a secondary metric that nobody watches.
Protocol distribution is invisible
A healthy web server receives mostly TCP traffic on port 443. If that server suddenly starts receiving 30,000 UDP packets per second on random high ports, that is an attack. But standard monitoring only shows aggregate bandwidth. It does not break traffic down by protocol, by port, or by packet size. The UDP flood is invisible in the aggregate view.
Averaging hides bursts
Most monitoring tools collect data in 60-second or 300-second intervals and display averaged values. A 5-second burst of 500,000 PPS followed by 55 seconds of silence averages to roughly 42,000 PPS over the minute. If normal traffic is 35,000 PPS, the average looks like a modest 20% increase. Not alarming. But during those 5 seconds of burst, the server experienced severe packet loss, TCP retransmissions spiked, and users saw connection timeouts.
No baseline comparison at the host level
Network monitoring tools track device-level and interface-level metrics. They do not know what "normal" looks like for an individual host. Server A might normally receive 1,000 PPS and Server B might normally receive 50,000 PPS. A jump to 10,000 PPS is a crisis for Server A and a rounding error for Server B. Without per-host baselines, there is no way to know which deviation matters.
How ftagent Reveals What Monitoring Misses
Flowtriq's agent (ftagent) is built specifically for the kind of detection that monitoring tools cannot do. It runs on the host, monitors the actual network interface in real time, and analyzes traffic at the packet level with per-second granularity.
Per-second PPS and BPS tracking
ftagent records packets per second and bits per second every single second. No 60-second averaging. No 5-minute collection intervals. When a 5-second burst hits, it appears in the data as a 5-second spike, not a statistical blip smoothed into the background. This is the difference between seeing the attack and not seeing it.
Protocol and port classification
Every packet is classified by protocol and destination port. If a web server that normally receives 95% TCP/443 traffic suddenly sees 40% UDP traffic on random ports, ftagent flags the protocol distribution shift immediately. The classification shows exactly what kind of traffic is arriving, not just how much.
Dynamic per-host baselines
ftagent builds a baseline for each host based on that host's actual traffic patterns. It knows that Server A normally receives 1,200 PPS of TCP/443 and 50 PPS of ICMP. When Server A suddenly receives 8,000 PPS of UDP/53, the deviation from baseline is unambiguous. This per-host context is what makes low-and-slow attacks and carpet bombing detectable.
Kernel counter analysis
Beyond raw traffic metrics, ftagent monitors kernel-level counters that reveal server stress. TcpExtSyncookiesSent climbing means the server is under SYN flood pressure. UdpInErrors incrementing means UDP packets are being dropped because the socket buffer is full. TcpExtListenDrops rising means the server cannot accept new connections. These counters tell you exactly how the attack is affecting the server, even when the traffic volume is low.
Automatic attack classification
When ftagent detects an anomaly, it classifies the attack by type: SYN flood, UDP amplification, DNS reflection, ICMP flood, carpet bomb, and dozens of other signatures. Instead of a vague "traffic anomaly" alert, the consultant gets a specific classification with protocol breakdown, top source IPs, and packet characteristics. That turns a multi-hour investigation into a five-minute confirmation.
The key difference: monitoring tools answer "how much traffic is flowing?" while ftagent answers "is this traffic legitimate, and if not, what kind of attack is it?"
Adding DDoS Detection to Your Troubleshooting Toolkit
If you do network troubleshooting for clients, adding DDoS detection to your standard workflow is straightforward and immediately valuable.
Step 1: Deploy ftagent during the engagement
When you arrive on site for a troubleshooting call, install ftagent on the affected servers as part of your initial data collection. The agent installs in under 60 seconds on any Linux server and starts collecting per-second traffic data immediately. No DNS changes, no traffic rerouting, no firewall modifications. It is a passive observer on the network interface.
# Install on the affected server curl -sSL https://flowtriq.com/install.sh | sudo bash # Agent starts collecting per-second PPS, BPS, protocol distribution # Data appears in the Flowtriq dashboard within seconds
Step 2: Check the data before chasing infrastructure
Before spending hours on switch configs and ISP escalations, look at the ftagent data. Is there a traffic anomaly? Is the protocol distribution abnormal? Are kernel counters showing connection exhaustion or buffer overflows? If ftagent shows clean traffic patterns, you can confidently rule out DDoS and focus on infrastructure. If it shows an anomaly, you just saved yourself days of troubleshooting the wrong problem.
Step 3: Use the classification for resolution
If ftagent identifies an attack, the classification tells you what mitigation to apply. A SYN flood can be mitigated with SYN cookies and rate limiting at the firewall. A UDP amplification attack requires upstream filtering or RTBH. A carpet bombing pattern needs subnet-level analysis and upstream coordination. The classification provides the specificity you need to resolve the issue, not just detect it.
Turning a One-Time Call into Ongoing Monitoring
Here is where the troubleshooting engagement becomes a recurring revenue stream.
You solved the client's immediate problem. You showed them that the "network issue" they have been chasing for weeks was actually a low-and-slow DDoS attack. They are relieved that the mystery is over, and they now understand that conventional monitoring did not catch it.
The natural follow-up question is: "How do we make sure this does not happen again?"
The answer is continuous monitoring with ftagent. The agent stays deployed, builds long-term baselines, and alerts when anomalies appear. Instead of waiting for users to complain about slow connections, the detection happens in seconds and fires alerts to Slack, PagerDuty, email, or webhook. The client gets proactive DDoS detection without hiring a full-time network security engineer.
For the consultant, this means:
- Recurring monthly revenue: Flowtriq is $9.99 per node per month. You set your own margin for the monitoring, alerting, and incident response you provide on top. A client with 10 servers paying you $30/node/month is $3,600/year in recurring revenue from a single troubleshooting engagement.
- Faster future engagements: When ftagent detects an attack, it captures a PCAP and classifies the traffic automatically. Your next troubleshooting call starts with data instead of guesswork.
- Differentiation from other consultants: Most network consultants show up with a laptop and Wireshark. You show up with a detection platform that can identify attack patterns in real time. That is a different conversation with the client.
Two Certifications for Network Consultants
Adding DDoS detection to your troubleshooting practice requires two things: the ability to deploy and configure the detection platform, and the foundational knowledge of how DDoS attacks work at the protocol level. Two free certifications cover both.
CFC: Certified Flowtriq Consultant
The CFC certification covers the deployment and consulting side. It walks through agent installation, threshold configuration, alerting setup, client onboarding, and the partner program. If you want to offer DDoS detection as part of your troubleshooting practice, the CFC gives you the operational knowledge and unlocks partner pricing. Free, takes about 20 minutes, and earns you a LinkedIn badge and directory listing.
CDDP: Certified DDoS Protection Practitioner
The CDDP certification covers the detection fundamentals. It teaches the attack vectors, protocol mechanics, and classification techniques that make you effective at identifying DDoS patterns in troubleshooting data. When a client asks "how do you know this is an attack and not a network issue?", the CDDP gives you the vocabulary and technical depth to answer with confidence. Also free, 20 questions, and no prerequisites.
Together, the CFC and CDDP give network consultants everything they need to add DDoS detection to their standard troubleshooting process and convert one-time engagements into ongoing monitoring contracts.
Stop chasing phantom network issues. The CFC (deployment, configuration, partner pricing) and CDDP (attack vectors, detection fundamentals, classification) are both free. Add DDoS detection to your troubleshooting toolkit and find the attacks that monitoring tools miss.