Phantom traffic reported by Netflow collector

Unanswered Question

Hi Todd,

Where exactly are you collecting the NetFlow data from? Is it the WAN interface itself or on the LAN side of the router? If it is the LAN side WCCP could be re-directing some of that 25 Mbps to a cache engine and not using the WAN.

Also, have you checked the Input\Output rates on the physical interfaces. I think NetFlow Tracker will source its information from the interface counters using SNMP. So it might be worthwhile validating these on the router itself.

Cheers

Stephen

I am exporting from the WAN interface only.

WCCP is 62 IN on WAN G0/1 / 61 IN on LAN G0/0

My understanding is that netflow exports are UDP and are not candidates for optimization. WCCP 61/62 are TCP permiscuious services only.

below is a snip of the WAN interface configuration

interface GigabitEthernet0/1

description 4Mbps MPLS link

bandwidth 4096

ip address 192.168.1.1 255.255.255.252

no ip redirects

no ip proxy-arp

ip wccp 62 redirect in

ip flow ingress

ip flow egress

load-interval 30

duplex full

speed 100

input and output rates fluctuate but this 4MB circuit is historically fully utilized. ( hence the need for WAAS :) )

so you are correct, SNMP is used to reporting bandwidth utilisation, (note bandwidth statement in the config above, I still cant see how it is feasable for netflow to report > 25MB of bandwidth based on the config and my knowlede of SNMP counters.

dstolt Tue, 03/10/2009 - 08:52

Hey Todd,

I'm looking at DDTS: CSCsm35350 which I think is the Netflow reporting issue that you mentioned. It says that the phantom packet count is caused by the return traffic from the WAE, which would be uncompressed.

What kind of compression are you seeing on the WAEs? Could your uncomressed traffic be roughly 20+ MB and compressed 4 giving you roughly 25 MB?

Just seeing if that fits your scenario?

Thanks,

Dan

dstolt Tue, 03/10/2009 - 13:35

What I posted is a IOS reporting bugs that counts the incoming WAN traffic (compressed) and also counts the traffic leaving the WAE (uncompressed) when using WCCP negotiated return, which seems to fit your situation. See below from the bug toolkit on cisco.com...

Symptom:

When configured with WCCP redirection, WCCP GRE return traffic may by counted twice. This can result in the accounting records (NetFlow input interface) and interface counters (incoming packets) being incorrectly incremented on the original incoming interface if symmetric paths are used, or on the RPF (reverse path forwarding) interface if asymmetric paths are used.

Dan

cfolkerts Thu, 04/16/2009 - 08:51

Todd,

Have you been able to find a code that fixes the Netflow issue? I am noticing our Netflow collector reporting high utilization rate as well just to find out the circuits are fine through Cacti and SNMP info.

Thanks

dstolt Thu, 04/16/2009 - 10:12

Guys,

According to DDTS: CSCsm35350, it is resolved in 12.4(15)T4 or 12.4(20)T1, however, if you are using versions that it's supposed to be fixed here, please open a TAC case and let the forum know the results as I'm very interested to see if there is a regression of this in the code or something else is causing it.

Thanks,

Dan

Actions

This Discussion