Re: [pmacct-discussion] Multiple pmacct processes listening at similar interface

[itriA30110]

Hi Paolo,

I have to collect aglow and nflow , after consideration I assign sflow to port 
999 and nflow to port 997.

But in this thread I have a 2nd thought that I can assign both sflow and nflow 
to a single port listen by libcap app. Is this a good approach ? Any risk ,like 
packet drop?

I've seen a commercial solution that can collect all flow protocol in a single 
port , but don't how this implemented.

Sent from my ASUS

 原始郵件 
寄件者：Paolo Lucente
傳送日期：Thu, 25 Feb 2016 05:53:05 +0800
收件者：pmacct-discussion@pmacct.net
主旨:Re: [pmacct-discussion] Multiple pmacct processes listening at similar 
interface

Hi Franz,

Yes, it's no problem if, in general, two processes running libpcap
are binding to the same interface. You can in fact not only have any
two pmacctd binding there, but also a pmacctd and a tcpdump, etc.

Cheers,
Paolo

On Tue, Feb 23, 2016 at 01:23:29PM +0100, fboehm wrote:
> Hi,
>
> I couldn't find a definitive answer on the web regarding following
> situation:
>
> Is it technically ok if multiple pmacct instances listen to the same
> interface via libpcap? The interface is in promiscuous mode and is
> getting traffic via a mirrored switch-port.
>
> I like it because I don't need to restart all plugins after I
> changed the configuration of just one plugin.
>
> Until now it seems to work but I'm not sure how to check if all
> pmacct instances are processing 100% of the incoming packets. Maybe
> such a setup works but isn't described anywhere because it's
> considered too cpu demanding in high-traffic environments.
>
> Thanks,
> Franz
>
> ___
> pmacct-discussion mailing list
> http://www.pmacct.net/#mailinglists

___
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists



本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。 
This email may contain confidential information. Please do not use or disclose 
it in any way and delete it if you are not the intended recipient.___
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists

Re: [pmacct-discussion] hsflowd & sfacctd - flow generation & analysis

[Paolo Lucente]

Hi Nicolas,

Support for sFlow counters was introduced in 1.5.2 and made more robust
in 1.5.3. However consider this is interface counter stats; the host sFlow
structs is currently not supported - we can think about it if there is
interest around it. Same applies to the agent side of the things, which
was your second question.

Cheers,
Paolo


On Tue, Feb 23, 2016 at 05:47:57PM +0100, nicolas prochazka wrote:
> Hello,
> it seems that sfacctd  discards the counter sample and works only on flow
> sample,
> so host sflow ( http://www.sflow.net/ ) cannot be used with pmacct .
> 
> However, does it exist a solution to use pmacct with the host sflow agent ?
> 
> 
> Regards,
> Nicolas Prochazka

> ___
> pmacct-discussion mailing list
> http://www.pmacct.net/#mailinglists


___
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists

Re: [pmacct-discussion] Multiple pmacct processes listening at similar interface

[Paolo Lucente]

Hi Franz,

Yes, it's no problem if, in general, two processes running libpcap
are binding to the same interface. You can in fact not only have any
two pmacctd binding there, but also a pmacctd and a tcpdump, etc.

Cheers,
Paolo

On Tue, Feb 23, 2016 at 01:23:29PM +0100, fboehm wrote:
> Hi,
> 
> I couldn't find a definitive answer on the web regarding following
> situation:
> 
> Is it technically ok if multiple pmacct instances listen to the same
> interface via libpcap? The interface is in promiscuous mode and is
> getting traffic via a mirrored switch-port.
> 
> I like it because I don't need to restart all plugins after I
> changed the configuration of just one plugin.
> 
> Until now it seems to work but I'm not sure how to check if all
> pmacct instances are processing 100% of the incoming packets. Maybe
> such a setup works but isn't described anywhere because it's
> considered too cpu demanding in high-traffic environments.
> 
> Thanks,
> Franz
> 
> ___
> pmacct-discussion mailing list
> http://www.pmacct.net/#mailinglists

___
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists

Re: [pmacct-discussion] iBGP and networks_file

[Steve Dodd]

Just wanted to confirm, setting

networks_file_no_lpm: true


achieved the desired result.

Thanks,
Steve

On 2/24/16, 11:25 AM, "pmacct-discussion on behalf of Markus Weber"
 wrote:

>Hi Steve,
>
>you are using nfacctd_as_new fallback? That is said to work like "When
>'fallback' is specified, lookup is done against the winning longest
>match lookup method (sFlow/NetFlow <= BGP), which can be different for
>source and destination IP prefix.".
>
>If I understand you correctly, you want to have the networks file take
>precedence over BGP, ignoring normal longest match lookups. I remember
>Paolo stating a while ago, that this is/was not possible ... and
>fallback would have been renamed to "longest" make this clear.
>
>... Oh, OTOH, check out networks_file_no_lpm - which "Makes a matching
>IP prefix defined in a networks_file win always" (1.5.2) ... guess this
>is what you are looking for (and what I've been looking for as well ;-).
>
>Markus
>
>
>
>On 24.02.2016 16:57, Steve Dodd wrote:
>> Hi all,
>>
>> I¹m trying to address the case of iBGP learned routes showing AS0 for
>> src_as/dst_as. I have defined a list of our internal network space
>> with a mapping to our AS. However, it appears that an explicit match
>> is required IE:
>>
>> [networks.lst]
>> 65001, 10.0.0.0/8
>>
>> This would result in an appropriate src_as/dst_as mapping of 65001 for
>> 10.0.0.0/8, but not for 10.1.0.0/24.
>>
>> Is this the expected behavior?
>>
>> Thanks,
>> Steve
>>
>>
>> ___
>> pmacct-discussion mailing list
>> http://www.pmacct.net/#mailinglists
>
>
>___
>pmacct-discussion mailing list
>http://www.pmacct.net/#mailinglists



___
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists

Re: [pmacct-discussion] iBGP and networks_file

[Markus Weber]

Hi Steve,

you are using nfacctd_as_new fallback? That is said to work like "When 
'fallback' is specified, lookup is done against the winning longest 
match lookup method (sFlow/NetFlow <= BGP), which can be different for 
source and destination IP prefix.".


If I understand you correctly, you want to have the networks file take 
precedence over BGP, ignoring normal longest match lookups. I remember 
Paolo stating a while ago, that this is/was not possible ... and 
fallback would have been renamed to "longest" make this clear.


... Oh, OTOH, check out networks_file_no_lpm - which "Makes a matching 
IP prefix defined in a networks_file win always" (1.5.2) ... guess this 
is what you are looking for (and what I've been looking for as well ;-).


Markus



On 24.02.2016 16:57, Steve Dodd wrote:

Hi all,

I’m trying to address the case of iBGP learned routes showing AS0 for 
src_as/dst_as. I have defined a list of our internal network space 
with a mapping to our AS. However, it appears that an explicit match 
is required IE:


[networks.lst]
65001, 10.0.0.0/8

This would result in an appropriate src_as/dst_as mapping of 65001 for 
10.0.0.0/8, but not for 10.1.0.0/24.


Is this the expected behavior?

Thanks,
Steve


___
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists



___
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists