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

Read more »

Jon Mills
Marketing & Public Relations Manager
Follow Me On Twitter

I’m doing some more work lately with Wireshark and Scrutinizer v7. I thought that the topic of egress vs. ingress might be interesting to some readers.  NOTE: Egress is only available in Cisco NetFlow v9 and not NetFlow v5.

IPFIX or NetFlow v9?
In theory, ingress and egress should work the same in IPFIX, which is based on NetFlow v9, but they are certainly different. Although they are very similar, don’t let any company tell you they are exactly the same. Many collectors that work with NetFlow v9 will puke when they receive IPFIX. Scrutinizer handles both with ease. Nortel supports IPFIX, as does/did Avici, which is now Soapstone Networks, Inc. Other vendors, such as Adtran and Enterasys, support NetFlow v9.

One annoying area where IPFIX and NetFlow v9 differ is in the labeling of fields: NetFlow v9 has ‘IN_BYTES’ and IPFIX labels the same field ‘octetDeltaCount’.  IPFIX probably renamed it because when talking about egress flows, IN_BYTES is sort of misleading.

Ingress vs. egress differences
NetFlow v9 Ingress is collected on traffic going into (i.e. inBound) an interface.  This is how NetFlow v5 collects data. To figure out outBound traffic volume, ingress must be collected on all interfaces and the reporting software then displays outbound traffic. What goes in must go out, right?  Ya, usually.

NetFlow v9 Egress is collected on traffic going out (i.e. outBound) of an interface.  Generally, it is used in combination with Ingress, but it doesn’t have to be. I’ll dive into this a bit more.

Why collect with egress?
Why collect with egress, if ingress worked so well with NetFlow v5? Because hardware such as WAN optimizers compress data.  Traffic compression with Cisco NetFlow means that what comes in 100 bytes might go out as 50 bytes. If only using ingress flows, the NetFlow reporting software will show 100 bytes outbound, even if it was compressed to 50 bytes. GASP!!! This is because it was calculated using ingress flows.

Tell me the truth!
If the router is exporting both ingress and egress and the NetFlow monitor can report on both without overstating utilization, you can see how much of each flow is being compressed. It’s pretty slick, but it requires that the NetFlow collector understand what is known as the flow “Direction”. If the field in the NetFlow v9 packet is a 0, then it is an ingress collected flow.  If the field is a 1, then it is an egress collected flow.

Ingress Flow with IPv6 (the same with IPv4)

Egress Flow with IPv6 (the same with IPv4)

The network traffic reports produced by the NetFlow analyzer need to be intelligent when dealing with ingress and egress flows. I feel that dynamically figuring out flow direction in mixed NetFlow v9 ingress egress environments is crucial, especially if the customer has hundreds of routers. If you are just setting up ingress, I would keep this blog in mind: “ip route-cache flow or ip flow ingress… Which do I use?”

Something else to think about
NetFlow traffic analysis is going to be taken to another level as Flexible NetFlow matures. Perhaps we’ll see it take advantage of what NetFlow v9 calls ‘OUT_BYTES’. (IPFIX, needing to be different, calls this same field ‘postOctetDeltaCount’.)

Now you might ask: how is it related to ingress or egress?  Stay tuned…

Michael Patterson
Scrutinizer Product Manager
Follow Me on Twitter

I was trying to find some real meat and potatoes on the differences between IPFIX and Cisco NetFlow v9. In my searches I kept coming back with an empty plate.

This is one of those times where I had to roll up my sleeves, dig into the RFCs and actually find out for myself.

A word about the RFCs
You probably already know that IPFIX RFC 5101 and RFC 5102 are derived from the NetFlow version 9 RFC, which was written by Benoit Clais, a business friend of mine. Actually, you’ll notice that Benoit worked on the IPFIX RFCs as well. Anyway and more to the point, what makes them different? I wanted some specifics!

The chicken or the egg?
NetFlow v9 came first. IPFIX made provisions for NetFlow v9 and added support for it. This is not a tough one to figure out if you look at the RFC numbers.  heh heh  Anyway, IPFIX lists an overview of the “Information Element identifiers” that are specified in Section 5 of the RFC and are compatible with the “field types” used by NetFlow v9.  These are basically the juicy details of information that can be exported by NetFlow. Some things you will notice right away:

• The very first ID ‘1′ NetFlow v9 calls it ‘IN_BYTES’ and IPFIX calls it ‘octetDeltaCount’.  This is a big deal because if we are talking about flows, is IN_BYTES really inbound data?
• Another thing I noticed is that NetFlow v9 defines 79 ‘field types’ and IPFIX defines the same 79, but goes on up to 238! Wow.
• Many of the Reserved Information Element identifiers are actually defined in NetFlow v9 (e.g. NetFlow v9 field type 3 is defined as ‘Flows’ and in IPFIX it is ‘Reserved’).  This is common when comparing the RFCs. NetFlow v9 defines field types 33, 34, 38, 39, etc with values. The same field types are all defined as ‘Reserved’ in the IPFIX RFCs. It was likely done to keep IPFIX compatible with NetFlow v9 (i.e. the chicken).
• IPFIX allows a vendor ID to be specified whereby the vendor can stick proprietary information into NetFlow and export anything they want and this isn’t limited to just SNMP information. I MEAN ANYTHING!
• NetFlow v9 on the other hand supports Flexible NetFlow which arguably is equally as flexible as IPFIX. More on this later.

So, there you have it (i.e. some meat and potatoes).  I could really dig in and blog in detail about the differences even more, but maybe I will later.  At first I have to digest the above. 

Oh, here is the NetFlow v9 format.

Michael Patterson
Scrutinizer Product Manager
Follow Me on Twitter