Hello,
I will answer the issues you listed separately below.
First issue is the Netflow TCAM notifications occurring repeatedly.
The messages "%EARL_NETFLOW-4-TCAM_THRLD: Netflow TCAM threshold exceeded, TCAM Utilization" indicate that the NetFlow ternary content addressable memory (TCAM) is almost full. The Supervisor Engine 720 checks how full the NetFlow table is every 30 seconds. The Supervisor Engine turns on aggressive aging when the table size reaches 90 percent.
The idea behind aggressive aging is that the table is nearly full, so there are new active flows that cannot be created. Therefore, it makes sense to aggressively age-out the less active flows (or inactive flows) in the table in order to make space for more active flows.
The capacity for each policy feature card (PFC) NetFlow table (IPv4), for PFC3A and PFC3B, is 128,000 flows. For the PFC3BXL, the capacity is 256,000 flows.
This issue with Netflow TCAM may happen when you set the NetFlow mask to "full" mode or there are too any flows - TCAM for NetFlow can overflow because there are so many entries. WCCP also uses Netflow resources in its operation. You can use the "show mls netflow ip" count command in order to check Netflow mode. Another solution to reduce number of entries is to change the sampling - which you did by modifying the sampling packet based to 4096.
Note that TCAM for packet forwarding and TCAM for NetFlow accounting are separate, so there is no impact to packet forwarding because of this issue.
Second issue is related to CPU spikes on the switch. Looking into the packet dump you collected, it seems that packet is sent to CPU for processing - dest_indx 0x380 is a Unicast packet punted to CPU - CPU port (15/1).
------- dump of incoming inband packet -------
interface Vl56, routine draco2_process_rx_packet_inline
dbus info: src_vlan 0x38(56), src_indx 0x4A(74), len 0x56(86)
bpdu 0, index_dir 0, flood 0, dont_lrn 0, dest_indx 0x380(896)
38020400 00380000 004A0000 56000000 002F0438 00000400 00000000 0380A9D1
mistral hdr: req_token 0x0(0), src_index 0x4A(74), rx_offset 0x76(118)
requeue 0, obl_pkt 0, vlan 0x38(56)
destmac 00.19.A9.9D.FA.C0, srcmac 00.D0.83.05.A0.73, protocol 0800
protocol ip: version 0x04, hlen 0x05, tos 0x00, totlen 68, identifier 13053 df 0, mf 0, fo 0, ttl 30, src 192.168.56.195, dst 10.0.0.1, proto 47
Due to this packets there was likely high CPU utilization by interrupts.
You mentioned that this traffic source was related to WCCP. Also, protocol type shows 47 - which is GRE.
The reason this causes high CPU is indeed that there is HASH assignment instead of MASK. Using HASH is not recommended on Catalyst 6500 switches.
The assignment method in WCCP determines how traffic will be distributed among multiple WCCP clients in a given service group. There are two assignment methods available, hash-based and mask-based. The assignment method chosen for a given service-group is negotiated between the router and the WCCP clients.
The negotiation of the assignment method is performed between the router and the clients via the WCCPv2 ISU and WCCPv2 HIA messages, respectively. The Cisco Catalyst 6500 supports both the hash-based and mask-based assignment methods and will advertise these capabilities in its ISU messages. The WCCP client must be configured for mask-based assignment and then implicitly choose the mask-based assignment method by first observing the supported method in the router's ISU message and then advertising mask-based assignment in its subsequent HIA messages.
The hash-based assignment method is the default and will be chosen unless the client is configured to support the mask-based assignment method.
1. MASK assignment:
The combination of an ingress traffic intercept method with mask-based assignment provides a full hardware-based traffic assignment method. This means that CPU resources are not used with this type of assignment, so there would not be CPU spikes.
Traffic is filtered for WCCP redirection using an Access Control List. The WCCP mask value is then applied to the redirect ACL to create entries in the Cisco Catalyst 6500 ACL TCAM[3]. The TCAM entries are used to provide hardware accelerated lookups and to derive a specific WCCP client which will service the traffic flow. In this way the forwarding path is performed completely in the Cisco Catalyst 6500 hardware resources.
2. Hash-based assignment method is supported but not recommended on the Cisco Catalyst 6500. A hash-based assignment method will utilize a combination of software and hardware forwarding resources. Traffic flows will need to be forwarded via software initially while also setting up flow entries using the Cisco Catalyst 6500 Netflow resources. This approach is certainly viable for some deployments but is not the best practice solution for the Cisco Catalyst 6500.
Kind Regards,
Ivan
This session will provide an opportunity to learn and ask questions about Cisco Catalyst Switches IOS architecture, and how to troubleshoot any unexpected reboots and other errors on switches.
Ivan Shirshin is a customer support engineer in High-Touch Technical Services (HTTS). He is an expert on Routing, LAN Switching and Data Center products. His areas of expertise include Cisco Catalyst 2000, 3000, 4000, 6500, Cisco Nexus 7000, ISRs, as well as Cisco routers ASR1000, 7600, 10000 and XR platforms. He has over 7 years of industry experience working with large Enterprise and Service Provider networks. Shirshin holds a CCNA, CCNP, CCDP, and CCIE (# 43481) in routing and swtiching, as well as XR specialist certifications. 
Naveen Venkateshaiah is a customer support engineer in High-Touch Technical Services (HTTS). He is an expert on Routing, LAN Switching and Data Center products. His areas of expertise include Cisco Catalyst 3000, 4000, 6500, and Cisco Nexus 7000. He has over 7 years of industry experience working with large enterprise and Service Provider networks. Venkateshaiah holds a CCNA, CCNP, and CCDP-ARCH, AWLANFE, LCSAWLAN Certification. He is currently working to obtain a CCIE in routing and switching.
