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

[Tóth András]

Hi Jeremy,

By doing a "debug snmp packets", do you see the SNMP requests from the
non-allowed host? If CoPP is working correctly, you should not see
them as they are dropped in HW.

Best regards,
Andras


On Thu, Sep 22, 2011 at 7: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/
>