search

phaag / nfdump

Netflow processing tools
Other
751 stars 193 forks source link

Format time Issue of Netflow data in NFDump #542

Open richilav opened 2 days ago

richilav commented 2 days ago

Dear Mr. Haag,

Please , could you help me with the following issue found :

I have configured the following configuration to receive Netflow Data of Lab router:

NFCAPD: options='-t 120 -p 3001 -n ROUTER1,10.10.10.10,/var/cache/nfdump/dir/

NFDump: nfdump -r nfcapd.202406282128 -o csv > test.csv

I am receiving Netflow data from my router but the time formato f the following fields are`t including miliseconds: StartTime(Ts), EndTime(Te) so TimeDuration(td) field is receiving too much 0.000 seconds. Please do you know if I am missing any additional configuration to enable both fields to receive Date and Time including miliseconds time? ![Uploading Conv Convert NFdump to csv file ert NFdump to csv file.png…]()

richilav commented 2 days ago

If you can´t see the uploaded image, here you can check the nfdump output result : ts,te,td,sa,da,sp,dp,pr,flg,fwd,stos,ipkt,ibyt,opkt,obyt,in,out,sas,das,smk,dmk,dtos,dir,nh,nhb,svln,dvln,ismc,odmc,idmc,osmc,mpls1,mpls2,mpls3,mpls4,mpls5,mpls6,mpls7,mpls8,mpls9,mpls10,cl,sl,al,ra,eng,exid,tr,eth 2024-06-28 23:17:41,2024-06-28 23:17:44,3.000,128.14.118.163,38.250.154.56,443,10693,UDP,........,66,24,9,11214,0,0,435,471,21859,0,22,27,0,0,10.10.16.154,0.0.0.0,0,323,00:00:00:00:00:00,00:00:00:00:00:00,00:00:00:00:00:00,00:00:00:00:00:00,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0, 0.000, 0.000, 0.000,187.86.167.5,0/0,2,2024-06-28 23:18:00.018 ,0x0000 2024-06-28 23:17:44,2024-06-28 23:17:44,0.000,146.75.126.73,38.250.151.97,443,14549,TCP,...A....,66,0,3,3130,0,0,435,584,54113,0,22,32,0,0,10.10.34.5,0.0.0.0,0,591,00:00:00:00:00:00,00:00:00:00:00:00,00:00:00:00:00:00,00:00:00:00:00:00,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0, 0.000, 0.000, 0.000,187.86 .167.5,129/0,2,2024-06-28 23:18:00.018 ,0x0000 2024-06-28 23:17:44,2024-06-28 23:17:44,0.000,71.18.75.241,38.250.152.110,443,58727,TCP,...A....,66,16,1,70,0,0,435,436,396986,0,24,32,0,0,10.10.12.254,0.0.0.0,0,426,00:00:00:00:00:00,00:00:00:00:00:00,00:00:00:00:00:00,00:00:00:00:00:00,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0, 0.000, 0.000, 0.000,187. 86.167.5,0/0,2,2024-06-28 23:18:00.018 ,0x0000 2024-06-28 23:17:20,2024-06-28 23:17:44,24.000,38.250.159.70,200.25.46.144,8006,443,TCP,...A....,66,72,30,2524,0,0,584,414,0,7195,27,24,0,1,45.183.47.166,45.183.47.166,0,10,00:00:00:00:00:00,00:00:00:00:00:00,00:00:00:00:00:00,00:00:00:00:00:00,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0, 0.000, 0.000, 0.000,187.86.167.5,0/0,2,2024-06-28 23:18:00.018

phaag commented 1 day ago

It is true, that in the old representation ts and te are strings up to second resolution. However, the duration uses internal msec resolution. It looks to me, that your exporter only supports start and end timestamps with second resolution. All your other csv rows only have second resolution, too. You may check that with the vendor. You may also list your flows in normal line output to see if the duration is other than sec resolution. If you use the latest code from the current master repo, you can even adapt the output -o 'csv:...'