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