phaag / nfdump

Netflow processing tools
Other
789 stars 206 forks source link

issue with timestamp and src-ip/dst-ip with TOS 0: nfdump 1.6.21 (ubuntu 16.04) #260

Closed nbajpai-code closed 2 years ago

nbajpai-code commented 3 years ago

Device: Cisco NCS6K - 7.2.1 release nfdump ver: 1.6.21 host OS: ubuntu: 16.04

nfdump -a -o "fmt:%ts %td %pr %sap -> %dap %flg %tos %pkt %byt %fl" -R . Date first seen Duration Proto Src IP Addr:Port Dst IP Addr:Port Flags Tos Packets Bytes Flows 1970-01-01 00:00:00.000 0.000 UDP 192.10.101.1:49152 -> 192.10.101.0:3784 ........ 192 17 884 15 1970-01-01 00:00:00.000 0.000 TCP 2011:20..f::1002.64319 -> 2011:20..f::4a02.179 ......S. 192 1 100 1 1970-01-01 00:00:00.000 0.000 TCP 2011:20..f::4a02.179 -> 2600:40..:154:47.40484 ...A.... 192 1 80 1 1970-01-01 00:00:00.000 0.000 0 0.0.0.0:0 -> 0.0.0.0:0 ........ 0 100285 148.4 M 579 1970-01-01 00:00:00.000 0.000 UDP 192.10.101.0:49152 -> 192.10.101.1:3784 ........ 192 26 1352 25 1970-01-01 00:00:00.000 0.000 TCP 2011:20..f::1002.33692 -> 2011:20..f::4a02.179 ......S. 192 1 100 1 1970-01-01 00:00:00.000 0.000 TCP 2011:20..f::4a02.179 -> 2600:40..:154:52.22821 ...A.... 192 1 80 1 Summary: total flows: 623, total bytes: 148.4 M, total packets: 100332, avg bps: 0, avg pps: 0, avg bpp: 0 Time window: 2020-11-18 18:55:00 - 2020-11-18 22:20:00 Total flows processed: 623, Blocks skipped: 0, Bytes read: 83496 Sys: 0.002s flows/second: 311500.0 Wall: 0.000s flows/second: 1476303.3

nbajpai-code commented 3 years ago

nfcapd.zip nfcapd capture attached.

nbajpai-code commented 3 years ago

cisco-ncs6000-rel7.2.1.zip packet capture

nbajpai-code commented 3 years ago

See the issue with nfcapd.16.13 and nfdump.16.13/1.6.15

nfdump1.6.13 -a -o "fmt:%ts %td %pr %sap -> %dap %flg %tos %pkt %byt %fl" -r nfcapd.202011192111 Date first seen Duration Proto Src IP Addr:Port Dst IP Addr:Port Flags Tos Packets Bytes Flows 1970-01-01 00:00:00.000 0.000 0 0.0.0.0:0 -> 0.0.0.0:0 ...... 0 2048 3.0 M 9 Summary: total flows: 9, total bytes: 3031032, total packets: 2048, avg bps: 0, avg pps: 0, avg bpp: 0 Time window: 2020-11-19 21:11:23 - 2020-11-19 21:16:23 Total flows processed: 9, Blocks skipped: 0, Bytes read: 1244 Sys: 0.005s flows/second: 1800.0 Wall: 0.000s flows/second: 13412.8
ubuntu@vw-vta-iperf-s-2-8-1:/dev/shm/logs/amsncs01-ie$ nfdump.1.6.15 -a -o "fmt:%ts %td %pr %sap -> %dap %flg %tos %pkt %byt %fl" -r nfcapd.202011192111 Date first seen Duration Proto Src IP Addr:Port Dst IP Addr:Port Flags Tos Packets Bytes Flows 1970-01-01 00:00:00.000 0.000 0 0.0.0.0:0 -> 0.0.0.0:0 ...... 0 2048 3.0 M 9 Summary: total flows: 9, total bytes: 3031032, total packets: 2048, avg bps: 0, avg pps: 0, avg bpp: 0 Time window: 2020-11-19 21:11:23 - 2020-11-19 21:16:23 Total flows processed: 9, Blocks skipped: 0, Bytes read: 1244 Sys: 0.002s flows/second: 4500.0 Wall: 0.000s flows/second: 130434.8

phaag commented 3 years ago

Looking at your pcap, I can not identify a problem with nfdump. Your exporting device - CISCO NCS6000 does not export enough information in order to display timestamps correctly. Timestamps: Your device exports flowEndSysUpTime(21) and flowStartSysUpTime(22) which are relative time stamps - relative to system uptime. This uptime would be required - element systemInitTimeMilliseconds(160) - but it is not reported by your device.

https://tools.ietf.org/html/rfc5153 - section 4.7:

  Exporting just relative times in a device without an absolute clock
   is often not sufficient.  For instance, observed traffic could be
   retained in the device's cache for some time before being exported
   (e.g., if the Exporter runs once per minute), or stuck in an Inter
   Process Communication (IPC) queue, or stuck in the export stack, or
   delayed in the network between the Exporter and Collector.

   For these reasons, it can be difficult for the Collecting Process to
   convert the relative times exported using the flowStartSysUpTime and
   flowEndSysUpTime Information Elements to absolute times with any sort
   of accuracy without knowing the systemInitTimeMilliseconds.
   Therefore, the sending of the flowStartSysUpTime and flowEndSysUpTime
   Information Elements without also sending the
   systemInitTimeMilliseconds Information Element is not recommended.

As of src-ip/dst-ip and TOS - these element are also missing in template 275, therefore they are reported as 0

You may check with CISCO or try to export netflow v9 instead of IPFIX. Maybe that implementation is less buggy.

nbajpai-code commented 3 years ago
tos_and_date

Thanks for taking a look. v9 has date fixed but src/dst ip still 0.

nbajpai-code commented 3 years ago

Another question - Is there a way to reveal interface descriptions for v9/v10 using nfdump.

Thanks.

praines commented 3 years ago

Peter,

I am trying to drive the inclusion of Element 160.

  1. If we plan to put option 160 into a option template; not in data flow records, will that work?
  2. Today nfcapd does not decode element 160, so that will need to be added. How long would that take to make that change so we can test the potential resolution.

Thanks.

phaag commented 3 years ago

Element 160 has been add in commit b88a077 as part of the normal flow record data, as some Huawei router now export this element. This does not affect the ticket of @nbajpai-code and others. I am still open to accept element 160 as part of an option record - which would make more sense - as proposed by @praines.

phaag commented 3 years ago

@praines - If I know, how element 160 gets exported, I could implement that within a few days. If you have a working implementation, it's easiest for me, if you could send me a pcap capture, sent too the collector, containing all templates and data records, that would be helpful. If you do not want to share it publicly here @github, you find my email address in the AUTHORS file.

phaag commented 3 years ago

Another question - Is there a way to reveal interface descriptions for v9/v10 using nfdump.

Thanks.

Interface name (82) and description(83) are string values which are not supported in nfdump-1.6.x. Flexible netflow (FNF) and varlength elements are supported in upcoming nfdump-1.7.x. If you could send me an example pcap containing these elements I can push them into 1.7-beta (master.unicorn). nfdump-1.6.x will be supported also in future an small changes will be applied. The main development work will go into nfdump-1.7, which also supports threading and way faster statistics. Be aware nfdump-1.7 is not yet considered production ready, however feel free to play with.

phaag commented 3 years ago

@praines Any news on that?