We had a customer approach us the other day with an nprobe issue. Apparently, he could see the NetFlow v9 data in Flow View of Scrutinizer, but he couldn’t report on the data. How come?

He sent us a Wireshark packet capture and brought up Flow View. Flow View is a way to see the raw flows (inclusive of all columns) being exported by a device.

Anyway, in Flow View everything looked normal, but then one of our developers spotted the word ‘post’ in front of a couple of import column names. We (and Scrutinizer) expect to see ‘octetDeltaCount’ and instead, the customer had configured nProbe to kick out ‘postOctetDeltaCount’.

Why did the nProbe kick out the wrong field?
The nProbe was exporting postOctetDeltaCount because the user asked for it. It was probably just a user error. Once we made the change it worked fine.

We decided to do a little research on this. The nProbe documentation states:

[ 23] %OUT_BYTES                 Outgoing flow bytes

rfc3954 states
                                           Outgoing counter with
                                           length N x 8 bits for the
   OUT_BYTES                    23   N     number of bytes associated
                                           with an IP Flow. By
                                           default N is 4

The above sort of makes it sound like OUT_BYTES is the element id to use for egress flows, but it isn’t. To the best of my knowledge, most commercial NetFlow exporters that implement egress flows do so with IN_BYTES.

We are a standards based company, so we looked to RFC 5102 to see what IPFIX had to say about this issue. It seems that IPFIX changes the names, but not the element ids, for IN_BYTES and OUT_BYTES to octetDeltaCount and postOctetDeltaCount respectively. NOTE: the implied directionality of IN and OUT was dropped.

The IPFIX descriptions further clarify how these elements are intended to be used.

Excerpt from rfc5102.

5.10.1. octetDeltaCount
Description:
The number of octets since the previous report (if any) in
incoming packets for this Flow at the Observation Point. The
number of octets includes IP header(s) and IP payload.
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
ElementId: 1
Status: current
Units: octets

5.10.2. postOctetDeltaCount

Description:
The definition of this Information Element is identical to the
definition of Information Element ‘octetDeltaCount’, except that
it reports a potentially modified value caused by a middlebox
function after the packet passed the Observation Point.
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
ElementId: 23
Status: current
Units: octets

If there is no middlebox (or middlebox function) involved, we shouldn’t get postOctetDeltaCount.

nprobe Commands
When in doubt, here is a basic configuration of nProbe that works great with Scrutinizer:

nprobe.exe /c --interface 0 --in-iface-idx 3 --out-iface-idx 5 –-local-networks 192.168.1.0/24 –-local-traffic-direction --collector 192.168.1.51:2055 --flow-version 5 –-lifetime-timeout 60

Summary
We got the customer up and running by using a different “nprobe configuration“  and he is now performing network traffic analysis with arguably the best NetFlow analyzer on the planet!

Brian

For a free 30 day trial of Scrutinizer, Download Now!

Sign up for Advanced NetFlow Training™ coming to a city near you!

Tags: best NetFlow Analyzer, ipfix, NetFlow v9, Network Traffic Analysis, nProbe, nprobe commands, octetDeltaCount, postOctetDeltaCount, Wireshark

This entry was posted on Thursday, March 4th, 2010 at 5:11 pm and is filed under NetFlow, NetFlow Analyzer, Network Traffic Analysis, Third Party Integration. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.