cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1539
Views
0
Helpful
6
Replies

Inaccurate Netflow Data?

jason.williams
Level 1
Level 1

I'm having a strange issue. We have a router that is connected to an OC12 and it is sending ingress netflow data on all layer 3 interfaces.

The thing that I'm seeing is that the bandwidth utilization will go over the bandwidth of the OC12. I've seen spikes as high as 900Mbps.

Now these are only spikes and will only appear over a one minute sample, so it is not something that's maintained, but it is still an issue because now I'm afraid that I'm getting bad data.

Any thoughts?

Thanks.

Jason

6 Replies 6

Jan Nejman
Level 3
Level 3

It is very strange. Which analyzer do you using? Try contact your software distributor for more detail debugging.

I noted that I found the similar problem in Scrutinizer. Scrutinizer is counting the long time flow (i.e. 500MB data flow) in the exporting time. So it producing a spice 500MB in one minute instead of distribution of flow in the time.

Jan

I'm actually using 2 right now in trying to figure this out.

Lancope Stealthwatch and NetScout

Both of them are showing the same spikes over the bandwidth. However I'm seeing another odd thing between the two of them. The graphs are not identical, one will have a spike where the other doesn't.

Overall, they're pretty close, just the odd spike. The main thing is that they are both showing the same spikes that are over the OC12 bandwidth.

Hello,

maybe you can solve this by decreasing active flow timeout. Which Cisco device do you using? Did you configure active flow timeout (or mls long aging)?

Jan

In this case, it's a 6509-E.

I did configure both.

active flow timeout is set to 1

mls long aging is set to 64

It is a strange. The configuration looks OK. Can you more debug which flow cause a spike? I.e. web traffic from source A to destination B? Is it one flow or more flows? Try to enable ip top talkers (ip flow-top-talkers) and compare your results with the "show ip flow top-talkers".

If you will find the same results in IOS CLI, the problem is with your line card. If not the problem will be with the analyzer.

Jan

"Spike" rings a bell:

mls aging long 300 <-- we use 64

"This breaks up long-lived flows into 5-minute segments. choose any number of seconds between 64 and 900; if you leave the default of 900 seconds (15 minutes) you will get spikes in your utilization reports." -- don't recall where I got this quote from.

There're a number of other variables to tune:

mls aging fast threshold

mls aging normal

ip flow-cache timeout active

ip flow-cache timeout inactive

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: