With most devices that sample NetFlow, there is an export of the sample rate in the flow record or an option template. The collector then uses that sampler information to multiply results (packet and byte counts) to arrive at traffic use numbers that more closely reflect actual bandwidth use.
That’s all great Scott, but what is so special about the Nexus 7000?
In researching sampling, option templates, and collector multipliers, I read a Cisco doc that explained how the Nexus 7000 sampled NetFlow configuration works on the F2 and F2e line cards.
The general school of thought when sampling is that you configure a sample rate that gets used as a literal indicator of how many packets from the total are sampled. But with the F2 and F2e line cards, Cisco by default samples at 1 in 100 packets.
This means that if you configure a sampler at 1 to 1, you are actually sampling at 1 in 100.
So what’s the problem?
The problem is that the collector sees an option template telling it that the sample rate is 1. The collector multiplies packet and byte counts by 1, and understates the bandwidth use.
That’s no big deal, I’ll just change my sampler to be 1 in 100.
Doesn’t work that way. If you make that configuration change, Cisco takes your literal 1 in 100 sample rate and applies the default sample rate of 100 to that. You are actually sampling at 1 in 10,000. But because the collector received an option template telling it the sample rate was 100, bandwidth is drastically understated because the multiplying factor is not correct.
Here is another interesting configuration point. If you specify a sample rate of 1 in 4956 (or higher), Cisco now uses your sampler configuration as the actual sample rate. Sampling is done at a 1 in 4956 packet level, passes 4956 down to the collector as the sample rate, and the collector multiplies packet and byte counts by 4956.
My point is that you need to be aware of the vendor default sample rates and flow rate limiters when you are working with sampled NetFlow.
Having fun yet?
The good news is that on our collector, we can override the sample multiplier and get you bandwidth use results that mirror the actual traffic numbers.
So what is all the fuss about sampling?
If you have read my past blog posts, you probably already know that I am not a big fan of sampling. Sampled traffic reporting is great when you want to look at trends. But security analysts, who use flows for network security forensics and incident response, don’t want 1 out of every 100 packets. They want, and need, every single one.
When you sample flows, you only see a percentage of the traffic and you are limiting visibility. Sampling technology simply doesn’t provide the full story. It’s like only reading every 100th word in a novel. At the end of the story, you have a vague outline of what happened and who the characters were, but little more.
Even if you take into account the fact that we apply a multiplier, you are really only applying the sample multiplier to the sampled traffic, not all of the traffic.
What options do you have when looking to get around having to sample?
Offload the NetFlow function to a NetFlow Probe Appliance. The probe will take in mirrored traffic streams and create NetFlow record exports. You eliminate the resource burden on the network device and move it to the probe. The probe in turn is giving you 100% NetFlow visibility. You can also gain insight into network performance by metering latency, jitter, and packet loss. The probe also provides detailed layer-7 analysis of your DNS traffic to immediately alert when malware uses DNS for information exfiltration or command and control.
If you are currently sampling NetFlow and would like better network traffic accounting, we can help you with your NetFlow configuration and reporting.