Interpreting NNA Data
Re: Interpreting NNA Data
In wireshark, I am using the CFLOW decoder.
Be sure to check out our Knowledgebase for helpful articles and solutions!
Re: Interpreting NNA Data
Thanks for the quick response!
Re: Interpreting NNA Data
Your welcome
Be sure to check out our Knowledgebase for helpful articles and solutions!
Re: Interpreting NNA Data
SO after 6 months I apparently got an All-Star to work on this. Here is what he said (He is still working on it, just giving you guys an update):
Hi Ayrek,
I appreciate the feedback , I was wondering why the earlier captures didnt show what I was expecting but it seems that was just because the capture was cut before the Fortigate could send the data template.
I setup an environment quickly and I can now see it for myself in the netflow v9 captures as well.
Concerning the Nagios query on the BYTES supposed to be IN_BYTES , I think that's just mislabeling on the part of the wireshark cflow dissector.
According to
https://www.cisco.com/en/US/technologie ... a3db9.html
What identifies a field type is just a numerical value and not a string , the BYTES string is just something that the wireshark dissector appends to make it easier to read.
For example , cisco defines type 1 as IN_BYTES , in the capture we can also confirm that FortiOS properly sets type 1 and that in the payload of the packet itself , it's not a string value , so that BYTE label is purely interpretation on wireshark's part.
Bytes-NETFLOW-Fortigate.PNG
The label PKTS also has the correct type value (02) which is IN_PKTS as defined by Cisco.
That by itself seems to be fine , what I think the real issue is when I look at actual data flows. The value for IN_BYTES and OUT_BYTES are the same , it is also the same for IN_PKTS and OUT_PKTS , if these two values (IN & OUT) are being added up by Nagios potentially that is why there is some incorrect data showing up.
I see this as well in your capture (if I read it manually , despite not having the template in the capture) your first 4 fields in the capture , the first two have the same value (IN/OUT BYTES) and the next set also has the same values.
When looking at the template for ASA's it seems to fully circumvent this by just offering the BYTES_TOTAL of whatever flow it is exporting instead of a value for each direction , so less potential mistakes involved.
I have attached the sample capture and a screenshot just to point out what I was looking. Feel free to share this with Nagios if they want to sanity check my theory.
Cheers,
Hi Ayrek,
I appreciate the feedback , I was wondering why the earlier captures didnt show what I was expecting but it seems that was just because the capture was cut before the Fortigate could send the data template.
I setup an environment quickly and I can now see it for myself in the netflow v9 captures as well.
Concerning the Nagios query on the BYTES supposed to be IN_BYTES , I think that's just mislabeling on the part of the wireshark cflow dissector.
According to
https://www.cisco.com/en/US/technologie ... a3db9.html
What identifies a field type is just a numerical value and not a string , the BYTES string is just something that the wireshark dissector appends to make it easier to read.
For example , cisco defines type 1 as IN_BYTES , in the capture we can also confirm that FortiOS properly sets type 1 and that in the payload of the packet itself , it's not a string value , so that BYTE label is purely interpretation on wireshark's part.
Bytes-NETFLOW-Fortigate.PNG
The label PKTS also has the correct type value (02) which is IN_PKTS as defined by Cisco.
That by itself seems to be fine , what I think the real issue is when I look at actual data flows. The value for IN_BYTES and OUT_BYTES are the same , it is also the same for IN_PKTS and OUT_PKTS , if these two values (IN & OUT) are being added up by Nagios potentially that is why there is some incorrect data showing up.
I see this as well in your capture (if I read it manually , despite not having the template in the capture) your first 4 fields in the capture , the first two have the same value (IN/OUT BYTES) and the next set also has the same values.
When looking at the template for ASA's it seems to fully circumvent this by just offering the BYTES_TOTAL of whatever flow it is exporting instead of a value for each direction , so less potential mistakes involved.
I have attached the sample capture and a screenshot just to point out what I was looking. Feel free to share this with Nagios if they want to sanity check my theory.
Cheers,
You do not have the required permissions to view the files attached to this post.
Re: Interpreting NNA Data
The Wireshark mislabeling on the part of the wireshark cflow dissector that the Fortigate tech said it good to know that the name really doesn't matter as long as the data is sent correctly.
But I agree, the IN_BYTES and OUT_BYTES are the same , and also the same for IN_PKTS and OUT_PKTS is what is causing the issue.
If that can be fixed, I feel it will resolve the problem.
But I agree, the IN_BYTES and OUT_BYTES are the same , and also the same for IN_PKTS and OUT_PKTS is what is causing the issue.
If that can be fixed, I feel it will resolve the problem.
Be sure to check out our Knowledgebase for helpful articles and solutions!
Re: Interpreting NNA Data
I thought this was closed. I apologize. Long story short, some time ago, they let me know they will register it as a bug. They gave me absolutely no time of completion so I think we all know where this is going. 
Close the thread. I apologize for not having an actual solution.
Close the thread. I apologize for not having an actual solution.