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’.

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!

🙂

Kelly Kading

Kelly Kading is the Regional Manager for the Northeast US here at Plixer. Kelly strives to deliver the best customer experience possible. He enjoys building relationships with his customers and wants to find the solution to best meet their needs. When not in the office, Kelly tries to always be in the outdoors. His favorite hobbies are hiking, snowshoeing, traveling and generally just being outside!

Related