Nothing matches that yet. Tell us what you were looking for and it goes on the list.
Linux netfilter / kernel · Event net_ratelimit: callbacks suppressed
The kernel throttles how fast it will print network messages, and this line is it admitting how many it threw away. Any count you calculate from netfilter LOG output during that window is wrong, usually by a lot — and this is the only warning you get.
Also written as net_ratelimit callbacks suppressedkernel net_ratelimitcallbacks suppressed iptables logmissing firewall log lines linux
Your firewall was blocking things faster than the system could write them down, so it stopped writing some of them. Nothing broke — the packets were still handled correctly. Only the record of them is incomplete.
Two consequences worth internalising. First, any 'how many times did this source hit us' figure derived from LOG output is a floor, not a count, and the suppressed number is the only correction available. Second, an attacker who can generate enough noise can push the lines they care about into the suppressed window — flooding a firewall to bury a single connection is cheap and this message is where the evidence of it lives.
Sanitised. Addresses come from the RFC 5737 documentation ranges.
Sep 7 14:07:19 gw-01 kernel: [1234567.890123] net_ratelimit: 412 callbacks suppressed
Sep 7 14:07:19 gw-01 kernel: [1234567.890456] [UFW BLOCK] IN=eth0 OUT= SRC=198.51.100.77 DST=192.0.2.15 LEN=44 TOS=0x00 PREC=0x00 TTL=51 ID=54321 PROTO=TCP SPT=53122 DPT=3389 WINDOW=1024 RES=0x00 SYN URGP=0Everything else in the log line is context.
Most of the time it is one of these.
What gives it awayA very large suppressed count immediately around the time of interest, with the surrounding traffic being trivially cheap to generate — spoofed sources, a single repeated port, no completed connections.
ATT&CK T1562.006What gives it awaySustained suppression over minutes rather than a single burst, with the logged sample showing many destination ports or many source addresses.
ATT&CK T1046grep -c 'callbacks suppressed' /var/log/kern.loggrep -oP 'net_ratelimit: \K\d+(?= callbacks suppressed)' /var/log/kern.log | awk '{s+=$1} END {print s}'journalctl -k --since '1 hour ago' | grep -E 'callbacks suppressed|IN=.*OUT=' | tail -50sysctl net.core.message_cost net.core.message_burstThe kernel limits how many network-related messages it will print per unit of time so that logging cannot starve packet forwarding. When rules produce more messages than that budget allows, the extras are discarded and the kernel prints this line saying how many. Nothing went wrong with the traffic itself — only with the record of it.
Yes, exactly as many as the number in the message. Those packets were still matched and still dropped or accepted according to your rules; the kernel simply did not write them down. This matters most when you are counting: a source that appears 20 times in the log may have hit you 400 times, and the suppressed count is the only clue.
Rate-limit deliberately instead of leaving it to the kernel: add `-m limit --limit 10/minute --limit-burst 20` to your LOG rules so you get a predictable sample. For logs you actually intend to analyse, use the NFLOG target with ulogd rather than LOG — it delivers to userspace and does not compete for the kernel's printing budget. Raising net.core.message_burst is possible but trades forwarding performance for log volume.
In principle yes, and it is cheap to attempt. Generating enough throwaway traffic to saturate the limiter pushes other messages into the suppressed count, including ones that would otherwise have recorded something specific. A very large suppressed count around a time of interest, with the visible traffic being trivially generated, is worth noting rather than dismissing.
Last reviewed 7 September 2026