phaag
Flows with a lifespan of one month or more
On one of the Cisco N9k series switches, we see a small number of flows that tstart is 50 days or an hour before.
While the Flow timeout on this switch has 10 seconds and a time interval of 10 minutes has been set for the Nefcapd.
When I sniff packets with a TCPdump, the maximum time interval of a flow is 15 seconds, and I did not observe the flow with this length of time (50 days).
For the second test, I used Manageengine and solarwind netflow analyzers, but I did not see such flows.
Thank you for letting me know if a point needs to be considered.
See below for logs captured from one of nfcapd files :
` Date first seen Duration Proto Src IP Addr:Port Dst IP Addr:Port Packets Bytes Flows 4/1/2022 45:52.2 4294967.238 GRE w.x.y.z:port -> z.y.x.w:port 12 2835 1 4/1/2022 45:52.2 4294967.22 GRE w.x.y.z:port -> z.y.x.w:port 11 4641 1 4/1/2022 47:03.0 4294967.28 TCP w.x.y.z:port -> z.y.x.w:port 61 4514 1 4/1/2022 47:03.7 4294967.264 GRE w.x.y.z:port -> z.y.x.w:port 12 8264 1 4/1/2022 47:08.1 4294967.228 GRE w.x.y.z:port -> z.y.x.w:port 17 12261 1 4/1/2022 47:31.5 4294967.264 GRE w.x.y.z:port -> z.y.x.w:port 8 6784 1 4/1/2022 47:33.8 4294966.8 GRE w.x.y.z:port -> z.y.x.w:port 58 66235 1 4/1/2022 47:51.0 4294967.243 GRE w.x.y.z:port -> z.y.x.w:port 13 7835 1 4/1/2022 48:11.6 4294967.263 TCP w.x.y.z:port -> z.y.x.w:port 117 7492 1 4/1/2022 48:17.4 4294967.232 GRE w.x.y.z:port -> z.y.x.w:port 14 7493 1 4/1/2022 48:32.0 4294967.252 GRE w.x.y.z:port -> z.y.x.w:port 5 4072 1 4/1/2022 48:39.2 4294967.017 GRE w.x.y.z:port -> z.y.x.w:port 13 4139 1 4/1/2022 49:02.5 4294966.796 GRE w.x.y.z:port -> z.y.x.w:port 5 2706 1 4/1/2022 49:02.6 4294967.279 TCP w.x.y.z:port -> z.y.x.w:port 60 4440 1 4/1/2022 49:09.4 4294967.211 GRE w.x.y.z:port -> z.y.x.w:port 16 7533 1 4/1/2022 49:39.8 4294967.272 GRE w.x.y.z:port -> z.y.x.w:port 4 3402 1 5/21/2022 38:40.0 4194.234 GRE w.x.y.z:port -> z.y.x.w:port 3 812 1 5/21/2022 38:45.7 4194.17 GRE w.x.y.z:port -> z.y.x.w:port 3 445 1 5/21/2022 38:46.3 4194.226 GRE w.x.y.z:port -> z.y.x.w:port 2 231 1 5/21/2022 38:46.5 4194.302 GRE w.x.y.z:port -> z.y.x.w:port 2 497 1 5/21/2022 38:46.6 4194.179 GRE w.x.y.z:port -> z.y.x.w:port 4 422 1 5/21/2022 38:51.5 4194.067 GRE w.x.y.z:port -> z.y.x.w:port 8 1051 1 5/21/2022 38:57.5 4194.303 GRE w.x.y.z:port -> z.y.x.w:port 3 504 1 5/21/2022 39:06.5 4194.298 GRE w.x.y.z:port -> z.y.x.w:port 2 1252 1 5/21/2022 39:06.8 4194.05 GRE w.x.y.z:port -> z.y.x.w:port 6 1094 1 5/21/2022 39:22.1 4194.076 GRE w.x.y.z:port -> z.y.x.w:port 2 347 1 5/21/2022 39:26.4 4193.739 GRE w.x.y.z:port -> z.y.x.w:port 4 790 1 5/21/2022 39:42.5 4194.298 TCP w.x.y.z:port -> z.y.x.w:port 20 1284 1 5/21/2022 39:55.4 4193.923 GRE w.x.y.z:port -> z.y.x.w:port 3 550 1 5/21/2022 39:55.7 4194.299 GRE w.x.y.z:port -> z.y.x.w:port 2 342 1 5/21/2022 39:56.1 4194.24 GRE w.x.y.z:port -> z.y.x.w:port 3 256 1 5/21/2022 39:56.3 4194.255 GRE w.x.y.z:port -> z.y.x.w:port 3 302 1 5/21/2022 39:57.2 4194.067 GRE w.x.y.z:port -> z.y.x.w:port 2 136 1 5/21/2022 40:06.3 4194.218 GRE w.x.y.z:port -> z.y.x.w:port 6 865 1 5/21/2022 40:11.9 4194.299 GRE w.x.y.z:port -> z.y.x.w:port 3 838 1 5/21/2022 40:12.5 4194.284 GRE w.x.y.z:port -> z.y.x.w:port 4 822 1 5/21/2022 40:12.7 4194.296 GRE w.x.y.z:port -> z.y.x.w:port 2 222 1 5/21/2022 40:20.7 4194.226 GRE w.x.y.z:port -> z.y.x.w:port 7 1512 1 5/21/2022 40:25.1 4193.801 GRE w.x.y.z:port -> z.y.x.w:port 4 513 1 5/21/2022 40:35.3 4194.232 GRE w.x.y.z:port -> z.y.x.w:port 4 348 1 5/21/2022 40:43.1 4194.3 TCP w.x.y.z:port -> z.y.x.w:port 14 926 1 5/21/2022 41:06.5 4194.301 GRE w.x.y.z:port -> z.y.x.w:port 3 353 1
`
The nfcapd config is :
ExecStart=/usr/local/bin/nfcapd -w -D -p 9996 -z -B 1073741824 -t 600 -T -1,-2,+13 -I Chavoosh-NetFlow -P /var/run/nfcapd.pid -l /home/data/netflow/
Best Regards, Hamed Haghshenas
Actually nfcapd does no magic. It collects, what is sent by the exporter. In order to understand, why you have such long lifetimes, I would need a pcapd which you capture at nfcapd collectors port, so I can see what is sent to nfcapd. If you can do this, pls send it to the email in the AUTHORS file. Otherwise, it's very hard to debug.
Hello, I send pcapd and nfcapd files from my network to AUTHORS Email. I appreciate it if check it...
According the data you sent I must assume, that your exporter is sending wrong data. The exporter uses tags 21,22 in order to send start/end time. These are relative miliseconds since boot. Together with the header fields SysUpTime and UNIX_SECs the final time can be calculated. So far the theory. The size of these tags 21,22 are 32bits, which means they may overflow. The overflow occurs after 49 days. This results in tStart > tEnd. In that case this overflow is recognised automatically by the collector and adjusted accordingly, to get the correct values. All these flows with incorrect duration have tStart > tEnd and are internally corrected, which is why this large duration occurs. The difference is however, relative small 0.039 seconds which is unusual, if a true overflow occurs. Given, that the SysUpTime of the device was Tue, Apr 12 20:00:02 (my Timezone) an overflow can not have happened. There are every now and then some unmotivated tStart > tEnd, which then result in duration time > 49 days. => This is a bug in the exporter. You can check this in your pcap - Packet 14021 contains the templates, and packet 14088 flow data. Record 20 in this flow data is wrong - the flows before and after are correct. Given the more or less continually increasing tStart of all flows allow compare these rel. tags 21,22. If you want to experiment yourself, I can send you back a tiny pcap which just those extracted packet which you can replay to the collector.
Using tag 160 wires now correctly the sysuptime with first/last tags 21/22. Your pcaps are now correct decode using the latest master repo code.