[c-nsp] 65K/S720/SXI - CoPP and RP SPAN order of operations?

[Jeremy Reid]

Hey 65K CoPP/SPAN gurus, 

Does anyone know the definitive order of operations (for a 65K/s720 running 12.2(33)SXI5) between CoPP and an rp-inband CPU SPAN session? In other words, if I have a CoPP service policy applied to the control plane (input) that drops all traffic matching a specific class, should I expect to continue to see such traffic appear in the output of a SPAN session of the RP CPU even though its ultimately being dropped by CoPP? 

I've long assumed that a SPAN session of the RP CPU would operate on the 'back-end' of CoPP, and that I should not see traffic show up in a RP CPU SPAN that is dropped by CoPP, but recently have been working to tune our CoPP policies and have noted seeing traffic in an RP SPAN that is configured to be dropped by CoPP. Is this an indication of something wrong with my policy, or would it be expected that I should indeed continue to see the traffic in the RP SPAN because the RP SPAN is capturing traffic destined for the RP CPU *prior* to the application of the CoPP policy? 

For example given the following CoPP configuration: 

class-map match-all CoPP-Important 
match access-group name CoPP-Important 
class-map match-any CoPP-Undesirable 
match access-group name CoPP-Undesirable 
class-map match-all CoPP-Default 
match access-group 2 

policy-map CoPP 
class CoPP-Important 
police cir 1000000 bc 50000 be 50000 conform-action transmit exceed-action drop violate-action drop 
class CoPP-Undesirable 
police cir 32000 bc 6000 be 12000 conform-action drop exceed-action drop violate-action drop 
class CoPP-Default 
police cir 32000 bc 6000 be 12000 conform-action transmit exceed-action drop violate-action drop 

ip access-list extended CoPP-Important 
remark Important traffic destined for RP (Rate-Limited) 
permit udp host x.x.x.x any eq snmp 
permit udp host y.y.y.y any eq snmp 

ip access-list extended CoPP-Undesirable 
remark Undesirable traffic destined for RP (Post-Dropped) 
permit udp any any eq snmp 

control-plane 
service-policy input CoPP 

Should I be seeing traffic showing up in a SPAN session of the RP CPU that shows SNMP traffic destined for the RP that is NOT sourced specifically from host x.x.x.x or y.y.y.y, like this? (source IPs changed to protect the innocent): 

13:09:30.096405 IP (tos 0x0, ttl 128, id 1816, offset 0, flags [none], proto UDP (17), length 107) 
1.2.3.4.28316 > 192.168.0.51.161: { SNMPv1 { GetRequest(64) R=132061 .1.3.6.1.2.1.25.3.2.1.5.1 .1.3.6.1.2.1[|snmp] } } 
13:09:30.096407 IP (tos 0x0, ttl 128, id 1817, offset 0, flags [none], proto UDP (17), length 107) 
192.168.100.10.150.28316 > 192.168.1.184.161: { SNMPv1 { GetRequest(64) R=132062 .1.3.6.1.2.1.25.3.2.1.5.1 .1.3.6.1.2.1[|snmp] } 
13:09:30.096411 IP (tos 0x0, ttl 128, id 1818, offset 0, flags [none], proto UDP (17), length 107) 
10.10.2.5.28316 > 192.168.1.184.161: { SNMPv1 { GetRequest(64) R=132063 .1.3.6.1.2.1.25.3.2.1.5.1 .1.3.6.1.2.1[|snmp] } 

Note: RP Span configured as follows: 

monitor session 1 type local 
source cpu rp 
destination interface Te3/3 

Looking at the policy-map counters, CoPP does appear to be properly dropping (at least some) traffic for the CoPP-Undesirable class: 

core1#show policy-map control-plane input class CoPP-Undesirable 

Control Plane Interface 

Service-policy input: CoPP 

Hardware Counters: 

class-map: CoPP-Undesirable (match-any) 
Match: access-group name CoPP-Undesirable 
police : 
32000 bps 6000 limit 12000 extended limit 
Earl in slot 1 : 
9612708 bytes 
5 minute offered rate 21960 bps 
aggregate-forwarded 0 bytes action: drop 
exceeded 9612708 bytes action: drop 
aggregate-forward 0 bps exceed 21368 bps 
Earl in slot 3 : 
0 bytes 
5 minute offered rate 0 bps 
aggregate-forwarded 0 bytes action: drop 
exceeded 0 bytes action: drop 
aggregate-forward 0 bps exceed 0 bps 
Earl in slot 4 : 
35380464 bytes 
5 minute offered rate 80784 bps 
aggregate-forwarded 0 bytes action: drop 
exceeded 35380464 bytes action: drop 
aggregate-forward 0 bps exceed 79224 bps 
Earl in slot 5 : 
0 bytes 
5 minute offered rate 0 bps 
aggregate-forwarded 0 bytes action: drop 
exceeded 0 bytes action: drop 
aggregate-forward 0 bps exceed 0 bps 
Earl in slot 7 : 
1640 bytes 
5 minute offered rate 0 bps 
aggregate-forwarded 0 bytes action: drop 
exceeded 1640 bytes action: drop 
aggregate-forward 0 bps exceed 0 bps 
Earl in slot 8 : 
0 bytes 
5 minute offered rate 0 bps 
aggregate-forwarded 0 bytes action: drop 
exceeded 0 bytes action: drop 
aggregate-forward 0 bps exceed 0 bps 
Earl in slot 9 : 
1312 bytes 
5 minute offered rate 0 bps 
aggregate-forwarded 0 bytes action: drop 
exceeded 1312 bytes action: drop 
aggregate-forward 0 bps exceed 0 bps 

Software Counters: 

Class-map: CoPP-Undesirable (match-any) 
4 packets, 672 bytes 
5 minute offered rate 0000 bps, drop rate 0000 bps 
Match: access-group name CoPP-Undesirable 
4 packets, 672 bytes 
5 minute rate 0 bps 
police: 
cir 32000 bps, bc 6000 bytes, be 12000 bytes 
conformed 4 packets, 672 bytes; actions: 
drop 
exceeded 0 packets, 0 bytes; actions: 
drop 
violated 0 packets, 0 bytes; actions: 
drop 
conformed 0000 bps, exceed 0000 bps, violate 0000 bps 
core1# 

Is this all completely normal behavior, and its just my expectation that I would NOT see CoPP dropped traffic in an RP SPAN that's incorrect? 

Thanks, 

-- Jeremy