10 May
2017
10 May
'17
12:18 p.m.
Tcpdump collection takes place off the raw interface, BEFORE any packets
are blocked, so the amount of blocking doesn't affect the sample.
Unfortunately, tcpdump doesn't have a 'run for N seconds then exit'
option. I can do it manually but that ruins the automation.
Still, you're probably right about the threshold being too low.
Right now the received packet rate is about 25 MB/s, which is a little
high for normal, but not unusual. So I'm going to turn off the blocking
(which won't affect the received rate as again it's sampled before the
blocking) and we'll see how the router program statistics fare.
Thanks!
- Brian
On Wed, May 10, 2017 at 10:03:10AM -0700, Tom Hayward wrote:
Worse, in periods of lower traffic, it will take
longer to collect
100000000 packets, so the allowed pps goes down. If 1000 packets per
287 seconds is the new threshold, hosts sending 3.5pps (max 5 KB/s)
through amprgw will be blocked. This is a fatal flaw in the system
because it can cause runaway--the more hosts blocked, the longer it
will take to collect 100 million packets, continually decreasing the
allowed pps.
Surely there will be some false positives with this threshold.