On 09/22/2011 06:28 PM, Jeremy Reid 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?
CoPP is an ingress QoS policy, run in the DFC or PFC. It should precede
any CPU reception.
You do have "mls qos" enabled globally, right?
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?
Assuming that:
1. The traffic type is one which CoPP drops in hardware
2. The CoPP policy is programmed into hardware correctly
Then no, you shouldn't see CoPP-denied traffic. I've just tested on our
sup720 running SXJ1 and a span of the RP does not see CoPP-denied traffic.
People have reported CoPP "mis-programming" bugs on the sup720 on this
list before; I've never seen it, but you might be able to find something
in the archives.
What does:
sh mls qos ip
...say?
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?
I don't think you should be seeing that traffic; it's unicast UDP with
no special handling, CoPP should process it in hardware before the RP
sees it.
What linecards are you using?
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
