Hi Paolo,
The Ubiquiti fork of Vyatta is using an old version of pmacct (0.12.5), so
I'm in the process of updating it to 1.5rc1. In testing the new code I've
noticed some differences in the plugin_pipe_size that I'm using. With the
following config:
vbash-4.1$ cat uacctd-i.conf
!
!
Ok, false alarm. I did some more debugging and noticed one difference
between the old version and the current version is that both pipe_size and
buffer_size have changed from int to u_int64_t. So if I change the log
messages to:
--- a/src/sfprobe_plugin/sfprobe_plugin.c
+++
Hi Stig,
Great to hear from you, long time no speak. You just anticipated
me :) That was precisely the issue and is already patched in CVS.
Cheers,
Paolo
On Wed, Nov 20, 2013 at 02:40:57PM -0800, Stig Thormodsrud wrote:
Ok, false alarm. I did some more debugging and noticed one difference
Great to hear from you again too Paolo. I knew I should've checked if you
had fixed it already.
Anyway another issue I'm looking into. I don't think this is a new issue
because there was a bug open for it back at Vyatta (
https://bugzilla.vyatta.com/show_bug.cgi?id=7693). Basically if I'm
Hi,
I have an interesting issue that I think perhaps results from a perhaps
unique configuration.
I have a very simple nfacctd setup on one box, its goal would be to
receive ipfix data from two sources (Juniper MX) and replicate it out to
a few places.
The configuration is -very- simple:
A useful piece of information would be that I'm running version 1.5.0rc1.
-Adam
On 11/20/13, 10:05 PM, Adam Jacob Muller wrote:
Hi,
I have an interesting issue that I think perhaps results from a
perhaps unique configuration.
I have a very simple nfacctd setup on one box, its goal would be
Hi Adam,
I'm guessing you've already thought of this, but is it at all possible that one
of the destinations you're tee-ing the packets to (e.f.g.h) is then feeding it
back (to a.b.c.d)?
Thanks,
Nathan.
-Original Message-
From: pmacct-discussion
Hi,
That was actually one of my first thoughts. But my topology is extremely
simple here and I only see the excess traffic on the replicator server
from server-network, not network-server, which I would expect in the
case of a loop.
The single collector in this case is another nfacctd
Gentoo and 64-bit.
Compiled from sources that I just downloaded.
I just downloaded 0.14.3 to test, and so far 0.14.3 appears to work
correctly (so far, running for about 10m).
With a single odd exception, 0.14.3 refused to start because:
mmap(NULL, 18446744072050714384,
To continue,
The instance of nfacctd that I said had no issues and was getting
netflow data just had the same behavior.
This instance was running without the buffer/pipe sizes, it handles a
proportionally smaller amount of traffic (probably an order of
magnitude) so perhaps just took longer
10 matches
Mail list logo
