Then check that NFCAPD processes are listening on ports 9996 and 9997, and also, if you've recently reconfigured your netflow sources you need to wait a bit for them to send a template packet to describe the data format they are sending. I found this can take up to 30 minutes sometimes...
On Fri, Aug 21, 2015 at 3:47 PM, Roman Mavrichev <[email protected]> wrote: > I tryed to disable rp_filter on interface, that recives flow`s, and again > use non-local ip as source, but without success. > > I can see recieved traffic: > root@msk-nms-1:/home/rmavrichev# tcpdump -i eth0.152 udp port 9996 or > 9997 or 9998 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on eth0.152, link-type EN10MB (Ethernet), capture size 65535 > bytes > 15:39:19.065175 IP 10.78.19.1.57893 > 10.77.27.12.9996: UDP, length 1416 > 15:39:20.077726 IP 10.77.19.1.61026 > 10.77.27.12.9997: UDP, length 1416 > 15:39:22.077653 IP 10.77.19.1.61026 > 10.77.27.12.9997: UDP, length 1416 > 15:39:22.657511 IP 10.77.19.3.40000 > 10.77.27.12.9998: UDP, length 1316 > 15:39:23.077736 IP 10.77.19.1.61026 > 10.77.27.12.9997: UDP, length 1416 > > rp_filter for eth0/152 is disabled: > root@msk-nms-1:/home/rmavrichev# sysctl -a | grep 152.rp_filter > net.ipv4.conf.eth0/152.rp_filter = 0 > > But nfcapd write emty files after reconfiguration: > root@msk-nms-1:/home/rmavrichev# nfdump -r > /srv/nfsen/profiles-data/live/MSK-c3945-PE1/2015/08/21/nfcapd.201508211525 > Date first seen Duration Proto Src IP Addr:Port Dst > IP Addr:Port Packets Bytes Flows > No matched flows > > Before reconfiguration, all was ok: > root@msk-nms-1:/home/rmavrichev# nfdump -r > /srv/nfsen/profiles-data/live/MSK-c3945-PE1/2015/08/21/nfcapd.201508211500 > | tail -n 10 > 2015-08-21 15:04:41.752 0.000 TCP 109.232.108.94:65083 -> > 5.45.249.59:443 1 40 1 > 2015-08-21 15:04:41.920 0.000 TCP 109.232.108.94:65086 -> > 87.250.247.193:443 1 40 1 > 2015-08-21 15:04:41.944 0.000 TCP 109.232.108.94:65085 -> > 87.250.247.193:443 1 40 1 > 2015-08-21 15:04:50.476 5.008 TCP 185.3.142.64:80 -> > 109.232.108.94:51590 17 19040 1 > 2015-08-21 15:04:50.476 5.036 TCP 185.3.142.64:80 -> > 109.232.108.94:51591 35 45774 1 > 2015-08-21 15:04:50.476 5.424 TCP 185.3.142.64:80 -> > 109.232.108.94:51593 105 149712 1 > Summary: total flows: 11241, total bytes: 75457199, total packets: 121691, > avg bps: 1692074, avg pps: 341, avg bpp: 620 > Time window: 2015-08-21 14:58:59 - 2015-08-21 15:04:55 > Total flows processed: 11241, Blocks skipped: 0, Bytes read: 719528 > Sys: 0.083s flows/second: 135410.9 Wall: 0.081s flows/second: 137120.5 > > > > > 2015-08-21 14:03 GMT+03:00 Adrian Popa <[email protected]>: > >> If your server doesn't have routes in the routing table back to the >> subnets of the source ips, then most likely the packets are dropped by >> Linux's rp_filter protection mechanism. You can disable rp_filter on all >> interfaces and see if there are any differences. >> >> On Fri, Aug 21, 2015 at 11:37 AM, Roman Mavrichev < >> [email protected]> wrote: >> >>> The are workaround exists - for example, I set up on my routers /32 >>> adresses on Loopback`s from same subnet, where nfsen located, as source for >>> netflow traffic. >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Nfsen-discuss mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/nfsen-discuss >>> >>> >> >
------------------------------------------------------------------------------
_______________________________________________ Nfsen-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nfsen-discuss
