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

[Pete Lumbis]

I have no idea where the CoPP policy applies but the RP Inband SPAN will be
on the connection between the SP and RP, I believe.

-Pete


On Thu, Sep 22, 2011 at 1:28 PM, Jeremy Reid <jeremy at mojohost.com> wrote:

> 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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>