Re: Firewall Sizing?

[Carson Gaspar <carson () taltos org>]

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 () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards