[c-nsp] reflexive ACL on 6500

[Gabriel Kuri]

We've been using reflexive ACLs on the 6500s for many years, in my own experience I'd recommend against it, unless it's absolutely your only choice. We use reflexive ACLs on the SVIs and it just doesn't scale very well.  You're better off purchasing a couple FWSMs or some real firewalls to get the job done. 

The basic downfall of the reflexive ACLs is that it knows nothing about session state of the underlying protocol (ie TCP session state). The moment you have an infected box or a box port scanning, expect the CPU to spike on the supervisor, while it sits in the Racl Ager process, aging out all the reflexive access list entries. We have the reflexive timeout set fairly low, but most of the time we're still hammered with chatty boxes generating tons of states and the CPU spiking while it ages them out.

In terms of CPU hits, here's been my experience:

- chatty boxes creating tons of unnecessary states spikes the CPU in the RACL Ager process. lately the HP Jetdirect print servers with SLP enabled has given us some grief in this arena (disable SLP on the Jetdirect print servers unless you absolutely need it). for boxes on the outside of the reflexive ACL that your boxes on the inside always talk to (ie DNS servers), save yourself the headache and create stateless entries on the access-lists to avoid unnecessary states to those boxes.

- enabling logging on a reflexive ACL punts it to the CPU (don't log on the reflexive ACL unless you want everything to be software switched)

- depending on the number of vLANs and ACEs for your ACLs, you need to watch your TCAM resources, although on a Sup720 you'd be pretty hard pressed to exhaust them unless you have a lot of entries.

- there seems to be a bug when generating a reflexive ACL on GRE traffic (and perhaps other IP - non TCP/UDP traffic). The GRE traffic doesn't seem to fall into the catch all rule 'permit ip <subnet> <wildcard> any reflect my-reflexive-acl'. for whatever reason we're stuck with creating a separate entry 'permit gre <subnet> <wildcard> any reflect my-reflexive-acl'.


Just my 2 cents ...


-----
Gabriel Kuri | Sr. Network Engineer
Instructional and Information Technology Division
California State Polytechnic University, Pomona
http://www.csupomona.edu/~iit | +1 909 979 6363



-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net on behalf of Michael Malitsky
Sent: Wed 10/29/2008 7:07 PM
To: cisco-nsp at puck.nether.net
Cc: Michael Malitsky
Subject: [c-nsp] reflexive ACL on 6500
 
Hello,

Does anyone have any experience using reflexive ACLs on a 6500?  I am
having trouble finding definitive information as to the manner these are
processed.  One document indicates the first packet of a flow is punted
to the MSFC, the rest are hardware-switched.  Another says that the
first packet of a flow is always punted to the MSFC, while for the rest
of the flow to be switched in hardware, mls netflow has to be enabled,
otherwise it's all software.
For the time being, we don't have a huge load on the box, so
software/hardware path selection isn't causing a lot of grief, but I'd
rather not wait until this becomes a pain point.
In addition, every so often (2-3 months) a particular ACL will stop
"reflecting".  As in the SYN packets will go through, will show up in
the reflected list, but the response packets won't be allowed through.
Only one list (out of a dozen or two) at a time, and not necessarily the
same list every time.  The solution is to remove the list and recreate
it.
We are running a 6509/Sup720 with 12.2(18)SXF.

Any suggestions/experiences appreciated.

Michael
_______________________________________________
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/