On Mon, 13 Jan 2014, Paolo Lucente wrote:
> libpcap is leveraged for filtering purposes ('filter'
> keyword in pre_tag_map and 'aggregate_filter') and this is a known
> limitation (perhaps the most annoying) of libpcap-based filters.
That makes sense. Thank you for your assistance.
--
Kind regar
Hi Martin,
On Mon, Jan 13, 2014 at 02:45:25PM +0100, Martin Topholm wrote:
> On Fri, 10 Jan 2014, Paolo Lucente wrote:
>
> [ .. ]
>
> > Any chance the traffic is VLAN-tagged and/or MPLS-labelled and
> > VLAN tag and/or MPLS labels are exposed to pmacct via IPFIX? In
> > such a case you should ref
On Fri, 10 Jan 2014, Paolo Lucente wrote:
> To clarify: no traffic at all, both originated from and delivered
> to your address blocks listed, gets tagged with 612/613/712/713.
> Correct? Or some is and some is not?
Most is classified correctly, but about 7% doesn't match our filter.
tag pac
Hi Martin,
To clarify: no traffic at all, both originated from and delivered
to your address blocks listed, gets tagged with 612/613/712/713.
Correct? Or some is and some is not?
Any chance the traffic is VLAN-tagged and/or MPLS-labelled and
VLAN tag and/or MPLS labels are exposed to pmacct via I
We're trying to use nfacctd version 1.5.0rc2 to classify groups of
traffic based on ip ranges within our network. We have Juniper routers
configured with inline jflow. During a consistentcy test we discovered
some traffic was missing.
In the example below we list all our networks in a filter. We t
Hi Sven and all,
On Fri, 17 Nov 2006, Sven Anderson wrote:
>>> - First, he clearly pointed out, that flow accounting in the conntrack
>>> module makes sense _only_ if you use conntrack anyway (like firewall,
>>> NAT, ...). To use conntrack just for flow accounting would be just
>>> "overkill", he
Hi Chris and all,
Chris Wilson, 08.11.2006 08:00:
>> - First, he clearly pointed out, that flow accounting in the conntrack
>> module makes sense _only_ if you use conntrack anyway (like firewall,
>> NAT, ...). To use conntrack just for flow accounting would be just
>> "overkill", he wrote.
>
Hi Peter,
On Fri, 17 Nov 2006, Peter Nixon wrote:
>> On a side note, I'm working on scripts to provide better graphing output
>> from pmacct's database. You might like this one: top 10 local hosts by
>> bandwidth use, generated directly from the SQL database via rrdtool.
>>
>> [http://bmo.aidworl
> On a side note, I'm working on scripts to provide better graphing output
> from pmacct's database. You might like this one: top 10 local hosts by
> bandwidth use, generated directly from the SQL database via rrdtool.
>
> [http://bmo.aidworld.org/attach/Chris/pmgraph_nazarene.png]
>
> I hope to pu
Hi Paolo,
On Fri, 17 Nov 2006, Paolo Lucente wrote:
> Now your idea is much clear to my eyes. And i'm fully positive on its
> regards, agreeing with comments dropped before me by both Sven and
> Peter. Next weekend i'll gather some time to build up a SVN repository -
> astonishment and surpris
Hi Chris and all,
On Thu, Nov 16, 2006 at 08:49:17AM +0300, Chris Wilson wrote:
> What about the OS queues for packets? Were they not effective? Was pmacct
> doing a database write for each packet? (I can see how that would kill it
> very quickly).
My basic idea is to rely on the OS the less p
Hi Sven and the rest,
> > A direct flow to sql translation is a dead end no matter threads or
> no
> > threads, the database wont be able to support this.
>
> this conclusion is a bit too fast for me. What is a "direct flow to
> sql
> translation"? In my terminology, whatever is written to the
> > What works a lot better in general is removing the small flows. You
> can
> > remove about 95% of the flows by aggregating only 5% of the
> small-flow
>
>
>
> Sorry, this is not understandable. You aggregate the smallest
Sven Anderson, 16.11.2006 18:45:
> What works a lot better in general is removing the small flows. You can
> remove about 95% of the flows by aggregating only 5% of the small-flow
Sorry, this is not understandable. You aggreg
Hi Jaime and all,
Jaime Nebrera, 16.11.2006 12:39:
> A direct flow to sql translation is a dead end no matter threads or no
> threads, the database wont be able to support this.
this conclusion is a bit too fast for me. What is a "direct flow to sql
translation"? In my terminology, whatever is w
On Thu 16 Nov 2006 18:13, Sven Anderson wrote:
> Hi all,
>
> Paolo Lucente, 16.11.2006 02:03:
> > Now, back to our syncronous approach: what was killing it was the
> > excessive slowness the database and the concurrent arrival of packets at
> > very high rates. Keeping the two entities (network and
Hi all,
Paolo Lucente, 16.11.2006 02:03:
> Now, back to our syncronous approach: what was killing it was the excessive
> slowness the database and the concurrent arrival of packets at very high
> rates. Keeping the two entities (network and DB) asyncronous, segregated,
> gave a big relief and bet
Hello Chris and others,
Some prior thoughts and then some comments.
First of all, we are working with Paolo on releasing a threaded version of
pmaact. This new release wont help too much on single processors but in this
era of dual cores and ht we expect to gain some performance. We agree
Hi Paolo,
Thanks for getting back with your answers. The current behaviour makes
more sense to me now.
On Thu, 16 Nov 2006, Paolo Lucente wrote:
> In the very early days, pmacct had such a solution: just a main SQL
> process that was doing everything, receiving packets from the Core
> Process
Hi Guys,
sorry to join this - interesting, despite Peter's exagerations :-) - thread a
bit late, i'm having some terribly busy days. I want just to put a comment to
the following lines:
On Mon, Nov 13, 2006 at 09:57:09AM +0300, Chris Wilson wrote:
> I don't think it's as hard as all that. The OS
On Mon 13 Nov 2006 08:57, Chris Wilson wrote:
> Hi Peter, Paolo and all,
>
> On Sat, 11 Nov 2006, Peter Nixon wrote:
> > This is something I have discussed with Paolo on a number of occasions
> > also. I see no practical reason why pmacct cannot store all flows with
> > src and dest port and ip for
Hi Peter, Paolo and all,
On Sat, 11 Nov 2006, Peter Nixon wrote:
> This is something I have discussed with Paolo on a number of occasions
> also. I see no practical reason why pmacct cannot store all flows with
> src and dest port and ip for a low speed link (<10Mbit) yet 256K of
> traffic man
On Wed 08 Nov 2006 09:00, Chris Wilson wrote:
--snip--
> >> I'm still concerned about the performance of the MySQL plugin with
> >> threading, so I'm considering providing an option to disable the extra
> >> threads, and run updates synchronously.
> >
> > Interesting. What about having also a switc
Hi Sven,
On Tue, 7 Nov 2006, Sven Anderson wrote:
> He gave the same talk on the Linux Symposium 2005, you can find the paper
> in the proceedings:
>
> http://www.linuxsymposium.org/2005/linuxsymposium_procv2.pdf
Great, thanks for that.
> - First, he clearly pointed out, that flow accounting in
Hi Chris,
Chris Wilson, 07.11.2006 14:43:
>> Yes, traffic shaping between interfaces should be better done in kernel.
>> And i fully agree with you: doing the job twice is not great idea. So,
>> if you can see a way to, say, get the flows from libpcap and
>> classification infos from the kernel
Hi Paolo,
On Wed, 18 Oct 2006, Paolo Lucente wrote:
>> I'd be interested to know if anyone has combined layer 7 classification
>> with pmacct's traffic aggregation. For example, I would like to combine
>> all Kazaa traffic (per minute) into a single counter.
>
> It's already there, you can get a
Hi Chris,
On Wed, Oct 18, 2006 at 02:31:48PM +0100, Chris Wilson wrote:
> I'd be interested to know if anyone has combined layer 7 classification
> with pmacct's traffic aggregation. For example, I would like to combine
> all Kazaa traffic (per minute) into a single counter.
It's already there
El mié, 18-10-2006 a las 14:31 +0100, Chris Wilson escribió:
> Hi all,
>
> I'd be interested to know if anyone has combined layer 7 classification
> with pmacct's traffic aggregation. For example, I would like to combine
> all Kazaa traffic (per minute) into a single counter.
[...]
Hi Chris
Hi all,
I'd be interested to know if anyone has combined layer 7 classification
with pmacct's traffic aggregation. For example, I would like to combine
all Kazaa traffic (per minute) into a single counter.
I'm trying to figure out how this would be done, and it seems tricky.
pmacct doesn't see
Cool beans. I'm slowly getting the hang of this ...Thanks for the support ..Have you ever looked at a monitoring application called zabbix. I have configured it with pmacct to display per port traffic.. and it seem to be working quite well ...
On 7/20/06, Paolo Lucente <[EMAIL PROTECTED]> wrote:
Hi
Hi Gregory,
On Thu, Jul 20, 2006 at 03:16:11PM +0200, Gregory Machin wrote:
> But now I need to know the source and destination ip that the, of the
> packets with the applied filters ..
> How do I do this ..
The usual way. If you actually have your 'aggregation' value set to
'class', then switch
Hi I got the clasification working using the example provided, using the memory plugin..wich is cool.But now I need to know the source and destination ip that the, of the packets with the applied filters ..
How do I do this ..pmacct rocks!-- Gregory Machin[EMAIL PROTECTED]www.linuxpro.co.za
___
32 matches
Mail list logo
