[c-nsp] 3750 tcam log

[Brian Turnbow]

Hello Everyone,
I have a 3750 stack running 12.2(35)SE2 that had the cpu shoot up this
weekend and imediately thought that we had exhausted our tcam space but
looking it seems that this is not the issue.
We have prefered routing and 9 routed interfaces actually configured.
There was no jump in the number of routes over the weekend , so I am
trying to nail down what caused the jump.
3750E-Jenner#sh platform tcam utilization

CAM Utilization for ASIC# 0                      Max            Used
                                             Masks/Values
Masks/values

 Unicast mac addresses:                        400/3200         19/87
 IPv4 IGMP groups + multicast routes:          144/1152          6/26
 IPv4 unicast directly-connected routes:       400/3200         19/87
 IPv4 unicast indirectly-connected routes:    1040/8320        192/1436
 IPv4 policy based routing aces:               512/512           2/2
 IPv4 qos aces:                                528/528          82/82
 IPv4 security aces:                          1024/1024         80/80

What worries me is this

3750E-Jenner#sh platform tcam log-results


================================================================
                       CAM Log Results
----------------------------------------------------------------
Total Number of PortASICs: 1

  ASIC 0
    Lookup "Invalid", value 0
    TCAM Index 0, TCAM Table Index -1
    Cam Log Keys
      key-0: 0F-E3FFFF7E-BEFFFD7F
      key-1: 05-00088002-00000000
      key-2: 01-00118010-03008000
      key-3: 01-00118010-03008000

  Notes:
    a) key-0 is most recent cam key
    b) key-0 contains lsb's and key-3 contains msb's
    c) watch for Lookup field in cam key for validating results
    d) TCAM Table Index -1 indicates invalid results
================================================================


Lookup invalid and table index -1 don't look very promising but I cannot
find anything on the web 
Can anyone offer a clue as to if this is a problem? 
I tried clear ip route * but that had no effect.
As the stack is in production I have not reloaded yet and am trying to
see if it can be avoided.

Thanks in advance

Brian