Working in technical support I get asked a lot, “I enabled NetFlow on my router, why don’t I see outbound traffic?” This is because NetFlow version 5 only supports ingress flow monitoring and they don’t have NetFlow enabled on all interfaces. In NetFlow v5 outbound traffic is calculated by the idea what goes in must go out (or stop at the router) so, it’s necessary that all interfaces are monitoring ingress traffic to get an accurate representation of outgoing traffic. So, if ingress monitoring has been working great all along why enable egress monitoring?

Read more »

Paul Dube
Technical Support
Follow me on Twitter

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

Since the launch of our Systrax community website, we have written over three hundred blogs and generated two unique cases of Carpal Tunnel to bring you informative and sometimes quasi entertaining content.

I think its time though to lasso in some of the highlights over the year into one summary blog for quick and easy reference. This blog will link to others that have answered some of the more commonly asked questions. We hope you enjoy it.

Read more »

How do you know if the NetFlow collector is saving or even getting all of the NetFlow datagrams that are being sent to it or that it is receiving? It is important to know if any flows are missing.

Why do we care?

This is a great question. We care because a loss of flow exports is usually caused by one of three things:

1. The network dropped some packets
2. The router can’t keep up
3. The NetFlow receiver / collector can’t keep up

NetFlow sequence numbers are becoming increasingly important. When building a NetFlow collector it is important that the engine scales while staying accountable. If you look at the NetFlow v9 packet format you will notice something called the package_sequence.

Read more »

I was looking at a WireShark packet capture of some IPFIX traffic coming from a Nortel switch and quickly saw a few things that puzzled me.  At first, I started splitting hairs because I was thinking that if Nortel is going to market IPFIX support, it should adhere to the standard (RFC 5101).

Then again, it might have better luck working with the various NetFlow traffic analyzer solutions on the market if it makes the exported data look like Cisco NetFlow v9.

Read more »

____________________________________
Jim Dougherty aka "Jimmy D"
Lead PreSales Support Engineer and
Netflow Evangelist for Plixer International!

Follow me on Twitter
http://twitter.com/jimmydnet
____________________________________

Q: What is the difference between Cisco NetFlow v9 and Cisco NetFlow v5?
A: Four versions.

Heh heh, I slay me! Alright, sort of stupid I know. I’ll get serious about this.

NetFlow v5 is by far the most popular version of Cisco NetFlow. I would say over 90% of our customer base uses NetFlow v5.

Read more »

Michael Patterson
Scrutinizer Product 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

IPFIX is the same as NetFlow v9?
We have several dozen customers collecting IPFIX from their Nortel hardware. Mostly they have 5500 and 8600 series switches and routers. The biggest issue we find is that somehow customers are getting the impression that it is almost exactly the same thing as Cisco NetFlow v9 – and this is true… well sort of.

Nortel supports flow sampling with IPFIX
IPFIX is basically NetFlow v9. However, Nortel is only sampling packets on most of their switches (e.g. 5500, 5600 and 8300 series). The sampling is done in a round robin fashion, similar to sFlow technology. Nortel claims that the 8600 series can sample 100%, but our customers that I’ve spoken with are still seeing sampling and not 100%. Perhaps someone from Nortel could comment on this? Then there is the hash overflow [pdf] issue. You can find information on configuring IPFIX on Nortel switches on our web site.

Nortel gives away IPFIX in base code
In the past, IPFIX support required a purchase of the advanced routing software on top of the 5500 switch. Recently, I heard that they are putting IPFIX support in the base code of the new 5600 series. I would contact your local Nortel team for an update on where the company is going with their products. Sometimes you can find out a whole lot after signing an NDA.

Nortel is still restructuring
Nortel isn’t out of their financial woes yet. However, certain divisions are seeing success in sales.

Jon Mills
Marketing & Public Relations Manager
Follow Me On Twitter

Every once in a while I need to stretch my legs, and generally I go to see how the developers are doing up in the penthouse. Although they occupy the premium space here at Plixer, the penthouse has no windows. The view wouldn’t have been that great anyway as the penthouse overlooks the parking lot. Anyway, I went over to the coffee machine to get a cup of premium Joe (another perk). I spotted the quarter jar and looked both ways to see if anyone was watching.  I’m kidding…. I always pay.

I dropped in on the lab, and my counterpart, Mr. Flow Analytics had his nose almost pressed against his monitor. What are you up to? “Cool stuff,” he said. Then he brought up Wireshark and showed me some very interesting new fields available in Cisco NetFlow version 9 and IPFIX. Click to enlarge the screen capture below:

Notice the SRC_VLAN, SRC_MAC, etc.  These are all new fields and few Cisco NetFlow reporting software packages report on them. Very nice. Anyone interested in reporting on VLANs or MAC addresses using Cisco NetFlow?  Please contact me.

BTW: These are the new commands he typed into the Cisco 2800 router:

• ip flow-capture fragment-offset
• ip flow-capture ttl
• ip flow-capture vlan-id
• ip flow-capture icmp
• ip flow-capture ip-id
• ip flow-capture mac-addresses

The used Cisco 2800 router we purchased is now running alpha code from Cisco Systems, which  we are testing for some additional advanced features that can’t be discussed just yet. I don’t want to get in trouble with Cisco like Mix Master Mitch.

Sadly, not all my walks are this eventful, but I’ll be sure to check in on the developers again soon to keep you all informed.

Michael Patterson
Scrutinizer Product Manager
Follow Me on Twitter