We’ve noticed that HP is definitely making inroads into the switch market. People are still buying Cisco routers, but consumers are realizing that they can use less expensive switches on the periphery. The list of features on the HP Procurve is impressive, however, their promptness to market a feature doesn’t mean it was implemented well, or even free of bugs. Read more »

Michael Patterson
Scrutinizer Product Manager

We get a lot of questions on this topic. Personally, I generally deflect to some of the stuff we have posted on YouTube. Even though this webcast was recorded using Scrutinizer v6.X, I think the content is still very informative, if you have questions regarding the differences between sFlow and NetFlow collection for network traffic analysis.

 

Read more »

Jon Mills
Marketing & Public Relations Manager
Follow Me On Twitter

If you’ve done any comparison reading regarding the differences between NetFlow and sFlow, then you understand that NetFlow provides a much broader visibility into your network traffic stream, as opposed to being limited to the sample packets that sFlow provides.

Usually, when a person asks which I like better, I vote for NetFlow, simply because I’d rather see the whole story, as opposed to x% of it (based on sampling rate).

So if NetFlow is so great, why would a Cisco router support NetFlow sampling, when it can do so much more?

Read more »

I really should have written this a long time ago, but I guess sometimes inspiration is only realized when a current need slaps you in the face…

What is sFlow and how does it work?
sFlow is a sampling technology that was first introduced in 1991 by HP. Now, if there’s only one word that you need to remember in this whole blog post, please make sure it’s the word sampling. If you can remember that, everything following this paragraph will make perfect sense.

My wife is a big fan of Jelly Belly jelly beans. She loves them. So I think I will use this addiction for illustrative purposes.

Imagine you are at the mall (if you are wondering why are you at the mall in the first place, just imagine you were forced to go).

So anyway, you go to the local, over-priced candy shop, and you buy a one pound bag of assorted jelly beans. Within this one pound bag of assorted flavors, there are a total of 300 jelly beans.

When you setup your switch for sFlow, there are two portions you have to configure. The first being the polling interval, the second being the sample rate.

Polling interval counts the jelly beans in the bag
Now the polling interval functions as the counter for a small block of time. If you set the polling interval for 60 seconds, the switch is counting all of the packets that have gone through that interface in the past 60 seconds, and then exports that count. So when your switch exports these flows to your collector, it is saying, “Hey! There are 300 beans in this one pound bag!”

Make sense so far?

Sampling your jelly beans
Okay, now if your household works like mine does… you never actually get to eat the whole bag of jelly beans. I only get to eat about one out of every 50 jelly beans. So when I grab that one jelly bean, it’s luck of the draw. I get what I get; unless it’s the black liquourish type, and I just throw those back and try again.

Me randomly grabbing that one jelly bean is much like that second configuration, which is the sampling rate. With the sampling rate, you are telling the switch to sample one out of every X amount of packets that pass through the interface.

In this illustration, my sampling rate for the jelly bean bag I bought was 1/50. Easy right?

What can you learn from sampling?
Consider this: If my sampling rate is 1/50, I’m only getting six jelly beans out of the full 300. (grumble grumble)

But let me tell you about the six jelly beans I did get.

Out of the six I grabbed, I got (two) cherry flavored, (one) kiwi and (three) buttered popcorn.

Looking at the jelly beans that I did get, what conclusions can you come to?

Judging by samples that I took, can you tell me exactly how many of the 300 jelly beans are black liquorish? No.

Can you tell me exactly how many of the 300 are kiwi flavored? No, you can’t.

However, judging by the fact that out of the six samples that I took, three of them were popcorn, you could speculate that there may be quite a few popcorn jelly beans in that bag. Maybe the majority are popcorn flavored. However, you can never be 100% certain of the full content of that bag, without trying each and every one individually.

…and that is the difference between sFlow and Cisco NetFlow.

With Cisco NetFlow, you know that there are 300 jelly beans in the bag. You also get the luxury of eating them all, so you know exactly what kinds of jelly beans you have.

With sFlow, you will always know how much traffic is being generated, much like you know there are 300 beans in the bag; but since you are only sampling 1/50 of the packets, you will only see 1/50th of the content within those packets. You won’t truly know how much of that traffic is HTTP, SMTP or HTTPS based. However, if a lot of your samples happen to be HTTP traffic much like that buttered popcorn flavor jellybean, then it can give you a hint that there could be a lot of HTTP traffic on that interface.

Summary
When using Scrutinizer to monitor your sFlow switch, be sure to remember that your port utilizations are correct. Scrutinizer is aware that there are 300 beans in that bag. Be aware that the statistics regarding Top Hosts, Top Conversations and Top Protocols are all based on that sampled traffic.

You didn’t think you were gonna get to eat all the jelly beans, did you?

-Nate

Over six months ago we completed a technical review on the differences between sFlow and NetFlow, which was published in NetworkWorld.com. In this review you will find specific reasons why and when to use one or the other.

Because Scrutinizer supports all major versions of sFlow and NetFlow, we don’t need to pick sides on which one is better.  I will say that we periodically get calls from customers wondering why the sFlow statistics from a switch aren’t the same as those reported by NetFlow on the directly connected router.  They are comparing the totals for a specific IP address.

The reason is simple:

• sFlow samples anything and is network layer independent (e.g. IPX, NetBEUI, IP, etc.)
• NetFlow accounts for 100% of everything IP based (i.e. not IPX, NetBEUI, etc.)

I would consider this:

• If your network supports a heterogenious multiprotocol environment, you might want to consider sFlow switches.
• If your network supports only IP based traffic, a sFlow or NetFlow switch will do.
• If you want 100% accuracy on network traffic and accountability, I would select a NetFlow capable switch.  Only Enterasys and Cisco market a NetFlow capable switch.

Questions you may have:
Q: Why don’t more switch vendors support NetFlow at the switch?
A: Usually because of the cost to engineer and implement a NetFlow capable switch.

Q: I heard that sFlow is in hardware, and that NetFlow is in software and causes more overhead for the switch.  Is this true?
A: Yes and no,  Cisco routers use software and CPU to export NetFlow.  Many switches support NetFlow in hardware.

“The Enterasys Matrix N-Series switches collect NetFlow statistics for every packet in every flow without sacrificing performance based on the nTERA ASIC capabilities. Whether the network is operating at 10/100/1000, Gigabit or 10 Gigabit speeds – the NetFlow data can be leveraged for performance management and network behavioral analysis to ensure the confidentiality, integrity and availability of information.”

Trent Waterhouse, Enterasys Networks, Inc.

Q: How much does it cost for a ‘flow’ capable switch?
A: I’ve seen the following street prices: D-Link DGS-3627 sFlow switches as low as $2600 and Enterasys N1 series NetFlow switches for  ~$15,000.  I would not limit the decision to ‘flow’ support.  Foundry, Juniper, etc. make great flow capable hardware as well. Always evaluate before you buy.

Q: We leverage NetFlow for Network Behavior Analysis (NBA), will sFlow be as useful as NetFlow?
A: Remember, sFlow is sampling, so a host that scans a subnet is not as likely to be picked up by analyzing sFlow samples as it is with NetFlow; and it may not matter.  Most switches today are performing NBA at the switch, which we cover in our white paper.

Bottom Line
NetFlow or sFlow support should be on the list of features to consider, along with SNMP and NMS integration, when purchasing your next switch. We feel that a best of breed solution is the ideal investment for your company.  If you have other questions, just call me (207)324-8805.

Michael Patterson
Scrutinizer Product Manager