more netflow problems

Mar 23, 2008 4 Replies
more netflow problems open original image

I though I resolved my netflow problems, but they are back again. 6509 w/ Sup2 MSFC2 PFC2 IOS 12.2(18)SXD7b



Most of my interfaces are customer handoffs, so I add:



ip route-cache flow



to the interfaces, as well as having:



mls flow ip interface-full mls nde sender version 5



Things works fine. The interfaces are configured like this:



interface FastEthernet 7/15 ip address 1.1.1.1 255.255.255.0 ip route-cache flow



The port is given to customer, and they use the ip address as their default gateway.



The problem is when I do a customer interface like this:



interface FastEthernet 7/16 ip address 1.1.1.1 255.255.255.252 ip route-cache flow



ip route 1.1.2.0 255.255.255.0 1.1.1.2 250



In this case the customer takes the handoff and puts it into their own router, so the /24 is behind the router, and the /30 on the interface is used to connect the router.



In this setup, netflow data doesn't jive. The customer I did this for is pulling 3Mbps according to MRTG on Fe7/16 - yet the Netflow reports are only showing a couple kbps. Even my global netflow stats don't account for it.


Any ideas? Lately I've been weary of netflow. The reports dont seem to match MRTG, and in some cases is really off (like MRTG reporting



8Mbps, Netflow reporting 3Mbps).

I've been thinking about using RTG to poll and store SNMP stats for my



95th reporting instead of netflow and flow-tools.

Thanks John


For what your trying to do, SNMP polling is the way to go. Netflow is NEVER 100% accurate on counting packets (UDP is always troublesome). I'm work at a large enterprise and we use both SNMP interface polling (VitalSuite) and netflow, and the two are used for very different purposes. We keep track of all interface stats (traffic in/out, and errors in/out) on a 5 minute intervals and this is used to determine if we are having interface issues when problems are reported. At a glance we can pull up a graph and see if we have errors or bandwidth problems. Interface counters are ALWAYS 100% accurate (unless someone clears counters and then the data is wrong for the 5 minute interval). Netflow data is used to debug applications and doing analysis of traffic flows for QoS.

Well, thats why I am leaning towards RTG - which appears to take the raw snmp counters (like MRTG) but stores in a database for 95th percentile reporting - which is a must for us.

My only concern with RTG is it appears to be a dead project - last code release was 2003.

That may be the case but a) it still works, and b) the author still answers when emailed :-)

Failing that, Zabbix stores every poll it takes in SQL like RTG does although it may be a little OTT for what you're trying to do, and it can be tedious to set up.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required