NetFlow graphs showing more traffic than supported on T1 circuit

We have several routers deployed with a single T1 WAN connection.

When monitoring these routers over NetFlow, I'm noticing that they will show far more data than supported over the link. Here is an example: http://grab.by/42H9

No idea what is causing this, anyone have any clue?

Find more posts tagged with

netflow

ppp

cisco

adtran

monitoring

Accepted answers

tylerlucas

Yeah sorry I wasn't more clear - Was in a bit of a rush yesterday.

This command breaks up long flows into one minute fragments. The problem I was having was specific to really long flows - specifically data synchronization etc. This caused a single flow, which took hours, to look like it occurred in a short period of time when it was finally exported.

All comments

mcbridea

I recommend opening a ticket on this. BTW - What does it show when you switch from Mbps to % util?

GZhytar

tylerlucas,

I've seen 2 similar cases last time with T1 PPP interfaces. They are probably caused by bug in Cisco IOS (not confirmed by Cisco yet). The problem is that router exports duplicated data inside NetFlow packets (if you open packet capture with WireShark, you can see that some flows inside packet have duplicates), so the amount of data exported by router higher then actual.

thanks

tylerlucas

Thanks for the responses guys.

When I switch to percent util, it shows a percentage high above 100%.

GZhytar: I was wondering the same thing. We are using Adtran devices - definitely wouldn't be the first bug I had seen! I did open a ticket with SolarWinds and I have a very helpful engineer working with me. I'll update as I get info. He agrees that the logical PPP interface is likely the culprit one way or another.

tylerlucas

Solved:

ip flow cache timeout active 1

Impaler

I'm not really clear on how this command would resolve this issue. Could you explain a bit? Maybe share your complete netflow config?

mcbridea

The Cisco equivalent is

ip flow-cache active 1 in the global config.

ecklerwr1

Very interesting topic to bring up...

Cisco: ip flow-cache timeout active 1

Here’s a brief list of other usual suspects:

NetFlow (routers): ip flow-cache timeout active 1
NetFlow (Catalyst switches): mls aging long 64
sFlow: polling interval 60
Netstream: ip netstream timeout active 1
J-Flow: ip flow-cache timeout active 1

The above listed examples each regulate the export of flows for their respective devices. You’ll notice how most of the ones listed all specify either 1 minute or 60 seconds. This is no accident…

With this configuration, you are specifying the device to export flow records every minute. This is important to set up, since NTA calculates utilization based on what it receives at 1 minute intervals.

If you forget to configure this, then your Cisco device, by default, will try to export flows every 30 minutes or until the flow cache becomes full, which will then pound the collector with flows. This can potentially skew your interface utilization.

tylerlucas

I scoured the forums for the answer to my issue. I'm surprised this isn't more well known. I wonder how many others have the same problem...

GZhytar

ecklerwr1,

awesome. Your answer as always brilliant.

thanks

mcbridea

This is now in a KB. We will be adding the Jflow, S-flow and Cat commands. NetStream is not supported.

http://support.solarwinds.com/kbase/ProblemDetail.cfm?ID=1542