I'm currently working on the Debian packaging of nfdump. One sideeffect of switching to modern packaging helper is the testsuite (make check) being run by default. The testsuite always fails with this error

make  check-TESTS
make[4]: Entering directory '/build/nfdump-1.6.15/bin'
make[5]: Entering directory '/build/nfdump-1.6.15/bin'
PASS: nftest
FAIL: test.sh
=======================================
   nfdump 1.6.15: bin/test-suite.log
=======================================

# TOTAL: 2
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: test.sh
=============

IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv6 32bit packets 32bit bytes
IPv6 32bit packets 32bit bytes
IPv6 32bit packets 64bit bytes
IPv6 64bit packets 32bit bytes
IPv6 64bit packets 64bit bytes
IPv4 32bit packets 64bit bytes
IPv4 64bit packets 32bit bytes
IPv4 64bit packets 64bit bytes
4 bytes interfaces, 2 bytes AS numbers 24 25
2 bytes interfaces, 4 bytes AS numbers 25 27
4 bytes interfaces, 4 bytes AS numbers 26 29
diff: nfdump.test.out: No such file or directory
FAIL test.sh (exit status: 2)

============================================================================
Testsuite summary for nfdump 1.6.15
============================================================================
# TOTAL: 2
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See bin/test-suite.log
Please report to [email protected]
============================================================================

I had a look at bin/test.sh and I'm confused how this is supposed to work. As far as I can see nfgen generates some netflow, then it gets processed by nfdump and the output of multiple, different nfdump invocations is compared to a file nfdump.test.out that is neither shipped nor generated anywhere.

Is this testsuite supposed to work?

nfdump do not work with netflow v9 data from Fortigate. Byte and packet counters get all messed up.

Decoded by my perl script
Date first seen Duration Src-IP-addr SPort Dst-IP-addr DPort In Bytes Pkts
2016-11-23 13:57:41.960 0.000 130.240.95.1 48499 130.240.19.2 53 72 1
2016-11-23 13:57:41.960 0.000 130.240.152.246 21290 130.240.19.2 53 65 1
2016-11-23 13:57:41.970 0.000 130.240.156.73 58537 130.240.19.2 53 60 1
2016-11-23 13:57:41.940 0.020 130.240.6.26 49224 130.240.19.2 53 82 1
2016-11-23 13:57:41.970 0.000 130.240.202.178 44850 130.240.19.2 53 62 1
2016-11-23 13:57:41.970 0.000 130.240.172.108 63854 130.240.19.2 53 59 1
2016-11-23 13:57:41.970 0.000 130.240.172.108 50060 130.240.19.2 53 59 1
2016-11-23 13:57:41.960 0.000 130.240.42.11 47570 130.240.19.2 53 59 1
2016-11-23 13:57:41.980 0.000 130.240.202.178 45483 130.240.19.2 53 62 1
2016-11-23 13:56:29.210 72.750 130.240.12.154 58343 130.240.19.2 53 126 2
2016-11-23 13:57:41.950 0.000 130.240.12.154 37369 130.240.19.2 53 72 1
2016-11-23 13:57:41.950 0.000 130.240.202.178 58584 130.240.19.2 53 62 1
2016-11-23 13:57:41.950 0.000 130.240.172.108 62289 130.240.19.2 53 59 1
2016-11-23 13:57:41.950 0.000 130.240.172.108 62086 130.240.19.2 53 59 1
2016-11-23 13:57:41.950 0.000 130.240.109.136 64881 130.240.19.2 53 65 1

Decoded by nfdump: Version: 1.6.15
Date first seen Duration Proto Src IP Addr:Port Dst IP Addr:Port Packets Bytes Flows
2016-11-23 13:57:41.960 0.000 UDP 130.240.95.1:48499 -> 130.240.19.2:53 22916 1.6 M 1
2016-11-23 13:57:41.960 0.000 UDP 130.240.152.246:21290 -> 130.240.19.2:53 22916 1.5 M 1
2016-11-23 13:57:41.970 0.000 UDP 130.240.156.73:58537 -> 130.240.19.2:53 22916 1.4 M 1
2016-11-23 13:57:41.940 0.020 UDP 130.240.6.26:49224 -> 130.240.19.2:53 22916 1.9 M 1
2016-11-23 13:57:41.970 0.000 UDP 130.240.202.178:44850 -> 130.240.19.2:53 22916 1.4 M 1
2016-11-23 13:57:41.970 0.000 UDP 130.240.172.108:63854 -> 130.240.19.2:53 22916 1.4 M 1
2016-11-23 13:57:41.970 0.000 UDP 130.240.172.108:50060 -> 130.240.19.2:53 22916 1.4 M 1
2016-11-23 13:57:41.960 0.000 UDP 130.240.42.11:47570 -> 130.240.19.2:53 22916 1.4 M 1
2016-11-23 13:57:41.980 0.000 UDP 130.240.202.178:45483 -> 130.240.19.2:53 22916 1.4 M 1
2016-11-23 13:56:29.210 72.750 UDP 130.240.12.154:58343 -> 130.240.19.2:53 45832 2.9 M 1
2016-11-23 13:57:41.950 0.000 UDP 130.240.12.154:37369 -> 130.240.19.2:53 22916 1.6 M 1
2016-11-23 13:57:41.950 0.000 UDP 130.240.202.178:58584 -> 130.240.19.2:53 22916 1.4 M 1
mypcap.zip
mypcap.zip
2016-11-23 13:57:41.950 0.000 UDP 130.240.172.108:62289 -> 130.240.19.2:53 22916 1.4 M 1
2016-11-23 13:57:41.950 0.000 UDP 130.240.172.108:62086 -> 130.240.19.2:53 22916 1.4 M 1
2016-11-23 13:57:41.950 0.000 UDP 130.240.109.136:64881 -> 130.240.19.2:53 22916 1.5 M 1

pcap file and debug decoding of the pcap file by my perl script in attached file.

nfcapd cant handle the 8*8bit, 64 bit uint from Fortigate for "Field Type 1" and "23" correct so the couter values is wrong. Its also saves the data wrong on disk so if one uses nfreplay the values sent out are faulty.

Below is the output I get with the exact same flow in Cisco and Fortigate. The only difference is that Fortigate uses 64 bit counters for bytes.

Fortigate

./nfdump -o raw -R /mnt/netflows-fgc/2016/03/18/13/nfcapd.201603181300 "not src net 130.240/16 and src host 77.218.251.180 and dst host 130.240.19.2 and port 1144"

Flow Record:
Flags = 0x86 FLOW, Sampled
export sysid = 1
size = 60
first = 1458304467 [2016-03-18 13:34:27]
last = 1458304467 [2016-03-18 13:34:27]
msec_first = 960
msec_last = 960
src addr = 77.218.251.180
dst addr = 130.240.19.2
src port = 1144
dst port = 53
fwd status = 64
tcp flags = 0x00 ......
proto = 17 UDP
(src)tos = 0
(in)packets = 6963
(in)bytes = 752004
input = 50
output = 89

Summary: total flows: 1, total bytes: 752004, total packets: 6963, avg bps: 0, avg pps: 0, avg bpp: 0
Time window: 2016-02-02 14:37:50 - 2016-03-18 13:59:59
Total flows processed: 4612764, Blocks skipped: 0, Bytes read: 278971320
Sys: 1.385s flows/second: 3328619.3 Wall: 2.240s flows/second: 2058970.9

Cisco

./nfdump -o raw -R /mnt/netflows/2016/03/18/13/nfcapd.201603181300 "not src net 130.240/16 and src host 77.218.251.180 and dst host 130.240.19.2 and port 1144"

Flow Record:
Flags = 0x06 FLOW, Unsampled
export sysid = 4
size = 60
first = 1458304468 [2016-03-18 13:34:28]
last = 1458304468 [2016-03-18 13:34:28]
msec_first = 506
msec_last = 506
src addr = 77.218.251.180
dst addr = 130.240.19.2
src port = 1144
dst port = 53
fwd status = 0
tcp flags = 0x00 ......
proto = 17 UDP
(src)tos = 0
(in)packets = 1
(in)bytes = 108
input = 155
output = 541

Summary: total flows: 1, total bytes: 108, total packets: 1, avg bps: 0, avg pps: 0, avg bpp: 0
Time window: 2016-03-18 12:27:53 - 2016-03-18 13:59:57
Total flows processed: 4962501, Blocks skipped: 0, Bytes read: 300312984
Sys: 2.209s flows/second: 2245818.0 Wall: 3.816s flows/second: 1300159.2

Ex. Template Cisco
Sender = 533 FlowSetID = 0 Length = 84
Template ID = 256 Field count = 19
Field Type = 21 , Field Length = 4
Field Type = 22 , Field Length = 4
Field Type = 1 , Field Length = 4
Field Type = 2 , Field Length = 4
Field Type = 10 , Field Length = 2
Field Type = 14 , Field Length = 2
Field Type = 8 , Field Length = 4
Field Type = 12 , Field Length = 4
Field Type = 4 , Field Length = 1
Field Type = 5 , Field Length = 1
Field Type = 7 , Field Length = 2
Field Type = 11 , Field Length = 2
Field Type = 48 , Field Length = 1
Field Type = 51 , Field Length = 1
Field Type = 15 , Field Length = 4
Field Type = 13 , Field Length = 1
Field Type = 9 , Field Length = 1
Field Type = 6 , Field Length = 1
Field Type = 61 , Field Length = 1

Ex. Template Fortigate
Sender = 1 FlowSetID = 0 Length = 972
Template ID = 257 Field count = 17
Field Type = 1 , Field Length = 8
Field Type = 23 , Field Length = 8
Field Type = 2 , Field Length = 4
Field Type = 24 , Field Length = 4
Field Type = 22 , Field Length = 4
Field Type = 21 , Field Length = 4
Field Type = 7 , Field Length = 2
Field Type = 11 , Field Length = 2
Field Type = 10 , Field Length = 2
Field Type = 14 , Field Length = 2
Field Type = 4 , Field Length = 1
Field Type = 95 , Field Length = 4
Field Type = 65 , Field Length = 2
Field Type = 89 , Field Length = 1
Field Type = 136 , Field Length = 1
Field Type = 8 , Field Length = 4
Field Type = 12 , Field Length = 4

Hi all,

Great tool. Much appreciate.

Is there a possibility for nfdump to produce JSON output after reading pcap files?

This will be good for sending output to for example Elasticsearch.

Cheers

Hi,
I would like to use the SOF-ELK VM (https://github.com/philhagen/sof-elk/blob/master/VM_README.md) to analyse an archived pcap (acquired from another source). SOF-ELK use nfdump to parse netflow as input to logstash but I am interested into parsing pcap's.

I didn't manage to read any pcap with nfdump (bad magic: 0xC3D4) nor nfpcapd (1KB outputfile without any data in it) - see printscreen: and 1KB output file from nfpcapd (renamed .txt to be able to upload it): nfcapd.201703161358.txt
I understand that nfdump handles netflow's and no pcap's but I think that nfpcapd was design to do it.

I didn't find documentation on nfpcapd utility (well on nfdump en nfcapd) and I do not understand what is the problem ...
If you could recommend me with a another way to parse pcap in order to pass it to logstash instead of nfpcapd, it is also good for me.

Thank you in advance,

Kame

This is collected by nfcapd from Cisco ASR (ios-xr 5.1.3) with netflow v9.

nfcapd -w -D -p 9992 -u www -g www -B 400000 -S 1 -P /usr/local/var/nfsen/run/p9992.pid -T all -I sdn-core2 -l /usr/local/var/nfsen/profiles-data/live/sdn-core2

RAW:

Flow Record:
  Flags        =              0x06 FLOW, Unsampled
  export sysid =                 1
  size         =                96
  first        =        1445692480 [2015-10-24 16:14:40]
  last         =        1445692480 [2015-10-24 16:14:40]
  msec_first   =               424
  msec_last    =               424
  src addr     =       151.80.4.33
  dst addr     =       185.44.13.7
  src port     =              9322
  dst port     =             54303
  fwd status   =               195
  tcp flags    =              0x04 ...R..
  proto        =                 6 TCP
  (src)tos     =                 0
  (in)packets  =                 2
  (in)bytes    =                80
  input        =                10
  output       =                 0
  src mask     =                16 151.80.0.0/16
  dst mask     =                32 185.44.13.7/32
  dst tos      =                 0
  direction    =                 0
  bgp next hop =           0.0.0.0
  ip router    =       10.12.0.102
  engine type  =                 0
  engine ID    =                 0
  next as      =                 0
  prev as      =              9002
  received at  =     1445692500393 [2015-10-24 16:15:00.393]

But when "%sas" or "%das" used, they always 0:

nfdump -o "fmt:%ts %td %pr %sap %sas -> %das %dap %flg %tos %pkt %byt %fl" -r nfcapd.201510241615

2015-10-24 16:19:29.520     2.024 TCP   2a02:20..00::7:2.179        0 ->      0 2a02:20..00::7:1.46309 .AP... 192        2      139     1
2015-10-24 16:19:29.721     1.624 TCP   2a02:20..00::7:1.46309      0 ->      0 2a02:20..00::7:2.179   .AP... 192        2      139     1
2015-10-24 16:19:31.122     7.802 TCP   2a02:20..00::6:1.45426      0 ->      0 2a02:20..00::6:2.179   .AP... 192        2      139     1
2015-10-24 16:19:31.322     7.401 TCP   2a02:20..00::6:2.179        0 ->      0 2a02:20..00::6:1.45426 .AP... 192        2      139     1
2015-10-24 16:19:38.222     0.000 TCP      31.177.85.241:179        0 ->      0    185.44.12.255:63928 .AP... 192        1       59     1
2015-10-24 16:19:38.352     0.000 TCP      185.44.12.255:63928      0 ->      0    31.177.85.241:179   .A.... 192        1       40     1
2015-10-24 16:19:39.764     0.000 TCP        151.80.4.33:9322       0 ->      0      185.44.13.7:22540 ...R..   0        2       80     1
2015-10-24 16:19:42.614     0.000 TCP      31.177.85.166:179        0 ->      0    31.177.85.167:54077 .AP... 192        1       59     1
2015-10-24 16:19:42.814     0.000 TCP      31.177.85.167:54077      0 ->      0    31.177.85.166:179   .A.... 192        1       40     1

Hello,

I found significant memory leaks in OpenNewFile() (/bin/nffile.c) function when it is not possible to create a new file (for example, creating the file in a directory without permission). The problem is probably caused by unfreed structure "nffile" for the file.

Lukas

Hi,

I have found a memory leak in nfpcapd.

My dedicated server has 32GB RAM and the memory just goes up and up constantly.
I have written a small Script to kill nfpcapd, set swapoff, swapon and free all memory.

Version: latest.

Regards,
Nils

RADB route origin is not accurate at times. It would be nice to implement something for actual IP to ASN lookup, from a BGP dump (mtr/json)/file/DNS.

some alternative sources

• RIPEstat API
• https://www.team-cymru.org/IP-ASN-mapping.html
• http://www.routeviews.org/ (DNS lookup available)

Hi All,

We deployed a VMware cloud and we're trying to get some netflows out of the distributed switches. Oddly, one flow is showing huge ammounts of "other" traffic. Date values are also wrong. Both flows are coming from different distributed switches (same product level on both distributed switches) and all flows are being processed by one collector.
Total traffic values should be below 50 Mbits/s
Collector is an Ubuntu 14.04 with NFDUMP downloaded from repos and NFSEN (1.36p1)
VMware support team are clueless:

** nfdump -M /data/nfsen/profiles-data/live/f36-dc-LAN -T -r 2016/06/29/nfcapd.201606291245 -n 10 -s record/flows -B
nfdump filter:
any
Command line switch -s overwrites -a
Aggregated flows 17394
Top 10 flows ordered by flows:
Date flow start Duration Proto Src IP Addr:Port Dst IP Addr:Port Out Pkt In Pkt Out Byte In Byte Flows
1970-01-01 01:00:00.227 1344324763.421 0 0.0.0.0:0 <-> 0.0.0.1:341 0 38402 0 5105345.4 T 407
1971-08-20 13:33:27.552 4105988734.976 0 0.0.0.0:4353 <-> 0.0.0.0:0 0 69.4 T 0 407937.1 T 110
1971-07-01 20:30:40.256 3036541878.272 0 0.0.0.0:1537 <-> 0.0.0.0:4352 0 60.5 T 0 16287453.3 T 95
1971-08-20 13:33:27.552 3384434229.248 0 0.0.0.0:1537 <-> 0.0.0.0:4096 0 60.0 T 0 14569041.8 T 85
1971-10-09 06:36:14.848 3362959392.768 0 0.0.0.0:1537 <-> 0.0.0.0:512 0 60.9 T 0 15175234.0 T 67
1970-01-01 01:00:00.001 1467200863.999 0 64.1.0.1:2610 <-> 0.2.0.0:16123 0 5.5 G 0 61.2 T 55
1976-05-25 10:11:02.912 1627792605.184 0 0.0.0.0:1537 <-> 0.0.0.0:4608 0 25.0 T 0 4540379.5 T 48
1970-07-18 21:11:09.184 2993592205.312 0 0.0.0.0:1537 <-> 0.0.0.0:6144 0 28.6 T 0 14920364.8 T 44
1971-02-02 17:22:18.595 1224065679.133 0 0.0.0.0:0 <-> 0.0.0.2:341 0 8731 0 9425483.0 T 44
1970-01-01 01:00:00.001 1467200862.999 0 64.1.0.1:2610 <-> 0.2.0.0:65090 0 6.2 G 0 2.9 T 43
Summary: total flows: 54777, total bytes: 18316413.7 T, total packets: 7215088.0 T, avg bps: 4.1 G, avg pps: 1.7 G, avg bpp: 2
Time window: Time Window unknown
Total flows processed: 54777, Blocks skipped: 0, Bytes read: 3507444
Sys: 0.041s flows/second: 1321360.5 Wall: 0.040s flows/second: 1369288.1

Please, let me know if you need more data.

Thank you in advance.

Dear All,
I have problem as below. If anyone can fix, please share your experience
I can't get any sflow from DELL switch, sfcapd has 276 bytes size
Firmware: Dell Networking N4064, 6.2.6.6, Linux 3.7.10-8c2e3085,
Dell 48 Port 10GBaseT Ethernet
2 Switches Stack together, Switch IP: 172.16.15.1

sFlow in Switch
Clock time is exact
Console(config)#sflow 1 destination 172.16.15.9 2055
Console(config)#sflow 1 destination owner Flow1 timeout 2000000000
Console(config)#sflow 1 polling tengigabitethernet 1/0/47-1/0/48 30
Console(config)#sflow 1 polling tengigabitethernet 2/0/47-2/0/48 30
(I don't enter any sampling command as: sflow 1 sampling tengigabitethernet ...)

sfcapd CMD:
/usr/local/bin/sfcapd -w -D -p 2055 -u test -g apache -B 10240000 -S 1 -P /var/run/p2055.pid -z -T +6,+10,+12,+13,+14,+33 -t 300 -I sFlow -l /test/profiles-data/live/sFlow

tcpdump: can see packet from DELL Switch
15:27:39.370014 IP 172.16.15.1.sflow > 172.16.15.9.iop: sFlowv5, IPv4 agent 172.16.15.1, agent-id 3, length 748

WireShark

Notes: another test
hsflowd Linux sends sFlow to sfcapd: successful
use PRTG or sFlowTrend-pro can NOT get sflow from DELL switch

man nfdump | grep " -O"
-O order
-O orderby

In a standard unidirectional netflow, for traffic from "src" to "dst", the counters are stored in

                table->packets
                table->bytes

Then to support bi-directional flows, there are these extensions for "dst" to "src":

                table->out_packets // Extension EX_OUT_PKG_4/8
                table->out_bytes   // Extension EX_OUT_BYTES_4/8 

Therefore "src" to "dst" is considered as "in", and "dst" to "src" is considered as "out". I believe this is the opposite to how most people would think of it.

This becomes confusing when dealing with devices which do actually generate bi-directional flows.

• In the case of Cisco ASA NSEL, it gives NF_F_FWD_FLOW_DELTA_BYTES and NF_F_REV_FLOW_DELTA_BYTES. FWD refers to the "src" to "dst" direction, and REV to the "dst" to "src" direction. But these are stored as "in" and "out" respectively by nfdump.

  The result is: when you are looking at flows for (e.g.) a user connecting to a webserver, and looking separately at "ibytes" and "obytes", the outbound request is counted as "ibytes" and the downloaded traffic from webserver to user is counted as "obytes".

• Netflow version 9 has NF9_IN_BYTES and NF9_OUT_BYTES. I don't have a source to test these with, but I would expect "OUT" refers to the src to dst direction. (Need to check whether unidirectional flows set NF9_OUT_BYTES only)

To make this consistent, and assuming people would be happier with src to dst being "out" rather than "in" I have some suggestions:

1. Rather than swapping "in" and "out" throughout nfdump, maybe rename them to "fwd" and "rev" respectively. The default, for unidirectional flows, is "fwd".
2. Then change the aggregate query types like "ibytes" and "obytes" to use "rev" and "fwd" respectively. This would be change of behaviour (results swapped around compared to before); however people who use unidirectional flows and who query just "bytes" would be unaffected, now that #28 has been merged.
3. Check that when you use nfdump itself to synthesise bidirectional flows, it gets fwd and rev the right way round (I suspect it does already)
4. Store NF9_IN_BYTES as "rev" and NF9_OUT_BYTES as "fwd". This is unfortunately a swap and means that historical data will not be compatible. I don't see a way to avoid that.

I'm currently working with mpls traffic where a flow is identified by 2 labels (mpls label 1 and mpls label 2).
When I do a "nfdump -R nfcapd.201602180755:nfcapd.current.22662 -o "fmt:%ts %mpls 1 %mpls2 - %pr %bps %pkt %byt %fl"" can see the corresponding labels in each flow:

user@ubuntu15:/user/router1$ sudo nfdump -R nfcapd.201602180755:nfcapd.current.22662 -o "fmt:%ts %mpls1 %mpls2 - %pr %bps %pkt %byt %fl"
Date first seen          MPLS lbl 1   MPLS lbl 2    Proto      bps  Packets    Bytes Flows
2016-02-18 04:53:59.883    16005-0-0   130931-0-1 -     0    1.4 G   22.7 M   11.2 G     1
2016-02-18 04:54:31.873    16005-0-0   130930-0-1 -     0  940.4 M   15.3 M    7.5 G     1
2016-02-18 04:55:03.875    16005-0-0   130931-0-1 -     0    1.4 G   22.7 M   11.2 G     1
2016-02-18 04:55:36.872    16005-0-0   130930-0-1 -     0  943.8 M   15.3 M    7.6 G     1
2016-02-18 04:56:08.876    16005-0-0   130931-0-1 -     0    1.4 G   22.7 M   11.2 G     1
2016-02-18 04:56:40.875    16005-0-0   130930-0-1 -     0  937.1 M   15.2 M    7.5 G     1
2016-02-18 04:57:12.875    16005-0-0   130931-0-1 -     0    1.4 G   22.5 M   11.1 G     1
2016-02-18 04:57:44.866    16005-0-0   130930-0-1 -     0  939.0 M   15.2 M    7.5 G     1
...
...
Summary: total flows: 918, total bytes: 6402017113000, total packets: 12959753000, avg bps: 2335211837, avg pps: 590902, avg bpp: 493
Time window: 2016-02-18 04:53:59 - 2016-02-18 10:59:31
Total flows processed: 918, Blocks skipped: 0, Bytes read: 127848
Sys: 0.036s flows/second: 25500.0    Wall: 0.082s flows/second: 11120.5

But when try to aggregate the flows in terms of mpls1 and mpls2 a strange value appears in label 1 (the same hapend when I do -s mpls2/bps):

user@ubuntu15:/user/router1$ sudo nfdump -R nfcapd.201602180755:nfcapd.current.22662 -A mpls1,mpls2 -s record/flows -o "fmt:%ts %mpls1 %mpls2 - %pr %bps %pkt %byt %fl"
Aggregated flows 27
Top 10 flows ordered by flows:
Date first seen          MPLS lbl 1   MPLS lbl 2    Proto      bps  Packets    Bytes Flows
2016-02-18 04:53:59.883     3717-0-0   130931-0-0 -     0    1.4 G    7.9 G    3.9 T   346
2016-02-18 04:54:31.873     3717-0-0   130930-0-0 -     0  938.9 M    5.3 G    2.6 T   346
...
...
Summary: total flows: 934, total bytes: 6484468263000, total packets: 13126665000, avg bps: 2334526363, avg pps: 590729, avg bpp: 493
Time window: 2016-02-18 04:53:59 - 2016-02-18 11:04:20
Total flows processed: 934, Blocks skipped: 0, Bytes read: 130024
Sys: 0.004s flows/second: 233500.0   Wall: 0.005s flows/second: 176226.4

Any ideas about what could be wrong?

Thanks for any help.

Hello,

I've had some issues building nfdump on centos 6. The configure script runs successfully, but make wants aclocal-1.15, which doesn't exist:

$ make
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /home/user/nfdump/missing aclocal-1.15
/home/user/nfdump/missing: line 81: aclocal-1.15: command not found
WARNING: 'aclocal-1.15' is missing on your system.
         You should only need it if you modified 'acinclude.m4' or
         'configure.ac' or m4 files included by 'configure.ac'.
         The 'aclocal' program is part of the GNU Automake package:
         <http://www.gnu.org/software/automake>
         It also requires GNU Autoconf, GNU m4 and Perl in order to run:
         <http://www.gnu.org/software/autoconf>
         <http://www.gnu.org/software/m4/>
         <http://www.perl.org/>
make: *** [aclocal.m4] Error 127

Any suggestions? I tried various incantations of autotools with no luck.

the fairly important flow record flags (e.g. event vs. flow) are not accessible with any custom format; only -o raw prints them (which doesn't print other things, e.g. the nr of flows).

this is very easy to fix and i've amended this in our fork of nfdump; pull request will follow.

I have nfdump-1.6.14 and I'm capturing sflow v5 data from a DELL PowerConnect switch. Sfcapd crashes after few minutes after it has been started. Please see backtrace below.
Thanks

`GNU gdb (GDB) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-alpine-linux-musl".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/sfcapd...Reading symbols from /usr/lib/debug//usr/bin/sfcapd.debug...done.
done.
[New LWP 1685]

warning: Can't read pathname for load map: No error information.
Core was generated by '/usr/bin/sfcapd -w -e -z -I B044 -l /var/log/sfcapd -S 1 -T all -t 3600 -B 1'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000078317da78ec in getData32 (sample=sample@entry=0x71028e90ed10) at sflow.c:1336

1336 sflow.c: No such file or directory.
(gdb) bt
#0 0x0000078317da78ec in getData32 (sample=sample@entry=0x71028e90ed10) at sflow.c:1336
#1 0x0000078317daa5b8 in readSFlowDatagram (fs=0x6167d5d6de60, sample=0x71028e90ed10) at sflow.c:2487
#2 Process_sflow (in_buff=, in_buff_cnt=, fs=0x6167d5d6de60) at sflow.c:2743
#3 0x0000078317da7168 in run (receive_packet=, report_seq=, do_xstat=, compress=1, time_extension=0x78317dafcda "%Y%m%d%H%M", use_subdirs=1, t_begin=, twin=3600, peer=...,

socket=3) at sfcapd.c:642

#4 main (argc=, argv=) at sfcapd.c:1092

(gdb) quit`

tshark -n -r netflow-20170502-091404.cap -V | grep 'Post Octets:' | cut -d ':' -f2- | awk '{s+=$1} END {print s}'
4642488540

fdump -r netflow-20170502-091404.cap.nf -A outif
Date first seen Duration Output Packets Bytes bps Bpp Flows
2017-05-02 11:05:55.210 1801.720 0 7.8 M 639.7 M 2.8 M 81 1
2017-05-01 22:42:35.730 48143.270 36 554.0 G 85.5 T 14.2 G 154 598567
2017-05-01 22:36:57.570 48481.420 48 652.9 M 57.6 G 9.5 M 88 1074981
2017-05-02 11:15:36.390 1.550 57 78920 4.3 M 22.0 M 54 1
Summary: total flows: 1673550, total bytes: 171214120575424, total packets: 554651127469, avg bps: 28252321860, avg pps: 11440486, avg bpp: 308

tshark -n -r netflow-20170502-091404.cap -V | grep -c 'Flow 1'
1673956

ps: netflow v9

I have a task to save IP_SRC_ADDR, IP_DST_ADDR, postNATSourceIPv4Address and postNATDestinationIPv4Address. These fields are present in tcpdump. In the output of nfdump these NAT addresses are missing. Please help to solve this problem.

nfcapd: Version: 1.6.15
nfcapd -e -z -w -t 60 -l /netflow/test -b 10.0.0.118 -p 9995 -E -T all -B
200000
Process_ipfix: [0] Add template 258

After start of nfcapd errors appear

Process_ipfix: [0] option template length error: size left 20 too small for
5 scopes length and 1 options length

Flow Record:
  Flags        =              0x06 FLOW, Unsampled
  export sysid =                 2
  size         =                68
  first        =                 0 [1970-01-01 03:00:00]
  last         =                 0 [1970-01-01 03:00:00]
  msec_first   =                 0
  msec_last    =                 0
  src addr     =    10.0.176.236
  dst addr     =     54.194.31.135
  src port     =             56428
  dst port     =                80
  fwd status   =                 0
  tcp flags    =              0x00 ......
  proto        =                 6 TCP
  (src)tos     =                 0
  (in)packets  =                 0
  (in)bytes    =                 0
  ip router    =       X.X.X.X
  received at  =     1489584299366 [2017-03-15 16:24:59.366]

tcpdump output

Set 1 [id=2] (Data Template): 258
    FlowSet Id: Data Template (V10 [IPFIX]) (2)
    FlowSet Length: 52
    Template (Id = 258, Count = 11)
        Template Id: 258
        Field Count: 11
        Field (1/11): observationTimeMilliseconds
        Field (2/11): IP_SRC_ADDR
        Field (3/11): IP_DST_ADDR
        Field (4/11): postNATSourceIPv4Address
        Field (5/11): postNATDestinationIPv4Address
        Field (6/11): L4_SRC_PORT
        Field (7/11): L4_DST_PORT
        Field (8/11): postNAPTSourceTransportPort
        Field (9/11): postNAPTDestinationTransportPort
        Field (10/11): PROTOCOL
        Field (11/11): natEvent
Flow 1
    Observation Time Milliseconds: Mar  6, 2017 15:50:01.892000000 RTZ 2
(зима)
    SrcAddr: 10.0.166.44
    DstAddr: 104.157.28.150
    Post NAT Source IPv4 Address: X.X.X.X
    Post NAT Destination IPv4 Address: 104.157.28.150
    SrcPort: 17043
    DstPort: 22675
    Post NAPT Source Transport Port: 17043
    Post NAPT Destination Transport Port: 22675
    Protocol: UDP (17)
    Nat Event: 2

nfdump -r nfcapd.201703151624 -o "fmt:%nsa:%nsp => %nda:%ndp" -c 10

   X-late Src IP XsPort       X-late Dst IP XdPort
         0.0.0.0:     0 =>          0.0.0.0:     0
         0.0.0.0:     0 =>          0.0.0.0:     0

when compile i got this warnings? is it normal?

./configure --enable-nsel --enable-nfprofile && make && make install

scanner.c:1889:17: warning: ‘yyunput’ defined but not used [-Wunused-function]
     static void yyunput (int c, register char * yy_bp )
                 ^
scanner.c:1930:16: warning: ‘input’ defined but not used [-Wunused-function]
     static int input  (void)
                ^
nfcapd.c: In function ‘main’:
nfcapd.c:761:18: warning: variable ‘filter’ set but not used [-Wunused-but-set-variable]
 char *bindhost, *filter, *datadir, pidstr[32], *launch_process;
                  ^
netflow_v9.c: In function ‘Process_v9’:
netflow_v9.c:2028:28: warning: variable ‘option_flowset’ set but not used [-Wunused-but-set-variable]
 option_template_flowset_t *option_flowset;
                            ^
ipfix.c: In function ‘Process_ipfix_templates’:
ipfix.c:884:10: warning: variable ‘id’ set but not used [-Wunused-but-set-variable]
 uint32_t id, count;
          ^
ipfix.c: In function ‘Process_ipfix_template_withdraw’:
ipfix.c:1068:16: warning: variable ‘count’ set but not used [-Wunused-but-set-variable]
   uint32_t id, count;
                ^
ipfix.c: In function ‘Process_ipfix_option_templates’:
ipfix.c:1146:16: warning: variable ‘length’ set but not used [-Wunused-but-set-variable]
   uint16_t id, length;
                ^
ipfix.c:1145:12: warning: variable ‘enterprise_value’ set but not used [-Wunused-but-set-variable]
   uint32_t enterprise_value;
            ^
ipfix.c:1179:16: warning: variable ‘length’ set but not used [-Wunused-but-set-variable]
   uint16_t id, length;
                ^
ipfix.c:1178:12: warning: variable ‘enterprise_value’ set but not used [-Wunused-but-set-variable]
   uint32_t enterprise_value;
            ^
ipfix.c:1101:69: warning: variable ‘found_std_sampling’ set but not used [-Wunused-but-set-variable]
 uint16_t offset_std_sampler_interval, offset_std_sampler_algorithm, found_std_sampling;
                                                                     ^
ipfix.c:1101:39: warning: variable ‘offset_std_sampler_algorithm’ set but not used [-Wunused-but-set-variable]
 uint16_t offset_std_sampler_interval, offset_std_sampler_algorithm, found_std_sampling;
                                       ^
ipfix.c:1101:10: warning: variable ‘offset_std_sampler_interval’ set but not used [-Wunused-but-set-variable]
 uint16_t offset_std_sampler_interval, offset_std_sampler_algorithm, found_std_sampling;
          ^
ipfix.c:1100:75: warning: variable ‘found_sampler’ set but not used [-Wunused-but-set-variable]
 uint16_t offset_sampler_id, offset_sampler_mode, offset_sampler_interval, found_sampler;
                                                                           ^
ipfix.c:1100:50: warning: variable ‘offset_sampler_interval’ set but not used [-Wunused-but-set-variable]
 uint16_t offset_sampler_id, offset_sampler_mode, offset_sampler_interval, found_sampler;
                                                  ^
ipfix.c:1100:29: warning: variable ‘offset_sampler_mode’ set but not used [-Wunused-but-set-variable]
 uint16_t offset_sampler_id, offset_sampler_mode, offset_sampler_interval, found_sampler;
                             ^
ipfix.c:1100:10: warning: variable ‘offset_sampler_id’ set but not used [-Wunused-but-set-variable]
 uint16_t offset_sampler_id, offset_sampler_mode, offset_sampler_interval, found_sampler;
          ^
ipfix.c:1099:54: warning: variable ‘sampler_id_length’ set but not used [-Wunused-but-set-variable]
 uint16_t id, field_count, scope_field_count, offset, sampler_id_length;
                                                      ^
ipfix.c:1099:46: warning: variable ‘offset’ set but not used [-Wunused-but-set-variable]
 uint16_t id, field_count, scope_field_count, offset, sampler_id_length;
                                              ^
ipfix.c:1099:10: warning: variable ‘id’ set but not used [-Wunused-but-set-variable]
 uint16_t id, field_count, scope_field_count, offset, sampler_id_length;
          ^
ipfix.c: In function ‘Process_IPFIX’:
ipfix.c:1623:24: warning: variable ‘ObservationDomain’ set but not used [-Wunused-but-set-variable]
 uint32_t   ExportTime, ObservationDomain, Sequence, flowset_length;
                        ^
ipfix.c:1623:12: warning: variable ‘ExportTime’ set but not used [-Wunused-but-set-variable]
 uint32_t   ExportTime, ObservationDomain, Sequence, flowset_length;
            ^
nfreplay.c: In function ‘FlushBuffer’:
nfreplay.c:148:3: warning: implicit declaration of function ‘__fpurge’ [-Wimplicit-function-declaration]
   FPURGE(stdin);
   ^
netflow_v9.c: In function ‘Process_v9’:
netflow_v9.c:2028:28: warning: variable ‘option_flowset’ set but not used [-Wunused-but-set-variable]
 option_template_flowset_t *option_flowset;
                            ^
ipfix.c: In function ‘Process_ipfix_templates’:
ipfix.c:884:10: warning: variable ‘id’ set but not used [-Wunused-but-set-variable]
 uint32_t id, count;
          ^
ipfix.c: In function ‘Process_ipfix_template_withdraw’:
ipfix.c:1068:16: warning: variable ‘count’ set but not used [-Wunused-but-set-variable]
   uint32_t id, count;
                ^
ipfix.c: In function ‘Process_ipfix_option_templates’:
ipfix.c:1146:16: warning: variable ‘length’ set but not used [-Wunused-but-set-variable]
   uint16_t id, length;
                ^
ipfix.c:1145:12: warning: variable ‘enterprise_value’ set but not used [-Wunused-but-set-variable]
   uint32_t enterprise_value;
            ^
ipfix.c:1179:16: warning: variable ‘length’ set but not used [-Wunused-but-set-variable]
   uint16_t id, length;
                ^
ipfix.c:1178:12: warning: variable ‘enterprise_value’ set but not used [-Wunused-but-set-variable]
   uint32_t enterprise_value;
            ^
ipfix.c:1101:69: warning: variable ‘found_std_sampling’ set but not used [-Wunused-but-set-variable]
 uint16_t offset_std_sampler_interval, offset_std_sampler_algorithm, found_std_sampling;
                                                                     ^
ipfix.c:1101:39: warning: variable ‘offset_std_sampler_algorithm’ set but not used [-Wunused-but-set-variable]
 uint16_t offset_std_sampler_interval, offset_std_sampler_algorithm, found_std_sampling;
                                       ^
ipfix.c:1101:10: warning: variable ‘offset_std_sampler_interval’ set but not used [-Wunused-but-set-variable]
 uint16_t offset_std_sampler_interval, offset_std_sampler_algorithm, found_std_sampling;
          ^
ipfix.c:1100:75: warning: variable ‘found_sampler’ set but not used [-Wunused-but-set-variable]
 uint16_t offset_sampler_id, offset_sampler_mode, offset_sampler_interval, found_sampler;
                                                                           ^
ipfix.c:1100:50: warning: variable ‘offset_sampler_interval’ set but not used [-Wunused-but-set-variable]
 uint16_t offset_sampler_id, offset_sampler_mode, offset_sampler_interval, found_sampler;
                                                  ^
ipfix.c:1100:29: warning: variable ‘offset_sampler_mode’ set but not used [-Wunused-but-set-variable]
 uint16_t offset_sampler_id, offset_sampler_mode, offset_sampler_interval, found_sampler;
                             ^
ipfix.c:1100:10: warning: variable ‘offset_sampler_id’ set but not used [-Wunused-but-set-variable]
 uint16_t offset_sampler_id, offset_sampler_mode, offset_sampler_interval, found_sampler;
          ^
ipfix.c:1099:54: warning: variable ‘sampler_id_length’ set but not used [-Wunused-but-set-variable]
 uint16_t id, field_count, scope_field_count, offset, sampler_id_length;
                                                      ^
ipfix.c:1099:46: warning: variable ‘offset’ set but not used [-Wunused-but-set-variable]
 uint16_t id, field_count, scope_field_count, offset, sampler_id_length;
                                              ^
ipfix.c:1099:10: warning: variable ‘id’ set but not used [-Wunused-but-set-variable]
 uint16_t id, field_count, scope_field_count, offset, sampler_id_length;
          ^
ipfix.c: In function ‘Process_IPFIX’:
ipfix.c:1623:24: warning: variable ‘ObservationDomain’ set but not used [-Wunused-but-set-variable]
 uint32_t   ExportTime, ObservationDomain, Sequence, flowset_length;
                        ^
ipfix.c:1623:12: warning: variable ‘ExportTime’ set but not used [-Wunused-but-set-variable]
 uint32_t   ExportTime, ObservationDomain, Sequence, flowset_length;
            ^
nfexpire.c: In function ‘main’:
nfexpire.c:215:8: warning: variable ‘maxsize_string’ set but not used [-Wunused-but-set-variable]
 char  *maxsize_string, *lifetime_string, *datadir;
        ^
nfexpire.c:213:10: warning: variable ‘err’ set but not used [-Wunused-but-set-variable]
 int   c, err, maxsize_set, maxlife_set;
          ^
profile.c: In function ‘CloseChannels’:
profile.c:369:10: warning: variable ‘update_ok’ set but not used [-Wunused-but-set-variable]
 int ret, update_ok;

I'm having an issue with the -x parameter where the command is not executing properly. I'm trying to dump the current rotation using the following:

nfcapd -D -z -w -p 9995 -n R1,168.205.XXX.XXX,/var/nfdump/nfcapd -S2 -e -x '/usr/bin/nfdump %d/%f >> /var/nfdump/logs/netflow.log'

The capture files are being generated properly but the -x command is not. Taking a look at journalctl I can see this:

-------------------------------------------------LOG START-----------------------------------------------------------------
Fev 27 17:30:22 logica nfcapd[18062]: Ident: 'R1' Flows: 30538, Packets: 7944584, Bytes: 8989023481, Sequence Errors: 0, Bad Packets: 0
Fev 27 17:30:22 logica nfcapd[18062]: Signal launcher
Fev 27 17:30:22 logica nfcapd[18062]: Total ignored packets: 0
Fev 27 17:30:22 logica nfcapd[18063]: Launcher: Wakeup
Fev 27 17:30:22 logica nfcapd[18063]: Launcher: ident: R1 run command: '/usr/bin/nfdump -r /var/nfdump/nfcapd/2017/02/27/17/nfcapd.201702271729 >> /var/nfdump/logs/zabbix_netflow.log'
Fev 27 17:30:22 logica nfcapd[18063]: Launcher: fork child.
Fev 27 17:30:22 logica nfcapd[18063]: Launcher: child exec done.
Fev 27 17:30:22 logica nfcapd[18063]: laucher child exit 1 childs.
Fev 27 17:30:22 logica nfcapd[18063]: launcher child 18086 exit status: 255
Fev 27 17:30:22 logica nfcapd[18063]: laucher waiting childs done. 0 childs
Fev 27 17:30:22 logica nfcapd[18063]: Launcher: Sleeping
-----------------------------------------------------LOG END-----------------------------------------------------------------

Apparently the command is being issued to the system, but somehow is not working properly.

I'm currently using nfdump 1.16.13 and Debian 8.6

Cisco just released IPFIX support in IOS-XR 6.0. Timestamps don't seem to be working with nfdump.

{code}
jfleury@36netops3:/disk/data/nfdump$ nfdump -r db/edge01.mrs01/2016/09/07/nfcapd.201609072238 -o raw | head -100

Flow Record:
Flags = 0x86 FLOW, Sampled
export sysid = 2
size = 92
first = 0 [1970-01-01 00:00:00]
last = 0 [1970-01-01 00:00:00]
msec_first = 0
msec_last = 0
src addr = 80.249.164.124
dst addr = 162.158.21.12
src port = 80
dst port = 52241
fwd status = 0
tcp flags = 0x00 ......
proto = 6 TCP
(src)tos = 0
(in)packets = 49152
(in)bytes = 28311552
input = 133
output = 8
src as = 5483
dst as = 0
src mask = 24 80.249.164.0/24
dst mask = 32 162.158.21.12/32
dst tos = 0
direction = 0
bgp next hop = 0.0.0.0
ip router = 162.158.20.1
received at = 1473287928060 [2016-09-07 22:38:48.060]
{code}

This renders nfdump command unusable.

{code}
jfleury@36netops3:/disk/data/nfdump$ nfdump -I -t-600 -M db/edge01.mrs01 -R . -s record/bytes
Ident: edge01.mrs01
Flows: 44438237
Flows_tcp: 44171585
Flows_udp: 252007
Flows_icmp: 13668
Flows_other: 977
Packets: 775532773376
Packets_tcp: 770959589376
Packets_udp: 4306845696
Packets_icmp: 250331136
Packets_other: 16007168
Bytes: 582753486061568
Bytes_tcp: 581400941953024
Bytes_udp: 1251934371840
Bytes_icmp: 98734702592
Bytes_other: 1875034112
First: 1472687706
Last: 1473326628
msec_first: 268
msec_last: 0
Sequence failures: 580596

jfleury@36netops3:/disk/data/nfdump$ nfdump -t-600 -M db/edge01.mrs01 -R . -s record/bytes
Aggregated flows 0
Top 10 flows ordered by bytes:
Date first seen Duration Proto Src IP Addr:Port Dst IP Addr:Port Packets Bytes Flows
Summary: total flows: 0, total bytes: 0, total packets: 0, avg bps: 0, avg pps: 0, avg bpp: 0
Time window: 2016-09-08 09:08:48 - 2016-09-08 09:23:48
Total flows processed: 102367, Blocks skipped: 0, Bytes read: 9418196
Sys: 0.021s flows/second: 4831822.9 Wall: 0.015s flows/second: 6666688.4
{code}

Attaching pcap extract. Wireshark seems to have no problem reading the timestamps.

mrs_ipfix_2.pcap.zip

{code}
jfleury@36netops3:/disk/data/nfdump$ nfdump -V
nfdump: Version: 1.6.15
{code}

tested with 1.6.13 too, same issue.

$ ./configure --disable-compat15 --disable-nsel --disable-fixtimebug \
  --disable-nfprofile --disable-nftrack --disable-readpcap --disable-sflow \
  --prefix=/usr/local
<...>
checking lex library... -lfl
checking whether yytext is a pointer... yes
checking for rrd_update in -lrrd... no
configure: error: Can not link librrd. Please specify --with-rrdpath=.. configure failed!

As i can see in configure.ac, librrd required either by --enable-nfprofile or --enable-nftrack . In this case both options are disabled, but librrd checks still called.

There is a ugly patch from ports tree, showing the source of problem. BUT it works with generated configure, so may break periodically after autotools update:

--- configure      2014-08-10 13:37:42.000000000 +0200
+++ configure   2014-08-10 13:39:21.000000000 +0200
@@ -4975,7 +4975,7 @@


 # Check whether --enable-nfprofile was given.
-if test "${enable_nfprofile+set}" = set; then :
+if test "x${enable_nfprofile}" = xyes; then :
   enableval=$enable_nfprofile;
        { $as_echo "$as_me:${as_lineno-$LINENO}: checking for rrd_update in -lrrd" >&5
 $as_echo_n "checking for rrd_update in -lrrd... " >&6; }
@@ -5099,7 +5099,7 @@


 # Check whether --enable-nftrack was given.
-if test "${enable_nftrack+set}" = set; then :
+if test "x${enable_nftrack}" = xyes; then :
   enableval=$enable_nftrack;
        { $as_echo "$as_me:${as_lineno-$LINENO}: checking for rrd_update in -lrrd" >&5
 $as_echo_n "checking for rrd_update in -lrrd... " >&6; }

for a variety of reasons i need to aggregate some flows by the usual quintuple PLUS the submitting agent/router. however, as soon as one uses any -A with any aggregation choice, GetMasterAggregateMask() is triggered which nukes almost all useful information from the resulting record: for example, the router and the in/out interfaces are gone, all icmp types become 0, and the received timestamp becomes 0/1.1.70.

to reproduce: nfdump -r somefile -a -o raw (or a -o fmt that includes %tr), produces the expected "good" output and the data from the first aggregated flow comes through fine.

now try nfdump -r samefile -A srcport,dstport,srcip,dstip,proto -o raw, and you'll see almost everything
come out as zero.

the culprit/cause: the memset(...,0) line in GetMasterAggregateMask().

personally i think that passing through the data from the first matching flow should take place
both when using -a and with -A; i'm not sure under what circumstances you'd ever want to zero anything with GetMasterAggregateMask(), but maybe peter can provide a good rationale?

if there are such situations, then i'd suggest adding a cmdline option to pick the desired
pass-through behaviour for -A (and i'll cook up a patch/pull request for that on monday).

Traffic is exported by a Cisco ISR 2951 Router (using netflow v9) running IOS v15.5(1)T2.

IPv6 traffic netflow records are misinterpreted by nfcapd/nfdump v1.6.15 (tried v1.6.13 too), as IPv4 traffic and are read into the system totally wrong.

(Note: IPv6 traffic records from an ASA 5525 are interpreted correctly by the same nfsen/nfdump installation.)

IPv4 traffic records are read correctly into nfcapd files.

Here is such a wrong record:

Flow Record:

Flags        =              0x06 FLOW, Unsampled
export sysid =                 2
size         =                60
first        =        1470300950 [2016-08-04 11:55:50]
last         =        1470304097 [2016-08-04 12:48:17]
msec_first   =               124
msec_last    =               444
src addr     =          53.0.0.0
dst addr     =         169.0.0.0
ICMP         =              64.8  type.code
fwd status   =                 0
tcp flags    =              0x11 .A...F
proto        =                 1 ICMP
(src)tos     =                 8
(in)packets  =               566
(in)bytes    =                 0
input        =              4578
output       =             54272

which was derived from the following packet (exported by Wireshark as plain text) referring to IPv6 traffic:

No.     Time                          Source                Destination           Protocol Length Info
    877 2016-07-31 00:23:44.691830    195.251.204.254       195.251.204.212       CFLOW    163    total: 2 (v9) records Obs-Domain-ID=    0 [Data:257] [Data-Template:257]

Frame 441: 119 bytes on wire (952 bits), 119 bytes captured (952 bits)
Ethernet II, Src: CiscoInc_52:38:11 (f4:0f:1b:52:38:11), Dst: DigitalE_2e:f5:53 (aa:00:00:2e:f5:53)
Internet Protocol Version 4, Src: 195.251.204.254, Dst: 195.251.204.212
User Datagram Protocol, Src Port: 57095 (57095), Dst Port: 9995 (9995)
Cisco NetFlow/IPFIX
    Version: 9
    Count: 1
    SysUptime: 146439.410723936 seconds
    Timestamp: Jul 31, 2016 00:19:59.000000000 GTB Daylight Time
        CurrentSecs: 1469913599
    FlowSequence: 59898 (expected 271165)
        [Expert Info (Warn/Sequence): Unexpected flow sequence for domain ID 0 (expected 271165, got 59898)]
    SourceId: 0
    FlowSet 1 [id=257] (1 flows)
        FlowSet Id: (Data) (257)
        FlowSet Length: 57
        [Template Frame: 877 (received after this frame)]
        Flow 1
            DstAddr: 2001:648:2011:10::236
            Protocol: UDP (17)
            SrcPort: 58068 (58068)
            DstPort: 53 (53)
            Octets: 169
            Packets: 1
            [Duration: 0.000000000 seconds (switched)]
                StartTime: 146423.104000000 seconds
                EndTime: 146423.104000000 seconds
            SrcAddr: 2001:648:2011:8002:85c:c793:3e1f:c573
    [Expected Sequence Number: 271165]
    [Previous Frame in Sequence: 440]`

I am available to provide whatever additional information/data needed to resolve the issue.

Original packets captured on wire and the respective nfcapd files are available at your request.

Here is the setup on the router that produces the IPv6 netflow export:

flow record ipv6_record_cisco2
 match ipv6 destination address
 collect ipv6 protocol
 collect ipv6 source address
 collect transport source-port
 collect transport destination-port
 collect counter bytes
 collect counter packets
 collect timestamp sys-uptime first
 collect timestamp sys-uptime last
!

I am using:

# nfdump -V
nfdump: Version: NSEL-NEL1.6.15

nfdump 1.6.15 was compiled as:

./configure --enable-nsel --enable-nfprofile --enable-nftrack --with-rrdpath=/usr/include

and nfsen:

# /data/nfsen/bin/nfsen -V
/data/nfsen/bin/nfsen: 1.3.6p1 $Id: nfsen 53 2012-01-23 16:36:02Z peter $ 

Please correct nfdump/nfcapd to correctly interpret IPv6 flow records.

Note: I have posted the same info to the "[email protected]" mailing list.

There you can find some more junk nfcap flow records and the respective IPv6-traffic packets: https://sourceforge.net/p/nfsen/mailman/message/35251516/

Thanks in advance,
Nick

I had previously posted this in the "nfsen" mailing list. Maybe that was the wrong place.

I am using nfcapd with a couple devices, among them an OpenBSD "pflow" device, which is IPFIX (Netflow 10), and a Sophos UTM 9.4-08 Software Appliance, which makes the same claim to support IPFIX.

Nfcapd supports the OpenBSD "pflow" device just fine and captures all the data as expected according to the templates, but Nfcapd does not interpret the flow record times from the Sophos UTM appliance. It displays them as "12-31-69".

Upon request, I will furnish anyone interested with some sample captures showing the main observation I see that may be relevant and that is the difference in length of the flow record timestamps:

1. rex.lab.9995.pcap - shows IPFIX from an OpenBSD "pflow" device,
   which from what I can tell is RFC7011-compliant, displays flow
   records as 64 bit dateTimeMilliseconds
2. utm08-2.pcap - from a Sophos UTM 9.4 08 Software Appliance - which
   what I can tell is RFC7011-compliant, displays flow records as 32
   bit dateTimeSeconds

Both captures have have 32-bit IPFIX Message Header Export Timestamps.

Please note the template packets for each capture describes the
timestamps with accurate lengths (8-byte and 4-byte, respectively).

Am I reading the spec correctly? I am referring to RFC7011, section
5.1-6.1.8. It seems to leave open using either absolute or relative
times, as well as dateTimeSeconds or dateTimeMilliseconds or
dateTimeMicroSeconds. If the RFC allows for each all of those types of
timestamps, I am wondering which are supported by nfcapd? I can't find
any reference in the docs or on this list to show me which of those are
supported by nfcapd. Is RFC7011 the correct reference I should be using
here?

What RFCs and or other documents are recommended as a guide to debugging
NetFlow data, specifically in reference to nfcapd, nfsen? I have seen a
wide range of implementations of NetFlow among various Net Flow-enabled
devices. It would be great to know where the "keys" are, in order to
make a good analysis.

Many thanks for reading and for any information you can provide!
Also note: within reason, I am willing to pay for someone's time whoever can fix this. Of course the fix would be contributed back to here for Peter's review for inclusion in the next version.

Hello, I'm collecting Cflow v9 from Alcatel Lucent SRxx and i'm trying to aggregate on bgpnext.
This is my setting

• nfdump: Version: 1.6.13
• Ubuntu 14.04LTS

When I aggregate with

 nfdump -r nfsen/profiles-data/live/xxx/2015/11/02/nfcapd.201511021815 -A 'srcas,dstas,inif,outif,bgpnext' -o raw "ipv6" | grep bgp

And all i'm getting is something like that :

bgp next hop =           0.0.0.0
bgp next hop =                ::
bgp next hop =           0.0.0.2
bgp next hop =                ::
bgp next hop =           0.0.0.0
bgp next hop =                ::
bgp next hop =           0.0.0.0
bgp next hop =                ::
bgp next hop =           0.0.0.0
bgp next hop =                ::
bgp next hop =           0.0.0.0
bgp next hop =                ::
bgp next hop =           0.0.0.1
bgp next hop =                ::
(...)

Do you notice that bug ?

When I sniff the cflow packets from the interface. I see the correct Ipv6 Bgp Next Hop Address (or Ipv4 address is there is not an Ipv6)

If I apply a filter on ipv4 I get the BGP next hop ipv4 address properly. It seems only appear on Ipv6.

Hello Peter,
First of all thanks for your great work.
I am using nfsen with several Cisco routers and ASAs. Recently I've migrated nfdump from 1.5.8-2-NSEL to the latest 1.6.15 (compiled it with options --enable-nfprofile --enable-compat15 --enable-nsel) and nfsen from 1.3.6 to 1.3.7. $EXTENSIONS = 'all' in nfsen.conf
The netflow data from routers is ok, but there are no packet counters from ASAs.
But there were packet counters with nfdump-1.5.8-2-NSEL. All ASAs sw versions are the same (the versions range from 8.2.3 to 9.5.1).
Do i miss something with configuration or compilation? Or is it the netflow protocol mismatch? Or is it normal situation due to ASA behavior?

I am using nfdump 1.6.15
When running report with the following parameters "-s srcip/bytes/packets/flows" ipv6 address in the second parameter is wrong (packets order in that case )
It happen for any type of output and for any order of sorts (e.g. for srcip/packets/flows the flows report will have the wrong IP )
It happen for csv output and also for regular output
If I run the same report for single sort order it works ok and it also work ok for ipv4

In the following output please look on "2606:2800:133:1c88:7d4:2e2:1718:1cbc" and "881c:3301:28:626:bc1c:1817:e202:d407" you can see that both has the same counters and when I run the same report for with single sort order I dont see the second one

`[root@netflow nfdump-1.6.15]# /usr/local/bin/nfdump -V
/usr/local/bin/nfdump: Version: 1.6.15
[root@netflow nfdump-1.6.15]# /usr/local/bin/nfdump -M /space/moka/MX-B:MX-A -r 2017/07/12/09/nfcapd.201707120907 -q -s srcip/bytes/packets/flows -n 2 -ocsv -f /etc/netflow/all-in.flt
ts,te,td,pr,val,fl,flP,ipkt,ipktP,ibyt,ibytP,ipps,ibps,ibpp
2017-07-12 09:05:35,2017-07-12 09:07:51,136.068,any,2606:2800:133:1c88:7d4:2e2:1718:1cbc,8057,25.6,11523000,19.7,14622185000,22.8,84685,859698680,1268
2017-07-12 09:06:08,2017-07-12 09:07:42,94.345,any,93.184.221.200,417,1.3,639000,1.1,957730000,1.5,6773,81210874,1498

ts,te,td,pr,val,fl,flP,ipkt,ipktP,ibyt,ibytP,ipps,ibps,ibpp
2017-07-12 09:05:35,2017-07-12 09:07:51,136.068,any,881c:3301:28:626:bc1c:1817:e202:d407,8057,25.6,11523000,19.7,14622185000,22.8,84685,859698680,1268
2017-07-12 08:52:32,2017-07-12 09:07:57,925.286,any,149.154.165.120,168,0.5,1028000,1.8,1312717000,2.0,1111,11349718,1276

ts,te,td,pr,val,fl,flP,ipkt,ipktP,ibyt,ibytP,ipps,ibps,ibpp
2017-07-12 09:05:35,2017-07-12 09:07:51,136.068,any,2606:2800:133:1c88:7d4:2e2:1718:1cbc,8057,25.6,11523000,19.7,14622185000,22.8,84685,859698680,1268
2017-07-12 08:52:32,2017-07-12 09:07:57,925.286,any,149.154.165.120,168,0.5,1028000,1.8,1312717000,2.0,1111,11349718,1276
`

`[root@netflow nfdump-1.6.15]# /usr/local/bin/nfdump -M /space/moka/MX-B:MX-A -r 2017/07/12/09/nfcapd.201707120907 -q -s srcip/flows -n 2 -ocsv -f /etc/netflow/all-in.flt
ts,te,td,pr,val,fl,flP,ipkt,ipktP,ibyt,ibytP,ipps,ibps,ibpp
2017-07-12 09:05:35,2017-07-12 09:07:51,136.068,any,2606:2800:133:1c88:7d4:2e2:1718:1cbc,8057,25.6,11523000,19.7,14622185000,22.8,84685,859698680,1268
2017-07-12 09:06:08,2017-07-12 09:07:42,94.345,any,93.184.221.200,417,1.3,639000,1.1,957730000,1.5,6773,81210874,1498

[root@netflow nfdump-1.6.15]# /usr/local/bin/nfdump -M /space/moka/MX-B:MX-A -r 2017/07/12/09/nfcapd.201707120907 -q -s srcip/packets -n 2 -ocsv -f /etc/netflow/all-in.flt
ts,te,td,pr,val,fl,flP,ipkt,ipktP,ibyt,ibytP,ipps,ibps,ibpp
2017-07-12 09:05:35,2017-07-12 09:07:51,136.068,any,2606:2800:133:1c88:7d4:2e2:1718:1cbc,8057,25.6,11523000,19.7,14622185000,22.8,84685,859698680,1268
2017-07-12 08:52:32,2017-07-12 09:07:57,925.286,any,149.154.165.120,168,0.5,1028000,1.8,1312717000,2.0,1111,11349718,1276

[root@netflow nfdump-1.6.15]# /usr/local/bin/nfdump -M /space/moka/MX-B:MX-A -r 2017/07/12/09/nfcapd.201707120907 -q -s srcip/bytes -n 2 -ocsv -f /etc/netflow/all-in.flt
ts,te,td,pr,val,fl,flP,ipkt,ipktP,ibyt,ibytP,ipps,ibps,ibpp
2017-07-12 09:05:35,2017-07-12 09:07:51,136.068,any,2606:2800:133:1c88:7d4:2e2:1718:1cbc,8057,25.6,11523000,19.7,14622185000,22.8,84685,859698680,1268
2017-07-12 08:52:32,2017-07-12 09:07:57,925.286,any,149.154.165.120,168,0.5,1028000,1.8,1312717000,2.0,1111,11349718,1276
`

`[root@netflow nfdump-1.6.15]# /usr/local/bin/nfdump -M /space/moka/MX-B:MX-A -r 2017/07/12/09/nfcapd.201707120907 -q -s srcip/bytes/packets -n 2 -ocsv -f /etc/netflow/all-in.flt
ts,te,td,pr,val,fl,flP,ipkt,ipktP,ibyt,ibytP,ipps,ibps,ibpp
2017-07-12 09:05:35,2017-07-12 09:07:51,136.068,any,2606:2800:133:1c88:7d4:2e2:1718:1cbc,8057,25.6,11523000,19.7,14622185000,22.8,84685,859698680,1268
2017-07-12 08:52:32,2017-07-12 09:07:57,925.286,any,149.154.165.120,168,0.5,1028000,1.8,1312717000,2.0,1111,11349718,1276

ts,te,td,pr,val,fl,flP,ipkt,ipktP,ibyt,ibytP,ipps,ibps,ibpp
2017-07-12 09:05:35,2017-07-12 09:07:51,136.068,any,881c:3301:28:626:bc1c:1817:e202:d407,8057,25.6,11523000,19.7,14622185000,22.8,84685,859698680,1268
2017-07-12 08:52:32,2017-07-12 09:07:57,925.286,any,149.154.165.120,168,0.5,1028000,1.8,1312717000,2.0,1111,11349718,1276

[root@netflow nfdump-1.6.15]# /usr/local/bin/nfdump -M /space/moka/MX-B:MX-A -r 2017/07/12/09/nfcapd.201707120907 -q -s srcip/bytes/flows -n 2 -ocsv -f /etc/netflow/all-in.flt
ts,te,td,pr,val,fl,flP,ipkt,ipktP,ibyt,ibytP,ipps,ibps,ibpp
2017-07-12 09:05:35,2017-07-12 09:07:51,136.068,any,2606:2800:133:1c88:7d4:2e2:1718:1cbc,8057,25.6,11523000,19.7,14622185000,22.8,84685,859698680,1268
2017-07-12 09:06:08,2017-07-12 09:07:42,94.345,any,93.184.221.200,417,1.3,639000,1.1,957730000,1.5,6773,81210874,1498

ts,te,td,pr,val,fl,flP,ipkt,ipktP,ibyt,ibytP,ipps,ibps,ibpp
2017-07-12 09:05:35,2017-07-12 09:07:51,136.068,any,881c:3301:28:626:bc1c:1817:e202:d407,8057,25.6,11523000,19.7,14622185000,22.8,84685,859698680,1268
2017-07-12 08:52:32,2017-07-12 09:07:57,925.286,any,149.154.165.120,168,0.5,1028000,1.8,1312717000,2.0,1111,11349718,1276

[root@netflow nfdump-1.6.15]# /usr/local/bin/nfdump -M /space/moka/MX-B:MX-A -r 2017/07/12/09/nfcapd.201707120907 -q -s srcip/packets/flows -n 2 -ocsv -f /etc/netflow/all-in.flt
ts,te,td,pr,val,fl,flP,ipkt,ipktP,ibyt,ibytP,ipps,ibps,ibpp
2017-07-12 09:05:35,2017-07-12 09:07:51,136.068,any,2606:2800:133:1c88:7d4:2e2:1718:1cbc,8057,25.6,11523000,19.7,14622185000,22.8,84685,859698680,1268
2017-07-12 09:06:08,2017-07-12 09:07:42,94.345,any,93.184.221.200,417,1.3,639000,1.1,957730000,1.5,6773,81210874,1498

ts,te,td,pr,val,fl,flP,ipkt,ipktP,ibyt,ibytP,ipps,ibps,ibpp
2017-07-12 09:05:35,2017-07-12 09:07:51,136.068,any,881c:3301:28:626:bc1c:1817:e202:d407,8057,25.6,11523000,19.7,14622185000,22.8,84685,859698680,1268
2017-07-12 08:52:32,2017-07-12 09:07:57,925.286,any,149.154.165.120,168,0.5,1028000,1.8,1312717000,2.0,1111,11349718,1276`

Nitzan

please is there any way by NFDUMP to convert a time from ISO 8601 format to Unix(epoch) format
if any one could help
Thanks

Hello,

I Would like to know If It was as possible to recover the tag mpls In sFlow flow with sfcapd daemon of nfdump ??

Thank you for your answer.

I was trying to update the package formula of nfdump at MacOS Brew package repository and found out that parallel build (which default for brew) of nfdump fails with error message of linker about missing library nfdump. The problem reproduces on debian 8.2 jessie.

Here is the log of build with error message:

avp@dtm:~/tmp/nfdump-1.6.15$ MAKEFLAGS=-j2 make
---- Skipped ----
/bin/bash ../libtool  --tag=CC   --mode=link gcc  -g -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -fno-strict-aliasing   -o nfcapd nfcapd-nfcapd.o nfcapd-nfstatfile.o nfcapd-launch.o nfcapd-nfnet.o nfcapd-collector.o nfcapd-netflow_v1.o nfcapd-netflow_v5_v7.o nfcapd-netflow_v9.o nfcapd-ipfix.o nfcapd-bookkeeper.o nfcapd-expire.o  -lnfdump  -lresolv  -lbz2
libtool: link: gcc -g -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -fno-strict-aliasing -o nfcapd nfcapd-nfcapd.o nfcapd-nfstatfile.o nfcapd-launch.o nfcapd-nfnet.o nfcapd-collector.o nfcapd-netflow_v1.o nfcapd-netflow_v5_v7.o nfcapd-netflow_v9.o nfcapd-ipfix.o nfcapd-bookkeeper.o nfcapd-expire.o  -lnfdump -lresolv -lbz2
/usr/bin/ld: cannot find -lnfdump
collect2: error: ld returned 1 exit status
Makefile:920: recipe for target 'nfcapd' failed
make[3]: *** [nfcapd] Error 1
make[3]: *** Waiting for unfinished jobs....
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -ggdb -g -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -fno-strict-aliasing -MT scanner.lo -MD -MP -MF .deps/scanner.Tpo -c scanner.c -o scanner.o >/dev/null 2>&1
make[3]: Leaving directory '/home/avp/tmp/nfdump-1.6.15/bin'
Makefile:778: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/home/avp/tmp/nfdump-1.6.15/bin'
Makefile:402: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/avp/tmp/nfdump-1.6.15'
Makefile:334: recipe for target 'all' failed
make: *** [all] Error 2

Our Juniper MX router installed a jflow card to capture 1:1 netflow and send to nfdump 1.6.12. After first few minutes (about 2 to 5 minutes), the "Packets" and "Bytes" counts of the flow records are multiplied by 2, e.g. from "1 packet 40 bytes" to "2 packets 80 bytes". tcpdump confirm the traffic were multiplied.

Since the change occurred after few minutes, many "template" packets has been received. I think the sampling rate change would not be due to sampling rate reported. Please correct me if I was wrong.

The problem can be workaround by enforce nfcapd sampling rate (with parameter -s -1).

Below is the nfdump output showing first 11 lines of correct dump while lines after are multiplied by 2.

Date first seen          Duration Proto      Src IP Addr:Port          Dst IP Addr:Port   Flags Tos  Packets    Bytes      pps      bps    Bpp Flows
2016-01-11 09:38:08.173     0.000 TCP       74.101.184.1:21317 ->      74.240.202.66:443   .A...F  48        1       40        0        0     40     1
2016-01-11 09:38:07.518     0.006 TCP       74.101.184.1:42478 ->      74.240.202.33:80    .A..SF  48        3      124      500   165333     41     1
2016-01-11 09:36:18.101    90.002 RSVP       74.83.63.32:0     ->      74.83.63.12:0     ...... 192          3      792        0       70    264     1
2016-01-11 05:18:13.186 15584.096 TCP        74.83.63.32:50455 ->      74.83.63.12:646   .AP... 224         16      976        0        0     61     1
2016-01-11 09:37:05.969     0.005 TCP       74.101.184.1:34445 ->      74.240.202.33:8443  .A..S.  48        2       84      400   134400     42     1
2016-01-11 09:36:13.831   103.997 RSVP       74.83.63.51:0     ->      74.83.63.11:0     ...... 192          5     1320        0      101    264     1
2016-01-11 09:37:05.622     0.013 TCP       74.101.184.1:41270 ->      74.240.202.66:443   .A....  48        2       80      153    49230     40     1
2016-01-11 09:37:06.559     0.021 TCP       74.101.184.1:34422 ->      74.240.202.34:443   .A..S.  48        3      124      142    47238     41     1
2016-01-11 09:37:06.405     0.007 TCP     74.101.184.250:48462 ->      74.240.202.66:443   .A..S.  48        2      112      285   128000     56     1
2016-01-11 09:38:08.023     0.000 TCP       74.101.184.1:42517 ->      74.240.202.34:443   .A...F  48        1       40        0        0     40     1
2016-01-11 09:38:08.008     0.000 TCP       74.101.184.1:42504 ->      74.240.202.74:443   .A...F  48        1       40        0        0     40     1
2016-01-11 09:37:06.467     0.008 TCP       74.101.184.1:34408 ->      74.240.202.70:443   .A..S.  48        2       84      250    84000     42     1
2016-01-11 09:38:07.976     0.006 TCP       74.101.184.1:20962 ->      74.240.202.33:8443  .A..SF  48        2       84      333   112000     42     1
2016-01-11 09:38:05.290     0.000 TCP       74.101.184.1:49182 ->      74.240.202.33:8443  .A...F  48        4      160        0        0     40     1
2016-01-11 09:37:06.448     0.000 TCP       74.101.184.1:12834 ->      74.240.202.34:443   ....S.  48        2       88        0        0     44     1
2016-01-11 09:37:06.668     0.011 TCP       74.101.184.1:41646 ->      74.240.202.33:80    .A....  48        4      160      363   116363     40     1
2016-01-11 09:38:08.994     0.009 TCP       74.101.184.1:42892 ->      74.240.202.66:443   .A..SF  48        6      248      666   220444     41     1
2016-01-11 09:38:09.789     0.000 TCP       74.101.184.1:49415 ->      74.240.202.66:443   .A...F  48        2       80        0        0     40     1
2016-01-11 09:38:13.044     0.009 TCP       74.101.184.1:43175 ->      74.240.202.70:443   .A..SF  48        6      248      666   220444     41     1
2016-01-11 09:38:07.977     0.000 TCP       74.101.184.1:42502 ->      74.240.202.70:443   .A...F  48        4      160        0        0     40     1
2016-01-11 09:38:10.031     0.000 TCP       74.101.184.1:49678 ->      74.240.202.70:443   .A...F  48        2       80        0        0     40     1

All this setup perfectly works under CentOS 6.x.
Problems began when we decided to migrate to CentOS 7.2.

CentOS Linux release 7.2.1511 (Core)
Linux flows 3.10.0-327.22.2.el7.x86_64 #1 SMP Thu Jun 23 17:05:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

We have different sources, so we use shell-script to start all procesess:
nfcapd-start.sh:

!/bin/sh

start netflow-6500

/usr/local/bin/nfcapd -P /var/run/nfcapd/nfcapd-netflow-6500.pid -w -D -b x.x.x.x -p 3000 -S 7 -t 180 -z -l /mnt/array0/netflow/nfcapd-netflow-6500 -I cat6509 -x '/usr/local/adm/analyze.sh %i %d/%f'

office

/usr/local/bin/nfcapd -P /var/run/nfcapd/nfcapd-netflow-office.pid -w -D -b x.x.x.x -p 3001 -S 7 -t 180 -z -l /mnt/array0/netflow/nfcapd-netflow-office

cisco 7206

/usr/local/bin/nfcapd -P /var/run/nfcapd/nfcapd-netflow-7206.pid -w -D -b x.x.x.x -p 3010 -S 7 -t 180 -R 127.0.0.1/3210 -z -l /mnt/array0/netflow/nfcapd-netflow-7206
/usr/local/flow-tools/bin/flow-fanout 127.0.0.1/0/3210 0/127.0.0.1/3310 -f /tmp/filter.flow -F xxx
/usr/local/bin/nfcapd -P /var/run/nfcapd/nfcapd-netflow-7206-b2b.pid -w -D -b 127.0.0.1 -p 3310 -S 7 -t 180 -z -l /mnt/array0/netflow/nfcapd-netflow-7206-b2b

flow-fanout used to separate b2b traffic from all flow.

here we go:
root 22703 0.0 0.0 22364 2628 ? S Jul11 0:00 /usr/local/bin/nfcapd -P /var/run/nfcapd/nfcapd-netflow-6500.pid -w -D -b 77.50.0.16 -p 3000 -S 7 -t 180 -z -l /mnt/array0/netflow/nfcapd-netflow-6500 -I cat6509 -x /usr/local/adm/analyze.sh %i %d/%f
root 22704 0.0 0.0 11080 580 ? S Jul11 0:00 /usr/local/bin/nfcapd -P /var/run/nfcapd/nfcapd-netflow-6500.pid -w -D -b 77.50.0.16 -p 3000 -S 7 -t 180 -z -l /mnt/array0/netflow/nfcapd-netflow-6500 -I cat6509 -x /usr/local/adm/analyze.sh %i %d/%f
root 22707 0.0 0.0 22360 2648 ? S Jul11 0:00 /usr/local/bin/nfcapd -P /var/run/nfcapd/nfcapd-netflow-office.pid -w -D -b 77.50.0.16 -p 3001 -S 7 -t 180 -z -l /mnt/array0/netflow/nfcapd-netflow-office

but when 7206 capturer starts we got error:

Jul 15 15:42:55 flows nfcapd[27478]: Add extension: 2 byte input/output interface index
Jul 15 15:42:55 flows nfcapd[27478]: Add extension: 4 byte input/output interface index
Jul 15 15:42:55 flows nfcapd[27478]: Add extension: 2 byte src/dst AS number
Jul 15 15:42:55 flows nfcapd[27478]: Add extension: 4 byte src/dst AS number
Jul 15 15:42:55 flows nfcapd[27478]: Add extension: 4 byte output bytes
Jul 15 15:42:55 flows nfcapd[27478]: Add extension: 8 byte output bytes
Jul 15 15:42:55 flows nfcapd[27478]: Add extension: NSEL Common block
Jul 15 15:42:55 flows nfcapd[27478]: Add extension: NSEL xlate ports
Jul 15 15:42:55 flows nfcapd[27478]: Add extension: NSEL xlate IPv4 addr
Jul 15 15:42:55 flows nfcapd[27478]: Add extension: NSEL xlate IPv6 addr
Jul 15 15:42:55 flows nfcapd[27478]: Add extension: NSEL ACL ingress/egress acl ID
Jul 15 15:42:55 flows nfcapd[27478]: Add extension: NSEL username
Jul 15 15:42:55 flows nfcapd[27478]: Add extension: NSEL max username
Jul 15 15:42:55 flows nfcapd[27478]: Add extension: NEL Common block
Jul 15 15:42:55 flows nfcapd[27478]: Bound to IPv4 host/IP: x.x.x.x, Port: 3010
Jul 15 15:42:55 flows nfcapd[27478]: Replay flows to host: 127.0.0.1 port: 3210
Jul 15 15:42:55 flows nfcapd[27480]: Another collector with pid 22707 is already running, and configured for '/mnt/array0/netflow/nfcapd-netflow-7206'
Jul 15 15:42:55 flows nfcapd[27480]: initialize bookkeeper failed.
Jul 15 15:42:55 flows nfcapd[27480]: Software error in bookkeeper.c line 401: Entry not found in list

As you can see, pid=22707 - is a pid of previous process with work dir '/mnt/array0/netflow/nfcapd-netflow-office'

What could it be? How to find a reason of such behavior?

Dear,

We compiling with nfpcapd support, I have an issue with a type 'sig_atomic_t'.

Configure set with option --enable-nfpcapd then make.
Make failed with the following error:
gcc -DHAVE_CONFIG_H -I. -I.. -D_BSD_SOURCE -g -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -fno-strict-aliasing -MT nfpcapd-pcaproc.o -MD -MP -MF .deps/nfpcapd-pcaproc.Tpo -c -o nfpcapd-pcaproc.o test -f 'pcaproc.c' || echo './'pcaproc.c In file included from pcaproc.c:72:0: flowtree.h:112:2: error: unknown type name ‘sig_atomic_t’ sig_atomic_t list_lock; ^ Makefile:1283: recipe for target 'nfpcapd-pcaproc.o' failed make[3]: *** [nfpcapd-pcaproc.o] Error 1 make[3]: Leaving directory '/home/durvada/git/nfdump/bin' Makefile:780: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/home/durvada/git/nfdump/bin' Makefile:403: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/durvada/git/nfdump' Makefile:335: recipe for target 'all' failed make: *** [all] Error 2
Thanks for help!
Best regards,

David

It would be cool to have a possibility to include a timezone in files produced by nfcapd, for following reasons:

• there would not be collisions on timezone changes (e.g. I suspect that when switching the daylight saving time some NF data are currently lost as a result)
• It would make the filenames zone-oblivious globally, making moving/indexing easier.

Actual solution may be quite easy, e.g. using gettimeofday() somewhere around this:
https://github.com/phaag/nfdump/blob/master/bin/nfcapd.c#L486
Suggested final filename form is something like nfcapd.yyyymmddHHMM+ZZZZ.

I'll try to write a patch asap to see if there's no compatibility issue.

(side note: is there any reason why not to include seconds in the filename as well?)

I am trying to use nfdump to read a NetFlow feed from Meraki devices. I am using nfcapd with -T all to receive the data feed.

When I use nfdump to read the file I get an incorrect timestamp. It seems to be fixed to 1451164051, or 2015-12-26 15:07:31:

$ nfdump -r local_cap.nf -b -q
2015-12-26 15:07:31.296     0.000 TCP       192.168.5.25:445   <->       10.10.1.13:57377        6       10      530      638     2
2015-12-26 15:07:31.296     0.000 TCP       192.168.5.25:445   <->       10.10.1.11:42433        3        5      265      319     1
2015-12-26 15:07:31.296     0.000 TCP       192.168.5.25:445   <->       10.10.1.11:42439        6       10      530      638     2
2015-12-26 15:07:31.296     0.000 TCP       192.168.5.25:445   <->       10.10.1.14:59302        6       10      530      638     2
2015-12-26 15:07:31.296     0.000 TCP       192.168.5.25:445   <->       10.10.1.13:57380        6       10      530      638     2
2015-12-26 15:07:31.296     0.000 TCP       192.168.5.25:445   <->       10.10.1.12:36507        3        5      265      319     1

Wireshark's CFlow dissector can properly interpret the timestamp:

I have attached a small excerpt of the nfcapd-generated file and also a PCAP file with a sample packet:
v9-export.zip

I would expect nfdump to show the timestamp like Wireshark.

we are sending ipfix from a juniper ptx at 1:10000. the template includes the sample rate field, and the sample rate is being sent periodically. however, the flows are showing up in nfcap/nfdump as unsampled.

i have attached a pcap with the exported flows. packet 26, set 5, flow 1 contains the sample rate as you can see.
ptx-ipfix.pcap.zip

here is an example from nfdump -o raw:
Flow Record:
Flags = 0x06 FLOW, Unsampled
export sysid = 1
size = 96
first = 1480524513 [2016-11-30 16:48:33]
last = 1480524513 [2016-11-30 16:48:33]
msec_first = 958
msec_last = 958
src addr = x.x.x.x
dst addr = y.y.y.y
src port = 44861
dst port = 80
fwd status = 230
tcp flags = 0x10 .A....
proto = 6 TCP
(src)tos = 8
(in)packets = 1
(in)bytes = 52
input = 796
output = 637
src as = 65000
dst as = 65001
src mask = 23 x.x.x.x/23
dst mask = 24 y.y.y.y/24
dst tos = 0
direction = 0
ip next hop = a.a.a.a
bgp next hop = b.b.b.b
ip router = c.c.c.c
received at = 1480524600006 [2016-11-30 16:50:00.006]

it's no longer possible to build nfdump without shared library, despite configure exposing --enable-shared. if you use --enable-shared=no, then the build fails:

Entering directory '...../bin'
/bin/bash ../libtool --tag=CC --mode=link gcc -ggdb -g -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -fno-strict-aliasing -release 1.6.14 -shared -o libnfdump.la -rpath /usr/local/lib nf_common.lo util.lo minilzo.lo nffile.lo nfx.lo nfxstat.lo flist.lo fts_compat.lo grammar.lo scanner.lo nftree.lo ipconv.lo exporter.lo -lresolv -lbz2
libtool: link: can not build a shared library

Please add the pipe output NEL.

nfdump version: 1.6.13

Debian Gnu Linux version 8.2, i386 (32 bits)

Flow type being collected: sflow

First and last date in "Time window" line are not being reported correctly, for example:
Time window: 1906-11-07 07:19:46 - 2010-03-31 15:12:53

I tracked down this issue and found that there is an overflow happening in variable _t, in sflow.c

Instead of:
_t = 1000*now.tv_sec + common_record->msec_first;

It should be:
_t = (unsigned long long) 1000*now.tv_sec + common_record->msec_first;

Doing this cast to uint64_t solves the problem.

I can't find where i can find 'nftest' binary.

Even if i have configured with './configure --enable-nfprofile --enable-nftrack --enable-devel'
This string is from the manual:
You can check the compression speed for your system by doing ./nftest .

feature request nfpcapd process bzipped pcap files

sfcapd logs every received sflow on /var/log/messages. It is possible to reduce the log level to warning?

Hi,
i am using nfdump: Version: NSEL-NEL1.6.15 and I am having an hard time finding how to aggregate data using the SEL/NSEL parameters.

I am looking for a way to aggregate the flows using either :
xsrcip NSEL/ASA translated src IP address
xdstip NSEL/ASA translated dst IP address

nfdump -R nfcapd.201701020849 -A nsrcip -o "fmt:%ts %te %pr %sap %xsa %pkt %byt %fl"
Unknown aggregation specifier 'nsrcip'

nfdump -R nfcapd.201701020744 -o nsel -A srcip,xsrcip
Unknown aggregation specifier 'xsrcip'

Does anyone know the correct syntax for nfdump?
Thanks

This leads to failures in make check:

make check-TESTS
make[3]: Entering directory '/var/tmp/portage/net-analyzer/nfdump-1.6.15/work/nfdump-1.6.15/bin'
make[4]: Entering directory '/var/tmp/portage/net-analyzer/nfdump-1.6.15/work/nfdump-1.6.15/bin'
PASS: nftest
FAIL: test.sh

Testsuite summary for nfdump 1.6.15

TOTAL: 2

PASS: 1

SKIP: 0

XFAIL: 0

FAIL: 1

XPASS: 0

ERROR: 0

============================================================================
See bin/test-suite.log
Please report to [email protected]

=======================================
nfdump 1.6.15: bin/test-suite.log

TOTAL: 2

PASS: 1

SKIP: 0

XFAIL: 0

FAIL: 1

XPASS: 0

ERROR: 0

.. contents:: :depth: 2

FAIL: test.sh

IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv4 32bit packets 32bit bytes
IPv6 32bit packets 32bit bytes
IPv6 32bit packets 32bit bytes
IPv6 32bit packets 64bit bytes
IPv6 64bit packets 32bit bytes
IPv6 64bit packets 64bit bytes
IPv4 32bit packets 64bit bytes
IPv4 64bit packets 32bit bytes
IPv4 64bit packets 64bit bytes
4 bytes interfaces, 2 bytes AS numbers 24 25
2 bytes interfaces, 4 bytes AS numbers 25 27
4 bytes interfaces, 4 bytes AS numbers 26 29
diff: nfdump.test.out: No such file or directory
FAIL test.sh (exit status: 2)

See also https://bugs.gentoo.org/624336

Is it possible to record only the tcp flows by nfcapd?

Hi,

We have some Nexus7700 boxes and after upgraded to NXOS v8.0.1, nfcapd began to flooding syslog and soon log partition gets full.
Logs:
Jan 27 10:24:39 hotdog nfcapd[2711]: Process_v9: Corrupt data flowset? Pad bytes: 24
Jan 27 10:24:39 hotdog nfcapd[2711]: Process_v9: Corrupt data flowset? Pad bytes: 24
Jan 27 10:24:39 hotdog nfcapd[2711]: Process_v9: Corrupt data flowset? Pad bytes: 24
Jan 27 10:24:39 hotdog nfcapd[2711]: Process_v9: Corrupt data flowset? Pad bytes: 36
Jan 27 10:24:39 hotdog nfcapd[2711]: Process_v9: Corrupt data flowset? Pad bytes: 24
Jan 27 10:24:39 hotdog nfcapd[2711]: Process_v9: Corrupt data flowset? Pad bytes: 24
Jan 27 10:24:40 hotdog nfcapd[2711]: Process_v9: Corrupt data flowset? Pad bytes: 24
Jan 27 10:24:40 hotdog nfcapd[2711]: Process_v9: Corrupt data flowset? Pad bytes: 24
Jan 27 10:24:40 hotdog nfcapd[2711]: Process_v9: Corrupt data flowset? Pad bytes: 24
Jan 27 10:24:40 hotdog nfcapd[2711]: Process_v9: Corrupt data flowset? Pad bytes: 24
Jan 27 10:24:40 hotdog nfcapd[2711]: Process_v9: Corrupt data flowset? Pad bytes: 24
Jan 27 10:24:40 hotdog nfcapd[2711]: Process_v9: Corrupt data flowset? Pad bytes: 24
Jan 27 10:24:40 hotdog nfcapd[2711]: Process_v9: Corrupt data flowset? Pad bytes: 24
Jan 27 10:24:40 hotdog nfcapd[2711]: Process_v9: Corrupt data flowset? Pad bytes: 24
Jan 27 10:24:40 hotdog nfcapd[2711]: Process_v9: Corrupt data flowset? Pad bytes: 24
Jan 27 10:24:40 hotdog nfcapd[2711]: Process_v9: Corrupt data flowset? Pad bytes: 24
Jan 27 10:24:40 hotdog nfcapd[2711]: Process_v9: Corrupt data flowset? Pad bytes: 24

In RFC3954 there is no explicit padding size limit:

5.3. Data FlowSet Format
Padding
The Exporter SHOULD insert some padding bytes so that the
subsequent FlowSet starts at a 4-byte aligned boundary. It is
important to note that the Length field includes the padding
bytes. Padding SHOULD be using zeros.
strange-netflow-with-template.cap.zip

Does it breaks the RFC?
nfcapd interpret data flowset incorrectly?

Thanks in advice.
Tibor

No valid security contact information is available. The email address in the AUTHORS file bounces and no replies are received from the source forge account. An email address for the project maintainer needs to be added for the private disclosure of security vulnerabilities currently affecting nfdump.

nfdump has this feature:

-B
Like -b but automagically swaps flows, such that src port is > 1024 and dst port
is < 1024 as some exporters do not care sending the flows in proper order.

Unfortunately this doesn't work for services running on higher ports. For example, it's quite common to run a webserver on port 8080, or an NFS server on port 2049.

In theory, all ports below 49152 are available for IANA to assign to services. In practice, the Linux kernel defaults to using ports 32768 and above for ephemeral ports.

So my first thought was to update the algorithm with several tests:

• if src port < 49152 and dst port >= 49152, then swap
• if src port < 32768 and dst port >= 32768, then swap
• if src port < 1024 and dst port >= 1024, then swap
• else leave alone

But this begs the question, why not simplify it to this:

• if src port < dst port, then swap!

That seems to work for the vast majority of cases. It would be rare to initiate a connection from a low port number to a higher port number; either the destination is way up in the ephemeral range, or the source has explicitly bound to a low port number. (Only examples I can think of are peer-to-peer apps and this)

This then suggests another feature. In nfdump you can aggregate by srcport, dstport, or any port. The latter counts each flow twice, once for src and once for dst.

It would be useful to have a new aggregate "minport" to aggregate on the lower of src and dst ports. This would in the vast majority of cases show you the service being used, without the extraneous noise of ephemeral ports mixed in. (A side effect is that flows both to and from that port would be aggregated, so heavy uploads and heavy downloads would both count)

However, I think this can be generalised.

Note that you can also currently aggregate by srcip, dstip or any ip. It would be possible to add new aggregates for the ip address corresponding to the lower port and the higher port in the packet respectively. This would show you traffic in/out of server and traffic in/out of client respectively.

But rather than adding a whole load of new aggregate types like "srvip" and "cliip", I think it would be better to have a single flag which changes the meaning of "src" and "dst" so that "src" is the side with the higher port, and "dst" is the side with the lower port.

Setting this flag, and aggregating on dstport, would give the minport behaviour I described above. Setting this flag and aggregating on dstip would give the total traffic in and out of a given server (i.e. "busiest server"). Aggregating on srcip would give the total traffic in and out of a given client (i.e. "busiest client")

Example:

srcip:srcport    dstip:dstport  bytes
1.2.3.4:45678 -> 192.0.2.1:80   200KB
19.2.0.1.1:80 -> 1.2.3.4:45678  400KB

with this flag becomes:

srcip:srcport    dstip:dstport  bytes
1.2.3.4:45678    192.0.2.1:80   200KB
1.2.3.4:45678    192.0.2.1:80   400KB

Im trying to find out why cflow is not recognised in RRD/NFSEN. With nfdump (nfdump -r nfcapd.datetime) im able to read the nfcapd files without issue.
Does anyone have a hint in the good direction please?

This is from the syslog:
[code] Error GenGraph: Profile: live, packets-day: parameter 'X' does not represent a number in line STACK:[/code] (Where X is the router's name)