# AFM DoS-vector & profile explainer > Every AFM DoS vector explained in F5's own words, with the threshold mechanics spelled out and the configuration cross-checked: the silent mitigation-below-detection inversion, automatic-mode semantics, policing without detection, and the SYN-cookie interplay. Defensive configuration only. - Tool: https://ronutz.com/en/tools/f5-dos-vector-explainer - Family: Networking --- # AFM DoS-vector / profile explainer A BIG-IP AFM - Advanced Firewall Manager device-DoS configuration is a hundred small dials with three failure modes: thresholds that never fire, thresholds that fire silently, and thresholds someone set without knowing what the vector actually counts. This tool reads the configuration back to you the way the reference manual would. Paste a `security dos device-config` stanza, one or more `security dos profile` stanzas, or both, exactly as tmsh lists them. Every vector entry renders as a card: the vector's identity in F5's own one-line description (the tool carries the full 105-entry vector table from the tmsh reference, sys-db tunables included), each threshold field annotated with the reference's semantics, and deterministic observations underneath. The semantics matter more than they look. A pps detection threshold compares a one-minute average against an absolute value; the percent variant compares that same one-minute average against a dynamically learned one-hour baseline; and the internal rate limit is programmed into hardware on platforms that have it, with bad packets always dropped regardless. The tool spells each of these out on the field where it applies. The observations are the point. The marquee check is the inversion F5's own SYN-cookie troubleshooting series warns about: a mitigation rate limit set below the detection threshold rate-limits traffic before an attack is ever declared, so packets drop with no attack log. The tool flags it in both attribute-naming families, device (`default-internal-rate-limit` vs `detection-threshold-pps`) and profile (`rate-limit` vs `rate-threshold`), and repeats the check per-source for bad-actor rates. Around it: automatic-threshold mode explained the way the DDoS training material states it (detection thresholds adjust to observed traffic; mitigation limits are always stress-driven, so anomalies without stress alert but do not block), manual numbers marked inert under automatic mode, `simulate-auto-threshold` scoped to manual mode as the reference requires, detection disabled while a finite limit polices silently, `enforce disabled` and `detect-only` called out as monitoring rather than mitigation, and orphaned bad-actor wiring in either direction. A single vector name renders one card; the word `vectors` renders the whole catalogue grouped into nine categories. Vectors outside the curated table still parse and get the threshold mechanics, flagged honestly as outside it rather than guessed at. This tool explains defensive configuration and never generates traffic of any kind. Everything runs locally; nothing you paste leaves the page. ## Standards and references - [F5 TMSH Reference: security dos device-config (the vector-types table with per-vector descriptions and db tunables; the threshold parameter semantics; floor/ceiling; simulate scoping)](https://clouddocs.f5.com/cli/tmsh-reference/v13/modules/security/security_dos_device-config.html) - the curated catalogue's names and descriptions verbatim; the 1-minute/1-hour threshold semantics; the hardware rate-limit statement; bad-actor and blacklisting attributes - [F5 TMSH Reference: security dos profile (per-profile vector attributes: rate-threshold, rate-increase, rate-limit, state, per-source and per-destination controls, scrubbing defaults)](https://clouddocs.f5.com/cli/tmsh-reference/latest/modules/security/security_dos_profile.html) - the profile-context attribute names the parser and inversion check map - [F5 DDoS training labs: auto-thresholding behavior (detection thresholds adjust to observed traffic; mitigation limits are always stress-driven; anomalies without stress alert but do not block)](https://clouddocs.f5.com/training/community/ddos/html/class1/module1/lab6.html) - the automatic-mode explanation the auto-threshold observation quotes - [F5 DevCentral: SYN Cookie Troubleshooting - Logs (AFM Device DoS precedence over the LTM global SYN cookie; the mitigation-below-detection warning and its silent-drop consequence)](https://community.f5.com/kb/technicalarticles/9-syn-cookie-troubleshooting-logs/279431) - the tcp-half-open interplay notes and the inversion observation's operational consequence ## Related reading - [Connection Eviction Policies: What BIG-IP Throws Overboard, and When](https://ronutz.com/en/learn/bigip-connection-eviction-policies.md): The connection table is finite, and something decides what dies first when it fills. Before 11.6 that was the adaptive reaper and two db keys; since 11.6 it is the eviction policy: watermark triggers whose meaning changes with the attachment context, strategies the manual honestly calls statistical and opportunistic, and a slow-flow block with a clean monitor-first pattern. - [SYN Flood Protection on BIG-IP: Cookies, Thresholds, and Who Answers First](https://ronutz.com/en/learn/bigip-syn-flood-protection.md): A SYN flood attacks the connection table's half-open state. BIG-IP's answer is the SYN cookie: a stateless SYN-ACK with the state encoded in the sequence number. The interesting part is the layering: LTM global and per-VS thresholds, per-VLAN hardware cookies, and an AFM device vector that takes precedence over all of it, plus one threshold arrangement that mitigates silently with no attack log.