Compaq 117755-003 - ProSignia - 740 Guide de référence rapide

WHITE

PAPER

278A/0497

April 1997

Prepared By

Intranet/Groupware

Solutions Group

Compaq Computer

Corporation

CONTENTS

Introduction

.....................

Executive Summary

..........

Benchmark Tools

.............

NSTL Methodology

of Internet Firewalls

.........

Configuration

........................

Test Bed Setup

.....................

Hardware and

Software Tuning

Characteristics

...............

Hardware Characteristics

.....

Software Characteristics

......

Base System

.......................

Test Configurations

of the Firewall

................

Evaluation of

Results

.........................

Tests results with HTTP

and FTP Transactions

..........

Tests Results

with HTTP Only

...................

Conclusions

...................

Appendix A

....................

Appendix B

....................

Performance Analysis and Tuning of

Raptor’s Eagle NT 3.06 Firewall on

Compaq Servers

As firewalls make their mark as a security measure used to protect intranetworks, it is

not clear what is lost from network performance when security is implemented. Today,

the lack of multi-protocol benchmark tools makes it difficult to determine network

performance through firewalls. Since few tools are available and most are used to

determine http performance, determining the loss of network performance and what

can be done to improve it remains difficult.

This paper looks at performance of firewalls using Raptor’s Eagle NT 3.06 product on

Compaq servers, and the popular protocols ftp and http. It answers questions about

the level of hardware needed to address capacity planning, software tuning

parameters for the system and firewall, and what to expect in performance gains and

losses while incorporating a secure environment for internet connections.

WHITE PAPER (cont.)

278A/0497

NOTICE

The information in this publication is subject to change without notice.

COMPAQ COMPUTER CORPORATION SHALL NOT BE LIABLE FOR TECHNICAL

OR EDITORIAL ERRORS OR OMISSIONS CONTAINED HEREIN, NOR FOR

INCIDENTAL OR CONSEQUENTIAL DAMAGES RESULTING FROM THE

FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL.

This publication does not constitute an endorsement of the product or products that were tested.

The configuration or configurations tested or described may or may not be the only available

solution. This test is not a determination of product quality or correctness, nor does it ensure

compliance with any federal, state or local requirements. Compaq does not warrant products other

than its own strictly as stated in Compaq product warranties.

Compaq, ProLiant, and SmartStart, registered United States Patent and Trademark Office.

Netelligent and ProSignia are trademarks and/or service marks of Compaq Computer

Corporation.

Other product names mentioned herein may be trademarks and/or registered trademarks of their

respective companies.

Microsoft, Windows, Windows NT, Windows NT Advanced Server, SQL Server for Windows

NT are trademarks and/or registered trademarks of Microsoft Corporation.

Eagle, Eagle NT 3.06, and Raptor are trademarks and/or registered trademarks of Raptor Systems

Inc.

NSTL makes no recommendations or endorsement of any product. This data was prepared by the

client using licensed testing products from NSTL. NSTL does not guarantee the accuracy,

adequacy, or completeness of the services provided in the connection with the clients product.

NSTL MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO RESULTS TO BE

ONTAINED BY ANY PERSON OR ENTITY FROM USE OF THE SERVICES OR THE

RESULTS THEREOF, OR ANY INFORMATION OR DATA INCLUDED THEREIN NSTL

MAKES NO EXPRESSED OR IMPLIED WARRANTIES OR MERCHANTABILITY OR

FIRNESS FOR A PARTICULARPURPOSE OR USE WITH RESPECT TO THE SERVICES

AND/OR RESULTS TEREROF, OR ANY INFORMATION OR DATA INCLUDED

THEREIN.

Firewall Performance Tuning

First Edition (April 1997)

278A/0497

WHITE PAPER (cont.)

278A/0497

INTRODUCTION

The intent of this paper is to help answer questions about performance of firewalls so that logical

decisions can be made for capacity planning using Raptor’s Eagle NT 3.06 firewall product. A

base line for a specified firewall system is defined, options are added to the base line, and the

load differences and performance are evaluated. This base line is used to determine how each

configuration change affects the performance of the firewall from the base line system.

This paper starts by describing different benchmarks available, gives a definition of the

methodology chosen for the tests and the test bed setup, describes the rationale for determining

performance characteristics used in the test, explains test cases based on the characteristics, and

evaluates the results.

EXECUTIVE SUMMARY

This paper uses the NSTL software benchmark methodology to test firewall performance on the

Eagle NT 3.06 firewall. A base line test is run and individual hardware and software components

are added to the base system and the differences are evaluated. Variable hardware and software

components modified in the tests include memory, bus architecture, drive controller, network

speed, Raptor’s Eagle NT 3.06 HTTP Cache and DNS Lookup switches, the firewall rule base

with 100 rules, and NetFlx-3 MaxRecieve buffers.

From the sets of test run, the following performance summary resulted:

• For hardware configurable tests, upgrading the Network Interface Cards from the EISA bus

to the PCI bus achieved very noticeable increases in performance.

• The processor scales well with two processors, making dramatic increases in performance as

the load increases.

• Adding memory increases performance slightly as the load increases.

• Network throughput also increased when changed from a 10Mb network to 100Mb network.

The firewall was able to process more than 10Mb worth of data through the firewall with

both HTTP/FTP and HTTP only transactions, with large loads, and showed expected

decreases with normal loads on a 10 Mb network because of higher collision rates.

• Software configurable tests with HTTP Cache on, resulted in increased performance in both

HTTP/FTP and HTTP only tests.

• Tests with the DNS Lookups for HTTP switch turned off, displayed high performance

increases for greater loads on HTTP Only tests.

• Differences between HTTP/FTP and HTTP only transfers showed increased results for

HTTP only transfers, highlighting the added performance enhancements included in Raptor’s

Eagle NT 3.06 firewall product for HTTP.

BENCHMARK TOOLS

The popular benchmarking tools available today are used to test webserver or system

performance only. Webserver benchmarks can generate loads for static web pages of varying

sizes, test webserver processor performance using CGI or ISAPI/NSAPI loads, and calculate the

transaction times, throughput, and connections per second. Most benchmarks use a control station

for gathering and reporting load data and starting virtual client sessions. Although these

benchmarks determine performance and load capacity for webservers, they do not exercise the

WHITE PAPER (cont.)

278A/0497

variability of multi-protocol loads through gateways/firewalls. Multi-protocol benchmarks allow

firewalls to be stressed in ways, which closely simulate real network traffic. Of the four

benchmarks described below, NSTL’s Benchmark enables two protocols to be used, HTTP and

FTP, which are the two most used on the Internet and thus the tool used to test performance of the

firewall in this paper.

WebStone

Webstone measures the raw throughput of a standard HTTP workload. It is measured across two

main variables--latency, in seconds, and the number of connections per second. Other data can

also be collected, such as throughput in bits per second. The benchmark itself uses a client/server

architecture, and each client runs a configuration file that tells it which server to connect to, how

long to maintain the connection, and which URLs to fetch.

WebBench

WebBench reports two types of results: the average number of requests per second the HTTP

server handled, and the average number of bytes per second that moved between the clients and

the server. The controller computes these results by collecting each client's results as that client

finishes the test.

SpecWeb

SpecWeb measures the response time for server requests across a number of different workloads.

It sends HTTP requests to the server, based on defined workload parameters, and calculates the

overall throughput at the end of a run. The workload information that the benchmark takes into

account includes request rate and request type, file set, database transactions, security, and slow

networks.

NSTL Benchmark

This benchmark was designed specifically to stresses the ability of the firewall to route traffic

based on a set of rules. It simulates real usage of the firewall by directing heavy loads of FTP and

HTTP traffic through the firewall. The toolkit also allows WAIS traffic and CGI requests to be

sent. The results are measured in overall transaction time for each client data transfer for a set of

virtual clients. This is then broken down into TPM (Transactions per Minute) based on the

number of URLs and FTP files requested.

NSTL METHODOLOGY OF INTERNET FIREWALLS

This section describes in detail the NSTL methodology used for the tests and the alterations made

to the methodology to allow more traffic to pass through the firewall.

Configuration

The NSTL methodology was designed to stress the ability of the firewall to route traffic based on

a set of rules. Heavy loads of HTTP and FTP traffic are generated for requests through the

firewall. The overall transaction time for each client transfer is measured and reported under

various load conditions. The original methodology used three scenarios for measuring

performance through the firewall. Together, the three scenarios did not provide an effective

challenge to the firewall, so changes were made to NSTL’s benchmark configuration to allow

more traffic to pass through the firewall from both sides.

WHITE PAPER (cont.)

278A/0497

This scenario, described in more detail below, is the scenario used in the benchmark tests for this

paper. Performance ratings for the test runs are calculated from individual performance scores for

the number of virtual clients used in the tests. Performance ratings are then translated into

transactions per minute. This rating reflects the speed at which the firewall system processes

network traffic, as it performs security tasks based on the security rule set.

The security model that the NSTL Methodology uses specifies security zones, security rules, the

protocols used in each security rule set, and logging. The benchmark creates load through the

firewall by establishing multiple virtual clients on each physical client machine in each security

zone. A control client is used to send requests to each physical client that dictates the number of

virtual clients it used and gathers, from the virtual clients, the transaction information used to

calculate the transactions per minute. (See Figure 1)

Inside Outside

Figure 1:Test Bed Configuration

Three areas determine security zones:

• Private Zone - the secure area of the network or the area protected from the Internet with a

firewall. Internal networks reside in the private area.

• DMZ - the network area unsecured by the firewall. Usually Internet servers are located here

such as Web Servers, News Servers, DNS Servers, FTP Servers, etc.

• Hostile Zone - or public area, is the cloud of the Internet or the outside network.

NSTL’s benchmark can be run with the three zones implementing three network segments or

with two network segments. When two network segments are used, the DMZ and the Hostile

Zone are combined. This is the setup selected for performance evaluation of Raptor’s Eagle NT

3.06 contained in this paper.

Transaction refers to the amount

of time it takes to open a

connection from the client to the

server, request data from the

server, download that data from

the server to the client, and

closing the connection from the

client to the server. Transactions

are measured in Transactions Per

Minute. (TPM)

WHITE PAPER (cont.)

278A/0497

The security rule set contains the following rules using FTP ports (20,21), HTTP port (80)

protocols:

• Private to Private, Private to Hostile, and Private to DMZ - Allow All

• Hostile/DMZ to Private - Allow only to specified servers.

Logging affects the firewall throughput; therefore moderate logging is used. This logs all

connections, spoof detection messages, TCP syn/fin messages, and connect rejection messages.

The test methodology uses 6 virtual servers from 3 physical servers and 1 to 72 virtual clients on

8 physical clients. Virtual clients are administered from one of the physical clients known as the

control machine. Each virtual client makes 100 request for FTP GET and HTTP GET transfers to

the 6 virtual servers. HTTP/CGI requests were also available but not used because HTTP/CGI

requests could skew the totals due to web server processing of CGI requests.

Percentages used to determine the amount of traffic the virtual clients send to the virtual servers

is a configurable item for the methodology. For configurations used in test runs contained in this

paper, each virtual server receives the percentages of HTTP and FTP requests from the virtual

clients as listed in Table 1.

Servers % FTP requests % HTTP requests

server01, server03, server05 10 90

server02, server04, server06 90 10

Table 1:Test Bed Protocol Percentage

Server requests percentages are the same for all sets of virtual clients used. Also, the setup places

server01 and server02 in the Private Zone and server03 through server06 in the DMZ/Hostile

Zone. This setup follows the procedures used in previous NSTL tests.

The amount of requests per virtual client is also configurable. In practice, using 100 requests per

virtual client and using up to 72 virtual clients produces a good load on the client systems and

pushes a high amount of traffic through the network. Therefore, using 72 virtual clients was

adopted as the maximum number of virtual clients used in the test runs. In all test runs (eight per

hardware configuration), the number of virtual clients was 1, 12, 24, 32, 36, 48, 60, and 72. This

approach in the number of virtual clients used shows how the firewall reacts under progressively

heavier loads. The percentages of servers that are hit from each of the physical clients are also

configurable items as presented in Table 2.

Clients server01 server02 server03 server04 Server05 server06

client01 -

client05 2.4% 2.4% 23.8% 23.8% 23.8% 23.8%

client06 -

client08 40% 40% 5% 5% 5% 5%

Table 2:Percentage of Servers hit by Clients

The file types used for transactions for the benchmark were ZIP files for FTP transfers and

HTML and GIF files for HTTP transactions. The sizes of the files for FTP are 32, 64, 128, and

256 kilobytes. HTTP file sizes, with one directory depth, were 1, 2, 4, 8, 10, 20, 40, and 80

kilobytes for HTML files and 512 bytes, 1, 2, 4, 10, 26, 52, 104, and 208 kilobytes for GIF files.

All files were automatically generated using the NSTL configuration toolkit.

WHITE PAPER (cont.)

278A/0497

Using NSTL’s two-zone configuration (private zone behind the firewall and DMZ and hostile

zone in front of the firewall), two physical servers are located in the DMZ/hostile zone and one

physical server is located in the private zone. Physical client configurations place the control

station between the two network segments (client01), four clients in the private zone (client02

through client05), and three clients in the DMZ/hostile zone (client06 through client08). Having

the control station between both network segments allows data to flow across both networks with

no interaction with the firewall, thus simulating real FTP and HTTP network traffic. Also, the

control station is used to gather transaction time information and send virtual client load

information to the physical clients on port (2001). Please refer to Figure 1 for a pictorial view of

the testbed.

Test Bed Setup

Table 3 describes the hardware and software for the clients and web servers used in the test bed

setup. All clients and servers are connected to a 100Mb network except for one test set, which

connects clients and servers to a 10Mb network. Network configurations are discussed in the

section Hardware and Software Tuning Characteristics.

Machine Hardware OS Software

Client01 ProLiant 2000, 2-

Pentium/90, 64 MB RAM, 2

EISA NetFlx-3 10/100 NIC,

ON BOARD SCSI, 2 GB

Drive

Windows NT

4.0

Workstation,

Service Pack 2

NSTL Firewall

Benchmark Software

for client machines,

NSTL controller

software

client02

client08

ProLiant 2000, 2-

Pentium/90, 32 MB RAM, 1

EISA NetFlx-3 10/100 NIC,

ON BOARD SCSI, 2 GB

Drive

Windows NT

4.0

Workstation,

Service Pack 2

NSTL Firewall

Benchmark Software

for client machines

server01

server06

ProLiant 2000, 2-

Pentium/90, 32 MB RAM, 1

EISA NetFlx-3 10/100 NIC,

ON BOARD SCSI, 2 GB

Drive

Windows NT

4.0 Server,

Service Pack2

Microsoft IIS 3.0

configured with FTP

and HTTP

Table 3:Client and Server Hardware Makeup

Eagle NT 3.06 Firewall Setup of Base System

The hardware and software setup for Raptor’s Eagle NT 3.06 firewall starts with a base system

configuration. Modifications are made to hardware and software on the firewall to determine

performance differences from the base system. Determinations can be made at this point about

how the firewall handles different configurations. An explanation about differences in the

configurations and the reasons why such configurations were chosen are discussed in the section

Hardware and Software Tuning Characteristics.

This section discusses the hardware and software requirements for a base system configuration. It

also shows the configuration of the Raptor Eagle NT 3.06 firewall using the GUI to the firewall

(Hawk) and concentrates on the configuration items that do not change for all test runs.

WHITE PAPER (cont.)

278A/0497

Table 4 shows the hardware and software makeup of the firewall for the base system.

Machine Hardware OS Software

firewall01 ProLiant 5000, 64 MB

RAM, 1-Pentium PRO

200/512K cache, 2 EISA

NetFlx-3 10/100 NICs, PCI-

Smart-2 Ctrl, 1-2 GB Drive

Windows NT

3.51 Server,

Service Pack 5

Raptor’s Eagle NT

3.06 firewall software

and Hawk GUI.

Table 4: Firewall Hardware and Software Makeup

Firewall configuration with Eagle NT 3.06 starts with DNS setup. The network segments for

Inside and Outside used the network addresses 10.10.10 and 11.11.11 respectively and the

domain was set to testbed.com for both segments. This information was configured from the

Gateway screen File->Set up DNS... menu option.

Two files: HOSTS and HOSTS.PUB located in the

%SYSTEMROOT%\SYSTEM32\DRIVERS\ETC directory are created with DNS changes when

saved. The HOSTS and HOSTS.PUB files correspond to DNS names for inside and outside hosts

respectively. Outside DNS queries are done on the HOSTS.PUB file and inside DNS queries are

done on the HOSTS and HOSTS.PUB files. The HOSTS and HOSTS.PUB files for the firewall

setup are listed in Appendix A.

Since access is allowed from the DMZ/Hostile network to the private webserver for benchmark

testing, configuration for the private webserver is done through the Gateway screen File-

>Set up HTTP... The physical server holds the address of 10.10.10.8 and is assigned

the DNS names of server01 and server02 to create two virtual servers. Port 80 is used for both the

inside port of the webserver daemon and the firewall gateway. Please refer to Screen 1, the HTTP

Setup screen.



Screen 1: Http Setup

Names given to network segments, hosts, groups, etc. are configured in the Net Entities

screen. Rules can be applied based on names, once the network entities are configured. Inside,

Outside, Server1, Server2, and universe are names for network entities needed in the firewall

configuration. Please refer to Screen 2 for configured network entities.

WHITE PAPER (cont.)

278A/0497

Screen 2: Network Entries

Eagle NT promotes transparency of IP addresses, meaning the only IP address the DMZ/Hostile

zone can see is the outside interface of the firewall. Specifically, FTP transfers from the outside

to the inside must first be connected to the firewalls outside interface, the FTP username becomes

Error! Reference source not found., and the password becomes the password for FTP at the

FTP server. More authentication may be required by the firewall depending on the rule set. HTTP

transfers from the outside to the inside must be directed to the firewalls outside interface. If an

inside HTTP server has been configured as in Screen 2, the firewall checks the rule base to ensure

that traffic is allowed to pass, then makes a connect request to the Web server. The client on the

outside sees only the destination and source IP addresses of the outside interface of the firewall in

the IP packet header. This technique is similar to address translation, except in an application

firewall such as the Eagle NT 3.06, you get this feature for free.

Finally, the rules are configured to allow access from Private clients to Private servers, Private

clients to DMZ/Hostile Servers, and DMZ/Hostile clients to specified Private servers. The

convention of Inside and Outside mapping to Private and DMZ/Hostile was used. Also, note that

specific rules must exist for access from the DMZ/Hostile network to the private network. Refer

to the Screen 3, the Authorization screen.

FTP setup is also done at the Authorization screen. All rules have the FTP GET check box

selected.

WHITE PAPER (cont.)

278A/0497



Screen 3: Authorization Rules

Alert Thresholds track the number of times a particular client has connected through the firewall

in a given time period. For the purposes of benchmark testing, this feature was disabled so that it

would not skew transaction times.

HARDWARE AND SOFTWARE TUNING CHARACTERISTICS

In order to determine the affect in performance of the firewall system, software and hardware

changes were evaluated and compared to a base system. Only one software/hardware

configuration change at a time was made from the base system to determine the affect it may

have. Since only one change is ever made to the base system for every benchmark run, decisions

can be made to change firewall configurations in order to increase performance. It also allows

those decisions to be made based on sets of individual configuration changes, since multiple

individual changes can lead to higher performance than one individual change.

This section discusses hardware and software characteristics used in the benchmark tests. It also

describes in detail, how to make the configuration changes in hardware and software so it can be

referenced at a later time.

Hardware Characteristics

The various hardware options used in the tests are described below. Each hardware configuration

change made was re-configured using the Compaq system partition utilities found by pressing the

F10 key during the system bootup process.

Processor

Processor MHz

Pentium Pro

Uni and Dual,

200, 512KB cache

Pentium Pro 200, 256KB cache

Pentium 133

Pentium 120

Autres manuels pour 117755-003 - ProSignia - 740

Ce manuel convient aux modèles suivants

Table des matières

Autres manuels Compaq Serveur

Compaq

Compaq ProSignia 200 Guide de démarrage rapide

Compaq

Compaq DL760 - ProLiant - 1 GB RAM Manuel d'installation et d'exploitation

Compaq

Compaq N2400 - TaskSmart - 1 GB RAM Mode d’emploi

Compaq

Compaq ML350 - ProLiant - G2 Instructions d'utilisation et de sécurité

Compaq

Compaq ProLiant DL380 G2 Instructions d'utilisation et de sécurité

Compaq

Compaq 2500 - ProLiant - 64 MB RAM Manuel utilisateur

Compaq

Compaq DS20E - AlphaStation - 1 GB RAM Manuel utilisateur

Compaq

Compaq 231027-002 - ProLiant - DL320R01 Guide de référence rapide

Compaq

Compaq 108164-003 - ProLiant - 800 Guide de démarrage rapide

Compaq

Compaq BL10e - HP ProLiant - 512 MB RAM Manuel utilisateur

Compaq

Compaq DL760 - ProLiant - 1 GB RAM Guide d'installation

Compaq

Compaq ProLiant 400 Guide de référence rapide

Compaq

Compaq ProLiant 8500 Guide de démarrage rapide

Compaq

Compaq ML370 - ProLiant - G3 Manuel

Compaq

Compaq 6400R - ProLiant - 1 GB RAM Manuel

Compaq

Compaq 108164-003 - ProLiant - 800 Guide de référence rapide

Compaq

Compaq ProLiant ML350 (G2) Manuel utilisateur

Compaq

Compaq DH-64BAA-AA - AlphaServer - ES40 Manuel utilisateur

Compaq

Compaq DL360 - ProLiant - Photon Guide de référence rapide

Compaq

Compaq 234664-002 - ProLiant - ML330T02 Manuel utilisateur

Compaq

Compaq 112726-001 - ProLiant - 6500 Guide de référence rapide

Compaq

Compaq ProLiant 1000 Manuel de l'opérateur

Compaq

Compaq ProLiant 400 Instructions d'utilisation et de sécurité

Compaq

Compaq 234664-002 - ProLiant - ML330T02 Instructions d'utilisation et de sécurité

Manuels Serveur populaires d'autres marques

HP AlphaServer ES47 Manuel utilisateur

Dell

Dell PowerEdge R410 Manuel utilisateur

PowerNAS

PowerNAS CMA Manuel utilisateur

Supero

Supero FatTwin F617R3-FT Manuel utilisateur

MSI

MSI P1-109N-L70 Manuel utilisateur

Dell

Dell PowerEdge XE9640 Manuel

Dell

Dell PS4100 Instructions de montage

EtroVISION

EtroVISION EV3151 Manuel utilisateur

NEC

NEC Express5800/T110j Manuel utilisateur

HP ProLiant Gen9 Manuel utilisateur

Dell

Dell PowerEdge 3YPMN Manuel utilisateur

iRobo

iRobo IPC2U Manuel utilisateur

Nortel

Nortel 1000 Con?guration guide Manuel utilisateur

Asus

Asus AP7500 Manuel d'utilisation et d'entretien

Avid Technology

Avid Technology AirSpeed 5000 Manuel utilisateur

HP Integrity rx2600 Guide d'installation

Milestone

Milestone Husky IVO 350T Manuel utilisateur

Planet

Planet NAS-7410 Manuel utilisateur