[c-nsp] Sup2T CoPP

[Phil Mayers]

Couple of questions for people running Sup2T CoPP.

First, has anyone had crash/reload when fiddling with the CoPP policy 
under 15.1(2)SY2? We had a box die the other day, and I'm wondering if 
there's a "safe" way to work with it. I have a TAC case open, but no 
response as yet.

Second, for my own curiosity I'm wondering if anyone has any deep 
insight into the special built-in CoPP class-maps e.g.

class-map match-any class-copp-icmp-redirect-unreachable
class-map match-all class-copp-glean
class-map match-all class-copp-receive
class-map match-all class-copp-options
class-map match-all class-copp-mtu-fail
class-map match-all class-copp-ttl-fail

...and so on. Their functions are pretty obvious - although they lack 
"match" statements in the IOS config, they seem to correspond pretty 
closely to the "type control-plane" / "match exception" class-maps under 
NX-OS, and presumably offer a way to use CoPP rather than platform (nee 
mls) rate-limits on a type of punt traffic.

(I note sup2t comes with the glean RL enabled by default, rather than 
using the special glean class-map in the default CoPP - anyone know why)

What I'm specifically curious about are what those match precisely; the 
command "sh platform hardware acl tcam A ip qos" shows the TCAM matches 
pretty clearly, but for the "special" stuff there appear to be 
mysterious non-zero ACOS/AS values which I assume are some internal fields.

Finally, in the dumped TCAM, there appears to be a fair bit of 
duplication, in particular for value/mask entries of 
224.0.0.13/255.255.255.255 and 224.0.0.0/255.255.255.0. Anyone know why? 
The reason I ask is that before my crash, it looked like there had been 
some horrible combinatorial explosion of value/mask entries after my 
CoPP edits, and I'm wondering if this was my fault or IOS.

Cheers,
Phil