ng_netflow: request for feature
glebius at cell.sick.ru
Thu Feb 19 04:18:17 PST 2004
On Thu, Feb 19, 2004 at 02:34:02PM +0300, Andrew Riabtsev wrote:
A> GS> a port of ng_netflow has been just commited to ports
A> GS> tree. It builds both on STABLE and CURRENT, and was tested
A> GS> to work on really busy routers.
A> GS> As before, I'd be glad for any kind of feedback: ideas,
A> GS> patches and else. Thanks.
A> GS> (Also crossposted to -net).
A> Few requests:
A> 1. Is it possible to include ability in that module to turn on rule:
A> (accounted = passed) or other words (not accounted = not passed)?
In most cases the answer is no. In 90 % cases ng_netflow is used on
top of ng_ether(4) node, which passes all data coming on wire. All
packet filtering with help of ipfw or ipf are done later.
You can try some workarounds using ng_bpf(4) just between ng_netflow
and ng_tee(4), but I have not tested such configurations.
A> 2. And there is one possible vulnerability. I've tryed
A> ng_ipacct befor, as I undestand ng_netflow source code based on
A> ng_ipacct, and found the following problem. No matter how much free mem
A> has kernel soon or later all mem will be filled with "garbage" if
A> "smart" host generates the following trafic, for example:
A> 14:06:31.194057 188.8.131.52 > 184.108.40.206: icmp: echo request
A> 14:06:31.194058 220.127.116.11 > 18.104.22.168: icmp: echo request
A> 14:06:31.194059 22.214.171.124 > 126.96.36.199: icmp: echo request
A> 14:06:31.194060 188.8.131.52 > 184.108.40.206: icmp: echo request
A> 14:06:31.194061 220.127.116.11 > 18.104.22.168: icmp: echo request
A> and so on
Either you have incorrectly described the situation or you are not
right at all. The tcpdump you showed is the perfect situation
for any traffic accounting soft, because it does not generate any
new entries, it just increments byte and packet counters on one entry.
A> It could be icmp request, or tcp syn, or udp or anything else, the
A> point is to generate as much outgoing packets as it possible, sometimes it
A> does few hosts. The result is huge lag (huge accounting hash table
A> each packet going throw) and very soon box becomes unavalible to do
I am using ng_ipacct in production, and I have never faced such a
situation. May be you do not checkpoint/clear accounting database, and
it grows to a huge size during some hours? Normal checkpoint interval
is 15 minutes.
A> any tasks even routing. Is it possible to include ability to limit
A> amount of records in accounting hash table for src addr? With policy
A> (not accountes = not passed) it will protect box from this kind of
A> attacks. Limiting amount of memory used by accounting
A> table to not let it grow into huge laggy monster leads to fill with
A> "garbage" account table and no more traffic accounting till new check
A> point comes.
Such things will lead to loss of accounting data. However I have never
faced such a problem. May be your problem is a slow box itself?
I'm running ng_netflow on 5 FE interfaces that are sometimes running
at wire speed with up to 3000 simultaneous flows and I see no real
load on it. It is some Athlon XP.
Totus tuus, Glebius.
More information about the freebsd-net