Zero'd packet count with Cisco ASA

[bwallace]

Good catch on the sidenote - I had seen some indications of that on various forums, but was unable to confirm it. So we can put that item to rest now, thanks.

About the discrepancy with bytes. I'm pretty sure I reproduced this here. My windows machine is sending flow data to NA, and I downloaded the same 648MB file as you did for your test. I immediately went to NA which showed only 588 MB. After 10 minutes had elapsed while looking into what could be wrong, I re-ran the report in NA to see that the file size (and then some) was accurately recorded.

I conclude that since NA reads the newest nfcap.d file every 5 minutes, the data was spread across two nfcap.d files, so of course the 1st look would appear to be inaccurate. Give it some time and then see if the bytes reported for that dst IP / download are accurate then

[reinaldo.gomes]

I did a couple more tests, and the results were the same. You said you ran a report, but reports don't show the total bytes the same way as queries, do they?
Another thing I've noticed is that, when the download is split between 2 nfcap files, it shows a slightly smaller total bytes at first, then it shows a doubled total after a few minutes, probably after the current file is finished. I Have no idea how this happens, but it has in all my tests. Also, it always messes up the numbers by treating "300MB" as if it were "300,000,000B", and then dividing it by 1024 to turn it into MB

[bwallace]

Sorry, I actually ran a custom query, not a report. Here is what is shown for my test, where bytes are accurately displayed. Are your results similar when you run a custom query like the one below?
(test download file is from http://fisica.ufpr.br/kurumin/kurumin-7.0.iso)

custom query NNA.jpg

[reinaldo.gomes]

For me, it still shows twice the real value. These are from yesterday:

download1.png

And there's this one I've just tried:

download2.png

It should be 648MB, but show up as nearly two times that number. Everything else is still messed up. But from you screen shot, I can tell it's something I'm doing wrong

What I do know is that the nfdump is not duplicated:

Code: Select all

[root@localhost flows]# nfdump -r nfcapd.201609291350 | grep 130.239.18.176
2016-09-29 13:54:02.169 CREATE  Ignore TCP        1.1.1.1:59400 ->   130.239.18.176:80         1.1.1.1:59400 ->   130.239.18.176:80           0        0
[root@localhost flows]# nfdump -r nfcapd.201609291355 | grep 130.239.18.176
2016-09-29 13:54:02.169 UPDATE  Ignore TCP        1.1.1.1:59400 ->   130.239.18.176:80         1.1.1.1:59400 ->   130.239.18.176:80         171  108.8 M
2016-09-29 13:55:03.349 UPDATE  Ignore TCP        1.1.1.1:59400 ->   130.239.18.176:80         1.1.1.1:59400 ->   130.239.18.176:80           0  209.7 M
2016-09-29 13:56:04.548 UPDATE  Ignore TCP        1.1.1.1:59400 ->   130.239.18.176:80         1.1.1.1:59400 ->   130.239.18.176:80           0  230.0 M
2016-09-29 13:57:05.738 UPDATE    2031 TCP        1.1.1.1:59400 ->   130.239.18.176:80         1.1.1.1:59400 ->   130.239.18.176:80           0  132.2 M
2016-09-29 13:54:02.169 DELETE    2031 TCP        1.1.1.1:59400 ->   130.239.18.176:80         1.1.1.1:59400 ->   130.239.18.176:80         171  680.8 M

Maybe it's counting all of the flows together, the partials and the final one...?

You're collecting data from your wan interface, right? I'm collecting from my lan interface, and the public IP shows as destination. In your case, it's the other way around.

[bwallace]

I'm just collecting data from my Windows machine, as outlined here:
https://assets.nagios.com/downloads/nag ... alyzer.pdf

Also, I see your query is aggregated differently than mine, which is only src ip, dst ip. I have to presume this is another quirk with how ASA writes flow data.
A good test on your side might be to use the doc I posted above. Configure your Windows workstation to export netflow and in NNA configure it as a source. Then compare data between that and your ASA source.
I'd do as much here, but do not have an ASA device to test with.

[reinaldo.gomes]

I did install nProbe on my home desktop and sent the data back to my office's NNA where I've been working at, and it worked perfectly, just as I thought it would. Very accurate and much more detailed than ASA's crappy netflow

Running 'nfdump -r' on the files fed by nProbe also kinda confirms my suspicions about the doubled totals for ASA's netflow: nProbe doesn't send a 'grand total' by the end of the flow, whereas ASA does. I believe NNA sums this grand total along with the flow's partials, thus doubling the final number. Not sure if you guys can do anything about it, though.

I would happily use anything else other than ASA as a source, but I've got a dozen remote sites to monitor, where there's nothing but an ASA and a couple 2960S (which have no netflow capability) to work with. Implementing new hardware is not an option in the near future. Gotta try and find a way to get something useful from ASA somehow.

[reinaldo.gomes]

I've made some progress. This documentation was key to understanding what had to be done:

"The significant events that are tracked include flow-create, flow-teardown, flow-denied (excluding those flows that are denied by EtherType ACLs), and flow-update. The ASA implementation of NSEL generates periodic NSEL events, called flow-update events, to provide periodic byte counters over the duration of the flow. These events are usually time-driven, which makes them more in line with traditional NetFlow; however, they may also be triggered by state changes in the flow."

I changed the event type from 'all' to 'update', and those extra bytes (from teardown event) were gone. Now it shows a correct 'total bytes':

Sem título.png

Unfortunately, there are still a couple issues, such as 'Bytes' field displaying some weird numbers, and 'Average Bytes/sec' showing "Average BITS/sec" instead. Got no clue about how to solve these two.

[lgroschen]

Hey reinaldo,

Glad you figured out your original problem. Did you want to open a new topic for the other issues you are having? It might help get them resolved faster if you create a new post.

If the bytes are showing as bits it may well be a bug.

[reinaldo.gomes]

Will do that, thanks. I guess we're done here for now.

[dwhitfield]

Glad to hear this particular issue is resolved. I am going to lock the thread. We look forward to your next post. Thank you for using the Nagios forums!