Hi TC, I would simply not recommend to run both sFlow and NetFlow on the same port; the only way possible is the one you mention in your last email: use a replicator to feed the actual daemons; but it seems too involved to me if you do not have strong reasons for it (technical limitations or corporate bureaucracy to overcome).
Cheers, Paolo On Sat, Feb 27, 2016 at 04:47:14PM +0000, itria30...@itri.org.tw wrote: > 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 daemon that parse flow packets, send them > to sfacctd or nfacctd separately. It sounds not difficult but one needs to > understand every kind of flow packet frame structure. > ________________________________________ > ?q: pmacct-discussion <pmacct-discussion-boun...@pmacct.net> ?N?? fboehm > <fbo...@aon.at> > ?H??????: 2016?~02??28?? 00:22 > ??: pmacct-discussion@pmacct.net > ?D??: Re: [pmacct-discussion] ?^??: Multiple pmacct processes listening at > similar interface > > 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 are running a software that is aware of > netflow AND sflow packets. > > But you are trying to run two separate processes (nfacctd + sfacctd) on > a similar UDP port. The first process will open the port and will > receive the UDP packets. The second process won't be able to open the > same port again and will terminate. > > Maybe you can find a UDP proxy tool that creates a virtual network > interface and duplicates all the traffic towards two separate ports on a > virtual network interface (tun0). > > It wouldn't be very difficult to write such a tool but it would > definitely be more work than a router configuration and would introduce > new potential problems :) > > Franz > > _______________________________________________ > pmacct-discussion mailing list > http://www.pmacct.net/#mailinglists > > ==================================================================== > ???H???i???]?t?u???|???K???T?A?D???w?????????A?????????????S???H?????e?A?????P?????H???C > > 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 _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
