Darden, Patrick S. wrote:
> Paul,
>
> This is an incredibly complex question, that I don't think has an easy answer. Major factors (in *generally* desdending order of importance):
>
> 1. # concurrent sessions (this is more and more important the more your firewall does: layer 3, stateful, packet inspection, app proxy, anti-malware, vpn endpoints, ssl endpoints, etc.)
> 2. bandwidth.
> 3. # rules.
> 4. complexity of rules.
> 5. depth of the firewall--e.g. is it just layer 3 or is it doing application proxying as well? Does it also scan for malware? Even if it is only layer 3 is it stateful, is it doing packet inspection, is it doing protocol sanity checking?
> 6. is it doing encryption, e.g. a VPN endpoint. 3DES takes a lot more cpu than AES. etc.
> 7. you should match the hardware it is running on to the depth of the firewall; e.g. if you are doing app proxying, virus checking, and stateful packet inspection, then you should have multiple CPUs. If your rule base is large and stateful, and/or you are using several services such as VPN and app proxy, then you will need more RAM. Etc.
> 8. is it doing a lot of routing as well?
> 9. Is the hardware dedicated/accelerated in any way--e.g. using ASICS for ROSM, thus making extensive routing less of an issue (e.g. for a WAN firewall with hundreds of networks attached).
>
> My best advice to you is to get a unit and test it in a lab under worst case conditions (take what you have and double it--# connections, # rules, etc.). In lieu of that--over-purchase. You don't want to do a major upgrade and then have to do it again due to performance issues.
[ Belatedly responding - greetings from Florence! ]
I generally agree with the above. However there are 2 other things to
worry about:
- Packet rate. Usually _far_ more important than bit rate ("bandwidth"
above). May be influenced by:
- Ruleset size / complexity
- # of current sessions
- Protocol logic complexity
- Packet rewriting (NAT etc.)
- Connection establishment rate. Especially important for HTTP servers.
Having presided over a large firewall RFP for a Fortune 50 financial, I
can tell you that almost no vendors will disclose the numbers needed to
make a sane sizing decision (64-byte packet forwarding rate, anyone?).
The only way to be sure is to spend too much money (over-purchase) or
test it with your workload in-house. Or negotiate a full credit for an
upgrade with your vendor, in the event that you purchase a unit that is
too small for your needs (this is not at all uncommon, and is a good
idea in any case).
--
Carson
_______________________________________________
firewall-wizards mailing list
firewall-wizards_at_listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
Received on Jul 28 2008
Intro
