>[EMAIL PROTECTED] wrote,
>On the higher-end routers you can compile the ACLs and
>they get processed a little bit quicker. The feature
>is called Turbo ACLs. I haven't had a oppurtunity to
>be around a higher-end router long enough to really
>test them to see how much of a difference it makes.
True. As you suggest, it _is_ important to see if access list
performance problems actually are significant in _your_ context.
Fact, as can be seen from any number of posts on the NANOG mailing
list: providers that exchange large exterior routing tables can't
filter them even if they want to. In general, such providers trust
their peers will already have filtered their provider routes, but are
exposed to someone that hacks their peer network from the inside, or
simply a misconfiguration inside their peer. But, in this context,
we are talking about access lists with tens of thousands of rules.
Processing power isn't always the limitation in working with such
filters. One large provider, who filters extensively, has a bold
warning sign on its main router consoles: DO NOT WRITE MEM/SAVE RUNNING START.
Their access lists exceed the size of NVRAM, and cannot be saved to
it. They MUST keep a small configuration in NVRAM, and then TFTP in
the access lists.
Processors are much faster now than on earlier routers, and
processing power isn't always the problem. Yes, it is sometimes. But
I don't recommend huge amounts of effort to minimize access lists
unless:
1. You regularly monitor CPU utilization and see either a trend
or actual statistics that will take you much above t50-60%
5-minute utilization. There are LOTS of simplifying assumptions
here; it's only a guideline.
2. You are CERTAIN that you have enough outgoing bandwidth that
queueing for the medium isn't a problem
3. You are CERTAIN your processing load can't be reduced by
configuring different switching modes and/or thinking through
carefully that you have the most efficient placement of access
lists with respect to interfaces. In other words, it might
be much better not to have access lists at all on inbound
interfaces, but only on outbound interfaces, because the load
often depends more on the presence or absence of an access list
(and the consequent effect on switching path) than it does on
number of lines in the list.
>
>--- "Howard C. Berkowitz" <[EMAIL PROTECTED]> wrote:
>> >You need to limit your ACLs because the more ACLs
>> your CPU usage will go up.
>>
>>
>> No, the total number of ACLs affects memory but not
>> CPU.
>>
>> The number of lines in each ACL affects CPU.
>>
>> Depending on platform and switching mode, adding
>> access-lists at ALL
>> is the main impact on performance and CPU.
>>
>> But saying you need to limit your ACL's because
>> usage will go up
>> doesn't make sense. If you have a legitimate need
>> for the functions
>> that the ACLs perform, and your CPU isn't fast
>> enough, you need to
>> get a router with a faster CPU. The ACLs are there
>> for a business
>> reason. The only justification for the router is to
>> meet business
>> requirements. There's no value to conserving a
>> resource just for the
> > sake of conserving it.
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
