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

2016-02-27 Thread itriA30110
Hi Paolo, Is there potential risk, such as packet lost to implement a daemon (or modify pmacct) listen to both Netflow and sflow and split them? Libcap is known of packet drop when CPU low (I might be wrong for that community keep improving). Sent from my ASUS 原始郵件 寄件者:Paolo

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

2016-02-27 Thread fboehm
Am 27.02.2016 um 13:06 schrieb itria30...@itri.org.tw: Is there potential risk, such as packet lost to implement a daemon (or modify pmacct) listen to both Netflow and sflow and split them? Libcap is known of packet drop when CPU low (I might be wrong for that community keep improving). I think

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

2016-02-27 Thread itriA30110
My coworker, an IT guy in operation team, once proposed to set all router, including sflow and nflow equipments, to a single port on a single collector. In the end we setup sfacctd listen on a port and nfacctd on the other. But I am wondering if it's possible to fulfill previous requirement? T

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

2016-02-27 Thread fboehm
Am 27.02.2016 um 17:08 schrieb itria30...@itri.org.tw: > In the end we setup sfacctd listen on a port and nfacctd on the other. But I > am wondering if it's possible to fulfill previous requirement? This feature > is useful for ease (a little bit) of router setting. This would only work if you

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

2016-02-27 Thread itriA30110
I think UPD proxy will work , cause I have ever observed that sfacctd skipped nflow packet and only record sflow packets if all routers send to the same collector same port. (but you'll see a lot of 'parsing header...not a sflow packet' similar errors in log) A even better way is to implement a