[c-nsp] PFC3/3B/3C ACL support

[Phil Mayers]

Kevin Graham wrote:
> The "Understanding ACL on Catalyst 6500 Switches"[1] white paper indicates that:
> 
>    All TCP session traffic, except for the TCP
> three-way handshake (SYN,
>    SYN/ACK, ACK) and session close (FIN/RST), is
> handled in hardware 
> 
> ...which makes sense for reflexive ACL's, but is that also true for extended ACL's
> matching TCP flags? The need to punt on these flows for reflexive's would suggest
> that they can be distinguished in hardware and based on 'sh tcam int ...' it would
> seem that there are masks allocated for TCP flags[2] that could presumably be
> leveraged for 'simple' filtering.
> 
> With the convenience of object-group/port-group in SXI, I'm inclined to spend some
> time improving ACL usage on 6500's and was hoping to make them a little more
> correct at the same time.

I'm not sure I understand the question as worded, but:

  1. For reflexive ACLs, I believe (never used them on this platform) 
that the opening & closing packets are punted to CPU, so that the 
"reverse" flow can be installed into and removed from the netflow table.

  2. For other ACLs, matching is in hardware, regardless of whether 
you're matching TCP flags, first/subsequent fragments, etc. unless 
you've got another modifier that requires a CPU punt (e.g. "log")


An easy way to see whether something is hardware or punted is to use the 
tcam commands:

sh tcam interface layer3int acl in ip [detail]

Items which list "permit" or "deny" in the 1st column are hardware 
processed. Most everything else is CPU-processed.