On Sat, 3 Jan 2004, Wes Noonan wrote:
> One of the problems that we had when I was working for a company that made
> network performance management tools was dealing with this exact issue.
> Because every packet size is variable in most networks (ATM, etc. are
> obvious exceptions), the impact that many things have on the performance of
> a network device becomes almost impossible to make a general baseline
> statement about, much to the chagrin of the sales force. This is so true
> that Cisco (and most other vendors) typically refer to a set 64K packet size
> in the small print on all of their performance metrics, although this is
Erm, you mean 64 *byte* don't you?
> obviously an impossible number to achieve in the real world.
The idea thing would be to get some averages from the real world, call
that a good metric and do some testing. Some traffic is worse than others
though, so it's good to put some performance suckers in there (multicast
on Cisco anyone?)
> The obvious performance impact on a router with ACLs has to do with the fact
> that every packet now must be processed by the router before it can be
> forwarded. This also requires the router to be able to queue and buffer the
It already is, so the processing overhead is incremental, that's why Cisco
did so much work on access lists and ensuring the switching paths were as
fast as possible even without things like VIP cards. Seriously- adding
permits first for the bulk of the traffic will keep the router singing.
I've had to overcome the "can't put filters on that router" thing for
production routers way too many times- and every single time, when the
rules were sane, the router's CPU wasn't even measurably impacted. Am I
beating a dead horse? Sure! Because it'll make it easier if people
understand that for most routers, IF you do it right, extended access
lists won't hurt it- if they do, the router's seriously underconfigured
anyway- the ACLs won't be the real issue.
> packet during processing. I seriously doubt that anyone could produce
> numbers more accurate than "In my environment, generally speaking" or "in an
> absolutely controlled environment, this is what we saw". I agree with Paul
You can produce some general numbers and a traffic profile that's "good
enoough" to measure with. Traffic like multicast, and traffic *to* the
router will do more to impact performance than stuff you're passing
through it, since those are process switched (AFAIR) and that's where the
real hits come from.
> here though that the when you start trying to do things to the router itself
> you can really see the performance impact some of these other things have. I
> can't count how many routers I have seen reboot when trying to show the
> running config because the router was under too much stress for whatever
> reason (often times BGP routers that are skimpy on RAM).
Yep, I've mandated extended access lists on every border router I've ever
seen, even those carrying full routes and significant traffic, and never
had a problem, but I've seen lots of problems with underconfigured
routers.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
proberts_at_patriot.net which may have no basis whatsoever in fact."
probertson_at_trusecure.com Director of Risk Assessment TruSecure Corporation
_______________________________________________
firewall-wizards mailing list
firewall-wizards_at_honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
Received on Jan 04 2004
Intro
