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
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
