2811 - 12.4(20)T1
WCCP / Negotiated return
I have a 4MB WAN link that is reporting 25MB. This is larger than the common double accounting issues.
My netflow collector is Fluke Networks Netflow Tracker3.04.
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.
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
description 4Mbps MPLS link
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
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.
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?
Im not sure I follow your question.
what kind if compression? Well we are seeing a mix of TFO and LZ. I dont believe any of the traffic woudl be more than the limitation of the 4MB WAN pipe.
is this a Netflow reporting problem or is it a WAN compression "fooling the reporting?
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...
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.
Hi Dan, thanks for the feedback.
I recall the double accounting issue was resolved in 12.4(15)T4. Since I am running 12.4(20)T1, I assume that bug is not a factor here.
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.
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.
I do have A tac case open and have found that this is an interoperability issue.
12.4(20)T1 just enabled Netflow to report detination interface of WCCP redirected packets.
Netflow is reporting both optimized and un optimized flows.
I have both ip flow ingress and ip flow egress on the serial link.