Re: Network Access Control Changes - Firewall and ACL policy changes

["Greg T. Grimes" <greg.grimes () MSSTATE EDU>]

Hi Gary,

MSU has been using the FWSM for 1.5 yrs.  We love ours.  We have 6, 1 for
each 6500 on campus.  Unfortunately we are still using Cisco Works'
Management Center for Firewalls to manage the firewalls.  The new Cisco
Security Manager is very nice and easy to manage and update.  We have a
test environment, just waiting for the new year to get a production
environment up and running.  As for manually changing configs, I do it on
occasion.  And I have never seen any issues with traffic flow.  The best
thing about the FWSMs is that it moves the load of Access Control off of
the switch's processor(s).  We HAD to move to the FWSM b/c our main campus
router/switch was being bogged down by all of the ACL lookups it was
doing.  The load on the 6500s dropped to almost nothing almost over night.
Now we only have ACls for stuff we can't manage via the FWSM (Border
router type stuff).  As the guy who is the primary lead on our firewalls,
I wouldn't go back to ACLs, unless you paid me a lot of money...I MEAN A
LOT!  9-)  Hope this answers some questions.



On Mon, 4 Jun 2007, Gary Flynn wrote:

> Hi,
>
> We extensively use Cisco ACLs for our network access controls.
> Our current method of handling ACLs, that has worked for
> over a decade, is centered around two text files containing the
> security configuration for all our internet and core routers.
> After editing, a perl script breaks out the ACL configurations
> for individual routers and vlans and stores them on a tftp server.
> When an access change is needed, we edit the file, generate
> the ACL configuration files, and reload the appropriate router
> with just the ACL.
>
> The new Cisco router architectures have hardware assist for
> ACL processing. With the new hardware, reloading one of our
> ACLs now results in 20-60 second network outages. For example,
> we've got a 7206 on one Internet connection and a new 7604 on
> the other. Near identical ACL for both. On the old router it
> takes seconds to load with no visible outage. On the new router,
> it takes 90 seconds with network traffic cut off for 60 of them.
>
> TAC tells me the behavior is because it takes longer to load the
> ACL into the hardware than it does to initiate it in software.
> While the new architecture may process the ACL faster and
> eliminate the problem of unwanted traffic during the ACL
> load, it has really messed up our business process. We are
> accustomed to and expect to be able to make multiple changes
> in real time without adverse effects. Generally, we make
> several a day for things like new service deployments,
> troubleshooting, exceptions to our Internet default deny policy,
> quarantining infected computers, and reacting to outside
> malicious activity.
>
> While hand editing the live config is an option in an emergency,
> I don't believe it practical long term due to the complexity
> of an ACL with hundreds ( nearly thousands ) of entries and
> the risk associated with changing the live configuration on a
> frequent basis.
>
> Our Juniper ISG IPS has firewall capabilities and we're
> looking at the Cisco FWSM for the core routers but I was
> hoping someone with that type of hardware already installed
> would comment on their experiences with real-time changes to
> large policies and ACLs during production.
>
> Thanks for any assistance and information.

--
Greg T. Grimes
Systems Programmer
ITS -- Network Services
Mississippi State University
greg () its msstate edu